Programming games in the 1980's

I want Arcadia to include some of my retro gaming mini-projects.  I do post a lot of this stuff over on my other blog, and I thought - well, its all about gaming - why am I not linking that stuff back here!

For those interested, I've written a few articles and tutorials...  Taking old-school games from the 80's and recreating them in python is a load of fun and challenge.  Here's a list of my articles right here:

Learning about programming by doing it how it was done in the 80s

• Part 1 - Getting started
• Part 2 - Understanding a BASIC game listing
• Part 3 - Recreating the BASIC using Python
• Link to video presentation I gave at NZPUG
• Github source files from this presentation

Recreating an old Atari 2600 game in Python

• Empire strikes back (w. source code, etc)

Data converting for future projects

• Converting ZX Spectrum graphics into PNG files w/ python
• Playing back ZX Spectrum BEEP's w/ python

I do have a lot more in the pipeline, and I'll post those here as I go...  But for that nostalgiac fix, or just because you're historically curious do check those out. Also check out some of my other non-coding retro posts.  A variety of hardware fixes, reviews and 3D imagery!

Read More

Holy-moly! $15 for gaming tools!

As I said a few months back, the whole Python code thing is about my need to write all of the code for my MyCade game without resorting to a game making tool...  I guess its a mix of nostalgia and inability to let go of my past, along with a dose of arrogant avoidance of game making tools as the 'easy way' to do things...

And to be honest, I've managed to get quite a chunk of that code to a stage I'm pretty happy with... But I'm at the point where I need to take all of that coding and build the game itself (ie. the goals, rewards and everything else that makes a game a challenge)

Well, what a surprise I got a few weeks back when one of my students asked me if I'd seen a deal on Humble-bundle for GameMaker:Studio...

yoyo games, creators of Gamemaker studio

At a mere US$15 for the full professional studio, plus all of the exporters for Android, iOS, HTML5, Windows, OSX and so forth I just didn't see why I shouldn't go for it...  In fact, it was such a great deal that I decided to buy a copy for my brother, a guy with incredible creative talent being able to come up with some pretty original ideas.

Unfortunately this deal is over, though I would suggest everybody keep an eye out as Humble Bundle often throw in deals like this every other month or two from what I've heard...

GameMaker:Studio Pro

I will have to say that this is a nice piece of kit.  It was intuitive enough to use straight out of the box (eh, I mean straight after installation) after just a small amount of 'getting started' reading, and with a quick simple tutorial to explain the process of setting up a introductory game, I knew pretty much enough to play with my own ideas.

Actually fairly intuitive after you get the basics...

I did try the basic intro game tutorial, developed literally from simple drag-n-drop actions.  It was easy to work with, but to be honest the first thing I thought to myself is this is why I preferred to code everything - this approach to me doesn't have the feel of producing a piece of software, more a game-making construction kit with fairly simple events and actions.

I knew GameMaker had some kind of scripting ability - and digging a little deeper suddenly changed my mind completely about this tool...

Step

The Step event is one that runs constantly during a games execution.  There was an action I could attach to this event that would execute a script.  Once I linked these two together - poof! - instant reason I could now consider moving MyCade across to this tool and not drag out the Python scripting any further!

In a way, I'm saddened about abandoning the development using Python as I really get personal gratification out of coding everything from scratch (as inefficient a use of time as it was).  However, now I had code level development sussed and there were many functions and features in GameMaker that I didn't need to code from scratch - I think I'm making the right choice to move forward.  No more reinventing the wheel either - GameMaker also appears to have A* functions built in for path finding, which is an algorithm that is faster than breadth-first searching...  Great!

Events, Actions, Script...  Great!

I also like that GML is a very easy to use language (being fairly much the same structure as most ECMAScript languages) so it was relatively simple to pick up...

That said - I've got loads of development work still on in regards to Maya, Nuke and now RenderPal (a render farm platform) so it isn't like I'm going to suddenly stop coding in Python...  In the end its the best of both worlds, really.

Practice makes perfect (sense)

I haven't started to move anything across yet for MyCade, but to have a test-run at coding in GML, I figured I take a quick stab at building a simple platformer (well, a single test screen).  As I've got loads of old-skool graphics from the 80's drawn by my brother (who I bought a license for) for games we'd planned but never wrote, it was a no-brainer.  Back then there were so many cool ideas, it gave me way too many options to choose from, and it became a case of starting nothing as any game development back then required a huge amount of effort.  The amount of effort to even code just one game was way more complex as well back in those days.  Writing actual sprite routines to draw to the screen, compressing data into tiny amounts of RAM, breaking down game loops into Z80 assembler...  Well...  Yeh...  enough said on that.

I built a very simple platform jumping mini-project using images for a game we titled "Multiranea".

Multiranea

The game that never was has now become...  Well, a simple test and not really a full game - more a screen that the player can be move and jump around with some simple obstacles.

Its pretty simple, but all of the sprite animation sequences, collision, dissolving rocks, etc was done with code rather then use GameMaker's own drag-n-drop actions.  I imported all of the sprites, then used code and a load of modulus, timers and various commands to take care of the frame-by-frame animation.  I'll post up a tutorial about some of the ways in which I worked through these soon.

For anybody curious to see how it worked out and give it a play, I have an exported Windows .EXE file that can be run.

Disclaimer: Please read this before you download and run the game.  By running the Multiranea program, you agree that you do so at your own risk and will not hold me accountable for any issues that arise (that is, if they do (though its unlikely)).

Also note that its only tested under Windows 7, but hopefully (not guaranteed) it should technically work on Win 8 and 10 just fine.

Controls are left arrow, right arrow and space to jump.

The question mark blocks will dissolve after you've landed on them.  The angry-face blocks will shock you (then disappear) and the green devils will shock you on contact as well.  The devils travel left and right on the platforms, and will randomly stop for a short amount of time.

There's no goal here other then being a muck-around experiment to work my head around GameMaker scripting, so once you're done, press Escape to exit.  Occasionally it seems to freeze on collision which looks like a GameMaker issue (maybe?) but you can close the window and re-run it as it only seems to affect the game window and not the machine.

Now I'm on a roll...  Lets see where we can go from here.

More soon...

Read More

Pixel graphics... That whole retro vibe...

Thought I'd just post up a few snippets of info on the current 'NES'-ish style graphics from this project.  Its been interesting to think about making this feel less 'flat' and give it some pseudo-3D-ish style.  The concepts are all pretty simple, so I figure why not blog about it... :)

Pixel graphics

I'm still tossing up on final graphics once this proof-of-concept version is done (graphics of course are just the visuals on top of the game itself).  I kinda like the idea that an arcade theme have an old arcade style.

The sprites are all 16x16 pixel images.  For drawing them, I used GraphicsGale - its a Japanese tool.  There's a free edition, and it works very well.  I exported all of them out to transparent png's - and for making any edits I've been bringing the png's into Photoshop...

Design and style

I had run through a few different designs, and I actually did like the test one I started with (that my brother had drawn up on the ZX Spectrum).

However I wanted more an old-school arcade style, with smaller less detailed sprites.  The closest way to describe the design would be that it reminds me of very old NES style sprites...

Generic 16x16 guy...  4 frames per direction.

I like simple, though I'm also throwing about the idea of even lower-res graphics (maybe 8x8?) as well as slightly higher (64x64)...

A few random 'muck around' ideas...

To be honest, like everything to do with development the visual representation is a layer on top of the game code, so final look can be tweaked when things are closer to complete.  On the other hand, a lot of the python code I've written is related to the graphics - lol!

That less-2D feel

To get a little depth to the graphics, I drew the machines with a semi 'top down' feel.  Each machine was built up graphically in two tiles (though the machine 'tile' in the game is just one - sounds confusing, but its not really).

Dependent upon the direction of the machine, most of them had an extra 'upper section' that got drawn on top of the screen after the characters were drawn, covering the characters so they appear to walk behind the machines.

The down-facing machine on the other hand was the opposite.  I wanted the characters to walk in front of the machine, hence the tile below this machine I drew the front view of the machine before I drew the characters.

The basic 101 of drawing the arcade

The effect is fairly nice and feels much better then small arcade machine graphics in a single tile (they look way too small, as well as flat 2D).

Code-wise, it was fairly straightforward, however I did need some more logic when it came to machine direction - what was above, below and to each side - to test if I was supposed to draw an upper or lower half.  When there were side-facing machines next to each other, I created a top-of-machine sprite to represent the top of the next arcade machine (ie. rather than just drawing 2-tiles of a machine, and overlaying them (that's messy and wasting processing time)).

To optimize the drawing process for the top 'overlay' tiles and lower tiles, they were stored in a simple look-up tuple/list of (x,y) locations.  The basic arcade was drawn in a quick initial pass to blank out the place (including the characters), and only what was needed from the tuple/list was drawn on top/underneath.

So yup - its all go.  Once graphics are up and working, the motivation to keep moving forward with the game itself is refreshed.  Lots of fun, and plenty more stuff to do.

More soon.

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

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