Lachlan's misadventures in games programming

Monday, 12 December 2011

Ideas for art style

12/12/2011 11:54:00 pm Posted by Lachlan , No comments
I've been trying to work out what Jack should look like. Here is one idea:

A blueprint has the joint benefits of being simple to draw, and somewhat unique. I still don't know what the best way to implement switches etc would be. I could always do it as a blue print now, and make it more 16-bit pixelly later.

This is only an idea, which may or may not end up being implemented like this. But it honestly is an idea I like.

Thursday, 8 December 2011

Mighty Ascension of Jack Finished Design?

12/08/2011 12:39:00 am Posted by Lachlan , No comments
I think I've finished the design of the Mighty Ascension of Jack (the final level), though won't know for sure until it is made and playable. Furthermore, this is the last level that I will be designing for now unless any bolts of inspiration hit me, and my efforts now will be focussed on making these levels playable - including sound, graphics and most of all, programming. My design efforts will be largely limited to tweaking the design to better work with the code

The Mighty Ascension finishes now with a squish area with stop signs for timing, a small but elegant teleporter puzzle, a small life and a final subtle teleport. I don't know whether this will be fun or not, but I hope so. The whole bloomin thing, the level that is in scale, about 5 levels worth of level is reprinted below.

Monday, 5 December 2011

The Mighty Ascension of Jack

12/05/2011 11:03:00 pm Posted by Lachlan , No comments
Current status of the Mighty Ascension of Jack (Final Level)
I'm still working on the final level. You can see my latest work sitting on the top above the top red line.

I struggle with puzzle design... Maybe one or two parts to be added - but I do actually like the top bit.

Lets see what happens

Tuesday, 29 November 2011

The Mighty Ascension of Jack

11/29/2011 12:16:00 am Posted by Lachlan , No comments
The Final Level So Far
I'm still working on the final level. I've started working on the next stage. I had a pretty cool idea of what I wanted, but I don't think that I have quite got what I wanted, and that it may not be as much fun as I'd like it to be at the moment.

I think I might need to redo it. I'll see if I can improve it more a bit later.

Sunday, 27 November 2011

The Mighty Ascension of Jack

11/27/2011 02:09:00 am Posted by Lachlan , No comments
Part of (the only designed part of) "The Mighty Ascension of Jack"
I'm playing with the idea of making a big final level for my "Jack is a Fool" thing. Now - it's still my intention that what I release will be only about half an hour long, and only a fairly short game from which I can figure out whether its fun, and probably release it as freeware. It won't have graphics that it would if I turned it into a longer commercial indie game. But anyway. I digress.

Big final level. Portal has a phenomenal final level. In it, you use all the puzzle solving techniques you've used throughout the rest of the game to be able to finish a big epic amalgamation of the puzzles. Something nice and final. I think the idea of ascending to the surface in Portal 2 is brilliant too, and feels good. So - I've been thinking of combining the few styles of puzzles I'm using into one big final level that will have hopefully interlinked puzzles, a couple of checkpoints and something that will hopefully feel like a satisfactory finish even if the game is somewhat short.

So far, I've designed the grand total of what you can see above. In reality, it's about a third of the length as I'd like it to be, and currently has about 3 puzzles in it - linked by the big lift in the middle. I think, once I've finished designing it (at least to some level I'm remotely happy with), I'll call my "designs before programming" a day, and start working towards making them work.

Tuesday, 15 November 2011

Teleporting Levels

11/15/2011 06:54:00 pm Posted by Lachlan No comments
I've been experimenting with an idea for a new mechanic - even though I haven't really done that much with the 'Stop' one. But I got bored with it - so we'll add more as inspiration strikes. My new puzzle mechanic is teleporters. You can see how they will work below:
The idea is that when he's in a teleporter, you'll see a 'ghost' of where he would come out. You push the button, and he will teleport to the other side, in the same direction and speed he went in as if nothing happened - just at a different place. So far, I've designed one Introduction to Mechanic level ("For science. You monster."), one easier puzzle ("Teleprompter") and a very suddenly more difficult level (I think) ("Tower of eternal telefrags"). I may do some more of them.

For science. You monster.


Tower of eternal telefrags.

A notable limitation is that none of these levels incorporate any of the mechanics (other then being squashed) from earlier levels. I'm going to try to do a couple that particularly combine stop signs and teleporters. I also think that there needs to be a bit gentler of a transition to Tower of eternal telefrags - so adding another level there.

By my (admittedly baseless) estimate, the level designs will have about 21m of Gameplay time. When I actually program them, we'll see whether my estimates are close or way off. I'll probably stop the designing of levels (at least as my primary goal) when I reach about 30m - it should be long enough to discover whether it is fun or not. Either way, I should possibly avoid adding more mechanics, and see if I can make do with the 3 I already have. Though a fourth would be nice....

9 Actual Puzzles
3 Simple "Introduction to mechanic puzzles"
12 Total
None of them actually work in engine yet - all just designs.

Update 7:48PM
I've come up with a level that is a bit easier, and uses elements from all three groups of level - it's below. It uses bits of other levels just a bit. I think I need a couple more of these

Monday, 14 November 2011

2 New Levels

11/14/2011 07:43:00 pm Posted by Lachlan , No comments
First new level

Second new level
I've got two new level plans done. The first will work, the second may or may not be finishable; I'll verify in the next day or so. Which does mean one thing: I'm back on. Friday featured my last exam for the semester, so now I actually have some time to attempt to get the prototype of Jack out.

So - I'm back to trying to design enough puzzles to make me happy enough to make a prototype. Problem is - I have no idea how hard they will actually be to play. I know I'm struggling designing them as I have no experience in Puzzle design before.

We'll see.

7 Actual Puzzles
2 Simple "Introduction to mechanic puzzles"
9 Total
None of them actually work in engine yet - all just designs.

Saturday, 5 November 2011

[Non Games] Movember

11/05/2011 11:03:00 pm Posted by Lachlan No comments
Me, on the 30th of Movember. Hopefully.
I'm going to digress slightly off topic today and make a small request:
I'd really love for you to support me in Movember, and donate money for a pretty awesome cause, and for me to grow a pretty awesome moustache*.

If that was enough to convince you - please donate online at

If not - here is the official spiel: 


It’s Movember and time to focus on men’s health. To show my commitment, I’m donating my face to the cause by growing a moustache for the entire month of November, and need your support. My Mo will spark conversations, and no doubt generate some laughs; all in the name of raising vital awareness and funds for prostate cancer male depression.

Why am I so passionate about men’s health?
*1 in 9 men will be diagnosed with prostate cancer in their lifetime
*This year 20,000 new cases of the disease will be diagnosed
*1 in 8 men will experience depression in their lifetime

I’m asking you to support my Movember campaign by making a donation by either:
*Donating online at:
*Writing a cheque payable to ‘Movember,’ referencing my Registration ID: 807802 and mailing it to: Movember, PO Box 60, East Melbourne, VIC, 8002

Funds raised will help make a tangible difference to the lives of others. Through the Movember Foundation and its men’s health partners, the Prostate Cancer Foundation of Australia and beyondblue – the national depression initiative, they are funding world class research, educational and support programs which would otherwise not be possible.

If you’d like to find out more about the type of work you’d be helping to fund by supporting Movember, take a look at the Programs We Fund section on the Movember website:

Thank you in advance for supporting my efforts to change the face of men’s health. All donations over $2 are tax deductible.  
So yeah - please?

* History will show I've tried in the past. And I've grown a bit of hair above my top lip. But I'll try! I'll spend my afternoons trying to push more hair out - and try not to look like Max Payne in his first games in the process!

Tuesday, 1 November 2011

Temporary Hold of Proceedings

11/01/2011 12:54:00 pm Posted by Lachlan No comments
I'll be around, but not particularly productive with programming until at least next friday (The 11th) - Before then, I have a 2500 word case study on the Carbon Market due Friday (which will probably be made available on Scribd - potentially after further research), Competition law exam on the next Monday, Property law exam on Tuesday and a Civil Procedure exam on Friday. Its unlikely I'll be doing much other then work.

Meanwhile, however, I think after this date, I'll set a deadline to get the 'first taste' version of Jack is a Fool out - and see if it's fun enough to finish and sell.


Monday, 24 October 2011

Designing moving mazes is difficult!

10/24/2011 10:44:00 pm Posted by Lachlan , No comments
Today in an unrelated post, I heard it said that the poster hated blog posts that start with 'The Title Says It All' - after all, then there wouldn't need to be the rest of the post accompanying it. But still, as my title says, designing moving mazes is difficult!

For that matter, I'm finding designing puzzles difficult. I am finding it difficult to, without experience, judge the difficulty of the puzzles. What has taken me ages might indeed be a simple puzzle, and what I've been able to think was simple might be prohibitively difficult to actually solve as opposed to design.

But I'm actually struggling with this. Its a map I actually wanted to make - a maze that uses elevators to change the layout as you're going through it. What I've done is make a path, and then attempt to make a map that goes with it. I think the basic design is close - but it might be workable. I think I might try to make a timeline of it and see.

Hmmmm.... Lets see how workable this is

Update - 11.57 PM
I'm pretty sure it's solvable now. There's some changes from above. Questions are a) whether my thoughts that it is solvable is correct, b) whether it is practically solvable in the limited time and c) how difficult it actually is. We'll see once its coded up!

5 Actual Puzzles, 2 Simpler Introduction to mechanic Puzzles
Total 7 Puzzles

Friday, 21 October 2011

An open letter to Cyanide Studio regarding Securom

10/21/2011 03:11:00 pm Posted by Lachlan No comments
I make no secret of the fact I detest SecuROM. I detest intrusive DRM, but I have a special deep loathing for install activation limited games that treat me like a thief. It is a sad thing when a pirated copy ends up being a better copy then the actual purchased product - and a terrible way to encourage people to purchase your product. Its like the masses of unskippable ads and anti-piracy messages at the start of DVDs - I just bought your damn DVD and you're telling me in an unskippable manner that I shouldn't pirate the said video? If I pirated the damn thing, then I could just watch it! I will probably write a more full post on it later.

I bought Blood Bowl on sale late last month. I've finally downloaded it and installed it to discover that it's installed the SecuROM malware on my computer, and will use all of 5 activations with minor changes in my hardware or when I need to reformat after a crash if I lack the forsight to uninstall it (and everything else like it) manually before my computer crashes. It royally pisses me off when I feel treated like a thief when I've purchased a product. I just sent this open letter to Cyanide studio to the only address on their site I could find - . For what it's worth, I'm placing it in the public domain, so you are welcome to copy it when you feel ripped off by SecuROM or other anti-piracy measures, and so Cyanide have the opportunity to respond if they indeed care to.

To Whomsoever at Cyanide Studio this concerns,

I've just finally finished my Steam download and am really disappointed to find the inclusion of an install-limited version of Securom. I know that I should have seen it whilst purchasing the game - or more precisely, preventing me from purchasing the game, but now I feel really very ripped off, and just a little violated.

Given how secure SteamWorks as a non intrusive, account limited DRM is, are there any plans at all to release a DRM removal patch or switch it across to SteamWorks in the future? If not, could I please beg of you to consider it. Blood Bowl is past its peak of sales, and removal of the overly strict DRM in favour of a non-limited one (such as SteamWorks) could only possibly increase future sales - any quick search over the internet quickly reveals people unwilling to even buy the product at 80% off due to the limited activations of Securom.

As somebody who barely plays multiplayer games, I feel like I'm getting a worse quality product then if I pirated it. Which is really disappointing, because it looks like a fascinating game that I'm looking forward to playing - only, with my consistent reformats as a minor game developer myself, it looks like I won't be able to play it long. I understand that there is a de-activation/uninstallation tool, however I don't understand why it is necessary to treat me like a thief when I do the right thing and purchase your game. And I shouldn't have to do a full restart because I'm running some tools I use to develop that happen to be detected by SecuROM - your game isn't the only thing I use my system for.

I've seen various people state that you care about customer feedback - and I beg of you to consider this piece of it. Until you remove SecuROM, I won't be purchasing any more of your games - which is disappointing because you seem to have some original games. I'll simply have to go without.

Yours legally and legitimately

Lachlan Kingsford

Thursday, 20 October 2011

Jack is a Fool - Puzzle Progress - Update on Squish Time!

10/20/2011 09:15:00 am Posted by Lachlan No comments

Turns out yesterday's puzzle wasn't necessarily solvable. I've adjusted the position of each of the platforms, and now it is.

I calculated new positions using a copy of Calc (basically as fancy pen and paper), starting with the final position and backtracked 5 positions.

Next puzzle!

Wednesday, 19 October 2011

Jack is a Fool - Puzzle Progress

10/19/2011 10:46:00 pm Posted by Lachlan No comments

Just a brief update on progress of puzzles.

Turns out one of the puzzle ideas was if not bad, very difficult to execute (as in, fully design). It was an idea for a kind of moving maze. I'll wait until I can think about it more - but I still like the idea.

I've been working on another puzzle inspired by the valves puzzle (with the wheelburrow) in Grim Fandango though its turned out nothing like it. I'm trying to think of a simple thing that a couple of buttons could do to the moving platforms to make it a puzzling and solvable challenge to make them all align. I'm just not quite sure yet. The puzzle as stands is below - though may change totally.
I'll update when I've done just a little more.

---UPDATE - 11:03PM ---

I think I've made my puzzle. 
Please Click for the detail

The idea is that the platforms are going really fairly quickly and hence will squash jack unless they're put in the right order (maybe - 3 in line then 2 in line) - though this isn't so important. I can't test it yet anyway.

You put them in the right order with the Navy, Blue and Green buttons. The navy one pauses A C and E, the blue one B D & E and the green one A C & D. They each pause for everything else to make one quarter of the journey - I've marked out the distance with x.

Problem is - whilst I like the idea, I don't know how many moves (or indeed even if - though I stronly suspect so) it will take to be solved. So - I'll solve my puzzle tomorrow to be sure.

I like the idea of the level though - looks challenging.


Saturday, 15 October 2011

Jack is a Fool - Potential use for platform engine

10/15/2011 01:13:00 am Posted by Lachlan , No comments

I've started toying with an idea to use with the Platform Engine. It's called 'Jack is a Fool'.

In Jack is a Fool, you won't control Jack directly at all. Instead, you'll control the machinery around him, to try to successfully get him to the exit. Think something along the lines of lemmings, where you control floating platforms to stop Jack falling in holes, and move doors around to get him through mazes. It will be almost a pure puzzle game - that happens to be with a guy who walks on platforms.

I've started doing some design drawings of levels etc. to figure out how viable this idea is in LibreOffice Draw. So far, I've designed 2 basic non interactive 'levels' (which will be a grand total of being a more entertaining way to write 'Nerdy Gentleman Games Presents' and on the next one 'Jack is a Fool' while introducing the basic start of gameplay). I've designed 1 basic level to demonstrate the moving mechanic.

I've finally so far designed 2 actual puzzles - I don't count the others as puzzles at all. The first involves moving lift doors and a lift to get Jack to the top of the level, and the second moving a series of platforms to get Jack to the other side without crushing him, or allowing him to fall off. Both are just design ideas, and as such don't look like what actual gameplay would. For your benefit, they're included below.
First fully designed level
Second fully designed level
I've got ideas for a couple of other mechanics I could add for puzzles, and a couple of unfleshed ideas I could use for the mechanics already introduced. I want to get to somewhere between 10 and 20 puzzles (probably closer to 10) before focussing on implementing the features they need, and seeing if gameplay is fun. If it is, I may more fully finish the game. If I can't figure out interesting puzzles, I won't bother.


Saturday, 8 October 2011

Platform Progress - Saving and loading levels

10/08/2011 05:45:00 pm Posted by Lachlan No comments
Wow... 3 posts in one day!? But - achievements get posts.

I can now save and load levels! So:
FatController bind_wing_keys K_LEFT "Actor inst 100" K_RIGHT "Actor inst 101" "Actor inst 102"
FatController bind_key_down K_SPACE "Actor inst 103"
FatController bind_key_up K_SPACE "Actor inst 104"
FatController bind_key_down K_ESCAPE "Game quit_signal"
FatController bind_key_down K_BACKQUOTE "Game toggle_console"
FatController bind_key_down K_e "Game toggle_editor"

run "level" "levels"

Game gravity_ddy = 400;
Game gravity_max_dy = 500;
Game gravity_ddx = 0;
Game gravity_max_dx = 0;



Game new_feature "f_1" 
x1 = -20
x2 = 600
y1 = 500
y2 = 550
z = 0
collision_function = 1
visible = 1

Game new_feature "f_2" "f_1"
x1 = 150
x2 = 200
y1 = 450
y2 = 500
z = 0
collision_function = 1
visible = 1

Game new_feature "f_3" "f_1"
x1 = 700
x2 = 1500
y1 = 500
y2 = 550
z = 0
collision_function = 1
visible = 1

Game new_feature "f_4" "f_1"
x1 = 900
x2 = 950
y1 = 400
y2 = 500
z = 0
collision_function = 1
visible = 1

Game new_feature "f_5" "f_1"
x1 = 500
x2 = 800
y1 = 350
y2 = 400
z = 0
collision_function = 1
visible = 1

lead to an end result of:

Note - as well, this script is the actual save file, and was saved from within the game! Boo yeah!

Platform Progress - SLOC

10/08/2011 12:54:00 pm Posted by Lachlan No comments
If its your sort of thing:

Files 70
Lines 5460
Statements 3117
% Branches 21.8
% Comments 3.1
Class Defs 32
Methods/Class 9.44
Avg Stmts/Method 6.1
Max Complexity 46
Max Depth 9+
Avg Depth 1.88
Avg Complexity 2.75
Functions 12

Platform Progress - Scripts Ahoy!

10/08/2011 12:12:00 pm Posted by Lachlan No comments

I've started the process of being able to load scripts from files and (am working towards at the moment), saving them to files. As of Thursday, it loads (most of) the keyboard configuration from a script file. This script file, actually:

FatController bind_wing_keys K_LEFT "Actor inst 100" K_RIGHT "Actor inst 101" "Actor inst 102"
FatController bind_key_down K_SPACE "Actor inst 103"
FatController bind_key_up K_SPACE "Actor inst 104"
FatController bind_key_down K_ESCAPE "Game quit_signal"
FatController bind_key_down K_BACKQUOTE "Game toggle_console"
FatController bind_key_down K_e "Game toggle_editor"

This is important for a couple of reasons. The primary one is that levels are to be saved as a script which contains instructions on building levels - I've got recipe's being generated already, now I'm ensuring that I can save them.

The first step of this project was adjusting the PuppetMaster's Process Command thing to take multiple commands by splitting it by newlines and semicolons (though, in the case of the latter, providing that they're not within double-quote marks). I decided to use the same method I have for actually processing commands -  using an overly complex RegEx command that I barely understand, as processed by boost::regex.  The RegEx function I ended up using is:

The sad thing is, I'm not entirely certain how this works except it does when I run it through "The RegEx Coach" (excellent piece of software btw). In reality though, RegEx seems to me to be a return to the archaic language of APL (see Wikipedia to see why I make this comparison). It's an ol' APL proverb that:
'Tis every programmers goal in life
Before his race is run
To write three lines of APL
And make the damned thing run!'

Friday, 30 September 2011

War of the Apocalypse Samurai - A Potential Plot?

9/30/2011 02:52:00 pm Posted by Lachlan , No comments

I've had a general idea of what I'd like War of the Apocalypse Samurai to be for quite some time - a prince of persia-ery sword fighting platform game owing heavy inspiration to Samurai and Revisionist Western Films (ie. Kill Bill Volume 1 and Volume 2 Respectively). I've never had a story that would tie it together.

I think I do now. I've been playing with the idea of using the platform engine to make a James Bond-ish game.  During this week I concluded that it would be a good idea for such a game to be set in a fictional version of the 1960s - middle of the Cold War. One thing has lead to another, and now I have an idea for the Samurai Game I want which is at once plausible (given the ridiculous world) and very pulpy.

In 196-, the soviets were losing the cold war. Fearing the possibility of losing a nuclear war, and unable to afford to continue to build a brand new nuclear arsenal, the soviets train and hire the 4 greatest warriors living for $250000 (~$1.8m in today's currency) each, organises and trains them as the Apocalypse Samurai and places them around the world to be able to identify and kill any person on the planet within 5 hours. A credible threat to be able to retaliate to any nuclear attack without having to just bomb a civilian population.

Unfortunately, they overestimated the inhumanity of their anonymous elite force and directed War to kill her father. She defected to the US and was further trained and offered complete immunity to remove the Apocalypse Samurai from the world, and the Dragon who controls them. The game would consist of finding and killing each of the Samurai and finally the Dragon and the Beast across the whole world.

I like this idea. I want to see how well this could work...

Wednesday, 28 September 2011

Platform Progress - Collision Detection Sucks

9/28/2011 03:27:00 pm Posted by Lachlan , No comments
Those red boxes? The things you can collide with. The white box?  You. Simple looking I know - but slowly getting there
I've been wrestling with collision detection quite extensively over the last week and a bit (and a bit more). I've had varying things working, but they either partially work by colliding well and not necessarily putting the actor back quite where it needs to go, or getting stuck in walls, and generally not being able to register as a collision when they're just touching - or freezing the box if it could.

I've ended up using a simplified case of the technique in - it's the one they use for 'N'. If I end up adding ramps or anything I may have to do it in more detail, but it seems to work. However, the code wasn't liberal enough in detection of collision where the platform and actor are just touching - without overlap. So, I've added a simple, more liberal check at the end. Code is below, if it's your sort of thing or you need help doing something similar.

  1 void Feature::TotalCollision(Actor* actor, float dt)
  2     //Method described in this... partially
  3     //
  4 {
  5     //These shouldn't be using typecast x1() but instead x - w/2 or something - Maybe
  6     //This may change if features start being defined by x, w, y & h rather then
  7     //w and h being calculated and the feature being defined by (x1, y1) and (x2, y2).
  8     float left_a = actor->x() - (actor->w() / 2);
  9     float left_f = (float)x1();
 10     float right_a = actor->x() + (actor->w() / 2);
 11     float right_f = (float)x2();
 12     float top_a = actor->y() - (actor->h() / 2);
 13     float top_f = (float)y1();
 14     float bottom_a = actor->y() + (actor->h() / 2);
 15     float bottom_f = (float)y2();
 16     float midx_f = (left_f + right_f) / 2;
 17     float midy_f = (top_f + bottom_f) / 2;
 19     //bool colliding = Collides(left_a, right_a, top_a, bottom_a, left_f, right_f, top_f, bottom_f);
 21     bool colliding = true;
 23     if (bottom_a <= top_f) { colliding = false; };
 24     if (top_a >= bottom_f) { colliding = false; };
 25     if (right_a <= left_f) { colliding = false; };
 26     if (left_a >= right_f) { colliding = false; };
 29     if (colliding)
 30     {
 31         float x_overlap = (actor->x() > midx_f) ? left_a - right_f : right_a - left_f;
 32         float y_overlap = (actor->y() > midy_f) ? top_a - bottom_f : bottom_a - top_f;
 33         if (std::abs(x_overlap) > std::abs(y_overlap))
 34         {
 35             actor->set_y(actor->y() - y_overlap);    
 36             actor->set_dy(0);        
 37             actor->set_v_collided (true);
 38         }
 39         else
 40         {
 41             actor->set_x(actor->x() - x_overlap);
 42             actor->set_dx(0);        
 43             actor->set_h_collided (true);
 44         }        
 45     }
 47     //These fill the special case uncovered by the above where there needs to be a collision
 48     //for whether or not we can jump or not, but the code doesn't need to move the actor
 49     if
 50     (
 51         ((bottom_a == top_f) || (bottom_f == top_a)) &&
 52         !((left_a > right_f) || (right_a < left_f))
 53     ) 
 54     {
 55         actor->set_v_collided(true) ;
 56     } ;
 58     if
 59     (
 60         ((right_a == left_f) || (right_f == left_a)) &&
 61         !((top_a > bottom_f) || (bottom_a < top_f))
 62     ) 
 63     {
 64         actor->set_h_collided(true) ;
 65     } ;
 67 }

By the way - if any of you know a good, easy way to highlight code for blogs - preferably an online utility, I'd really appreciate knowing it.


Tuesday, 27 September 2011

Super Mario Bros: How Nintendo taught players the mechanics without a tutorial in Worlds 1-1 to 1-3.

9/27/2011 01:55:00 am Posted by Lachlan , , 1 comment

After some excellent company watching Flying High! and MASH (the movie), as well as excellent pizza from Gary at International Pizza in Montmorency, I set my mind at playing some of Super Mario Bros on the NES... or an emulated version thereof at any rate. During which, I learnt a few things:

  1.  Don't try to take screenshots through Nestopia with filters enabled. I had the NTSC filter for some old style scaling and colour bleed, but it ended up really squashed and odd
  2. Nintendo games rightfully deserve their reputation for difficulty. But, I made it to the end of the second world without losing a single life, and to the castle in the third world before losing the game. Fun fact: I've been spoiled by the SNES 'Super Mario Bros All Stars' versions of these games. I was expecting to start at the start of the world. Second Fun Fact: You don't. Also - I think the physics are noticeably different between All Stars and the original.
  3. The first few levels are brilliant game design.
I'm going to focus on Point #2. If what you want is difficulty, look at SMB 'The Lost Levels' or Super Meat Boy - I'm not in the mood to discuss it. And not good enough at platformers to discuss it anyway.

Super Mario Bros. has no tutorial. It has never needed one. I would, of course assume that it came with a manual - but even that (as you will soon bare witness) is not even required. I will clarify that the controls were made more intuitive by the fact that the control consisted solely of a D-Pad (The plus shaped thing with arrows on it for you non-gamer sorts), a select button, a start button, an A button and a B button. Controls weren't difficult to remember or even simply figure out. But they were improved by excellent early level design.

I'm going to demonstrate to you that the game teaches you how to play it, by playing it through the first few levels (particularly just World 1), and expose to you some of the brilliance. I'd like to forewarn that tutorial means teaches you how to play the game - not how to play it well.

World 1-1

This is about the first thing the player sees. He either runs into the Goomba and dies - and learns he can't run into the Goomba, or he successfully jumps over it. He'll usually in the process hit one of the ? blocks, and see coins come out with little numbers. You see the points go up, you see coins go up, you've been rewarded and you know that ? blocks can be rewarding.
So, you move forward, and find another couple of ? blocks, and the first has a Mushroom in it! Note how the location of the pipe means that the mushroom comes back to you, and that you actually require effort to avoid the mushroom. doesn't just fall off the screen. The Mushroom makes you bigger, at you'll probably figure out that you can now break the   Bricks.

You come across more pipes. You may figure out you can go down select pipes, you may not. I don't have a copy of the manual to check whether it hinted it or not. There is no indicator - and the first pipe doesn't let you so... brilliance has its exceptions. Or, we just take it as an old fashioned secret.

More Goomba's after returning from the secret area...

There's a staircase, and the flag. The flag moves to wherever you hit the pole which provides some feedback that higher is better. And the design of the level (staircase) hints that you should try to hit the top too.

World 1-2
A hint that something is different. At least it clearly takes control of Mario from the moment the character appears on screen.

This pair of Goomba's are the first indication that you can jump on two things successively for more points. Most people will do this on their first or second playthrough and learn.

Moving forward somewhat, you get the first clear indication (if you're still lucky/skilled enough to be big) that you can destroy blocks - as you're forced to. You also get the first introduction to turtles, and their mechanic of being able to jump on their shells.
You also get a sighting that there are the things that come out of pipes at a safe enough distance to guarantee survival - and they stop coming if you come too close. It's a good way of introducing the new enemy.

The level then introduces, in a very limited quantity, the first moving platforms. These become particularly important in the next level. You can't avoid them, forcing the player to learn of their safety.

World 1-3
Very brief comments. The world introduces the new platforms gently. Players have already encountered green turtles, but not red turtles - who turn around at the edges of platforms. The game introduces this by putting a turtle that is generally almost close to the end up top very close to the end of its platform (hence making the player feel that the turtle is going to land on the player) before the player sees it turn around. Red Turtles are used extensively in the level to emphasise the gameplay mechanic.

Studios seem to have lost the art of teaching players to play the game without an overly basic, trivial tutorial - or worse uninteractive video's. I might discuss this again. But, there are exceptions.

These problems have been most successfully avoided by Valve. I can list 3 very clear examples where Valve has been able to teach players the mechanics of the game effectively without a tutorial - being Half Life 2, Portal and Team Fortress 2. The latter two are particularly notable as Valve's customer-centric tester-centric approach to game design can most clearly be seen. If you own either game, I highly recommend playing the audio commentaries to understand how the games were designed. I was going to write more about the subject, but it is late and I'm tired. I may discuss it again later.


Tuesday, 20 September 2011

Platform Progress - Moving White Boxes - With Control!

9/20/2011 02:42:00 pm Posted by Lachlan No comments
I've got movement working! I've made a new class called 'FatController' who can get key-bindings and issue commands. There are a couple of odd things with Collision (half fixed), and you can jump when you're not on ground - but both of those problems will be fixed this afternoon.

I did do one kind of cool thing with FatController - in addition to the typical bindings of KeyUp and KeyDown I added a new set WingKey - so buttons like Left/Right which only one can be down at a time work. The KeyDown is called when it changes, and when you take a key off it goes back to the other one if it's still down, or calls the KeyUp if its not.

Video might be coming soon. If I can get the stupid thing to work... Either way - it's not that impressive.

But it works.

Friday, 16 September 2011

Ancient CRT Emulation

9/16/2011 03:21:00 pm Posted by Lachlan No comments
I was playing around with some idea's today about making stuff look early CRT era old. I was partially inspired by playing wee bits of fallout 2, and this article on SNES emulation - and making it work accurately rather then conveniently.

I tried to make a couple of screenshot mockups to see what could happen - not with anything I'll make (at the moment), but to see what kind of styles we could go for. I came up with these:

Completely original - except letters used from 
The infamous Doom title screen. Zoom in (click) for the detail
The first of these was just an idea for a piece of tiny art that I brought to fruition. The details are similar to the Doom one, which I'll explain more fully. The Doom one was me seeing what I could do to make something look old. I recommend zooming in.

What I did (all in Gimp)
- Started with the 320x240 resolution picture of the Doom title screen
- Resized it with no interpolation (ie. just making to blocks bigger) to 1280x960
- Colourised it to Amber
- Changed the colour curve to make it almost (but not quite) 4 colour - this works because the analogue screen I'm trying to emulate does have some transition between the 4 colours (but still actually 4 colours - just slightly more... antialiased) ... or something like that
- Duplicated the layer
- Blurred the top layer (lightly)
- Blurred the bottom layer more
- Added the lines at 40% opacity with a fill tool with a pattern on the top layer
- Merged layers
- Applied the lens distortion effect

It still could do with a few things to make it look more real - the colour still isn't quite right, the scanlines are in reality partially horizontal as well as vertical, there are little grey dots near the corners I couldn't be bothered with fixing and there could be some reflection on the screen, and maybe a little darker towards the edges.

I'd be fascinated to see if I could get this to run in real-time - though, I doubt it would be even remotely possible without lots of pixel shaders. It'd be fantastic to do though for a retro styled game. It's ironic it requires so much clockpower to make something look so old.


Platform Progress - Moving White Boxes - With Gravity and Collision!

9/16/2011 01:44:00 am Posted by Lachlan No comments
I've decided I'm going to post a basic list of things I'm doing whenever I'm doing them. I'm going to do some ol' fashioned devlogging. Maybe...

For those of you who never do maths, I use Δ a few times in this devlog. It is the greek letter Delta meaning (in this concept) the rate of change. ΔΔ means the rate of change, of the rate of change.

As of today, I have some working collision detection. Its not perfect yet, so if  Δx, Δy or Δt are too severe, it'll end up with the sprite either hovering or getting stuck. Maybe - I haven't got it stuck yet. Each Feature (which might be a platform or many other things) has a collision function which is as of right now either kNone or kTotal. The former being don't collide with this at all, the latter being everything collides with every facet of it. These will be expanded on later.

I've also got some basic gravity working. I define a ΔΔx and ΔΔy for gravity purposes, and a max Δx and Δy due to gravity. The result being that my white box speeds up until it reaches the max speed I've set for objects in the world, and then keeps going while the program runs, or the box runs into a feature.

A productive evening.

I've also included my current source metrics below - if that's your sort of thing. I might put it up a little more often. There won't be much from me until at least next week, owing to a take-home exam on property law over the weekend. There is a good chance of a couple of reviews coming soon. They'll likely be for:
- Rock of Ages
- Jamestown
Without giving a full review, both are cheap, fun, worthwhile and fantastic for split screen multiplayer.

Maybe also Grim Fandango - or maybe a 'Let's Play' - I dunno. Either way, it is my absolute favourite game of all time, and I highly recommend you play it (probably through Residual to get it working on a modern computer)

Cordially and Nerdily Yours,


Current Stats:

Files 62
Lines 4472
Statements 2552
% Branches 22.5
% Comments 2.9
Class Defs 28
Methods/Class 8.79
Avg Stmts/Method 6
Max Complexity 47
Max Depth 9+
Avg Depth 2
Avg Complexity 2.82
Functions 9

Wednesday, 14 September 2011

Platform Progress - Moving White Boxes

9/14/2011 06:13:00 pm Posted by Lachlan No comments
I sense that having a good design before you start would help. Unfortunately, I doubt that is going to happen yet - mostly 'cause I have very little clue, most of the time. It would make adding more stuff easier.

I didn't think I would need Floating Point numbers when I started being able to be handled by my PuppetMaster - turns out I did. The code made a mess. The reason for all this was, I'm beginning to add 'Actors' - players, monsters etc. At the moment, this means just a white box. A white box that due to my incompetence spent quite some time being debugged this afternoon!

Result: I now have a moving white box, that will maintain pace regardless of framerate. I'm going to start dealing with logic for it soon.

Btw - apologies for running so slowly. I get distracted, and have had a take-home exam to prepare for and do over the last week or so.

Some more reviews might be coming soon though.


Friday, 2 September 2011

Platform Progress

9/02/2011 11:51:00 am Posted by Lachlan No comments
I'm slowly progressing with my platform engine - working toward getting the basis of the editor working. As of yesterday, I can finally create new platforms by cloning other platforms. I'm working on getting the platforms to be able to generate their own 'recipes' so I will be able to save the maps and load them again.

The engine is actually fairly odd. Lots of things are stored in std::map's with strings. The whole thing is built around the PuppetMaster. Greenspun's Tenth Rule (though there are no proceeding laws) states that Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I'm slowly seeing this become true with my platform engine. It makes at least a minimal amount of sense to me, but I'm not always really certain I've done everything the best way - as can be expected from somebody who hasn't written much like this before. It's interesting just how much time I've been spending on the editor (which will still be buggy, and likely unfit for public consumption) because as I'm building it, I'm building the infrastructure. I'm not sure yet how I'm going to handle some of the odder things specifically related to platform games - like movement functions. It is my intention to build all of these out of the same feature rather then using polymorphism as I want to be able to create new types of platforms and features without changing code. I am considering whether I could add lua scripts as an alternative, though they may be slower.

Once I get this stuff down at least basically, I'm going to start dealing with Player-Characters/Actors/Monsters etc. Then I'm going to make a basic proof of concept game to test the engine. It will likely end up being a clone of World 1-1 of the original Super Mario Bros - or something like that.

Then I'll start working on the next full game. I've had a few concepts that I'll detail soon.


Monday, 18 July 2011

Platform Progress - Consoles

7/18/2011 01:56:00 pm Posted by Lachlan , , No comments

I've spent the last few days getting the console up and running. And it does.

Thus far, it can now access and manipulate things in classes which are exposed to it. For instance, the Game class is exposed to the 'Puppetmaster' (as I've dubbed it). If I load the console (Quake 1 style - by pushing ~), I can check what the cameras x value is by typing
Game camera_x
which will then return something along the lines of
I can also set camera_x in much the same way
Game camera_x = 30
This is advantageous because it is laying the foundation for me to be able to change the game without having to recompile. If I want new types of platforms etc, I may need to add them in C++ code. However, I'll be able to place them and modify them within the game itself (or in the editor of the game - which is currently (and will stay) in the same source as the game). The program is also going to use the triggers and console itself - in what may not be particularly efficient, but is going to make my job easier. For instance, I will add a Trigger underneath a block which tells the PuppetMaster that it's time for the block to the fall.

And so far it works!

Part of this has been learning to use the boost library - which I'm impressed with. I'm impressed with how consistent it is with the C++ STL itself - accessing regex results is done exactly the same way with iterators as any of the STL containers. I'm also finding boost::lexicalcast<> an absolute lifesaver.

I'm thinking next will be a very basic GUI for accessing code and using triggers that will operate through the PuppetMaster to make my life easier. Either that or just adding the template dude to make him jump around...

Wednesday, 13 July 2011

(Yet to be determined) Platform Game

7/13/2011 03:41:00 pm Posted by Lachlan No comments

You might be prone to ask 'What has Lachlan been doing since we saw the release of The (lite) night the Martians Came?' 'What masterful example of gaming is coming next?'

For a while, it looked like it might be soccer. But it's not. I've started programming a platform game of some form. I'm not sure whether this is the start of the codebase of 'The War of the Apocalypse Samurai' or not yet - but it is a platform game. I'm writing the level editor in the same engine as actual game to hopefully make it easier to keep making the game.

So far, it does a grand total of render platforms (ie. plain, red rectangles bordered by a slighter lighter red). The editor also allows you to add platforms by switching into editor mode (e) and placing a platform (p). I've started work on a console as well - which will be fairly important 'cause all scripted events, and most properties of platforms/moving things/actors etc will be changable by the console and the so-called GUI of the editor will mostly be links to the console.

At the moment, everything is going to be simply rendered as boxes until the game is playable and maybe even a little fun. Then I'll start worrying about looks.

I've no idea where or how this will finish. But the goal is set: A platform game - of some kind. Even if I do use it for War, it is likely a more simple game will be made first.

Wednesday, 29 June 2011

Prototype Graphics

6/29/2011 12:52:00 am Posted by Lachlan No comments

I've heard it said before that most people who attempt to make indie games are generally either Artists (of some form), or Programmers. When they're people like me - making games by themselves, that generally involves loving one and struggling through the other - Programmers need art for their games to look pretty (unless they're making a Roguelike or Old-School Interactive Fiction), and Artists need programming to bring their pieces to life. Unfortunately, I lean towards being a programmer, and I'm not particularly good at either. Except music - and even then, generally outside the realm of Video Game music.

I've got a few ideas for what I'd like to make next. Unfortunately, they inevitably involve needing artwork of people. So - I've made the first version of my Prototype Dude. He's made in inkscape in a nice, scalable vector format. He is simple to edit, and simple to change, and simple to modify to new purposes. I think I'll use him when programming these learning things, and the prototypes of games to see whether they are fun or not. If I decide to go all the way with one, and try to make it commercial, then I'll either embrace the simplistic style or replace the graphics with more complex art - which may, or may not be done by me.

So far, I've done a Walk-cycle. Its an old-school 3 frame walkcycle - which doesn't look great at higher resolutions but is certainly passable. I might bump it up (particularly the side walking) to 5 or 8 frames later.

This is him so far. He may be updated, but its a start. If anybody would like me to put up the SVG for you to use, let me know.

Saturday, 18 June 2011

The (Lite) Night The Martians Came Released! (v0.1)

6/18/2011 09:18:00 pm Posted by Lachlan 1 comment

My fully playable space invaders... tribute "The (lite) Night The Martians Came" is now playable by you. They get harder, they get faster. Staying alive will be an issue for you :). Feel welcome to post your high scores here - which may be a challenge 'cause each level gets faster too.

To install, just download, and unzip, and run 'The Lite Night The Martians Came'. Mouse or arrows move the ship. Clicking or pretty much every button except escape or f fires. Escape pauses, f goes to full screen.

You can download it from here.

I've seen this more then anybody... obviously

I've implemented almost every feature that I think needs to be implemented for a playable, and remotely enjoyable game. I might still add a few things, or make some changes but that's why I'm calling this the beta. I've learned a lot about C++ but the code itself whilst not buggy, is in a sorry state from having not really designed it. It'll be a pain to long term maintain - though there are distinct chunks of it I'll be able to use again. The code bounces all over the place, and isn't really well split into classes. But the thing works.
The source is an absolute mess - but I may release it too. Just not today.

Again, you can download it from here.

Update: 19/06/11 1:02AM

Something appears to be screwy when on XP. Everything points to a missing DLL but I can't figure out what it is. It should work if you have the VC++ 2010 Runtime installed, but I'm not convinced. If anyone has a clue how to fix it, please let me know.

Update: 19/06/11 12:15PM
I fixed the problem. Something related to manifests etc - and at least one library compiled against Visual Studio 2005 runtimes. I've updated the download - it should work on XP.