Planning, planning, planning

When it comes to creating a game like this, it doesn't hurt to do just a little planning in advance.  Originally it started out as hand-written notes, which eventually made it into a specification document.

However the specifications are fairly complex and detailed, and while its useful, its too much to take in and not the most inspiring of things when you're trying to get that creativity in while you create the game.

Anyway, thought I'd just show how much went on prior to coding this.  Its an 8-10 page word document that covers everything from original plan, through rewards, bonus levels, and even a touch on a financial model for mobile...  But its definitely not something that would win any pitching session.

I think in a way it was over-thought.  The plan is for porting this to mobile and as such I wanted to make sure I clarified everything across the board - and I did, but its STILL not finished believe it or not.  I have the feeling I'll be rewriting this at a future date anyway.

Not so corporate, please...

I wanted the game to be simpler, so back to hand-doodles and that's where the current project has come from.  I love hand-written notes - they're way more free form and easier to put together.

The hand drawn stuff is much more expressive.  Drawings of the game screen, notes everywhere explaining what happens.  Its a work of art...  Kinda (maybe I need a splash of colour... Haha!)

Good for your health...

I'm currently nursing a few stitches in my back from having a skin lesion removed, so sitting back on the couch and scribbling is a lot more relaxing then sitting here at the computer.  Once I'm done with a few more details, I may post up one or two full images for your amusement.

Back to coding...  and drawing a few more graphics, and, and, and...

Read More

Mostly there... Well, for those basics...

Its pretty amazing just how fast things go when you're on a roll.  Since the last post (just a couple of days ago) the game now has player interaction, a new NES-style (ok, so its kinda NES-like) look to the graphics, visible character timer bar (to show how long they will be in play), some basic score and time limit.  Overall a majority of the basic game system seems to operate as expected.

Its nowhere done and dusted, of course...  There's more game logic needed.  There needs to be an aim to the game itself.  In general its a collect coins and progress to the next level thing, which needs more then just a simple time limit.   That means more challenges to make it less 'collect coins for a limited time' and more 'collect coins, but watch out for...'

Never fear of course - I have a whole document load of stuff still to implement!

More graphical variation

In its current state, all the characters and arcade machines look the same.

Its fine for this proof-of-concept stage, but there's definitely going to need to be more variations in everything.  Different looking characters, variations in arcade game colours, etc.

Definitely more animated elements will be needed too.  While proof-of-concept is not necessarily about making sexy looking graphics then it is the game play, nobody ever got excited by generic looking imagery - especially important once I'm ready to let other people loose on it for testing and feedback.

Character functionality

I'm looking at some of the additional functionality of characters, as well as the introduction of 'bad guys' (those characters you don't want in your arcade).  Each character will need more attributes to really add some challenge to the game.  This will also tie in with getting some more variation into the character imagery.

Bonus levels

A bonus level or two never goes amiss in any game.  The chance to cash in and earn more points.  Definitely doable and fairly easily as well.

Obstacles

As mentioned - bad guys are one challenge I want to add into the game.  Other obstacles based on character functionality are another...  Angry at no machines free or interaction with one of these 'bad guys' I previously mentioned, games that are too hard to play or too old, etc. Limitations of various kinds, things that lower the coin spending generally and make it harder for the player to reach the goal.

So...

Still plenty to do, but overall progress is ripping along.  I'll post up some more stuff soon (and like the original post, reveal more about the game as I have something to show (and actually talk about)).

Read More

The power of boolean logic...

Snippets, tippets...  Well, a small collection of some approaches I'm applying to my code here as I go with myCade.  As predicted earlier, once the maze 'wandering' was completed with the BFS code, everything else is just falling into place.

It didn't take long to start to add coin tracking to machines, a time remaining bar that shows how long the delay is when a character stops at a machine to play it as well as keep tally on score (ie. allow the player to collect the coins) and a global time limit for the whole game itself (just to give it very basic 'challenge' of sorts, rather then testing forever wandering characters in an arcade)

But more about that later...

If lots of things then don't do it this way...

Yup - games have loads of things to ask.  If something is this, then do this...  Else don't do that and do this instead.  The amount of these can become quite excessive - which isn't a bad thing since how else will your game be 'smart'.

However there are some pretty cool things you can do to at least bypass of those extra if statements.

Booleans to the rescue!

If there are + or - values needed to be set based on whether a value is one thing or another, then consider not using if's and look at the power of booleans.  As you know, booleans are True or False.  Or in numeric-speak, that is 1 or 0.

Knowing the 1's and 0's means that with a little maths, we can take those to produce a statement that handles what some would use at least one if-else statement to do.  Whether this internally runs a little faster in Python, I don't know - though machines run so fast these days it's negatable for sure.

In this example, this is how I've been coding a change in direction for an agent (a character in the arcade).  A direction letter is passed (U,D,L,R) and two vector values that are added to the characters location are set.  U(p) and L(eft) use a negative value.  The other's require positive, and if neither the value should be 0.  SPEED is a constant set to the pixel movement per frame.

agent[2] = SPEED * ((currentPathDir == 'R') - (currentPathDir == 'L'))
agent[3] = SPEED * ((currentPathDir == 'D') - (currentPathDir == 'U'))

This is actually a tip used back in the 80's - in fact, you'll see it mentioned about half way down in my other blog article here where I do explain it a little more.

Python is 'in' da house... Ahem...

Another thing for my non-python readers curiosity has to be Python's in which iterates through items that are 'in' a list.  Its used a lot with the for loop, stepping through each item that is in a list.

Where it also comes in useful if for testing if something is in something else!  For example, find out if a sub-string exists inside a string using:

if 'hello' in 'a string containing hello somewhere':
    print 'hello was indeed inside that string!'
else:
    print 'Nope - could not see it.  Which is abnormal!'

But there's more to it then strings...  If we want to test the existence of an element within a list of items, we can use it there as well.  Makes this an ideal way to check if a character is in a particular area or group of items...

One example in my code where this came in particularly useful is to determine if a tile location is within a dictionary of arcade machine locations.  Dictionaries, for those coders who don't use python, are essentially hash tables (assuming you know what a hash table is, of course).  Its an array of information that can be referenced by a key, rather then an index location within an array.

For a lot of the game system, using physical x,y locations to track where things are makes searching for items a lot quicker then by searching for a value within a matrix (X by Y tile map).  The keys of the dictionary are tuples (pairs of numbers, surrounded by brackets) rather then a string.  A typical list looks something like this shortened example from myCade.  Each entry is referenced by the location ie. (7,3), and the data stored for that location is a small list ie. [1,1,True,3]

arcadeMachines = {(7, 3): [1, 1, True, 3], (4, 4): [1, 1, True, 4]}

Here's a rough example.  Note the first use of in to loop through an array of all of the gamerAgents (characters in the game) where I retrieve and append each gamerAgent's location (x,y) to a new list called inUse. (gamerAgents is a list containing the data for each character in the game.  Entries stored at indexes 7 and 8 are the x,y location of the machine they are playing)

# Collect a list of the machines currently in use
inUse = []
for agent in gamerAgents:
    inUse.append((agent[7],agent[8]))

# Check to see if an agent is using machine at (4,4)
if (4,4) in inUse:
    print "Machine at 4,4 is in use by a gamer Agent'

Mighty useful indeed.  And combine this with the boolean math above and you can really cut down some of your more bulky code pretty swiftly.

Well, those are just a couple of small snippets of general info for anybody interested.  I'll obviously throw in more as I go, as well as updates too.  Thanks for reading.

Read More

A cast of characters - some old concept art

Thought it was worth posting this up - I did this a couple of years back.  Its a collection of possible character concepts for the cast of the game.  I had a much more complex game structure back then, with various personality types, and a more indepth 'management' style approach to the game as well.

What the?!  Isn't that your blog name I see?

You'd notice that I'd also called the game Arcadia in the image - which is where I nabbed the name for the blog, but I felt that the blog doesn't need to necessarily be JUST about a single project.  I can't exactly keep making new blogs constantly when I decide that I need somewhere for the next game...  And well, its a game about an arcade, or as the player would probably say 'my arcade' (hence myCade).  Arcadia has a ring about it as well - arcade games, nostalgia, etc.

Anyway - that said - In regards to the artwork, each character had differing capabilities and attributes.  At one point I'd included favored game types (platformer, shooter, etc) to control their behavior as well as budgets, health, excitability, etc, etc.  It was a good idea at the time, but I think I'd kinda made something over-complicated for what was supposed to initially be a simple and fun game.

Some of these art designs I'll consider using when I develop sprites for the game.  Of course, I never throw those other technical ideas away either.  There is plenty of scope to implement some of the old concepts as the game development progresses.

But more about that in the future - and once the 'fun' version is done of course...

Read More

Getting it rolling - what a load of BFS!

I'm back.  This time I want to post up a little about my exploration into building a prototype 'proof of concept' for my game I'm simply dubbing 'myCade' (Working title) for now.

More about the game concept

The game centers around an arcade (hence the working title).  Unlike my inspiration, this time the goal is not to stock up the machines with coins and collect them back, but instead let incoming characters play the games and stock the machines up with their hard-earned pocket money.  As the player, you then collect the cash and store it in your safe.  The goal here is to collect coins and move on to the next level (well, at a basic level) once you reach a certain amount

Obviously there are other game play features involved, but that's the general gist of it.  I have a fairly hefty document and design plan I sketched out that covers things in more detail that I may post up at a later date (once I see if there are any details I've left out, and test that things are actually working in terms of game play).

Getting the ball rolling...

I figured I'd make a start on some coding...  In the past, the best thing for motivation when writing code for a game is to at least see something happening...  Even if its a bit at a time.  This initial start was to purely get some characters running around an arcade to empty machines - or in this case, target points.

Of course, I also needed some generic graphics.  As this is purely a proof of concept and not a final project, I don't need anything complex for testing...  But also not too crappy looking either.  I decided on 64x64 sprites so at least it looked decent on a high resolution screen.  Four arcade machine graphics (representing machines that face left, right, up and down) and a single character.  The character was actually drawn by my brother back in the 80's on a ZX Spectrum - he is also a pretty creative guy, so there were always cool ideas for other games from his artistic designs.  I may drag him in at some stage and see what we can put together in the future for other games.

When I resized the characters, they did look a little less appealing in that the pixels didn't retain their clean shape, but I figured it does what it needs to at this early stage of testing.  I can make prettier graphics later of course! :)

Quick-n-dirty test sprites

The game play field.

As you'd expect with games like this, the design centers around a tile-based map.  The map contains clear areas for walking, and machines (which come in 4 orientations) that each character will stop at and play.  The characters in the arcade enter and then travel to a target (one of the free machines).  This initial test code uses random locations just to test the travel algorithms and make sure all the game characters would move as expected.  After this is all working, the game code will make sure that a character will choose a free machine as its target.

I first tried to code the movement of the characters to use an approach I'd tested in a simple Pacman-style game I wrote for fun a while back to help me learn how to use Pygame,  My version of Pacman featured purely random motion of ghosts rather then the usual target-based system that the original used, but it worked and it was fun to play.

I used the same concept initially for my character movement in this game, using a constant linear direction movement and checking for exits in the arcade 'maze' that were opposite to the initial motion (if vertical, see if we could move horizontally and change if we needed to reach the goal).

This proved problematic.  I found that I ran into some situations where characters would get locked into corners, or even walk out of the arcade and game window.  I ran through my code, and while I could have eventually found where things failed I decided I was spending too much time with it.  Plus there were issues that affected the feel of the game play, making the motion of the characters look a little 'misguided' and unintelligent...

Fyi - if you want to download the pacman game code, its included with some other retro code (old 1k ZX81 games recreated in Python).  Click here for a direct link to the source code on my google drive, or click that previous link to watch me fumble my way through a presentation I gave on the retro gaming project I'd been doing.

What a load of BFS!

I instead opted for a path search system.  The character would be given a target location to reach, and then would calculate its path as a sequence of directional movements.  While the game loop ran, each tile the character entered would then check for the next direction to move and set the characters motion as expected.

The search algorithm I ended up using was a Breadth-first seach (or BFS for short).  This is a fairly well documented algorithm, finds the shortest route (and gives our characters less of a random appearance when moving) and benefited from not requiring any use of recursion, making my code less of a mental strain on my brain cells (and at my age, I need to retain as many as possible - lol!)

Bonus is that bfs only takes 7 lines of Python code to implement - short, sweet and clean!

It may not be the fastest (I'll look at other options at a later date, such as A*, etc) but for this proof of concept, and the fact I'm working in a small map (once I converted the tiles to a graph structure, the amount of data became even smaller) it worked great with literally no visible impact on game speed.

Arcade time!

Because the path is pre-calculated, the nice thing here is that I know a character reached the goal when the end of the path is met.  I found I could take advantage of this path to easily control whether the character traveled onto a target, or could finish at the correct location one tile away (ie. say I wanted to make a character reach the arcade machine rather then land on top of it (ie. prevent it walking onto the machine graphic)).

The pacman-approach used a 'target tile reached' test, and calculating the direction the character was moving, the tile location and testing for the machine being in direct line takes more code and was not as clean a solution as simply ending at a path's second-to-last position.

So, at this stage I've got things moving in the arcade.  This is perhaps the main thing needed in the game - getting the game characters moving and reaching their goal.  With only a few simple tests and some data management needed to get the game up and running, I feel that this project may come together a lot quicker then expected (well, I hope so - but famous last words and don't count your chickens until they hatch as the sayings go!)

Until next update...

Read More