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

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

The first post!

Well, I had to start somewhere!

Welcome to my Arcadia blog.  At the time of this post, the theme I installed is still untouched, so if you've ended up here and wondered what all those crazy default menus are about...  Sorry, I'll get on to those asap!  (Mind you, by the time you read this its likely I will have updated a few things)

Arcadia is a space where I want to share some of my own personal tips, thoughts and historical memories about a little of everything related to (mostly retro) gaming development.  That may be snippets of old-school programming mentality, or it may be a look back at a classic game from my past, or links to interesting articles.

As well as that, its also a space for documenting the process and production as I work my way through the development of my own personal gaming projects. Right now, I'm developing (proof-of-concepting at least) a game - a sort of arcade arcade game (double-arcade...  now that sounds like double the fun! lol!).

For now I'll refer it as 'myCade' (not a final title, but I have to give it something, right?)

"myCade" - Ancient Influences

My main inspiration for this game (once I start blogging about it) was an old Apple ][ game called Spare Change, released by Broderbund Software back in 1983.

Nothing says more retro then classic green screen!

In the game, you filled up machines with tokens, and then would collect them back out of the machines...  There were two characters (Zerks) in the arcade who would run around and steal the tokens and place them into a piggy bank.

Your goal was to collect the tokens to get to the next level.  Of course, as you collected tokens, the machines would run out and you'd have to refill them.  If the other characters managed to fill their piggy bank, the game was over.  You could distract them for a short while by placing a token into a phone (one of them would pick up the phone and have a conversation), jukebox (they'd go and dance about) and later a popcorn machine.

You would eventually collect all the tokens from machines, and need to go to the till to collect more to load up the machines.  Problem is, the till only has a finite amount of tokens in the till, and you would occasionally need to go to the safe to fill up the till again.

There was only so many tokens that the machines would take before they were out of service.  When that happens, you'd lose the tokens you placed in and its one less machine that is active.

When you think about it, it does seem a somewhat odd game idea, but the cartoon antics of the Zerks (you'd get to see a variety of different Zerk Show's - short animated sequences - as you completed levels), plus the challenge of collecting as many tokens as you could before they bet you was quite addictive.  You know its a good game if the memories of it stick with you for 35+ years.

No - I'm not out to create a modern version of the game, just one inspired by its arcade theme.

myCade as I've mentioned is just a working title for now.  I'll post up more about the actual game in a later post once I get something completed and ready to talk about. For now, I'll just keep it under wraps (ahem, well, until I actually have something to show ;-) )

The Nerd factor...

My goal at this stage is to prototype using Python and pygame.  I'm a pretty old-school programmer - my roots set in the 80's where you invented and wrote your own games - before the booming industry it is today.  It was a different world back then, and I like the feeling of just coding the whole thing from scratch rather then use a game development tool that takes away the nerdy fun.

Well, that and to be honest I just love toying in Python for my 3D work as well as punching out the odd retro game just for kicks...  Though I will eventually take that prototype across to a more mobile platform. No escaping the modern world forever...

As mentioned, Arcadia is also a space where I will post up some snippets and tips - there's definitely a few things as I code that I'm sure may be of interest to others...

Anyway, enough waffle for now.  My day job as a 3D animation and VFX tutor has picked up again (a whole new class for the year) so life will be busier which may make this a slow blog, but lets see where the year takes us.  Until the next post...

Read More