Crimbo is currently number 85 on the World of Spectrum's top 100 games
Monday 31 January 2011
Sunday 30 January 2011
Work continues...
Things have been very busy here at the Little Shop of Pixels! Over the last few weeks we've been busy making steady progress on Gloop Troops 2. Andy has done lots of experimenting with the Spectrum's colour palette and has nailed the look of our big unannounced feature! We will be posting screen shots for a big reveal shortly :-)
Andy has created all of the art assets for Gloop Troops, Crimbo, and our previously aborted Spectrum game ( more on this in a future post ). Through several years of work he has developed a high degree of mastery of the Spectrum's colour palette. So you can expect to see some very good things soon!
Meanwhile I've been getting my head around how we can best take advantage of the extra memory on the 128k Spectrum. I've gone backwards and forwards on this one, but think our memory usage plan is now in place. Getting to this point has unfortunately required a big re-write of the GT2 code base. The end result of this extra work is that the game is now capable of supplying richer environments than our previously released games.
We've also got an article on Gloop Troops in the 8bit Return Magazine!
We are hoping to post up some in-development shots of the game very soon!
Thursday 20 January 2011
Top tips for designing a platforming game
I stumbled across this link today - I found it to be very relevant to the types of games we're making here at the Little Shop of Pixels!
We were a little guilty of making the collision box larger than needed for the Xmas tree enemy in Crimbo. Next time we might use collision masks or multiple collision volumes to represent an enemy.
Point 5 - having a highly reactive character - is something we have strived for in our games. We update the player every frame, unlike the enemies which update every other frame. This allows the player's character to feel very responsive to the player's control. Sluggish controls are often found on early 8bit computer games. Normally this is due to taking multiple frames to read the player's input and draw the response on screen. Bad controls let down action titles and highlight the performance weaknesses of the platform.
Developing new games on old machines carries with it a lot of extra work. As well as developing a fun game which will entertain the player, but you also have to overcome the tight limitations of the machine.
We have always aimed to fully push each platform we develop on and to make sure that each game feels that it hasn't been compromised by the machine it runs on.
Friday 14 January 2011
Differing versions and the trouble with post release fixes
Publishing updates for a retro game out in the wild is tricky business! Modern PC and console games have the luxury of being able to easily connect to a server, download and apply then patch before relaunching the game.
This fantastic functionality can be hidden from the player. At worst the system can prompt them that the update process is about to begin!
Older platform's, without any online connectivity, do not have this luxury. Instead the best we can do is provide a version number on the game's title screen to help identify it. We then need a way to inform the player that a new version of the game is available for download.
Because of the extra hurdles involved, we've been reluctant to implement feature suggestions into titles we're already released. For example, with Gloop Troops we'd received some excellent feedback ( requests for music, keyboard control and a re-jig of the level order ). But by the time we were able to collect all feedback there had already been 4 versions of Gloop Troops made available over the internet!
One was the original version, then there were two hacked versions - one with music and one with a change to the title screen to circumvent a bug on real Spectrum hardware, and finally the official fixed version we'd released.
This makes it more difficult for anyone reviewing the game. If we release a version, then collect feedback and release another version then you may have conflicting reviews on game sites. We would also need a solid method of communicating the new version to existing players.
There are a number of solutions to this. We could provide a version number on the title screen along with a URL and a message informing the player to check for updates, but this feels messy and convoluted. This may be an interesting method to pursue if we explore an episodic game series.
The current solution we have in mind for our upcoming tiles is to have a beta period for our future titles. This way we can collect feedback and catch any issues with the game whilst it is being developed. The result of this extra testing should result with us releasing solid, quality games which we can all be proud of :-)
Wednesday 5 January 2011
Level design lessons from Super Mario Bros 3
We are constantly looking for sources of inspiration whilst development continues on our next game. As luck would have it I stumbled across this post yesterday:
The post does a great job of breaking down the early game of Super Mario Bros 3. Concepts like gradually introducing new mechanics to the player, teasing them with possibilities, and rewarding exploration are things we want to implement.
How these design lessons fit into Gloop Troops 2 however remains uncertain. We are currently re-evaluating all the work done on Gloop Troops 2. We're questioning every decision and making choices about whether it's better to stick with the current formula, or to take the game into a bold new direction.
Monday 3 January 2011
Happy new year!
Happy new year all! There's lots of work to do on our upcoming games - hopefully we'll be ready to make some exciting announcements in the not too distant future!
Subscribe to:
Posts (Atom)