Green Eggs and Plan
(So, I meant to post a proper plan about my new game a few days ago. I actually thought I had, but when I came back to check on my blog, I couldn’t find it anywhere. I figure it must’ve been lost in the awful internet void somewhere along the way. Because I’m fantastically lazy, I’m not going to re-write what I’d done, but I’ll upload a rough design doc I’d written for myself to stay on track, which pretty much covers the same content. This also covers an assignment for another Unit, which is why it mentions a hypothesis and how I’ll go about proving it, but you can safely ignore that. Also, I think I gave myself an extra week for GAM101, which I don’t actually have. Enjoy!)
The game will be a 3D third-person game, with an over-the-shoulder camera.
The game must feature multiple levels;
The game needs at least one trace-hit weapon, one projectile and one timed weapon;
The game must show a score multiplier or combo somewhere;
The game must have a persistent system, such as a high score or save system in place.
The project will be converted from my last 2D project, which already covers the rest of the brief. For the sake my testing my hypothesis for MDU103, I’m having people test the older version of my game, as well as the new one. People will be given a (digital) sheet to rate the differences between the games, as shown below. These will be tallied and the final result will determine which version of the game was more ‘successful’.
By the end of week 7 (the break week), the above brief must be met. This allows 2 weeks for polish for GAM101 and 3 weeks for MDU103, though the extra week is best spent testing for MDU103.
This means that, by the end of week 7, the game must be in 3D, have multiple levels, have a trace hit, projectile and timed weapon, have a score multiplier or combo and implement a persistent system. Doing so will leave me 2 weeks for polish and level design and then a final week for testing my hypothesis.
Make the game 3D – Since the original 2D game was built in a 3D engine, this is a simple task and should only take a matter of minutes. Don’t forget to disable the current camera script, or the camera will stay in a bird’s eye view. It’s also important that, at some point (probably in the second level), the player must traverse the Z axis or the game is technically still 2D. I’ll also need to add a skybox and decorate the existing area quite a lot more, since the game was built for 2D.
Include the trace-hit and timed weapon – The game already includes a projectile weapon, maybe make it explode after a timer? This may be less functional in terms of gameplay, but it provides me more time to polish the game and it meets the brief. Implementing a trace-hit weapon is probably the biggest task of the lot, since the current combat system is based on a targeting system I’ll also have to remove. This means a complete overhaul of combat, at least as far as the player goes. It may be possible to recycle a lot of the current code in order to meet the new brief.
Score multiplier or combo system – Will be easier to include a score system, since I can work this into a high score to meet the persistent system brief. Points can be awarded for killing enemies quickly, with the bonus being lost if the player takes too much time between kills.
Multiple Levels – This will be mostly about polish and level design. No scripting should be required short of loading the new level. This means I can quickly add existing prefabs into a new (probably smaller) level. This new level will include the final boss and will function similarly to the graveyard in my current game. One important feature to note is that in this second level, the player should traverse the Z axis at least once, in order to properly meet the 3D brief.
Polish – Polish the crap out of the game. This is where a bit over half of my development time will go, adding things like sound, feedback, tweaking the systems and graphics, etc. Polish is totally fundamental to a solid and fun game and is something I typically haven’t given enough time for in previous work. Some key things I want to fix are the GUI (since it’s ugly as hell and currently provides no player feedback), audio (needs a lot of work, most enemies don’t make noise when they attack or are attacked, for example) and player feedback.
When I say feedback, I mean systems that react to the player’s actions. These are things like the health bar shaking when you’re injured, enemies reacting to being attacked, the screen flashing red when you’re attacked, a particle effect or noise when you collect an item, etc. Currently, feedback and GUI are my two highest priorities when it comes to polish time.