Creating a PS2 Game: Post-Project Reflection

It's been a while since I've talked about my PS2 project for my consoles class at Abertay. Now that the project is finished, I'd like to look back and see what I've accomplished, what I could have done better, and where I'd like to go from here.

Title Screen for Pyroteknix

The Premise

As I mentioned in my design blog post for this game, I wanted to create a game all about putting on a fireworks show. I decided in the end to name the game Pyroteknix. In this game, the player controls a cannon which can shoot fireworks into the night sky. More specifically, they control a crosshair which the cannon rotates to point to, and which fireworks will target and explode on.

Gameplay for Pyroteknix

An audience watches the show below. Each audience member has a mood (indicated by their facial expression), which contributes to the points gained by each firework. A firework gains points for each audience member which sees it (based on the firework's x position on the screen and it's range), modified by the audience member's mood. The audience members' moods drop naturally over time, but are increased by seeing a firework. Therefore it's important to spread the fireworks out across the sky to keep all audience members in high spirits. If any audience members get upset, they will leave. If all audience members leave, the player loses.

In addition, each firework has a cost associated with it. The player is given a set budget at the beginning of the show, so they must space out the fireworks over time. The show has a set time limit, counting down and displayed to the player throughout the show. The player must balance keeping the audience happy, gaining points, and not letting their budget run out.

Technical Details

Working with the PS2 was an interesting experience. We could not use an IDE, so it was back to Notepad++ and a linux-based g++ compiler. In a way, this was refreshing - I really like Notepad++. But, I'd found I'd grown very fond of tab-complete for my class methods and data members, and missed that quite a lot. Additionally, working with the makefile setup we were given was frustrating, but I lacked the makefile know-how to fix the situation. Essentially, the makefile wouldn't detect .h file changes, and wouldn't recompile based on them, but wouldn't throw errors for things referencing stuff changed in the .h file, and so I got horrible crashes for no apparent reason. This also resulted in a need to reboot the PS2, which took around five minutes each time. Compiling was also quite slow, which was frustrating.

Another huge technical frustration came from working with the vector unit code. This was all assembly level stuff, which for those not code-inclined means very low-level stuff where you are literally moving memory around inside the processor to do calculations. It is NOT my kind of programming, and it was like pulling teeth. I thought what I wanted to do (a cel shading style) would be easy, but despite working on it for a full day I never figured it out, and ended up giving up on the vector unit code altogether. I still managed a very good mark on the project due to my other clever use of the system and a very nice framework.

Now on to technical successes. I was able to re-use the framework I've been using in my DirectX project, since I completely encapsulated all the graphics stuff. This was really useful and let me get a lot done very quickly, and looked quite professional to boot. It included support for screens, game objects, and particle systems. Since particle systems were very important for this game, I spent a lot of time making sure they looked nice and billboarded correctly. I wasn't 100% happy with the results but I think they were well enough for the time period allotted for this project.

I was also able to manage the display of graphics in such a way that optimized the texture buffer use so it was changed as little as possible, while still encapsulating all the graphics code. In addition, I had to edit a lot of the provided framework's graphics synthesizer instructions to allow for transparency and 2-D image rendering.

Finally, I was able to get in some decent effects to really pull off the cannon firing. I added sound effects for the cannon fire itself as well as a whistling as the firework went up. I also added both a screen flash (simply rendering a white texture over the scene for one frame) and a rumble feedback when the cannon fires. This made the game feel much more visceral and was great feedback for the player.

Future Plans

While I feel like what I managed to do with the restrictions imposed by the time frame and platform was pretty good, I would have liked to do a lot more with the project. Different kinds of fireworks, combos, audience requests, higher audience expectations later in the show (finale), and some kind of overdrive mode where you can shoot fireworks off for free - these would all be awesome features to add. I think this game concept is actually pretty strong and hasn't really been done much that I've seen, and I'd like to bring the concept to a mobile platform. I think it would suit touch controls very well, and it's shiny, fun style would do well with a mobile audience.

I'm not sure when I'll have time to work on this, but it's definitely going in my bank of "things I'd like to make". I'd call the project as it is a successful proof of concept and a great learning experience.

Creating a PS2 Game - Designing the Game

Last week, I settled in on an idea for my PlayStation 2 module project. In case you missed the previous article, the project is to create some application for the PS2 which uses the controller for input and the vector processing unit to render graphics. The better it takes advantage of the PS2 hardware, the higher a mark I will receive.

Today, I did some more thinking on the idea and have decided to tweak it a bit. Originally I was planning to make a shooting game where the player controls a cannon shooting things flying through the air. I wanted to try a cel shaded style, though, so I thought I'd make it cute. Today I was sitting in class and realized that shooting fireworks instead of missiles would be a lot more playful and match the art style better, and could actually lead to some really interesting gameplay.

I then spent the next few hours figuring out how to make a game about putting on a fireworks show. I've decided to call the game "Boom!" for now.

The Premise

The player controls a cannon that shoots fireworks into the sky above a watching crowd. The player can choose the firework color by moving the right analogue stick. Each of the four main buttons fires a different type of firework.

The main goal of the game is to keep the crowd happy during the performance, while carefully managing the number of fireworks used - each firework costs money, and the player only has a limited budget to work from. This means using all the fireworks up front will leave the rest of the show empty, and the audience will leave in disgust. The gameplay comes from choosing what fireworks to fire, when, and where to fire them.

Here is a graphic showing all of the elements of gamepay. Ignore the terrible art and the clutter of the screen - I wanted to get as much on there as possible just to show how everything works.

Concept for Boom! gameplay

Pacing

Choosing the pace at which you shoot will be a very important part of gameplay. In the lower left corner of the screen, you'll notice there is a blue and yellow bar. This is represents the length of the show. In the blue sections, the audience is expecting a slower pace, and will be patient with longer times between fireworks. In the yellow sections, they expect a faster pace. If too long goes between  nearby fireworks, their happiness will drop - and it will drop much faster during the yellow sections.  The player will have to ration out their budget to keep the audience happy.

Location

Everyone wants to be able to see, so the player must make sure to spread fireworks over the whole field. Fireworks higher in the air have a larger range. Clouds appear and can block audience view, and must be dispelled by a firework. Leave a cloud too long, and it might start raining! Fireworks placed on top of each other give fewer points.

Combo

The player can string together certain types and colors of fireworks to create combos. For example, the player could use colors together to make the flag colors for the country the show is set in. Other combos might simulate shapes (flowers), explosions (three flash-bang style fireworks at once combo called "Bombs bursting in air"), etc.

Bonuses

The player will get a bonus if they fill audience requests. Occasionally an audience member will ask for a certain type and/or color of firework. Sometimes, several will get together and ask for a combo. Filling these requests generates bonus happiness and points. There will also occasionally be rainbow rings in the sky - aim your fireworks here for bonus points.

Progression

Difficulty can be changed, which changes the budget available and the patience of the audience. Different stages can be selected, which changes the city in the background, audience preferences and standards, available budget, and firework costs.

Audience Happiness

Each audience member has its happiness evaluated based on how recently a firework has gone off near them. Audience emotions range from the following values:

• Very Happy: High increase in points per second, bonus for fireworks seen.
• Happy: Small points per second, bonus for fireworks seen.
• Unimpressed: small negative points per second, normal score for fireworks seen
• Unhappy: medium negative points per second, no score for fireworks seen
• Angry: high negative points per second, no score for fireworks seen. After a short time as angry, audience members leave the field.

If all audience members leave, the level is automatically lost. There may be other loss conditions, as well, such as having a low enough score at different points or having a low enough total crowd happiness.

Fireworks Types

There are four types of fireworks that can be purchased. Using the same firework type over and over reduces it's effectiveness until it hasn't been used for a while (similar to the bonus system at the end of a song in Rock Band).

• Flash+Bang: Very cheap, but lacks color so can't fill most requests. It doesn't last long but has a high range due to it's bright and loud explosion.
• Shooting Star: A wide trail going up followed by a few colored sparks. Medium price, long life, short range, colored.
• Crackler: Loud, colored bloom, followed by crackling white sparks. Medium life, medium range. High price.
• Traditional: Huge, colored bloom. Longest life and range, very expensive.

Finale Mode

Filling requests also fills up a meter (which will be displayed on the cannon itself). Once the meter is full, the player can press a button to go into Finale Mode. In Finale Mode  for a short time the player can fire fireworks without worry about budget. There is still a fixed fire rate, but this allows the player to recover if the audience was getting upset. It's best saved for high audience expectation moments, but can be used to get the player out of a pinch at any point in the show.

Going From There

That's a LOT of features, and I almost certainly won't implement them all in my PS2 module game. However, I am thinking of taking this game to other platforms, possibly just building it in Unity. I like the idea a lot and I think it's fairly simple in execution. I'm looking forward to working on it!