Developing ARGOS—Triumphs—Michael Lutz
Early in the Fall Semester for COSC469, I was recalling my own experiences of two past C# (XNA) projects in the previous Spring Semester. For one class it was fortunate scheduling, as I tended to be on campus earlier—on several occasions this allowed me to observe the future COSC470 class that I’m taking next spring. It was a sneak peak at finished games. One Unity game had me recall the previous summer when I was experimenting with the engine…just trying to understand the workflow from a programming and design perspective. I explored features, considering parts of future game ideas without really “making anything”—it was more of a creative exercise for learning’s sake. Then in the past Spring Semester’s Frontiers of Game Design, Processing really clicked with me. Fast-forward to COSC469 and I’m trying to decide…pick a project, form a group, join a group, something new? I joined a group of people I haven’t worked with before, Wayne, Alex, Arielle and Thomas. The concept was relatively new compared to recent seminar projects—those considered in the semester and on the occasions I was a guest for presentations for the final seminar classes. At the same time, the concept planned to use Processing, the program and features I was familiar with from the previous semester. Initial concepts considered mobile development, but to get the prototype running we focused on getting a computer version working. The general idea is a navigation game where the player proceeds through a building with the aid of 3D “maps” activated on reaching specific locations—follow a route from place to place and if you arrive at them all in time you win, gaining time upon arriving at a correct place. Here is where the small scope of the game was useful. There were two important elements to make the game. There was the camera which represented the player’s view. Next there were symbols to represent the locations in the building. By interpreting the camera information, the program looks for the symbols and then displays the maps as 3D models. After that, expand the proof-of-concept so it is more like the game concept. Processing had various libraries which could extend the basic abilities of the program by using existing behaviors. This took care of accessing the camera and displaying the models. This eased initial development of the important secondary features, allowing me to get the gameplay running ahead of schedule allowing other team members time to tweak the appearance and offer input on behaviors of the game. Then I created an empty structure for the “menu” system, with just placeholder text and timer values. I’m becoming more of a virtual designer now, but at the time I wasn’t one at all, so I asked for mockups on some occasions. Around this point Alex and I worked to integrate the starting screen, instructions, the main game screen, win and losing screens based on Wayne’s designs. That worked really well because then I virtually just dropped Alex’s appearance code into the screen sections to have the working system.