I’m currently designing levels for the campaign/story mode of my tower defensish game Def. There are various approaches that tower defence (TD) or RTS games take in progressively introducing new tower types and enemy types. It’s not uncommon to have a kind of tech tree, or a store where new tower types can be unlocked. As the player progresses through levels and gains more money or experience points, a greater variety of towers become available. These open up new strategies which usually need to be exploited immediately to deal with new enemy types. Continue reading…
With the design of GrandMasterPixel, I’ve generally worked on the principle that features should have to fight to be included (ala 37signals), and worked to create the bare minimum required to play the game. No more, no less.
Part of that philosophy lead me to forgo the customary title screen found in many games. At most, I planned to have the title text “GrandMasterPixel” overlayed on the Drawing screen upon first load, then elegantly fade away. This way the user is thrown straight into one of the two key mechanics – drawing (other being judging). They can immediately poke the screen an start creating some simple pixelart. There isn’t any dire need for a ‘navigation screen’ on the Android version, since all navigation can be accessed in the popup menu, by pressing the Menu button on the device. This is the convention for pretty much every Android app (and is the suggested style in the Android Menu Design Guidelines published by Google).
Recently, however, I’ve have a change of heart on the front page navigation screen idea. Maybe it is required, to better lead new players into the game. Additionally, I’ve also noticed that Android games conventionally seem to have a front page navigation screen, unlike other non-game apps.
Here’s a mockup of one possible front page screen for GrandMasterPixel, made with Mockingbird:
At the moment, I’m still looking for more people to play test what I have so far, before going crazy on implementing more features. There are certainly lots of parts that need work, but I’d like to direct my efforts toward areas where players feel they are more required. You can download the alpha version of GrandMasterPixel for Android with this link. I’d appreciate any feedback you have, on FriendFeed, or via Twitter @OMGWTFGAMES or right here in the comments !
So, the Game Design Concepts course officially finished a little over two weeks ago. I followed along for the first half, but dropped the ball when it came to the month-long design project. Playtesting is time consuming, but essential – and finding a bunch of ‘randoms’ to act as testers for blind playtesting is tricky.
Rather than working on my Game Design Concepts project, I instead decided to focus my game development time in August on getting something ready for the “Android Developer Challenge 2“. While I didn’t actually make that deadline (I decided it was not worth submitting something unpolished), it helped to push my uber-secret-Android-project into the realms of playability, and I should be able to release it before the end of the year.
Here’s a summary of my Game Design Concepts project, as it stands.
The game board “pre-prototype”:
Each player is given three destination cards, which are destinations they must visit during the game, as well as sharing two “shared destination” cards with two other players, which are destinations that each pair must meet at during the game. Once a player visits their five destinations, they win. Players move around the board one step each turn, but sometimes they must wait several turns at a station for a train to arrive (indicated by the “colour clock”). While they are waiting at a station, they must roll to possibly draw an “event card”, which can initiate things like rail strikes, or provide a “taxi ticket” to get them from A to B, pronto. The game forces players to determine the optimal route between their destinations, re-route as events occur, and negotiate their routes to be compatible with the players that they must meet.
I may finish designing this game at some point, including proper playtesting, but I also feel like the basic mechanic is a little tedious and there are not enough “interesting decisions”. I may be better off just scrapping it and starting with something entirely new. Below the fold are the rules as they stand, and my working notes …
Here’s a new game I’ve been developing on-and-off for a few months now. I’ve become pretty busy at “The Day Job” recently, and due to commuting time I haven’t found time to add all the features I’d like. I thought rather than sit on this game for many more months, I’d just release it as is. It’s polished enough to play … but you’ll need a friend (if you live in Melbourne … I’m happy to drop round and play it with you :) ).
Phobocore is a two-player hotseat game, where the aim is to capture all the planets onscreen by shooting them. It’s sort of a cross between Asteroids and Risk/Galcon, with a respectful nod to open field overhead shooters like Robotron, Bezerk or Gauntlet.
The experience of creating this game has been quite enlightening so far. It really got me thinking about aspects of game design I hadn’t thought deeply about. I threw around lots of ideas relating to ‘resources’ and ‘defenses’, particularly thinking about how RTSs like Starcraft require balance in play style between defense building, offensive maneuvers and resource gathering. Good players must multitask and proiritize to get the upperhand on their opponents. Key questions like “Should captured/neutral/enemy planets be solid objects or unhindering ?” occupied more than one dinner time conversation, bearing out all the ways these would changed the game. I had great fun testing the effect of different game rules, and how these changed the dynamics of the gameplay (with huge thanks to my long-suffering girlfriend for playtesting. The next best thing to writing an AI player :) ). If you are keen to fiddle with these game rules yourself, you can throw various flags in the phobocore.py sourcecode to test how these variations change the play style required to win.
I also spent considerable time tweaking things like fire rates and the “planets-held to ammo recharge rate” ratio to try and make the game somewhat fun. It works pretty well for players that are equally matched, but much like Galcon, once one player gets an edge, it can be hard to recover and things are over pretty quickly.
Big features I’d love to add in the future: an AI compurer player for single player mode, and maybe network play. I need to work on the collision detection, improve the graphics, add background music, and add a help screen / tutorial screen and slap on a license (probably GPL for code and Creative Commons for audiovisual assests).
Have fun & feedback is, as always, welcome !
There are some pearls of wisdom here, eg:
For me the retrogaming movement is more than just nostalgia of misty eyed Gen X’ers. It’s a reaction to the current graphical overkill, the simulation obsessed gaming environment of the late 90s. In our quest for absolute graphical realism, we have forgotten the basics of gaming.