With this one I wanted to try my hand at a very popular game genre at the moment, match-three. Because this is a rather simple style of game I thought it would be really easy and fast to make. Wrong. I spent hours without touching a keyboard trying to come up with some novel twist on the genre.
I toyed around with a gem dropping mechanic but that didn’t work so well, then I thought about how someone interacts with match-three games on mobile, by dragging the icons around. So I decided to base my game play on dragging gems around until they make a match.
I originally wanted a “mindless” match-three game like Montezuma, one where you play it as fast as you can without thinking too much about the moves. As I started developing the game play for this one however it seemed to fit a puzzle like game better so that’s what I ended up with.
Anyways give it a go and let me know what you think:
This one took a little less time at the others at 31hours over 7 days, as per the other two I recorded my time spent:
11:00 – 12:00
Well that’s the end of my challenge! Im surprised I managed to do it. A little over a week per game seems like hardly any time at all but having that time restriction really is good as it helps to limit your scope, preventing the game from ballooning out into something that could otherwise have taken months and still not have been any fun to play.
As for the tools I used. I used Richard Lord’s excellent Ash Game Framework to develop them all alongside Starling with Feathers on top of Flash for the rendering. For rapidly prototyping games they have been excellent. Now im more familiar with Ash I may write a post or two about how to go about structuring certain parts of a game in an enitity-component like manner.
For this one I decided on a type of game that I have been wanting to make for a while, a turn based strategy game. Many moons ago I used to play a J2ME (shudder) game called Ancient Empires. It was a great little game with lots of depth and replayabliltiy and I think it deserved a remake of sorts.
This game was far more complex to create than Latesha’s Crib and hence I spent about 43 hours over the last 9 days making this one.
I was able to save some time by reusing parts of the rendering and hopping logic from Latesha’s Crib. As usual I used the Ash Framework with Adobe Starling and Feathers. To code the AI for the computer player I used Tim Conkling’s Excellent Godmode Behaviour Trees library which is truly an excellent AS3 library. The way Behaviour Trees work is really cool, I strongly recommend checking them out if you are going to design any sort of AI.
Special thanks go to Mike Rigby for helping with play testing and Ian Callaghan for suggesting I check out Behaviour Trees
Let me know what you think of it, if people are feeling it then I may turn it into a full-blown mobile game!
Again I recorded the my time spent making this one, heres the log:
9:30am – 2pm
3pm – 7pm
9:30am – 10:30am
12:00pm – 4pm (-1 for josh, -1 for lunch & spanish)
2pm – 19:30pm
1pm – 3:30pm (-1 spanish and lunch)
4pm – 6pm
Ash is a high-performance entity system framework for game development.
An entity system is a way to organise the code for a game that is efficient for both code execution and code management. It uses composition rather than inheritance for sharing features between game objects and uses a data-oriented approach to separate the game state from the game logic. This makes it much easier to manage the code and to manage the game state.
Im not going to go into the details too much of why composition over inheritance is a good idea as Richard has already done a much better job than I ever could in these two posts:
If you haven’t got a clue what im talking about when I say Entity or Component I strongly recommend checking out his posts first.
The reason why Ash has piqued my interest is because for the last three years I have been working with Entity-Component systems for games but in a totally different way. The way I have been using and developing started with the Push Button Engine (PBE) method and later expanded out to include Dependency Injection culminating in the Swft Framework.
Ill give one example of why am starting to fall in love with Ash:
In PBE and Swft the components contain data and functions. They can also declare dependencies (via [Inject]) which are automatically fulfilled when a component is added to an Entity. The functions in the component are able to act on their own data, other components and interact with the game as a whole.
One problem with this method is that components are largely tied to their entity and once attached aren’t really free be removed or added. The reason is because other component may have dependencies that depend on that component being part of the Entity. Removing the component will cause the game to crash. This becomes a problem when you want to enable a certain chunk of functionality for a certain time then disable it, what you tend to end up doing is adding the component at Entity creation time then inside of it toggling its behaviour with a boolean.
In Ash components are pure data with the bulk of the functionality being contained within systems. Sure you can have functions in a component but they only act on their own data. There are no hard dependencies between components. What this means is that components are much more free to be added and removed from Entities. So how do component function together then? Well that’s where Systems come in.
Systems are classes that contain the logic that makes up your game. When added to the engine they grab one or many lists of Nodes. A Node simply defines a collection of components that must exist on an Entity. In effect it declares the dependencies that this System needs to operate. What’s neat about this is that this list of nodes is constantly changing as components are added and removed from entities. The Ash Engine manages this all for you so all the system need do is iterate over the linked list of Nodes each frame and execute its logic.
Systems also must not declare dependencies between each other. This rule means you don’t end up with large dependency hierarchies between Systems. This frees up systems to be added and removed from the Engine with no side effects! This is rather remarkable as it lets you do crazy things that you couldn’t normally do when there are many dependencies between systems. For example your game could have a Blitting based rendering system, then halfway through a running the game you could swap that out that System and replace it with a Starling based rendering System!
Thus far I have only spent a limited amount of time tinkering with Ash but I am having a whole lot of fun. I have started work on a little game to experiment around with the framework. At the same time I have been exploring Starling, the hardware accelerated 2D rendering framework built on Stage3D. Thus far I have produced this little map editor:
Click to place a block, shift and click to remove, scroll mouse to change block type and hold control and click to zoom in / out.
Its only a tech demo at the moment and as such hasnt got any game play elements. Im not entirely sure what to turn it into but as a platform for tinkering with Ash its been great.
Its too early to share the code at the moment but if you would like to see how some Ash code looks I strongly recommend you check out Richard’s Asteroids example on GitHub. I was really quite taken aback by how neat and modular the code is. The example is provided in 4 different flavours, one using RobotLegs one with Starling one with SwiftSuspenders and one with no dependencies at all. The fact that the code still works and looks simple in all the examples really demonstrates the versatility of the framework