* We managed to finish a home brew project! :-) We all start lots of mini projects in our spare time, and very few of these ever reach completion. We were both very proud to have seen one through to the end.
* Re-playability - Once the scoring mechanic was in we found that it made each level playable in multiple ways. The player could rush to the end collecting all the starts, or plan how to keep as many enemies glooped as possible in order to maximise their score.
* Great art work - a big thank you to Andy who stuck with the project in all it's guises and delivered some fantastic artwork for the game. He was able to work with the limitations of tghe spectrum, colour clash and all and deliver something which is brilliantly styled and makes each level easy to read at a glance.
* Tools - having written our own tools for editing levels, compressing level data and converting images files to a Spectrum friendly format allowed us to maximise what we could do with the platform.
What went wrong:
* The difficulty curve was too gradual, most retro gaming players could easily get to around level 15 without breaking a sweat before hitting the tricky levels. Our initial play testers were all friends and family who perhaps in hind sight may not have been the best candidates for testing. The reason for this is Gloop Troops is a very hard core retro game at heart and should have been tested by a more hard core games playing audience.
* Sound & music - this was something we only added late in the day. We had not been playing other Spectrum games and missed that the audio bar was much higher than we remembered :-) Next time we may target the 128k Spectrum and make use of the AY sound chip.
* Scoring mechanic was missed by a lot of players. We were going to display sprites over glooped enemies to show the amount of score you'd earned by glooping them. However this information was lost to the players we found as as this feature didn't make it in and a lot of players missed the score in the top right flashing. Next time we'd like to focus more time and memory on highlighting the player's achievements.
* Writing the game in assembly was time consuming. This had been done to maximise performance out of the limited hardware, but instead we could have used a C compiler such as Z88DK and rolled our own sprite and collision routines in assembly.
* Continuous experiments - whilst beneficial to the overall quality of the game, each new feature we added took around a weekend to implement, test, tweak and then decide if it was worth keeping or not. For future projects we've chatted about the possibility of creating a PC version to test game-play ideas before finally porting them to the target platform.
No comments:
Post a Comment