Posts Tagged ‘time travel’

A brief update

Posted by
Monday, April 20th, 2015 6:56 am

Wanted to show a work in progress shot here from my team’s jam game!


Things are coming along slowly, but we’ve been having a ton of fun!

I’m working in Unity 5.0 / C#, we’ve got Ryan Chadwick–our artist–turning out some really great looking work, awesome music has been composed by Xiao’an Li–from East Coast Scoring–and the creative firehose that is Dan Brainerd has been rocking out on writing detail as well!

We are all sharing game design work on this endeavor, but it was Ryan who brought the original concept to the group.

I’m really glad I decided to do the 72hr jam for the first time. I’ve been doing the solo competition for 5 years now and it has been great to change things up a bit and focus on collaboration.

We’ve got a lot more to put together today and I have a good bit of code left to write. We’ll see how far we get! :)

Timey Wimey Stuff – Apotheosis Post Mortem

Posted by (twitter: @bytegrove)
Saturday, September 7th, 2013 3:41 pm




Reaction to the theme

When I woke up on day 1, the theme I most feared would win had won. “10 seconds”?! Too specific. .. Urgh. On the other hand, that’s how I always react, I remembered.

This post mortem was written a little late, and pretty hastily. I filled it with as many pictures as I could, so that you’ll have something to look at while enduring the ramblings.

Based on my previous entries, I was determined on a couple of things (do not regard this as general advice or anything):

  • Keep the scope clean and simple, center around one core game mechanic.
    I do not consider myself a good game designer. I’ve been programming for longer than I’ve been “properly” designing and evaluating gameplay. Thus, the lure of writing “cool code” is always there and gets in the way of making a fun game.
  • Make it 2D.
    All of my previous entries were in 3D. I love programming 3D game logic. But 3D does add complexity in every stage of development. And I always spend too much time in Blender, modeling, animating and UV-mapping(I also wasn’t really keen on pursuing the minimalism angle again).
  • Make use of the freshest gamedev knowledge in your brain.
    During the summer I’ve been working on a 3D platformer, so all the platformer specific stuff was right there in my brain, unboxed and ready to be picked. I only needed to remove one dimension(and a boatload of quaternion math). Simplify, simplify!
  • Make the game longer than 10 seconds.
apotheosis gameplay

Rewind, Replay


I regret waiting this long for writing a post mortem. I’ve forgotten a lot of my brainstormed ideas. There was something with duels and seconds, but I never could center a fun gameplay mechanic around it. Later on I’ve seen several games using this interpretation, which is awesome!

There were also some clock ideas, with collecting the second marks of a clock as well as some idea of just making some arbitrary collectibles and refer to them as seconds(ugh).


Screenshot of the finished game


Braid+Mario Bros

After some thinking I wondered if I could do something cool with a rewinding ability. There are of course a lot of games already with this kind of functionality(Blinx, Braid, Ratchet & Clank, Super Time Force, to mention a few). I also wanted to keep the scope simple and by adding time rewinding (and possibly splitting timelines and paradoxes and gigawatts and what have you) I could risk ending up with something very bloated,unpolished and confusing.

So I thought about the very first Mario Bros and its single screen layout, and decided to make something similar to that.




What I ended up with in the end is a game in which you have to defend a fragile artifact from invading monsters as well as guide said artifact to a vortex in the sky. To elevate the artifact you have to rewind time (let’s call it a time defying magical artifact, mmkay?). Rewinding time also let’s you try that rewinded section of time again while your “old self” replays itself. Easy peasy.


I later realized, to my horror, during a debug session, that this was very much like the – what I thought at the time – super confusing shadow levels in Braid. I think I should go back and replay them, maybe I’ve learnt something.

Oh, and also, you can rewind a maximum of 10 seconds into the past and you have to wait the rewinded amount of seconds for the rewind functionality to reload. Which is a little too similar to what ended up being the premise of the very last episode of Futurama. Cool. Creepy.

Oh, and lasers.



Step one, global timer + rewind

My choice of working environment was my classic Unity setup. So the very first thing I set out to do was to make a rewindable replacement for the Unity engine’s time stuff.

It was easy but fun, and I wasted a couple of minutes just watching the seconds ping-pong back and forth. The simple pleasures.


Step two, transform buffer

The second step was to make some kind of buffer system for Unity’s transform component. With a 10 second restriction I could skip a lot of general stuff and make it explicitly for only 10 seconds. This buffer is read from while rewinding and replaying, and written to while playing. It was pretty cool the first time I saw it in motion. Ping-pong, ping-pong! xD


Step three, thumbnailing of level

Another thing I didn’t want to do this time around was to shove all of the art creation onto the last day. I wanted some pretty stuff in the game asap! As I didn’t really know what I wanted, I began by sketching out some rough thumbnails.


Thumbnail painting of level layout

Thumbnail painting of level layout


My main source of inspiration for the art was the book cover of the awesome novel by Arthur C. Clarke: “The songs of distant earth”. Which is also the inspiration for the awesome album by Mike Oldfield going by the same name.

Another source of inspiration was the beautiful grass-, wood- and dirt art in Rayman Origins. Such a pretty game. Also, I wanted to add some red hues in all that green.

Rigidbody-based Player controller

After having drawn for a while I got the urge to program some more. I began implementing the player controller. The already existing rigidbody system in Unity is pretty neat, and you can get some really nice results when using it for player controllers instead of the built-in “character controller”-body. And you don’t have to worry about collision bugs and explicit collision events later on. The workings of this was also fresh in my memory from just having implemented similar stuff in 3D, so its implementation went pretty smooth.

After I had it working I hooked the player object up to the time buffer component from before and added some state handling to switch off input and so on during replay.



I then went back to working on the level. I began by blocking out all the platforms(based on the layout in the thumbnail), and then I began working on the final art for the platforms. I made several separate chunks with grass and rock formations which I could build up the level of.


Timelapse of painting level parts

Timelapse of painting level parts

Then I got determined on making a sprite shader with lightmaps and other stuff. Big mistake. I got completely stuck with some of Unity’s weird sorting behaviours and spent too much time reading confused forum entries and lackluster documentation. I abandoned the idea after a couple of hours, and went for a simpler and built-in shader. By then my mood was at rock-bottom, but luckily this was the only real bump in the road this time around.


More work on the player

I then shifted my focus back to the player character. Based on the time I had left and not really determined on the art direction I wanted for the characters, I decided to make the player low-res and in black and white.

Timelapse of drawing player sprite

Timelapse of drawing player sprite

I figured the most importart part was to have the silhouettes there and if I got time to spare I could colour the characters. As I never got that time however, I’ve gotten some critique of the kind of mish-mashed art style I ended up with. And I understand that critique. One could counter with that the mixture of monochrome characters and coloured landscapes are “cool”. However, as it wasn’t my intention to make it that way, the result does not feel intentional, uniform or polished.


Implemented duplication of player on rewind completion

Another fun challenge was implementing the “duplication” effect after the player has performed a rewind. In the first iterations I got some hilarious recursion bugs filling the screen with player objects and crashing the game in milliseconds. 😀

When I had all that sorted out, the game looked like this:

Progress after day one

Progress after day one



After I felt that the player controller and rewind-stuff was solid enough and the roadmap of permuting objects and components into the remaining game elements felt clear enough, I began working on the music.

Apotheosis music (Soundcloud)

Figure music creation app

Figure music creation app

Prior to the compo I had discovered a pretty neat music app for iOS with simple controls(perfect for a tone deaf audio noob like myself) but with enough depth to make relatively unique samples.

It’s called “Figure” and I really recommend it if you want to make some simple loops or just play around. I used Bfxr to make sound effects, I had planned to record some as well, but by the time I got around to start making sound effects I didn’t feel like I had enough time to spend on recording and editing. Maybe next time I’ll do it as (based on the critique I’ve received on my entries so far) bleep-bloop effects aren’t too well received in non-pixely games. And I can see why they might feel a little out of place.



The last ten hours went by in a blur as usual and this time they involved GUI, particles, sprite animation, a rewindable animation system, enemies with their own animation, some super quick copypaste-magic for enemy AI as well as end-game conditions.

This is a video of the resulting gameplay:


And a timelapse video based on the stream data:


Feedback and post-compo

I was stunned by all the great feedback I received this time around! Thank you all once again!

I got a lot of response of the gameplay itself, which spurred me to add some more depth to it. And I found out that when you understood the core concept of the game, the powers of the player didn’t make much sense anymore and the game could be beaten with a one second hi-score without any effort. 😛

So in the current post compo version I’ve changed some of the enemy spawning behaviour, added extra difficulty levels and added a rewind punishment when touching enemies(instead of being invulnerable). I’ve also made some changes to the weapon, making it less effective when rewinding far, and more effective the longer you do not rewind(adding some more depth and ways to strategize).

I’m still open for more feedback though, so you’re welcome to try the post compo version if you’ve rated the original!



  • Prepared.
    I had bought all the food and snacks and made all the errands and downloaded all the tools beforehand. Development went smooth.
  • Location.
    Went to a friend that was also participating and worked there. A lot more fun when you’re more than one. Also, it was a bigger apartment with more shade, haha.
  • Scope.
    Kept it simple. One core mechanic, and a pair of sub gameplay mechanics. Kept the code and art modular, but didn’t overdo it. Ugly code? Yes. Who cares.
  • Bugs.
    Very few of them. One nasty shader ordeal, threw it away.



  • Game logic depth.
    Some of the gameplay aspects confused me, so I didn’t catch some pretty large flaws. Fixed some for post compo. I want to allocate more time for game testing next time around.
  • Stream.
    First time I streamed, I got some positive feedback on the music I played. But other than that I guess my showmanship is pretty lacking, as I had a maximum of five visitors at a time. Maybe I should post more links to the stream next time? I don’t really know.
  • Controls.
    I think almost everyone was confused by the control scheme and the aiming system. I’ve reworked it in the post compo version, but I’m pretty sure what many wanted was soldat-like aiming, which I’ll never add. 😛
  • Mixed art styles.
    I would have liked to allocate more time for creating prettier character sprites more in tune with the environment.


Another screenshot



All in all, I had a blast making this game and it has better gameplay than my previous entries in my opinion. However, the core gameplay turned out to be yet another cool-code trap sorta. I did not pour hours upon hours on getting it to work though. Making some neat art during day 1 instead of postponing created a great morale boost. Making a 2D game made it easier to create polished art in the style that I’m most fond of, and I got more content done in the 48 hour timeframe.

K.I.S.S. F.F.S. !

player_1Entry pageplayer_1


Yet another first Ludum Dare Post

Posted by
Tuesday, August 27th, 2013 2:12 pm

Well, the fact that I got this far must signify something.

This is my first Ludum Dare (the first for my partner too) and I’m pretty happy with the results. At 4:00 P.M on Sunday I was pretty sure this was going to be an absolute flop – but somehow it actually worked itself out. So without further ado, I’ll introduce the game concept and a few other details.


Game concept: It was heavily inspired by Chronotron, a game where players can go back in time and solve puzzles by making their former selves do part of the work. I played Chronotron a while back and didn’t really think much of it at first. But then… I realized there might just be something to this game that could be applied elsewhere. As in, the concept of time travel. Before Chronotron, I’d never really heard of a game which used time travel as a gameplay element. Turns out there are a few, but most of them don’t implement it like Chronotron.

So we decided to give time travel a second chance and incorporate it into a turn-based semi-strategy game. You would have as much time as you wanted to think about your actions, and then you would execute them. I even had ideas for a kind of time-travel portal device (past portal and future portal).

All in all, the game ended up having the art style of Geometry Wars, controls like a roguelike, puzzles like Sokoban, and gameplay like Chronotron.

And the name of the game: Timing is Everything


What went well:

  • During the early part of game development, I was just churning out code. My partner was drawing pretty well (I’m have the artistic skills of a planarian) and a lot of the early code was working flawlessly on the first test.
  • The art style was definitely influenced by games like Geometry Wars and Pew-Pew. One would think that it would have no place in such a strategic game. But it actually fit in quite nicely.
  • Some levels were quite creative. My partner designed all of them (although I did help out). The ideas of paradox avoidance shows up in the later levels and was well executed.
  • Libgdx proved to be pretty easy to use as well as cross-platform.

What didn’t go so well:

  • Time travel was a real pain to deal with. To make it easier on ourselves, we had started with a goal of making ANY game entity capable of traveling through time (just in case that time-portal device ended up being used). When I actually got to coding the player’s interactions with the time machine I hit problems. Originally, we wanted the player to be able to specify how far back in time they wanted to travel. This ended up creating a lot of annoying bugs and glitches, and the little framework which I had written didn’t suffice. So, we ended up ditching a huge chunk of code and going back to doing things Chrontron style – you can only go back to second 0. And after a lot of modification, we got that to work. The other problem was being able to use the time machine more than once. And the idea that when former selves went into the time machine, they had to DISAPPEAR but still get reverted later on. One of my ideas that never ended up completely working was that former selves could be linked to their future selves via some kind of linked list starting at the current player. In the end, annoying bugs and glitches made a game with more than two instances of the player impossible, and we ended up compromising and only allowing the players to use the time machine twice. If we had thought through the implications of time-travel ahead of time, we could have made a far simpler and more efficient framework which would have been able to handle that.
  • Some of the early levels were a bit too hard. Level 2 should have been level 8. And level 10 was too easy (at first). Some levels were designed with only 1 solution… so if you made one wrong move or if you forgot to sprint, you would inevitably fail.
  • The code eventually disintegrated into an absolute mess in the later hours. Best to look at the actual code if you want to see what an “absolute mess” looks like. Some code was unused.
  • Real life got in the way. This is probably the busiest time of the year for me, and to shove everything to the side for the Dare was not easy. In reality, we only put about 20 hours of work into this entry in the 72 hours we had to make it.
  • Porting issues. While they say “Port later” in the guide, be careful. If you want to make a web game, prototype on your browser frequently. I didn’t and I had an 1 hr and 45 mins to figure out Libgdx’s GWT port. And it didn’t work, so sometime this week when I have time, I’ll have to make a web port.


Anyways, if you haven’t yet played it, try it out here.


Posted by (twitter: @blubberquark)
Sunday, August 25th, 2013 2:55 pm

Frozen Braid is finished. It is a tactics game for two players where you plan 10 seconds of fighting.


It saves replays of your games, so you can learn from your mistakes.

play here

Frozen Braid Gameplay Screenshot

[cache: storing page]