I have a new image with new art assets. I am still working on figuring out generation of cars within a row. The rows are still being generated semi-randomly. The appearance is that the cars appear to be on a timer. I am still trying to figure out a fun way to generate cars. The current method is changing a set of magic numbers to fine tune harder or easier sets of cars. Overall, I feel we have a fun toy and have met our challenges for the week.
On Tuesday, 09/24/2013, in Rapid Prototyping class we were introduced to our new team and new project. We are taking games from 1978-1983 and reinventing them. The game my group decided on reinventing was Frogger from 1981 (http://en.wikipedia.org/wiki/Frogger). We are writing the game in HTML5.
My team members are:
Sean Moody – Producer
Shelwin Cheng – Engineer
Skip Fowler – Engineer
Vinod Madigeri – Engineer
Joe Rozek – Artist
I took initiative to divide the workload. The partitions in the engineering workload we made were level, player and obstacles. Today Shelwin came in with working players that can move in four directions. I put the obstacles in today which spawn randomly on their row with collisions that send the player back to the start. Vinod placed the background behind the level. Joe finished the some chicken art today which looks really good! Sean has set up a Trello and is managing group progress which is happening really fast.
Overall, I think I am learning a lot from this experience. My team is working well together and we have had some great successes. Our successes will allow us to push farther as we reinvent the classic game Frogger.
We finished our first prototype cycle in rapid prototyping. The learning curve was relatively steep. I am certain the reason for the steep learning curve was to help us understand some key concepts including how to juggle projects, work under time constraints and interface with other professionals.
The concept for the design of our first prototype is a navigational puzzle game. The responsibility of the player is to help animals get to the ark. Animals are autonomous doing animal things and require leading through devices that force the animal to move in a new way.
We succeeded in delivering a prototype that shows off our idea of a navigational puzzle game. We learned that navigational puzzles are fun, but should be predictable with no randomness. We learned that scope, communication and planning are very important in a game project. I will now include some screenshots including our post-mortem. I need to figure out how to post video.
Engineering challenges for the project included learning LUA and MOAI, figuring out how movement mechanics should be designed, loading .csv files for a map editor for our producers and interacting with a team of other people. Let me address each of the challenges individually.
First, learning LUA and MOAI was entertaining. I have worked with LUA in the past as I attempted to write add-on’s for the World of Warcraft interface. All my work in LUA prior to this project had been unfruitful however. LUA seems to be a strong solution for rapidly prototyping projects, but has some issues regarding scoping, typing and concurrency. MOAI is a strange SDK. The problem may be that MOAI is an extension of LUA and brings out some of the underlying weaknesses of LUA. A specific example of problems in MOAI is thread safety for MOAIProp2D:seekLoc. I ran into situations where multiple calls in the same thread would send props in crazy unexpected directions. I know that MOAI has delegates that indicate the progress of an operation, but should these delegates be placed in a global table for each individual thread? My solution was to give up on constructs and datatypes that I didn’t understand.
Second, we had a great idea for a navigational puzzle game. We felt like it would be unique and provide a challenge that could be accomplished while waiting in line perfect for mobile games. The problem came when we tried to decide how animals would move about the board. There were five members on our team and we had five different versions of how the mechanics actually worked. The ideas I heard included animals moving in a turn based manner simulating real time by moving at different rates executing in their own thread using timers, animals all moving at the same rate taking individual turns, animals moving in complete real time similar to Starcraft and some sort of pinball game. We finally decided late in development that animals would move at the same rate taking individual turns. The appearance was real time, but we had to use nefarious solutions including a busy loop to slow down execution enough to see animal movement.
Third, the engineers developed two separate versions of the grid. We thought this might be a good idea. We both ended up developing .csv importing for maps. The main point of this paragraph is that having a map editor gave our producers work to do designing levels for the game. It allowed us to showcase four well designed levels at the final presentation.
I built my own grid system without looking into the MOAIGrid system. I am grateful for this development however since it appears that MOAIGrid created problems for other teams trying to handle events and specific movements. My grid required a lot of math which also made me really excited. I spent time doing algebra allowing me to convert from Cartesian coordinates of (X, Y) to (Row, Column) to one dimensional array index in a completely one to one manner.
Fourth, interacting with a team of graduate students has been harder than the teams I have worked with in industry. A possibility is that the motivation is different. When working with a team in industry people are motivated to deliver the product and keep their job. The expectation is that the product will be finished as soon and bug free as possible. We weren’t able to start full scale development on the mechanics until the third week. That means over 50% into the project we started working on the key feature of the game. My experience tells me that developing key features that late in a project is a recipe for failure. I need to take responsibility for not managing the engineering side of our first prototype effectively. In the end the lack of effective management resulted in heavy crunch time preventing my fulfillment of preparing a presentation for game design prior to the day of the presentation.
Overall, I learned a lot working on this project. I spent a lot of time working on getting the project to the final pitch as did all the members of my team. For the next project I am going to gather requirements faster and push the engineering team to work in short sprints with a working product at the end of each sprint. The goal is to allow assessment of the product before we are over 50% into development and missing the mark.
I forgot to include images of the prototype. I am happy with the art direction that Tyler Ricks, our teams artist, chose when developing the art for the prototype. Please enjoy the images below. I blew them up a little, so they are slightly stretched.
I will stop using the index header. The title “Graduate School” is being used to indicate that I now feel I am adjusted to the rigors of my graduate study. I am now looking forward to future success.
I have had more to do recently as coursework has progressed. I have been writing papers for game design. Next week my three person team in game design will be giving a presentation on game design and war. I am interested in the military entertainment complex. I am excited about the amount of research and development going into creating better military simulations. The research and development then spills over into new and innovative games in the commercial sector. During the presentation I would like to address war on the internet. I took an introductory class in the mathematics of cryptography and may provide a “game” for the class in the form of solving a simple RSA related decryption problem.
In rapid prototyping our first prototype is due next Tuesday. The prototype my group developed has a number of successes. I will now try to define the prototype. The game is targeted at mobile devices. Players solve navigational puzzles by getting animals to a ramp. The player is required to get all animals to the ramp in order to finish the puzzle. The grid is a map of terrain features. Each of the five animal types has a preference for certain types of terrain features or other animals. Players employ tools in order to solve the puzzle and get animals to the ramp. At the core of the game is a spirit of navigational puzzle solving. Neat engineering features of our prototype include a level editor, a behavioral system for the animals and a customized grid system that adjust to the size of the device or window being used. The experience has given me a better understanding of how to organize design mechanics and prioritize engineering goals.
In my C++ course we have started working on a Vector3 class. If I find time I would like to add the transformations from my introductory linear algebra course. I am excited to begin work on my Vector3 class for my game engine.
At home I am trying to juggle my commitment to school and my family life. I am currently at school on Monday and Friday from ~9 AM to 6 PM and on Tuesday, Wednesday and Thursday from ~9 AM to ~9 PM. The new schedule is different from my schedule over the past two year studying mathematics where I was often home working on yet another proof. I need to spend more and better time with my wife on weekends to make up for all the time I am putting into school. Writing about this topic has given me the idea that I will do one thoughtful act for her every day. I will try this and report next week.
The transition from being an undergraduate in mathematics doing undergraduate research to being a master’s student in Entertainment Arts and Engineering has made me realize differences. The work required for classes is less structured. By less structured I mean that there is not a specific problem set on which to work. Indeed, even my mathematics research provided more structure since propositions were directly provable and provided more questions. Today I spent the morning and afternoon reading on game design.
Ideas such as “fun” and “game” are not concrete and offer little in the way of a formula for construction. Instead my readings have directed me that when I produce a game I am developing a particular experience that people willingly engage in to achieve a rewarding objective. The problem with definitions like the one offered in the previous sentence however is that they fail to encapsulate all of game development, design and play.
In development news I have created a grid system that changes size dynamically to fit the current environment in LUA using the MOAI SDK. I have also created a boundary system between cells in the grid allowing the artist a region to show transitions between cells more easily. In addition I have produced tools to allow map generation using comma seperated value files which means our producers can create content using Excel. I will be polishing the aforementioned developments with a current target of delivery by Friday.
The C++ Programming course is starting to gain momentum. We have been tasked with creating a game about movement entitled “Monster Chase” using C++ without STL. We are to separate the game and engine code. The engine is to be compiled as a static library and linked into the game. I have started work on this project and feel I can finish before Friday.
Therefore I am delivering two projects Friday. I am delivering a grid system with a map editor (.csv) that can be used by my teams producers to generate content prior to the behavioral system being added. I am delivering a working version of “Monster Chase” for my C++ programming class. By reaching this objective I will be practicing better management.