Pollinator, Flower Defence: Post-Project Reflection

It's been too long since I talked about my game for the Abertay Game Development Society: Pollinator, Flower Defence. The game was in a demo-able state for the last month and a half, seeing as we brought a build to the GDS showcase at the end of April. However, it wasn't running properly outside of the editor - we were having huge problems with the animated sprites scaling to gigantic proportions.

I'm glad to say this has now been fixed (albeit with a slightly hacky fix) and we now have a web version of the game available for everyone to try out! The game is located on my dropbox for now, since it's still just a prototype. If we continue work on it, we may try hosting it somewhere more permanent.

The Premise

For those who haven't been following this project: Pollinator, Flower Defence is a tower defence game in which you play as a group of bees defending their hive from attacking ants and beetles. It twists the genre slightly since you can freely move your bees from flower to flower - however they cannot attack while being moved and do not generate pollen or seeds while being moved. Additionally, players can build two separate "parts" for each tower - the flower (blocks movement, provides place for bee) and the bee itself (attacks, can be moved between flowers, generates resources from flower).

Difficulties

Developing this game was not without it's problems. First was simply the lack of time to devote to the project. We had a very small team (one programmer, one designer, one artist) and we all had our other coursework to work on. Additionally, two of the team members were going through Dare applications as well. Because of this, many of our grand plans couldn't be implemented - but luckily we recognized this from the very beginning and planned for modular development where we started with a minimum playable game and added more features time permitting.

On the technical side of things, I had more trouble than I was expecting using the Orthello 2D framework. It does everything I needed it to do, but sometimes it doesn't do it in the most intuitive fashion. We also had some serious issues with it's animated sprites resizing themselves to giants, which ultimately was fixed using rather hacky Update() size changes - not my best work, but a quick and dirty fix that did the job.

Design wise, the project did suffer from the lack of additional features. The two resource design (pollen and seeds) would have been interesting if there were more things to spend said resources on. As it is, it's actually quite boring because basically you just want to spend all your resources as fast as possible and there's no interesting choices between building flowers vs. building bees since their resources are de-coupled. The seed/pollen mechanic may also have been more fun if we'd gotten in the pollination feature - bees would carry pollen between flowers when moved, and only then produce seeds (or increase rate of production, at least).

There are also a few informational parts of the game we just didn't have time for, such as a how to play screen or tutorial, prices for the bees/flowers, and a credits screen. These are fairly easy to make and may be added in the near future.

Future Plans

Ultimately, this was a great initial project for the team. While we do hope to come back to the game and improve it (I really love a lot of the mechanics and interesting enemies Roy had designed that didn't make it in), I'm not really sure we'll have time for this. I have so many awesome projects in the pipeline now that this may be the last we see of Pollinator. This game will always have a special place in my heart because its first incarnation was the first video game I ever created. But I think it may be time to close this chapter and look forward to new and exciting things.

If any updates do make it in, I'll definitely write about them here! For now, farewell my buzzy bees. It was great fun!

You can play Pollinator, Flower Defence here: https://dl.dropboxusercontent.com/u/11838203/Pollinator/Portfolio_Web.html

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.