Our New Blog

I feel like it’s worth making a little post here now that we’ve revamped things a little. I was working on a something a few days ago, and found myself wanting to include a link to Voltic. I opened it up and sighed to myself, “Oh, yeah, that’s what it looks like”. The prospects of linking to an infrequently updated site with very little useful content didn’t fill me with enthusiasm.

I decided to say goodbye to wordpress, and use tumblr for our blogging needs. I also replaced the existing multi-page site with a simple single page design featuring who we are, our games and how to keep up with what we’re doing.

For anyone technically included, I built the site in a couple hours using HTML5 Boilerplate and Bootstrap 3.

Hopefully having a light-weight site and update platform will lead us to being a little more active. That remains to be seen, though.

Proof Devlog 3 - Ready, Set, Action!

The following post was originally created on Septemer 12, 2014

Since there was a fairly positive reaction to the last writeup I did, regarding our lighting, I thought I would write another piece corresponding to what I’m doing right now.

When we set out to make Proof, we knew that cutscenes would play a big part of the game (since it’s actually story centric, an unusual turn for us). This lead us to have to make some very difficult decisions regarding the implementation of scripted events. We came to a list of things we required:

  • Not an external language (binding all the functions would take too much time)
  • Syntactically light and logical
  • Flexible and easily extensible in specific cases
  • Possibly allow player to retain control during the scene
  • Allow other game objects to continue updating during scene

How did we achieve these?

ActionScript supports functional programming! Our cutscenes are defined as a list of functions, here’s an example of a defined scene.

public function FirstCutscene()
{
    super();

    addStep(panCamera, [320, 180, 0.001]);
    addStep(waitForTime, [4]);
    addStep(say, ["Proof"]);
    addStep(fadeToBlack);
    addStep(waitForTime, [4]);
    addStep(fadeFromBlack);
    addStep(waitForTime, [2]);
    addStep(crackBlock);
    addStep(waitForTime, [2]);
    addStep(fallBlock);
    addStep(waitForTime, [0.5]);
    addStep(changeLightBeam);
    addStep(end, [true, true]);
}

So, what you might notice right away here is the slightly non-standard syntax. AS3 doesn’t allow me to define an arbitrary number of arguments for each function I’m calling. The system passes the array of arguments as one actual argument, and the functions have to be smart enough not to access non-existent indices. (This can be done with varargs, but the performance suffers apparently and it provides no more documentation than this does).

Underneath this is a simple Stack implemented using a Vector (built in AS3 type) that just plays the next step until it’s told to move on.

/**
 * Add a new step to the cutscene list. 
 * @param f Functionality
 * @param p Parameter Array
 * 
 */     
protected function addStep(f:Function, p:Array=null):void
{
    stepList.push(f);
    paramList.push(p);
}

One might suggest that the parameter array and the function reference should be paired and use one stack, it makes little difference here from my perspective.

The functions themselves don’t actually get called in the way one might expect either,

protected function waitForKey(p:Array):void
{   
    if (Input.pressed(p[0])) nextStep = true;
}

Looking at this, you might be able to guess how it works - but I’ll explain anyway. The Cutscene handler calls the step once-per-frame until it decides to say nextStep = true, at which point it visits the next step. This has many benefits, one is obviously shown above (trivial to implement a wait) but this also means that the game’s update loop continues to run during every cutscene.

This is not particularly self documenting sadly, so commenting becomes very important (including a TODO and a magic number, I’m not perfect okay!):

/**
 * Displays an image on screen, in front of everything else.
 * @param p [image, x, y, width, height]
 * 
 */     
protected function showImage(p:Array):void
{
    shownImage = room.addGraphic(p[0], -21, p[1] - p[3]/2, p[2] - p[4]/2);
    //TODO: could get width and height from the image?

    nextStep = true;
}

This implementation also means that my cutscenes can access any object and/or method in the current game making my life much simpler (i.e. not having to write many wrapper functions to achieve things the game does anyway, no message passing etc.). I wanted to avoid having to write functions to control the camera, when I could directly access the object and its methods.

(Sidenote, this method leads to a large number of bugs where I forget to set nextStep. See below:)

Oh dear

That means that any really specific functionality can be modular and contained within other classes, which brings me to the other point about modularity. In the scene code I showed earlier, we called a function called crackBlock() this is not a global function, it is one specifically defined for this one scene. The system allows both aspects of modularity (subclassing and and encapsulating special cases), making code quite pleasant to look at.

Obviously, there is some annoying syntax involved (repeating addStep() isn’t ideal) but this was the best method I could think of when trying to work with our initial set of conditions. It’s an interesting design pattern, but it’s one that works for me - especially as someone who hates cutscene programming. Between this and FlashPunk’s built in tweening, it takes a lot of tedium out of scripted encounters.

Thoughts

In my early time as a programmer, I would have dived into an external (and possibly in-house) scripting language but as time goes on I realise, there is no need to put more work in than the game actually requires. It becomes much more important to be able to make the game not all the systems.

I also found that when I was starting out, no-one ever outlined how one might implement a cutscene system. It’s fairly straight forward logically, but very easy to get bogged down in. Our (very) old release EverEternal WinterWorld 2 used a fully externalized Lua system, which was very powerful but took forever to create (and was very challenging as a 15 year old!). Before that, we made the original EverEternal WinterWorld that uses an INI based scripting system, that was a shocker - but once again as 12/13 year olds we didn’t know better.

So, there’s another insight into our process. I hope you guys are enjoying these, I don’t profess to be an expert on this or any matter and this is not the method you should use, just a method - but I wish I’d seen more content like this when I was younger so I’m trying to give back!

If you want to know more about the game here are some links:

Our Website - Our Devlog - Indie DB- My Twitter - Ricky’s Twitter

Proof Devlog 2 - Lighting, Breaking It Down Now

The following was originally posted on August 27, 2013

A big part of Proof is the atmosphere, it’s something we’ve been working very hard on (and we aren’t completely happy with it still). There are a few steps that make the game a more interesting to look at than this:

No Lighting Here!

No Lighting Here!

Here, you can still see the aura the player has. This is a good time to talk about the layering in the game. It’s not too complicated, there are three visual layers to a room (and one collision layer, not pictured); background, ground and foreground. The player’s aura is between the background layer and the ground layer, so it doesn’t light the floor at all. Its purpose is to make background elements pop out when you pass near them.

All lighting is accomplished using alpha gradients with an Additive blend mode. In FlashPunk this is really easy to accomplish.

graphic = A.GlowImage;
graphic.blend = BlendMode.ADD;
graphic.originX = g.originY = 100;

I’ll go into depth later about how our asset handling system works (there are some hoops to jump through with ActionScript). The player lights are a different colour to our main lights, but we are going to have many  different colours in many areas.

Lights added... Still not great though.

Lights added… Still not great though.

The part that actually makes the game look any good, is a fullscreen overlay effect. This has a Subtract blend mode and makes all the colours much darker. This also makes the contrast of all the graphics much higher, which explains their washed out look in the raw format.

private function createDarknessOverlay():void
{
    darknessOverlay = Image.createRect(Main.WIDTH, Main.HEIGHT, 0x777777);
    darknessOverlay.blend = BlendMode.SUBTRACT;
    darknessOverlay.scrollX = darknessOverlay.scrollY = 0;
    darknessOverlay.alpha = 0.7;
    addGraphic(darknessOverlay, -5);
}

This hovers over everything in the game, apart from the HUD, and things end up like this:

There we go!

There we go!

Proof is all about darkness, so this is a pretty important part. It does make it a pain to draw the graphics since I can’t fully anticipate how the colours will look in game. I have to make  changes, run the game and look etc. over and over again.

The last part of the overall lighting system is the interaction between lights. Normal static lights have nothing special going on but, the player’s aura and the player himself do. As the player approaches a light, his aura disappears and his sprite becomes fully opaque. This is partially to prevent unwanted adding of the lights and partially to do with the story (no spoilers here..!).

So, there you have it. A quick breakdown of the lighting system in Proof! In the coming weeks (and months) I’ll have more posts giving an insight into our development process, there are a lot of tools involved.

Proof Devlog 1

The following is a copy of a post originally created on August 13, 2013

I’ve come to realise that we really neglect this website as an actual place people might come for updates about games. I feel it is much more suited to large updates than the bite-sized ones that we send out on the TIGsource devlog and through other sites.

For some people, it’s possible this will be the first you ever read about Proof.

So what is it? To quote our initial presentation to the world:

In Proof, you control an ethereal, disembodied spirit who becomes more tangible in light. You begin deep underground and must work your way to the surface. The game will be an atmospheric, puzzle-platformer based on a mechanic of collecting and combining items to create tools you use to manipulate your surroundings.


Whether that makes sense to you or not, rest assured there’s a lot to this game. For a long time (basically since the middle of development on Nightmerica) we - or at least I - have been unhappy. We started out making freeware PC games and the freedom that came with that was what made me fall in love with game development in the first place.

At first, iOS development was a novel idea: “We could get our games out to a huge market! And maybe even make money from them!”. We were excited to try something new, we designed a game for touchscreens (Run Run Die!) and pretty much executed it to the best of our abilities. Nightmerica was our attempt to move back towards the sort of game we would make for PC, meshed with an iOS style. For me, this felt like compromising my overall creative vision.

That’s not to say I’m not proud of what we’ve achieved, hell we’re in the top 10% of developers in terms of earnings on the App Store from what I can establish. We just want to move back to an audience that loves games for being experiences, fully fledged pieces of “art” as it were.

So, that’s what Proof is. It’s 100% the game we want to make, and we are bringing a long history of experience into it. It’s going to be challenging, atmospheric, mysterious and emotional - and we’re excited to bring it to you.

Backgrounds I realise this doesn’t explain the actual game much, that’s intentional. I’ll post here periodically, but for bleeding edge updates read the devlog, and/or follow me on twitter.