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

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