Please bear in mind that these are college students in a learning environment and are not subject to the same conditions as a developer would if they worked in a commercial setting (like the fear of getting fired if you screw up or having more than six weeks to create a game using technology that you have never used before). Also, none of us ever worked in any kind of professional development environment as programmers.

Tuition isn’t cheap and we all had a simple motivation to succeed on this project to make a game that may not have been revolutionary but, could improve our probability of getting employed somewhere.

FireLine is about facing an enemy that doesn’t think or feel. The enemy isn’t subjectively targeting you. Instead the enemy is a force of nature. The object of FireLine is to halt the wildfire’s advance before the entire forest is consumed by deploying Firefighters by ground and Smokejumpers by plane. If the fire consumes 90% of the forest’s trees and shrubs (fuel), you will lose the game. If you extinguish the advancing wildfire completely before 90% of the forest (fuel) is consumed, you will be victorious!

It was suggested that if we could make a game that would cause an XBox 360 console to self-immolate we would automatically pass the course.

We had t-shirts made for both of our class development teams.

What went right?

We (all six of us) made a game for the XBox in about six weeks using technology that we had not used before. Some of us had used different versions of XNA Game Studio before and only one of us had experience using Blender, which our graphics programmer insisted on using instead of Maya. After some unsuccessful attempts to program audio in XNA, our audio programmer took a book I found (“XNA Game Studio 4.0 Programming Developing for Windows Phone and Xbox Live” by Tom Miller and Dean Johnson) and learned how to use the XACT tool for XNA Game Studio.

The graphic art and textures turned out great. I asked for multiple variations and versions for the art required and then everybody got a chance to cast a vote for the logos, menu design, user interface art, icon design and graphic art used. The music and sound turned out great as well.

As with the art, I asked for multiple iterations of sounds, music, and composites. Instead of our group deciding the sounds, this time I sat down with our composer/sound designer/audio programmer (he’s only one guy) and made the decisions on which sounds would best convey the overall feeling of the game’s atmosphere. Choosing sounds the are unquestionably distinguishable as rock slides, fire crackling, blowing wind, aircraft flyovers and explosions were central to the selection. We were fortunate that all of the original music was usable and we set up the XACT wavetable to cycle through the different music loops randomly. Almost everyone has said that the music gets stuck inside their heads.

After several setbacks our graphics programmer delivered beautiful particle-based fire effects that didn’t crash every platform we put it on. They are beautiful and somewhat realistic.

Our user interface integrated fairly smoothly into the project along with individual instructions and controls menus for PC and XBox 360.

When it came down to finally integrating the 3D graphics into our project at week five of six, we hit a massive bug. For some reason, the terrain graphics for the rocks were not rendering on screen but, the preview suggested that they were there. Our audio, graphics and two main programmers (including myself) pulled together and spent the better part of a week trying to find and fix the problem. The contingency plan accepted by the a majority of group members was that if we couldn’t find the problem by the middle of week six, we would replace the rocks with 2D textures. Our audio programmer, who has professional testing experience, found something that indirectly pointed toward the problem. Our graphics programmer went and found the problem. Apparently, our rocks graphics were rendering underneath our game environment.

Despite having to remove about 40% of the intended content as covered in the original game proposal and in the early draft of the development documentation, we successfully created a 3D game using XNA Game Studio 4.0 for the PC and XBox with six weeks of coding time and two weeks of testing. We also avoided causing the XBoxes to explode into flames.

For some reason, something  happened during upload and messed up the “Complete” screen. Here is a screen capture of it:

When you win the game, this is what it looks like.

What went wrong?

FireLine is missing graphics assets for aircraft and ground units. Instead of having CGI animations for the group units, we have a group of three unanimated models represent the firefighters that creep along across the gamespace toward a target. Our 3D graphics programmer was overly perfectionistic and spent about four weeks of our six week development schedule perfecting our tree models and animating their gradual destruction by fire despite being told that he needed to move on to creating the fire animation, air and ground unit animations, rocks, water, grass and headquarters graphics. He became preoccupied with trying to produce top level graphics with absolutely no time to do it in. While the grass and rocks and headquarters models along with the water animations and the aforementioned trees and crude ground units were eventually delivered, the fire presented a serious problem.

Then, he went and spent the weekend jet skiing instead of coding.

Once the first graphics were ready to be delivered, our graphics programmer was unable to do so because he did not upload the assets to DropBox like everyone else on the team did. Instead, he wanted to connect directly to his home computer, that was a two hour commute from campus. As it turned out, his computer was turned off and he could directly connect with it. At that point several of us wanted to directly connect our fists to his face. But, I digress.

One week of testing was lost because of the new particle-based flames that crashed everyone’s computer during our testing phase because the particles had no population limit or life span and simply kept being generated until all available memory was consumed. When asked about whether or not the graphics programmer and lead programmer tested the graphics before we handed off the game for testing, the resounding answer from both individuals was evasive at best. It took one week to fix the problem which should not have been integrated into the project to begin with without preliminary testing.

Of course the question should be asked, “were was the project manager in all of this?” Answer: I was in the parking lot walking to the classroom. At first I was thrilled that they were taking initiative to get things in order before class started so we could have as much time as possible to find all of the bugs and get in some solid development time but, as the computers began to crash all around us, my hopes were dashed.

The particle-based fire animation was not the first misstep but, was (thankfully) our last mix-up in a series of mistakes that first began at the top of the second week of our development cycle.

At our very first meeting, we talked about our backgrounds and sought to play to our strengths as developers. The person who would eventually become our lead programmer would have simply been an ordinary programmer if he had not assured us that he knew how to program the tiled gamespace and randomize the tiles to create unique game experiences for nearly instance. He also used language that suggested that he had attempted making an real-time strategy game before. We would eventually discover that neither of these things were true. We liked what we heard though, I made him lead programmer and we agreed that he should begin work on a “Hello World” project and then move onto making a simple 2D gameboard with tiles that could be randomized while I began to adapt my game proposal into a design document. Before we went home for the weekend, I check on the lead programmer’s progress and told him to e-mail me over the weekend if he finished before the weekend was up and needed to know where to go from there.

The next week, we came back to class to hear that our lead programmer had decided to surprise us and “finished the game over the weekend.” Once seeing the code in it’s rough unfinished state with no comments or documentation and with several of its main functions missing, we realized that the game wasn’t even close to being “finished.” He had rejected the development document almost entirely.

It was two weeks down on the development cycle, four more weeks to go before two weeks of testing.

In my daily rounds of talking to my team members to mark their progress, our audio programmer and artist asked me how the project was going. I tried my best to re-assure them that we were going forward as best as we could and then our audio programmer said the word that had been running through my head continually for the past week, “triage.” Yeah, it was all triage at that point. There was no more time left in our development cycle so we opted to try fixing the code we were left with. I sat down and reworked the design document, removing two-thirds of the content and cutting back the game’s functionality by about 40% in order to ensure  that we could deliver something that would be considered a success.

We were now stuck at week three with a partial game in it’s early stages that had rejected it’s principle game dynamic. Instead of having tiles with several environmental properties (originally two or four), the each tile represented a single individual property. As a result, each game would only last about two to three minutes long, success or failure could be predicted fairly easily by the player in the minute of game play.

As it turned out, our lead programmer would spend nearly two weeks on pathfinding algorithms, rejecting help and advice from his fellow team members, ignoring our instructor’s suggestions for help. In doing this he rejected my thirteen months of research into sprites and crowd flow pathfinding that worked in favor of a brand new solution that took two weeks to develop that restricted flow of movement and caused more memory problems that we would have preferred.

We tried our best as a group to figure out his code with and without his help but, to no avail. After week four, with still no documentation or heading blocks detailing his work, we realized that the more that we asked him for his help in understanding his code the less we understood it and the less time he had to get it to work right. So we let him alone.

The use of the mouse to select and control units on screen was rejected entirely because our lead programmer told us that they would be too complicated to get working. Reminding him that there was more than one person on the team who could program changed very little.

Other aspects of the game were hampered by his obsession with prime numbers: instead of using numeric values that would be of pertinence to the game itself, he used numbers that had no logical correlation at all. The result was a gamespace that was often too small in one direction or too large in another.

We also had communications issues. Yeah, I know, big surprise. The lead programmer refused to answer our e-mails. His code was written incomprehensibly. He named constants with variable names like, “ARBITRARY_SIZE.” “Arbitrary” is a synonym of “variable”. Just because the person is planning on changing the values of the constant throughout the course of development (which is a given) does not mean that you give your constants variable names, rejecting object-oriented programming standards. This was not just a one-time concurrence, this was found in different places throughout the program.

During our second and final week of testing we found out that our lead programmer had decided unilaterally to change FireLine’s final user interface to one previously unseen, change the font to an Asian-inspired font called “Jing Jing” that distracted from the game’s overall design more than it helped, and selected a menu screen splash image himself.

Visual art was very important on this project and originally we each had a say in what went into the game. By the time we saw these gawdy changes to the art, and in our exasperation wanted the game finished already.

Then came the final insult. We put a lot of effort into creating and integrating the menu, credits, controls (PC and XBox 360) and instructions screens. Our lead programmer failed to program a way for the player to access the screens. I guess the stress finally got to him and he began to blame people for his own short comings. He asked me rewrite the text of the instructions specifically because they were not of any help to the player. I retorted that the instructions were of no help to the player because the player never got to read them because they never were presented an opportunity to access them to start with.

This angered him like nobody’s business.

In all fairness, I’ve never read Tolstoy’s War and Peace. The instructions that I wrote are by no means a comparison to an acclaimed Russian novel but, let’s face facts here: if I have never read War and Peace should that be a reason to rewrite it? I don’t think so.

If given more time, what would we do differently?

I would restore the removed content: aerial water bombers would be implemented; smokejumpers would not detonate their explosives on landing instead, the player would choose when they could get to deploy their payload and possibly get more from supply drops; a wind current and thermal current system would blow planes and smokejumpers off target and move the fire in different directions; explosions would affect aerial units; make every tile have at least two (four at the most) different terrain/fuel properties to increase the complexity of the game.

I would also try implementing mouse controls for the PC version.

Conclusion

When someone says that they know how to do something on a project, insist that they show you reliable evidence upfront and take any opinions from people who have worked with him in the past (or their instructors) with caution and measured optimism. Have your programmers talk about what needs to be in the game on a programming level, before they decide to do the obligatory “Hello, World” program. When your lead programmer shows up and tells you that he has “finished the game over the weekend” despite having read only the game proposal and not the actual development document, sit them down and ask them to explain themselves. If they don’t talk to you, figure out what needs to go in the game yourself and send it to everyone on the team – especially if you are the project manager. One monomaniac with a much-lauded reputation as a game developer can turn out to be the bad apple that ruins your chance to make an interesting game. Self-taught graphics programmers don’t always know how to meet deadlines because they learned in an environment without deadlines or supervision. Perfectionism can lead to a serious loss of development time that could be better spent on another aspect of the game’s development. Know your limitations and don’t see asking for help from someone as a sign of weakness or defeat. Collaborating with other people creatively is a great way to mitigate tunnel vision and preserve a project’s creative vision but, only if all of the team members engender the project’s ultimate goal over their own egos. A development team is for developers. If you want to be a rock star join a band.

Data Box

FireLine

Development team: 6 developers

Budget: None. We were students. Our instructor ordered pizza for us once.

Conceived: Early 2010

Development time: 8 weeks

Total development time: approximately 15 months

The release date of the game: June 23, 2011

The platform: PC and Xbox 360

Hardware used: Hewlett Packard PC, running Windows 7, Nvidia graphics card

Software used: XNA Game Studio, XACT, Blender, GIMP, DropBox, Paint.Net

Size of the project: 30 files (separate files for Xbox 360 and PC versions), approximately 500 GB

If enough people “like” the page I might post some screenshots.

The object of the game is to halt the wildfire’s advance before the entire forest is consumed by deploying Firefighters by ground and Smokejumpers by plane. If the fire consumes 90% of the forest’s trees and shrubs (fuel), you will lose the game. If you extinguish the advancing wildfire completely before 90% of the forest (fuel) is consumed, you will be victorious!

Units

Firefighter (Basic)

The Firefighter is the basic unit in FireLine. This unit charges forward to it’s assigned target and extinguishes any adjacent fire automatically within a one tile radius of itself. Once the Firefighter extinguishes the fire, they light backfires, creating fire lines to contain the remaining fire thereby, consuming all available fuel for the fire. Once their assigned task is performed they can be redeployed by selecting an idividual unit and selcting a different target. Firefighters are deployed by ground only.

Smokejumper

Smokejumpers are specialized firefighter units. Because they are a specialized unit, their respawn time is slower than basic Firefighter units. Smokejumpers are deployed by parachute directly to target area and utilize explosives to “blow out” the fire in the landing zone and clear trees and underbrush. By blasting fuel and oxygen from the flame and consuming oxygen in the combustion, fuel for the fire is removed. Once the explosives detonate, the Smokejumpers become basic Firefighter units (see Firefighter (Basic)). Deploying Smokejumpers by plane is faster than deploying basic Firefighters.

Pro-tip 1: Be warned that the Firefighters do not know fear and will charge through fire if ordered and may die while doing so.
Pro-tip 2: Place a Firefighter near water to have them regenerate their health.

NOTE: Feedback is essential. If you you see something that doesn’t make sense, let me know!

Tile:

• has a fuel, fire and obstacle property
• once fuel property is depleted, tile becomes ash (contains no fuel or fire)
• contains grass, trees, water, headquarters (1)

Obstacles:

• rocks that can be avoided
• dealt with as a tile property instead of as an actual sprite object

Water:

• similar to an obstacle but, can give a health buff to firefighters
• dealt with as a tile property instead of as an actual sprite object

Firefighter (basic firefighter unit):

• path-finding ability
• spawns from headquarters
• timed re-spawn: able to re-spawn every 30 seconds
• should be able to “extinguish fire” (gradual reduction of fire property) from a tile – reduction rate is up to the programmer
• can remove a tile’s fuel value below 50% (building a fireline)

Smoke jumper (advanced firefighter unit):

• path-finding ability
• spawns at selected drop zones
• timed re-spawn: able to re-spawn every 2 minutes
• becomes a “normal” firefighter unit upon landing
• detonates explosive charge reducing fire and fuel properties of tile they are “dropped” on (fuel by 30% , fire by 40%)
• should be able to “extinguish fire” (gradual reduction of fire property) from a tile – reduction rate is up to the programmer
• remove a tile’s fuel value below 50%

Fire:

• can only exist on a tile where fuel is available (fuel property above 50%)
• reduces fuel property while increasing fire property until all fuel is consumed – reduction rate is up to the programer
  
• cannot exist on ash tiles or tiles that have water
• can exist on tiles with rocks
• “spreads” to adjacent tiles (ignites other tiles) when 90% of a tile’s fuel property is consumed
• randomly generated explosions that kill nearby firefighters

Firefighter Victory Scenario:

• fire is extinguished while total fuel of the map is greater than 0%

Game Over Scenario:

• fire consumes 100% of the map’s total fuel

Music:

• coding will be added where needed
• multiple iterations and variations on themes are encouraged

Art and GUI:

• multiple iterations and variations on themes are encouraged

Advanced Game Objectives to be Implemented

Purpose:These things are only to be added if we have enough time. There are not vital but, might make the game a bit more interesting.

Wind:

• random wind currents will determine which tile the fire will spread to next
• can blow Smoke jumpers and Fire bombers off course

Fire bomber units:

• spawn at headquarters
• timed re-spawn: able to re-spawn every 5 minutes
• must fly to a ground target
• reduces fire property by 50%
• subject to explosions (fire-based)
• can be destroyed by thermal currents
• can be blown off course by wind

Thermal currents:

• can destroy Smoke jumpers and Fire bombers
• exist only in a swirling pattern over fires

A Wildfire-fighting Real-Time Strategy Game

Description / Overview

Fireline’s setting is a forest where the player deploys various forest fighting units (firefighters, fire/water/borate aerial bombers, explosives, smoke jumpers). No specific characters are controlled by the user only the fire-fighting units available to the authorities. Firefighter will be the game’s main unit with the other units listed above being on a rotating availability list. The main focus of the game is to put out the fire before it spreads (as represented by the wildfire spreading to the entire game space map. This game is unique in that it is a real-time strategy game where the user must fight an enemy which is devoid of character, remorse, personality, motivation and physical form that you must “kill” that doesn’t intend to kill you and doesn’t care if it does or not. The game’s point of view will be ¾ view. The size of the game space will either fit the screen or will extend beyond the available edges of the screen and be accessible by North-South-East-West scrolling. The game is intended to be single player and will play on the Xbox.

Detailed Analysis

• Real time strategy fire-fighting game
• Stop the wildfire before it consumes everyone. No scoring system; win or lose only.
• Contain and extinguish the wildfire before it reaches the outer edges of the map
• Deploy various fire-fighting units to combat the wildfire, support other units while never going outside of the map borders.
• 3D, ¾ view square or rectangular map with borders with 2D and 3D art assets.
• Player will use the mouse to select the location for unit deployment as well as menu options.

Characters

Firefighter ground units will walk to the fireline and once deployed, will follow the fireline as it moves with the wildfire. Smoke jumpers will be air dropped onto ground positions after which time they will become regular ground units (firefighters). Explosives teams will be directed initially to specific areas. Once there payload is depleted, they will become regular ground units (firefighters). Aerial units (fire/water/borate bombers) will follow airborne deployment and withdrawal trajectories chosen by the player.

Obstacles

Ground units will have to move around fire (when not trying to fight it) and boulders or mountains. Bodies of water can provide relief to ground units. Thermal currents and exploding trees can destroy aerial units.

Levels and Extensions

• Map Editor

Sound and Music

• Nothing annoying or invasive

Media and Installation

• Xbox DVD or Live Arcade

Major Milestones in Development

• Creating the 3D ¾ map placing a sprite on it and getting it to move.

When I posted my previous piece, Brayden Olson’s company was called “Novel Conception”. He has since graduated from Seattle University, been mentioned in an article in Businessweek magazine, changed the name of the company to “Novel Interactive” around May, moved into a new office space at Gas Powered Games, changed the company name again in October to “Novel Incorporated” and taken his new game in a somewhat different direction than World of Warcraft or Asheron’s Call. The Novel Incorporated team took some inspiration from Puzzle Pirates and decided to use the Persistent Browser-Based Game (PBBG) model for their “first-of-its-kind new massively multiplayer game for release in the U.S., France, Germany and South Korea.”

“Our games have no levels, no grind and are about more than just combat. Our first product is a game, our second is not.” – Novel-Interactive.com

Media courtesy of Novel Interactive.

On May 26, 2010, Novel Interactive launched the website for their upcoming game Empire and State. The overview on the website informs us that the game is “inspired by the freedom and scale of games such as Ultima Online, Asheron’s Call, and Alpha Centauri”. In light of previous information divulged regarding their first game, it could be conjectured that the Puzzle Pirates and PBBG model influence may be along the lines of in-game alliances, economies and monetizing the game itself. However, IGN revealed on October 1, 2010 that this was not the method of monetization Novel, Inc. will be going with.

Media courtesy of Novel Incorporated.

In IGN’s Empire and State Preview, it was revealed that Novel, Inc. was developing a browser-based massively-multiplayer real-time strategy game (MMORTS) taking inspiration from Civilization V. The “social strategy MMO” will consist of ten cities, “populated with player-run stores of varying level and function. One may take raw materials and process them into something useful, like turning logs into planks, or take these more useful materials and create weapons and items that players need. You can’t, we’re told, do both. …These businesses will also serve as a source of ‘quests’ for players.” Empire and State will include an electoral system described as “interesting”. Players will campaign for elected offices and other players will vote. Travel is an available option by way of a series of hexes (as it is in Civilization V), with moves regenerating over time. Characters can eventually create a party of drones (“robots who act as characters”) and travel the world. “Combat is stat-based and will use dice-rolls to figure out who wins, and how much damage is dealt”. Game play for city-mode will resemble Sim City. The player-driven economy of Empire and State integrates microtransactions with actual real-world money, “which will be used to buy player-made in-game advertisements” for political campaigns, wanted posters for political rivals, or advertisements for your store.

IGN’s “interesting” description of Empire and State’s electoral and economic model sounds exactly like the one in eRepublik which is not even as well-realized as the beta release of Virtual Nations. Empire and State’s combat mode sounds similar to eRepublik’s recently introduced Military Module which also included a pattern of hexes. The module itself was discontinued due to the overall contempt that it garnered from it’s users due to it’s slow PvP timers and economic cost (Note: wars cost money). The monetization model may still have the same in-game economic problems as eRepublik’s gold-based economy. When someone can get ahead by buying in-game items, resources or currency the end result looks a lot like real-world inflation. In-game ads will only be bought if they generate meaningful results for the player. If you advertise your business, it should result in increased sales. Nothing is mentioned regarding how players would gauge their progress by buying ads for guile and self-aggrandisement. Hopefully, Empire and State will feature competitive advertising rates that fluctuate with the in-game economy and ban currency purchasing through microtransactions.

So far, it would appear that the most dramatically original feature of Empire and State will be cities beautifully realized in 3D, based on atmospheric concept art.

Sign up for their alpha testing here.

Shedding light on the other non-game-related intellectual property, Olson has said, “‘I look at Novel as being a leader in the future of virtual reality…If we can help businesses with simulations, it can put us in position to be at the cutting edge of R&D.’”

Sounding like the reverse of the company depicted in the Jason Reitman film, “Up In The Air” (that is, a contractor that specializes in firing your employees), XEconomy.com writer Gregory T. Huang states:

“Here’s what that might look like. A company might evaluate its prospective employees’ leadership and teamwork skills by having a group of job candidates enter a game-like computer simulation where each person controls a virtual character. The simulation would present the group with various management problems, or other business situations. By watching how each person performs and interacts with others, the company could potentially learn more about them than it would in a run-of-the-mill interview. And if done right, it could be more time-efficient as well.”

Final note:
eRepublik has accumulated a fiercely loyal following of around 250,000 active players over nearly four years with publicity. It was developed by two programmers in Madrid, Spain.

Virtual Nations has a loyal following of over 2700 citizens in less than a year without publicity and is yet to begin monetization. It was developed by one programmer in Australia.

As you can see, the instructions state that Up Arrow key is no longer "Move Upwards" it is now "Jump Up".

In this case, Direct X Sprite flipping is not like flipping or vertically inverting textures where a person would use texture coordinates and swap the left and right or top and bottom coordinates. If you are using the DX Sprite class (ID3DXSprite), this will not work with a DirectX 3D Sprite since it has Vector3(X, Y, Z) coordinates in a DirectX 9.0c Draw() method.

Using a negative width for the texture region and rotating by 180 degrees was one option for me but, the former only made the program crash and the latter had no effect.

I made the Scale property’s X-value negative ( Scale = new Vector2(-1.0F, 1.0F) ) to flip and the Rotate property 250 (degrees). Why 250, I have no idea. (If used any number lesser or greater than 250, my sprites would get narrower and narrower until they disappeared from view.) Then to flip back, I just change the Vector2 back to its original state.

When resetting the sprite, be sure to have an original copy (Vector2 initialScale) or else DirectX will do things to your sprite when beginning a new game without restarting the application.

The Player can throw a pineapple (East-to-West in this case) and then run back to a safer distance (West-to-East as shown here).

Jumping was accomplished fairly simply. A jump cycle iteration is engaged when the player presses the Up Arrow key, moving the player sprite higher up the screen until it achieves a pre-determined distance (a constant integer in this case) which is then followed by another iteration that moves the player sprite downward. The Jump() method does not interfere with any East-to-West or West-to-East movement that I can tell.

What went right with my project.

The player sprite’s punching action animates smoothly. The scoring system works smoothly. I am content with how the Win and Lose screens have turned out. The overall game play pleases me. I fulfilled the Course Project requirements.

Food Fight was realized as a “Third-Person Eater” instead of the originally intended first-person since our instructor never got around to teaching the subject. The “hunger meter” came about by a truly happy accident. I was trying to place the pineapples on screen in order to keep score on the “hunger meter” when I found that the pineapples began to “fly” off the screen. At that moment, I made a two-fold discovery. On one hand, I saw what was wrong with the “hunger meter” and on the other hand, I saw how I could allow the player have an autonomous projectile weapon that could traverse a vector independent of the player. In other words: I figured out how to launch pineapples at an opponent and allow the player to move afterward instead of keeping the player stationary until the the weapon sprite terminates. I managed to get the game sounds implemented in DirectSound and the controls implemented with DirectInput successfully. I attribute the game’s smooth performance on the fact that code is now executed when needed instead of having nearly every game condition (as well as nearly every line of code) checked each time a key_down event is triggered (as is was in Late-Night Deathmatch). Since eight sprites can reside on screen simultaneously and nearly all of them have their own separate collision detection and lifespan requirements. I am quite pleased with how their implementation turned out. As I was short on time, I reused the background and player sprite graphics from Late-Night Deathmatch with a few cosmetic alterations instead of creating all-new graphics. I list this as something that went right since it allowed me to focus on the programming task at hand which was far larger that the project’s need for original art.

What went wrong with my project.

The player can not jump properly. Players do indeed have the option to throw food at their opponents however, I never was able to get around to programming the food sprites to be either “inedible” to the player after it is thrown but, “edible” to the opponent. The weight and size of the food in relationship to it’s effectiveness against an opponent was never implemented. The choice of having the Killer Lemon Meringue Pie as the game’s opponent instead of an eating champion was made because simply because I couldn’t figure out how to make an artificially intelligent human opponent. I knew how to make a finite state machine that could pursue a enemy one moment and flee them another. I admit, a killer autonomous flying dessert is a bit strange but, it’s size and ability to float around allowed the game to be at least somewhat challenging. The challenge offered by the opponent ends immediately upon it’s “death” as the pie doesn’t regenerate. I would like to have better control over the player sprite animation since it should only animate when the player is throwing something.

Many of these shortcomings exist because my original game proposal was built around a very simple truth: I devised Food Fight as a project that could be completed in the time allotted that could be made bigger or more polished depending on how many people worked on the project or less so depending on how few. The class was supposed to model a game studio and we would develop a project (or projects) as a group of developers. It didn’t turn out that way. My proposal didn’t interest anybody but me and I was left to work independently like most of the students in the class.

How I would extend my game.

I would allow the player to be able to throw multiple independent projectiles (pineapples) and to be able to turn in the direction that it was traveling in. I would also allow the sprites to jump. I don’t believe that the edible/inedible properties and weight/size properties would not greatly impact the quality of the game itself and don’t wish to pursue them. I have the basis of a game and I think that time would be better spent trying to fine tune the game’s dynamics to make it more challenging.

Fortunately, I had all Summer to solve those problems and get help from some friends from class as I finally decided to join the club I helped to found: The Game Developers’ Club of Edmonds C.C.