Posts Tagged ‘postmortem’

Demo, Timelapse and postmortem of my game

Posted by (twitter: @doppelgunner)
Saturday, May 6th, 2017 9:00 pm

POST MORTEM [link to postmortem – my blog]


Hyper Holomayhem 37 – The Hyper Post Mortem

Posted by (twitter: @JorgeGameDev)
Sunday, January 15th, 2017 12:00 pm

It’s been a full month since we released Hyper Holomayhem 37. With the holidays and university finals, we found little to no time to actually give our experience with Ludum Dare 37 the proper conclusion it deserved. But alas, some free time to be able to write and share with you the highs and lows of the development process of our second time on the rodeo!




Hyper Holomayhem 37 is a side-scroller platformer shooter where, as a jetpacker trainee, you must stay for as long as possible in the Hyperdeck, a room that’s constantly changing layouts as you power it up with gears. Gameplay is based around collecting the gears spread throughout the level which you must bring back to the room’s core under a time limit. Enemies chase you around, and you will have break the blocks in order to get to some gears you wish to collect. Once the time is over, your training is complete.

Our development team was composed of three game developers, each of us with a different area of expertise. JorgeGameDev returned again as the gameplay programmer and The ‘Moski once again fulfilled his role as the game’s artist, exactly as it had previously been the case with our Ludum Dare 36 game, Colossorama. However, this time around we also had the opportunity of having ZakBlystone as the game’s audio composer (which you can read more about below).




Tools Used

Keeping with the pace from last time, we decided to stick with the usual tools for Hyper Holomayhem 37’s Development. The game’s uses Unity as it’s game engine with gameplay programmed in C#. Krita was yet again used for producing the game’s art and Zak used FL-Studio for making everything from the Music to Sound Effects.

Game Idea and Design

After the jam’s theme (One Room) was announced, there were several ideas that were placed on the table as potential concepts that we could develop during the event. From all of those ideas, we decided to pick the concept of having an holographic room constantly changing layouts, now deemed in game as the Hyperdeck. Other ideas and concepts included impossible room puzzles and even an Fingered-esque game about room decoration.

The Hyperdeck idea was picked as the chosen idea not only due to the time limit we had to develop the game, but also to allow the game to have extra replayability value which is greatly enhanced in this concept thanks to the ever changing room layouts.

As progress on the game continued during the following days, we decided that we would focus on the game’s airborne platforming, as well as environmental destruction the player could make by destroying the blocks that made up the room’s layouts. These elements were then further expanded on with enemies, extra traps and even power-ups, all of them placed on the rooms at random, which also helped strengthen the game’s loop, even if several ideas had to be left on paper due to time constraints.




What went right?

Games Polish and Completion

One of the aspects that Hyper Holomayhem 37 was mostly praised on was the game’s overall polish. Although we had to make some cuts when it came to the gameplay, we made sure that game still felt complete and solid, as well as progressively let friends playtest the game in order to assure that no issue went unnoticed.

One of the reasons why we favor polishing overall is to allow each player to feel like they’re interacting with a vertical slice of a potential game. This allows them to always know what to expect in case they come back, either on their own or due to an update.

Task Scheduling and Submission

Once the game’s development was put up to speed, task division and scheduling was efficiently put into the place. We paced what needed to be done as we went through the days, and based on what content we knew we would be able to have in the game by the deadline. Same as last time, this allowed the submission hour to be fully dedicated to that for that alone, and based on requests from last time, we also provided a WebGL version right from the beginning.

Audio Composer

One of the things that we felt could have been better explored in Colossorama was the game’s audio. Last time, we were only able to find someone that could give us a hand on composing original tracks a few weeks after the game’s release and update. by that time, the great majority of potential players and Ludum Dare participants had already played the game.

However, with Hyper Holomayhem 37 we were able to find someone who was eager to give us a hand with the audio composing, Zak. Having someone doing and composing audio on the team helped us give the game a set of unique sounds and a great music track to boot, making the game more unique, and distinctive when it came to audio.




What could have gone better?

Overthinking Game Design

As mentioned above, several ideas were outlined right after the theme was announced. The final concept for Hyper Holomayhem 37 was only decided a few hours after the theme announced, which slightly delayed works.

Nonetheless, even after the final idea was picked, there was a period of uncertainty regarding what exactly made our concept unique and what exactly would be the game’s core loop. At the time this loop was only the player going around collecting the gears and bringing them back to the core. This eventually lead to multiple, overthought discussions about implementing features like puzzles, etc.

This uncertainty caused some delays, however, we then realized that the base loop we already had just needed to be spiced up, as collecting gears and destroying the room’s blocks was already engaging by itself, and playtesting helped confirm this fact. We then proceeded to add extra content to further solidify this game loop.

Unexplored Gameplay and Concepts

Despite having settled with our game loop, there was still a lot of content that had to be cut due to the time constraints, some of which caused by the delays of the concept’s uncertainty. Although each of us knew which tasks needed to be taken care off, and what schedule to follow, we believe we could have better explored the game’s concept, as well as added a lot more content into the game. One example of a game’s concept that was not fully explored, and caused us to have a not-so-good score when it came to the theme, was how the Hyperdeck represented a single room.

Some of this content that was unable to be included in the game included more types of enemies, power-ups and even completely changing the room’s aesthetic as the player completed layouts. We still hope to get back to these ideas in a future update.




Conclusion and Closing Remarks

Even if the game’s development was filled with mixed feelings, we’re still happy and glad of the final results, dazzled by how well the game scored, getting a 51st place in Jam Overall.

As a short summary from everything above as well as our notes advice both to you and for future projects:

  • If an idea you have the beginning of jam already seems like it’s going to be complicated to develop, it’s probably better to go for a simpler idea, unless you really want to challenge yourself to execute a complicated one.
  • Schedule your tasks, even if in an informal way. Make sure that every team member has a list of what’s needs to be done, especially if your team members are on different time zones.
  • It’s always for the best to make assets that might end up not being used than not having assets for the time they are needed.
  • Having an audio composer on board can really greatly improve your game and increase its atmosphere and value with unique sounds and music.
  • Don’t overthink your game’s mechanics. Sometimes a few basic and quickly learn-able mechanics are enough to create an engaging game loop and diverse content.
  • Always remember to build your game content, visuals and feel around your game mechanics. Form follows function.
  • Do playtesting often, even if it’s just limited to friends, in order to collect some low-level feedback on what to improve. Ideally, playtest with non-familiar people, as they provide the best and more honest feedback.
  • Focus on exposing your game after you finish it. One extra aspect we feel we could have done better was on spreading word about the game, which we didn’t do as much as we did with Colossorama.

Feedback is the greatest thing a developer can get, and we’re glad that we’ve been able to constantly receive it. Hyper Holomayhem 37 was yet another great game we enjoyed developing, even given the hiccups, and we’re full of ideas on how to improve it, as well as for brand new projects we hope to do soon!




Thanks a lot for reading! As always, even if post mortems are mostly for self-reflection, we have the optimism that those who read these always learn something from them. We’re really glad of our results and the feedback we’ve collected during Ludum Dare, and it’s all thanks to you, the wonderful jammer community.

Our hands are completely full with assignments, commissions and other projects we must get done under a tight time frame, but we hope we are able to come back with some new stuff to show soon, as well as give Hyper Holomayhem a brand new coat of paint and bring it to the same level of content as Colossorama. It’s probably going to take a while, but it’s something we want to do as soon as we can!

If you wish to keep up with what we’ve been doing, you can follow us at @JorgeGameDev and @The_Moski as well as @Zakblystone, which was a honor having as a guest to help compose the game’s audio.

Thanks a lot! Until next time! And don’t forget to try out Hyper Holomayhem 37 if you still haven’t given it a go already!

If you have low scores, read this.

Posted by (twitter: @TheFish523)
Tuesday, January 3rd, 2017 10:22 pm

Allo, Im Fishy.

Im gonna talk about a problem with our site here. (I’m not a mod, just using our as a community thingy) A-lot of people have been really bummed lately, due to seeing plenty of triple digits in there scores. Now, I can see this as concerning, and especially unfair. But check this out, you made a Video Game! And actually had the balls to submit it to the public! I’d be pretty proud If I were you. Yeah, so what if you got < 100 on all your ranks. YOU still had fun making it didn’t you? You learned from making it didn’t you? If you said yes to either of those, congrats! You’re a winner! You don’t need to tell people you got >10/200.

What I’m trying to say here, its fantastic job to all of you. You went through the effort, and if you hit the submit button, it was worth it. You now get feedback, and can say confidently that you didn’t wuss out like many other developers who somehow don’t think that they could even compete in this!

I’m proud of all of you! I hope you stick around for next jam! New site, new judging system, it should all be well and good! Have a fantastic morning/afternoon/evening where ever you are!




Thank you all for such a great Ludum Dare!

Posted by (twitter: @TheFish523)
Monday, January 2nd, 2017 3:10 pm

I gotta say this Ludum has been one of the best so far for me. (Even though it’s only my second one) Alot of people played my game compared to my last game (Seriously like 6 times as many people). I’ve learned alot from this jam. And I appreciate the mountain of feedback you guys have given me.  I’ve had 3 YouTubers play my game and even some streamers.

Two things really stood out.

1: How motivated you can get when there’s 3 hours left in the jam (Seriously I got more content in those 3 hours than I did the first day).

2: The community.

What do I mean by community? Well, what do ya think? The out-pour of feedback, and the downloads and ratings adding up everyday, I even got a guy on twitter who said I inspired him to participate in the next jam! it’s just a fantastic feeling.

Overall, I think 2017 is gonna be a great year for game development. You all ignited a fire of passion inside me, and Intend to use it. Again, thank you all so much, and I hope to see you in the next JAM!







PS: IF you want to play my game, you can find it here

BreakAround PostMortem/Last Chance To Play+Rate Plus More!!

Posted by (twitter: @xanjos)
Monday, January 2nd, 2017 1:26 pm

It’s a bit extremely last minute seeing as there’s only a few hours left until judging ends but I’ve just uploaded the post-mortem for my LD37 entry BreakAround which you can view by heading down to my blog.


In other news, I will be doing a livestream on my Twitch channel at around 9/10pm-ish GMT where I will be (yup, you guessed it) playing and rating some of your Ludum Dare entries. If you would like me to play/rate your game during the stream, you can do so either by filling in my small Google Form or leaving a comment when you play/rate my game so I can check it out (or alternatively just leave a comment here) otherwise when the stream does go live, feel free to send your games in the chat.

Take care folks!

UNH4CK3D – post-mortem (TL;DR version)

Posted by
Thursday, December 29th, 2016 5:52 am

First LD. Jam: not themed game, not solo. Realistic hacker simulator.

Before LD: static HTML/CSS/JS sketch for login screen and desktop. Private Github repo.


Day 1: terminal prototype, simple “internet” and system pages. Player which uses YouTube API.


Day 2: set up LAMP stack in a VM and worked on backend systems – translation, search, networking and URL handling. Made IRC with button mashing and delayed messages. Friend helped with dialogs.


Day 3: added ssh, integrated dialogs into IRC, created first two tasks and in-game blog with hints. Polished that a little: playlists, translation, icons, renaming, etc. Created an entry.

Reception: surprisingly well – I was a bit nervous if the game’s too short or not interesting. There was not enough hints and no “game’s over” message, though. There is a record of TVGS playing the game:

And a link for you to play it yourself. If you do, please leave some feedback!


UNH4CK3D – post-mortem

Posted by
Tuesday, December 27th, 2016 9:00 am

I’ve got the idea for my first LD game a little bit before theme was announced. That’s why I’ve decided to take part in Jam and not to think about the theme. My game is a web-based hacker simulator game with realistic terminal commands.

Before LD

Well, as I’ve decided to submit a Jam entry, I wasn’t really restricted with “only in 48 hours” and “do everything alone” rules, so I made a small sketch. It was static HTML page with some CSS and JS for login screen and a desktop page with some icons.

I’ve also asked some of my friends whether hey want to help me, and as they told me that they would, I’ve created a private Github repo for us to use.

The first day

On the first day I had some university lessons to attend to. Lucky for me, it was a lecture about something I already knew, so I could code instead. That’s how console prototype was created: there was no layouts, just JS code, which I’ve been executing through Firefox Developer’s Console. That’s not a real shell, of course, but it could parse the input string into arguments (supporting “quoted string” as a single argument and some escape sequences like \n). It also supported pipe |, because I already had an idea for that.

After those lessons I returned back to my room. First thing to do was to add that prototype to my sketch page and create some nice UI for it. I’ve actually been streaming all that to Twitch (even though noone does watch me), but I wasn’t recording.


Then I’ve started adding more pages into the “internet” of mine: some simple ones like Mailbox (totally static) and browseros system pages like settings, admin and no_internet.

By the end of the day I’ve also added a Play player, which is using YouTube API, and a temporary playlist to check that it works.

The second day

My friends helped me on the day two. One of them is really into web-development, but he was quite busy, so his total impact wasn’t as big as I thought it would be. The other one never worked with all that web stuff before, so I asked him to help me with the story and translation. I had some sketches for dialogs, but was working on the other things, so I explained him the story shortly and returned to my work.

First of all, I had to start working on backend part of the game, because I knew that I want to hide some parts from the player. So I created a lightweight virtual machine and set up some LAMP stack on it, because that’s what I have on my site hosting (where I was planning to release my game on). That’s where PHP was added in. From now on the game wasn’t just a bunch of static HTML pages, and required some server. From the other hand, now I could add login and use database to store player’s progress.

I’ve also made translation on backend: user’s browser sends a cookie to server and depending on its value I’m sending one or another texts in response. I wanted to determine user’s language by IP, but PHP geoip module wasn’t available on my site’s hosting, so I had to remove it later on.

Then some other backend systems were added: search, “networks” and URL handling. Even though it’s possible to implement these on frontend, it would also be possible to look in the JS source code and see which IPs, URLs and sites in search index are available, meaning the players could possibly find something I don’t want them to find yet.

Search gets user’s query, splits it into separate words and then searches for similar keywords in the “index”. Index contains all sites I wanted to be searchable, its title and descriptions and arrays of keywords. To make search a little bit smarter, I’ve decided to use Levenstain distance to find out whether keywords are similar, but that’s why search sometimes returns some funny results.


“Networks” is a special set of objects, which represent a network node. Each node can have an array of hostnames (IPs or actual names) and a set of opened ports with some “services” on it. Using that I could easily add more computers to the network of the game, and add some ssh/web/etc services (only the first two were implemented).

URL handling parses the string player enters in the in-game browser field and searches for a match. It’s basically a hardcoded set of strings (like “” redirects to some “/pages/search/index.html”), but it’s also aware of the networks, so if you’d try <IP>:<port> in URL field, it would check if there is such node and if there is a web service on specified port, and if so, show you the associated page.

Once I finished those, I started working on IRC, which was the key element of story telling in the game. I’ve decided to go with predetermined options for player to select from and a funny SUPERHOT-like button mashing mechanic for players to type these options. I also wanted new messages to appear one by one, so I’ve getting all new unlocked messages with AJAX and them play them in the order with the delay specified. I wasn’t using database to mark which messages were already read, so if player updates the IRC page, it instantly shows all new messages. The nice thing though is that message notification sound plays even if you’d leave the page. The sound was created with sfxr, btw.

By the end of the day I’ve got some dialogs from my friend. He wanted to make the entrance a little bit smoother for the player, so he added some tutorial part where you’re answering some kind of buddy who doesn’t know anything and always asks for help. The idea with different options for that sequence is totally his, and I think it’s quite funny.

The third day

So, in the beginning of the third day I already had some systems working, but there was no story or tasks for player to do. I already knew what tasks I wanted to add, but these were not implemented at all. For example, to run the exploit, player had to connect to the remote server with ssh, but there was no ssh yet. In order to implement that, I actually had to change a lot in that shell emulator of mine.

As this was Monday and had some lectures again, I couldn’t work on something heavy, so I was just implementing dialogs I got from my friend: redacting these a little, thinking of the names for the characters, testing how it shows up in the game.

Then I’ve added the first task: to open a web interface, login using given credentials and see the sticker on the monitor. It’s funny how everybody wanted to zoom the picture in and see what’s on sticker when my idea was that if that’s too small, player would go back to IRC to see what changed in there.

The second task was a bit harder: it requires a terminal, but as I knew hackers wouldn’t explain player how to open it and how to use it, I had to add some hints. That’s why I’ve added a scriptkiddie blog, where he shows a screenshot of open terminal and a browser URL which you could use to open it. There is also where I’ve put hint on how to use curl and curl | dash (that’s browseros shell). I didn’t add any hint on ssh, though.

Then I’ve started some polishing: added playlists (default “player’s” and an electronic “by Tkachov”), added translation everywhere (because the friend of mine couldn’t manage all the PHP I had in the project), drawn icons, renamed some things, etc.

After all that I felt a little bit tired, so I decided not to spend the last hours remaining to add content, and just moved the game to the hosting, created an entry and a short post.


Even though I knew my game is working fine, I thought it could be too short, not interesting or demanding some knowledge players don’t usually have. So I was surprised to see how well it was received by people who commented my entry. I actually ticked a checkbox to allow anonymous comments hoping that would get me more feedback, but I don’t really remember seeing any anonymous comments on this site, so it’s either broken or nobody wants to be anonymous.

What went well: it seems players did like the idea, and a lot of them liked button-mashing =)

What didn’t: not everyone liked button-mashing; there is not enough hints; there was no message to notify user that the game has ended already.

I’ve fixed the latter, but everything else remains the same it was when I created an entry. I do want to make more, but I’m not sure when I’d get time to do it.

TVGS played my game on their stream and uploaded the record to YouTube, so if you want to see it in action, here’s for you:

You can also play it in any modern browser without installing any plugins. I’d really appretiate your feedback, so please let me know what you think of it!


one rooms post mortem

Posted by (twitter: @AurelDev)
Sunday, December 25th, 2016 8:02 am


(this is a mirror of the same post mortem on my website)

It was that time of the year again! For Ludum Dare 37, I made a 2.5D point ‘n click adventure in 72 hours – one rooms. I also skipped one night completely, opting to work for 40+ hours without any sleep whatsoever. Here’s how everything went down …

The preparations

The week before this LD was somewhat busy for me still, because university. Mostly because of that, I didn’t prepare as well. I didn’t make a super customised wallpaper with different text for every theme possible, I didn’t make 9 of them for each one of my virtual desktops, I didn’t test my libraries. I did make a super quick wallpaper that you might see in the timelapse. Basically, I was not planning to do something very experimental. It was going to be another game made in Haxe, compiled to flash. Oh well.

I was also looking forward to seeing the new Ludum Dare page. But then, a week before the actual event, I realised it’s just not going to happen with the current progress. So, surprise, surprise, everything was done on the old Ludum Dare page which has bugs and issues, obviously, but is still much more reliable than a system ‘finished’ and launched without any alpha testing. Oh well #2.

Unlike most previous LD’s, I did not have a definite favourite among the final round of themes. These were my votes:

While I know that the event is growing larger all the time, the duplicate themes are getting old. Chain reaction is the only one marked, but ‘Small world’ is pretty much the same as ‘Tiny world’ (LD 23), then ‘Simplicity’ / ‘Minimalism’ (LD 26), ‘Wait, are we the bad guys?’ / ‘You are the Villain’ (LD 25), etc. And of course, the theme that was finally chosen, ‘One room’, was very exactly the way I interpreted ‘Entire Game on One Screen’ (LD 31), so it wasn’t my favourite. Oh well #3.

The concept

I woke up on Saturday (after going to sleep one hour before the theme was announced, silly me) somewhat late, and saw the theme. One of the first things I thought of was a rogue-like exploration / role-playing game – you, the player, control a boat / spaceship / caravan which is the one room. But because it is also a vehicle, you can control your one room and go places. Explore the sea / space / desert. It is a simple concept which can be taken in various directions. The game would also be quite difficult to finish, but I was up to the challenge. I was already considering going for the jam, so the extra 24 hours would definitely help here.

(I didn’t choose this interpretation in the end, but there are some that have done so, for example: 13 Jellyfish by Four Quarters – pretty game)

So, as we were brainstorming with my girlfriend, don’t ask me how, I thought of approaching the theme a bit differently – to have a room that ends with -one room. Then she suggested a game where you try to think of various -one rooms. And then, feeling ambitious, I thought of a full story to go with that. I already knew it would be a lot of work to even have various rooms, without even thinking of an actual story.

Poor man’s 3D engine

And so the idea was born. Then it was time to think of how to make the game look. I already experimented with pixel art / 3D fusion in Cell #327, although it seems like an overly-complicated way to make little bits of the room move. I didn’t really use it to its fullest potential. So this time around, I opted for simpler graphics, with the 2.5D effect of the spinning room being the highlight. The graphics ‘engine’ involved some basic lingebra, z-buffering, pixel-by-pixel blitting, but I suppose that deserves an article of its own!

72 hours again, music, voice acting

I was quite happy with my progress. Creating new rooms took a lot of time, because creating a user-friendly editor to place walls and floors in 3D would take even longer. By the second day I knew I didn’t have that much ready content-wise, but I didn’t panic and decided to keep going and submit a jam entry instead.

I had no idea what music I would have, or how I would make it, and having a jam entry allowed me to ask somebody friendly on the LD IRC chat. The request was fulfilled by ibispi, who promptly made Earthbound-sounding chiptune music for all the rooms. That added a lot of personality to the game. I would have gone for darker-sounding music, but I reconsidered, seeing as my game was rather light-hearted, with lots of quote unquote humour in the writing.

I also thought of asking Elijah Lucian to give voice to my game, as he did for Cell #327. He wanted to help, but couldn’t make it before the jam deadline, unfortunately. Right after the jam, however, he was hosting a voice acting stream on twitch. It was quite fun watching people try to act out some of the more unusual parts of the script (the actual voice acting starts around 01:11:00). He also promised to have the game voice acted post-jam. And I want to polish it plenty before that, and add some content – more rooms, more puzzles, more fun.

Sleep deprivation

As I’ve already mentioned in the beginning, I’ve skipped the second night entirely. I worked till 3 in the morning, then thought I might as well try to pull an all nighter. Maybe it gets better when you get used to it, but sleep deprivation is kinda scary. Monday morning was especially challenging. I tried to keep working, but I would keep falling asleep mid-work. Writing simple lines of code would merge with my dreams. I would have my eyes open, but I can’t say I was awake. Trains of thought were derailing left and right. It actually got better in the afternoon, and I was insane enough to stay up till 3 in the morning again. Watching Elijah’s stream of course.

I guess if there is an advantage to skipping a night (apart from the obvious additional working time), it would have to be the, er … ‘creative’ ideas you get. So that’s how the singing skeleton quartriplet and the late shift arcade got in the game.

The menu

The menu in this game was heavily inspired by the GUI in Mass Ef– Just kidding! I meant the food:

Also some muffins, pistachios, you get the idea. Good food management is crucial for a successful LD entry.

A javascript port

You might notice there is a playable javascript version this time around. I ported the game because some people complained that it’s hard to get it running on linux, and that flash is a dying platform anyway. Which is true, I suppose. So, post-jam, I ported the game. It took me a day, but I was quite happy, because the majority of changes were made in my libraries (which were basically used as a wrapper around the flash API), not the game itself. Meaning I can make a javascript build of my games to come much faster. Yay.

Some mistakes

As always, there are some things I should have done differently. Obviously there should have been many more rooms, at least some lines of dialogue for them. Writing those would have taken minutes, so really there is no excuse.

The palette I chose was 20 colours. Most of it worked out pretty well, but for some reason I chose a colour very similar to another that I never managed to use in the game. If I had taken some time balancing the palette more, the resulting graphical style would probably end up different as well. Probably more moody, as my games tend to be.

The faux 3D, while looking pretty, is also not very nice on the CPU. The javascript version suffers from this much more, but even the flash version gets my (admittedly quite old) computer spinning up its fans. I could have optimised this in many ways still, and I hope I will get to that for the post-jam version. Technically it should be doable with a shader, but I didn’t feel brave enough to write my first shader during LD.


And that’s about it. I will write another article about the way the rooms are rendered, and hopefully another article when there’s a post-jam version. Overall, I am very happy with my game, and I hope you enjoy it too!


Update: timelapse

HourGlass Collector. When simple things are not so “simple”.

Posted by
Saturday, December 24th, 2016 12:39 pm

First of all, I want to thank everyone for the provided feedback. We appreciate that!
It was an awesome jam and we had a lot of fun. So I decided to tell you our story.

A story of HourGlass Collector

HourGlass Collector


  • Skorpyo. Team Lead, Programmer, Project Manager.
  • Fourcy. Game Designer, Level Designer, Artist.
  • Xcentric Noizz. Composer.


    “One Room”. This theme was unexpected. But it turned to be a very interesting one. It wasn’t a hard one for us. The idea immediately popped up in my head. Our game designer polished it and we started our project.

Game Design

    Fourcy started to make game design. First thing he made was a list of game elements. They were used as game objects. With this list I could make a set of placeholders to test mechanics, controls and other stuff. I started coding while Fourcy was working further on game design.


     Next step – game mechanics. Our game has a lot of different game mechanics. Fourcy came up with around 15 of them. Not all of them made it to the end. Some were changed, rebalanced or trashed. I will not show you the full list cause this will ruin your game experience =) At this point Fourcy started to work on art.


    All sprites were made by Fourcy. He used Sai as graphics editor.

char animation standingarch door spawnerspikesbutton map

 Level Design

    Fourcy spent a lot of time polishing this “level”. It had to contain lots of “game layers”. This was the result of “brainstorming”.


    There are 3 spawn points on the map. A button works as a trigger and spawns hourglasses. Active spawn changes in a clockwise direction. (This is a hint for one of the levels)


    This game was made in Unity3D (C#). After recieving list of game elements I started to work. I made a list of placeholders and started to implement base logic. Here we began to move and jump. What a platformer without jumping?

     Spikes added (yellow box). First real danger. By “danger” I mean DANGER. See these corpses?

    Working with placeholders saved a lot of time. I’d made almost every game mechanic before we had sprites ready. But with sprites it looks better.


    Our game is almost ready. We need one more thing – a good soundtrack. This is where our composer starts to shine. Provided with gameplay and pictures he made an OST that changed the game. It was no longer a boring platformer but a funny game that attracts you from the start and keeps you till the end. If you like the OST and want to listen more, search for Xcentric Noizz.


    We asked everyone we could to try our game. We knew it was hard so we made the game a lot easier. We can’t make it even easier because it will become boring. We did our best to balance the difficulty curve. But there’s always room to improve. And thank you for the feedback and gameplay videos. This helped us to find the problem.

Thanks for reading!

Click here to play HourGlass Collector

Postmortem Time!

Posted by
Friday, December 23rd, 2016 1:40 pm




Here is the (likely incredibly dull) story of how I made my Compo entry, One Room HotelAs a bonus I also did some stuff with the CSS of the post, hopefully that works out when it gets to the front page.

theme announcement

When I heard the theme, I was not happy. I felt like I had no ideas for the theme, and that it was far too limiting.

Then I realized I had voted for it 😛

My brainstorming process is simple: come up with ideas for the given theme, then come up with themes related to the given theme, then brainstorm based on those. I find doing this is very helpful, as it forces you to look at the theme in different ways, rather than mentally getting stuck on a few ideas. I ended up writing down the idea I was going to use in the section headed “One Room at A Time.”

The idea, as written, was very unclear:

Action Hotel Management Rhythm Game

I  worked up the design of my game based on this, and it went through a few iterations.

  • In the first iteration, you controlled a room in a two story hotel, and needed to pick people up as they walked through to bring them to another side. The idea didn’t really make much sense, so I scrapped it.
  • The second idea was not related to the theme very much at all (it was closer to the “One Room at A Time” the original concept was written under.) You needed to place and remove rooms to optimize your hotel. I realized this did not fit the theme, and would not be very fun, and scrapped it.
  • The third iteration was the one I kept, where you need to carry people around in order to get them where they want to go quickly.

The inspiration for the game actually came from Hot Wheels Drive Through Dilemma, a time management flash game I played a long time ago. I was also thinking about the game SimTower, an inspiration which a couple of people seem to have picked up on.

After I had my full idea, it was time to start work.

starting work

One issue that has been common to every Ludum Dare I’ve competed in is a lack of initial confidence in my idea. I always second-guess myself and this compo was no exception.

I especially felt that the sprites I was drawing would not work. I nearly scrapped the idea right there, but my bad experience a year ago with wasting time on a second idea when working on Disphere led me to stick with my original plan.

One Room Hotel Early Development The basic mechanisms in place.  At this point I was still thinking about changing game ideas.

This uncertainty continued throughout the night, and into the next day.

I finished the day with a post showing people entering the hotel.

One Room Hotel With Guests The game started to have some form, but I was still unhappy with it.

the first day

When I woke up to start work the first full day, I saw that this was the most “hearted” post I had ever made, with 17 hearts. This is what finally convinced me that this was the idea to work on. If people were responding this well to such a basic illustration of the mechanics, I must have been on to something.

Getting the people to look good was a struggle, and took the better part of an hour and a half. For a while I was worried that I would need to pursue a different graphical style, but I ended up managing it.

When I finished the amenities, the game really started to come together. It started to fell like a real game, and I felt it was time to share what the gameplay was really like. I came up with a simple backstory for the game, and made a post. In a couple hours, this post had 27 hearts.

One Room Hotel With Three Amenities The most hearted image I have ever posted.

This post is by far the best received progress update I have ever had, and helped motivate me as I began to add more fleshed-out gameplay.

The next major change to the game was the addition of the day-night cycle. I needed a way to make it clear when a round was going to end and to create a feeling of progression during a stage, and this was the perfect way to do so.

Unfortunately, this somehow managed to be the most time consuming process of the entire project. I struggled with calculating how to blend colors, and with the scripts for doing so in GameMaker Studio. I eventually resorted to trial and error for getting the sky’s brightness right, and used an overlay rather than blending the color.

The ordeal was worth it, though, as it made the world feel more alive and gave the game a much better progression. The progression still wasn’t perfect, however, so I started to brainstorm ways around this.

One Room Hotel Timelapse The day night cycle took far too long to implement, but it was worth it.

After the day night cycle, there were still a few issues with the progression of the game. People came and went at any time of day, and rounds had nothing substantial separating them. I fixed this through two changes:

The first was a three part structure to days.

  • In the morning, people enter the hotel, and the player is calm.
  • In the afternoon, the hotel is full and hectic, making the player stressed.
  • At night, people leave the hotel, releasing the stress from the afternoon.

This change in the intensity of the day over time is critical to the feeling of the game. The stress I wanted would have tired the player if it was constant, or even if it was random. Because it happened at a specific time during the day, it created anticipation and gave the player a chance to prepare. This wasn’t perfect, however, as the RNG could throw incredibly difficult situations at the player. This is an issue with all of my games, and it is the main complaint people have with One Room Hotel in particular.

The next feature I added to improve the flow was hotel construction. The time between rounds felt rushed, and I needed another step in order to ease the transition to the next stage.

I thought about what I could add that would fit with the progression of the game, and I realized that adding a screen where you must construct your tower would accomplish three things:

  • Break up the time in between stages
  • Give a sense of progression as the tower grows higher
  • Add a layer (or maybe the illusion of a layer) of strategy

The building screen accomplished all of these things in my mind, and I personally think the blueprint aesthetic during construction looks really cool.

Construction of the One Room Hotel Construction helped the rhythm of the game, helping to better delineate stages.

After construction was finished, I squashed bugs and implemented small features for a while before going to sleep, with a near feature complete game ready for polishing on the second full day.

the second day


At the start of the second day, I had around 20-30 items on my to-do list, which was just a little bit nerve wracking. I legitimately thought I wouldn’t finish, but I pushed through and just started working despite this worry. Worries like that have hurt my performance in previous events, and I was NOT going to let that happen again.

After all of the panicking, I decided that the most important thing to get done was the user interface. I’ve neglected this somewhat in the past and it has hurt the quality of my games. I spent a few hours on the interface, and tried a few different styles before I settled on what I used in game (and in the styling of this post.)

One Room Hotel UI and Reviews I chose a UI matching the color palette of the hotel.

I also worked on the in-game UI, and got that looking good with a color changing satisfaction meter and an icon for your money (score.)

I wish I had taken the time to make a separate icon for satisfaction, but I was forced to focus on others things.

One Room Hotel User Interface The basic in-game interface: the satisfaction meter and score.

Something I added that not many people seem to have noticed is the randomly generated hotel and newspaper names. There are thousands of potential hotel names, each generated from an adjective, a noun, and then a type of establishment (Inn, resort, hotel, ETC.)

  • remote smile resort
  • summer arc retreat
  • summer cliff hotel
  • spring shark resort
  • enchanting gulf retreat
  • winter pond tower
  • regal delight hotel
  • enchanting tornado resort
  • winter mountain resort
  • pleasant delight tower
  • globetrotter mountain resort
  • regal park tower
  • pleasant arc tower

The newspaper names were a little simpler. They also consisted of three parts, but the first was simply a choice between have “The ” or “” at the start of the name. The next part was a noun, and the third was a type of publication.

  • The Remote Week
  • The Silver Herald
  • Hotel Times
  • Fascinating Week
  • Inn Enquirer
  • Terracotta Times
  • Hotel Journal
  • The Pleasant Week
  • Royal Tribune
  • Summer Chronicle
  • Happy Gazette

I love adding details like this to the game, whether or not anyone notices 😛

Since near the beginning I had ideas for the music of the game. I wanted some medium tempo jazz for the menus, and a really fast tune for in-game. I only had time to implement the menu music, unfortunately. I was disappointed at first, but when I changed the music to play in-game I realized it worked pretty well.

The music was originally intended to be for the menus only.

I made the music using Mixcraft 6 (NOT recommended, very buggy) and midi instruments, along with a (musical) keyboard. To come up with the tune I hummed along with the game when I was testing and recorded it. Once I sang something that I liked I just needed to figure out the notes to actually play it.

I would highly recommend this method to anyone who doesn’t typically write music, as it really saves time and does a lot for quality if you don’t know how to write music. It’s a lot easier to improvise melodies when singing then to mess around with a keyboard until something sounds good.

final hours

For me, the final hours of any event are some of the most important. This is where I add a final layer of polish, and elevate the game to the next level of quality. Strangely, what I feel is the most important single change I made on the final day was making the sun better:

One Room Hotel New and Old Sun The old sun is on the left.

The yellow of the sun brings the game’s visual style together, and I think it turned out really well. I don’t know why, but that’s when I really felt like I had made something good. Maybe that’s weird but that’s how I work.


One Room Hotel is the best received game I have ever made. I’m really happy with it, and I’m ecstatic reading people’s reviews.

A few people have called it one of the best games of the event. I never thought I would get to this point in my game development, and I am so happy that people feel this way about my game.

I’m incredibly excited to see how the game places, and I hope to finally break into the top 50 for fun, and maybe even for overall.

post compo plans

I may release a post jam version of the game, fixing some of the issues with it, and it may be coming to Android. I’m not sure at this point, but it is a possibility. I’m more likely to focus on a long-term project I’m going to be working on for FFSJama manic shooter.

Thank you so much for reading!

play now


[Almost] One Room Post-mortem – Part 2

Posted by
Thursday, December 22nd, 2016 6:21 pm

On the first part I wrote about how it was the birth of the idea. Today I want to talk about execution and learning, because if you remember correctly, the main idea was to learn Unreal Engine 4.

The starting point was to let the player find a number combination for a door. Every number will be in a copy of the same room, but every room will be lightly different.

We started thinking how to hide the numbers and we wanted to go beyond the easy way of hiding behind the furniture. We wanted the player to think out of the box, and our main fear was to make puzzles too hard to be guessed. With the time restrictions of a jam the harder part is to balance a game, and to balance something as subjective as a puzzle difficulty is only doable if you can make people play it, we hadn’t people.

The first thing we did was to draw a generic room layout with 4 doors, one on every wall but not in the center. Rooms in real life don’t usually have the door in the center, it wastes too much space and from a gameplay perspective, it will limit what you can place there and may compromise room walkability.


On the other hand I’ve started “coding”. For those who have not worked yet with Unreal Engine 4, it has a visual programming system called blueprints. In the editor you create logic by connection boxes; for example, you have the “branch” node, it receives a boolean expression and it has 2 outputs, one for true and the other one for false evaluation, the flow of the code will go from one output or another depending on the result of the expression, exactly like an if-else statement on traditional programming.

The first thing I coded was the num picker the player will use to put the numbers of the combination. The idea is simple, you will have a collision box to know when the player is next to the picker and everytime the player hits the mouse left button, we will increase the number up to 9, then, it will go to 0. Also, we will need various of these number pickers because the combination will have 5 numbers and every picker lets the player to select 1 number from 0 to 9. To be able to reuse this asset we will create a Blueprint Class, something like a object oriented class that groups code and other assets. In our number picker blueprint class we will have a box mesh, a UI text widget, the collision box and the code. We will be able to instantiate as many as we need and we will be able to access its public local variables to interact with them in the level blueprint.


Honestly, I’ve been coding for more tan 15 years and the mental switch you need to do to work with blueprints it’s remarkable. Not in terms of difficulty, in the end it’s logic flow and it does not matter if it’s a box or a code block, but more in terms of how do you have to do the flow. It’s hard to describe to me, because it’s not something specific. For example, for the num picker you need to increment an internal integer that stores the number on the picker, something that for me was a single line of code ( this.number = (this.number+1)%9 ) transforms in some nodes: a getter to get the value, next increase the number, then get the module and finally store it in the same variable. It can be done in less steps with a Math Expression Node, but it’s an example. What I’m trying to explain is that even when you know how to code the learning curve of the Engine, specially learning where do you have to go in the editor because it’s full of buttons and windows and tabs.

Back to puzzle design, we decided that we will need to teach the player that he needs to find numbers. That’s why we locked all the doors in the initial white room and put a first codelock there. Also this first puzzle is the easiest one, a giant black 35 in the ceiling, only partially hidden due to it’s like an humidity stain. Locking the player also gives us the moment of surprise when he opens the doors and finds the same room over and over again.


Once Carlos told me how the basics of blueprints and the event system I started to prepare the door unlock code. Meanwhile Carlos was working in the assets we will need, the furniture, doors, etcetera. We needed functional and easy to create assets and whats more generic, easy and reusable furniture in the world? Disclaimer, no brand or company funded the creation of our game. IKEA of course! :V

We relied in UE4 vertex painting tint every room, we used a material with a color parameter in some assets, giving us an incredible power to get all the rooms done with a minor impact in performance and a huge time saving. The only texture applied to the assets was a baked ambient occlusion to give them the correct shading.

Finally to create the puzzles we used different techniques. For the distance one is a simple material that changes the opacity depending on the distance from the camera. Something similar happened with the reflection, we have a copy of the same room below and the floor uses a material that changes the opacity in this case with a Fresnel function. We wanted that the details that changes in every room helps the player to find the clue. For example in the light one there is a second lamp, no other room has it, the green room is the only one where the statue is different.

And it’s all, we wanted to do more content, but I’m happy because we marked us a minimum product and we delivered it as we imagined it, but the process was good enough that if we had more time, more content would be done fast, spending again the major part of the time designing new puzzles.

Many thanks for reading, please play the game, rate us and please comment, we need your feedback!

Roomba Fight Club Postmortem

Posted by
Thursday, December 22nd, 2016 11:06 am

Play Roomba Fight Club here

A lot can change in a year. Just about one year ago I participated in my very first game jam, Ludum Dare 34. You can read about it HERE. I found the whole experience incredibly difficult, yet rewarding. Just a couple of weeks ago I decided to try it again with Ludum Dare 37. I wanted to see if the grueling game jam would treat me any differently now that I’ve had another year of game development practice under my belt. Did it? Well read on and see (or just skip to the end if you’re lazy).LD


The Game

The theme for this past Ludum Dare was “One room”. I decided to make a video game version of the Roomba knife fights videos from YouTube called “Roomba Fight Club”.  The premise to the game is very simple. You have a Roomba with a knife strapped to the front and three balloons strapped to the back. The goal of the game is to protect your balloons while popping all of your opponent’s balloons. This task is compounded by the intentionally difficult tank controls and scattered furniture around the room.


The Development

Development for this idea started really rough. Like incredibly rough.  I could not think of an idea for the “One Room” prompt. I lost about 2 hours of development time just pacing back and forth in my room trying to think of a game that would only take place in one room. I had learned last year that you can’t go too outside the box with the theme ideas. I had a couple of commenters let me know that they dinged me points for “Safe or Sorry” because while the meta game was played with only two buttons, the actual game was not.  I wanted to avoid that if at all possible and let the player know that I had indeed stayed on theme.

My first idea was to do some sort of multi-dimension thing ah la “Rick and Morty”. Something where there were a huge number of identical rooms in parallel universes, but that would require a bunch of ideas for each universe and time to implement them all. This was a no go for a game jam idea. I then came up with a bunch of plays on  the word “room” such as “The elephant in the room” or “Wiggle room”, but game mechanics weren’t apparent in either idea. I finally settled on Room-ba based room combat in a living room.  Hopefully the theme didn’t get lost on people this time.

This year I focused way more on “planning before execution” than i had the previous year. Before I started coding anything I had a basic idea for how the game would play. I had a basic idea of the shape of the room and the aesthetic for the game. I even picked out a color palette to stick with using before I ever even started coding. This is in stark contrast to last year where I just started coding right out of the gate. I think what changed this year is that I was at least a little familiar with the process.  I wasn’t so scared that I would run out of time that I felt that every moment needed to be put toward creating a tangible asset. Once I had my basic plans laid out I still didn’t just jump right into code. First I grey boxed everything.




I laid out the basic perimeter of the room and cordoned off the areas where props such as the couch and TV would go. This took a few tries to get right. I didn’t want the room comically large, but I also wanted it big enough to move around in.

Once that was done I moved into the pawn setup for the Roombas. I played with making them all physics driven, but that turned into a nightmare quickly. It was too easy to get flipped over or to create really weird physics issues. I eventually just had them inherit from the default Unreal Character class, but in doing so I wound up getting the default capsule collider which caused a few problems of its own. I even had the balloons on strings originally with forces constantly pulling them upwards. It was cool, but it made them impossible to stab with the little knife, and extremely unpredictable.

Once I got movement down I built out a really simple AI for your Roomba opponent. It’s a behavior tree with three nodes.

  1. Turn towards player
  2. Dash forward a random distance
  3. Wait a random amount of time.

By making some of the parameters random the AI feels a little less predictable, but all in all it took me the least amount of time in this project. I played around with making the AI smarter, and making it use Unreal’s path-finding, but I found out quickly that the game was way more fun when the AI just smashed its way through the environment like some 90’s kool-aid man.

Next came round after round of polish. By designing first, then coding, and leaving aesthetics till last, I ensured that I could take all the time I needed doing the art. I didn’t have a lot of code left hanging over my head.  My asset creation pipeline looked a little something like this:

  1. Create BSP volume in Unreal the approximate size of the asset I wanted.
  2. Export BSP as static mesh to use as a size reference
  3. Model basic mesh in Zbrush using Zmodeler and dynamic subdivision.
  4. Kick back to Blender to clean up, UV and Assigning materials.



That was about it. I skipped texturing which saved me a ton of time. Other than the wallpaper which I generated using a tile generator, every material is just a single color. Last year I used Substance designer to create my textures, but the amount of time I lost didn’t seem worth it for the final outcome.

The music for Roomba fight club was generated in Bosca Ceoil. The same as it was last year. Sound effects were created by a combination of recording noises on my cell phone and using .

What Went Well

  • Boxing out the room first
    • Boxing out the room first meant that I didn’t have to make zero hour design choices and updates. I played around with everything while it was ugly, so that once it looked nice I could just leave it alone.
  • Using a Pre-Determined Color Palette and Skipping Textures
    • By deciding I wasn’t going to waste my time this year with textures I freed up a lot of time to send on other aspects of the game. Because I stuck with a pre-determined color palette the game still looked pretty nice even as flat colors.
  • Multiplayer
    • Multiplayer wasn’t one of my original design choices. It got added to the game on the Sunday morning before turning it in. I had to call a buddy to bring over a Gamepad just to test to see if it even worked. This turned out to be an easy win due to how UE4 is set up. I just had to spin up a second player controller and that was about it. Most of the work the engine does right out of the box.
  • Destruction
    • Like multiplayer this feature was added late in the game but made a huge improvement. Originally couches were unmovable and the furniture was just something have to work around but I kept getting stuck on it. It was trying to figure out a solution to that problem that lead me to make the whole room alter-able. The effect was easy to implement and it made the game way more fun.
  • Juice
    • I tried adding a little Juice to this project. I added some time dilation and screen shake on balloon pops. I also added a confetti style particle effect. None of that was very hard to implement, but I think it makes it feel better when you score a hit.


What Did Not Go Well

  • Lighting
    • It turns out I had a lot to learn about lighting. I probably still do. Every other game I’ve worked on has either been outside, so the lighting was pretty much handled by the Sun (directional light) or has been intentionally dark. I found it really difficult to get the indoor light to look natural. I wound up just using a post process that added tons of ambient light, but I doubt that’s the right way to do it.
  • Unfinished features
    • There was a lot I wanted to implement that I did not get a chance to implement. I wanted to make the balloons semi transparent on the player’s Roomba so the player could still see it. I had intended there to be a choice of 3 weapons to extend the games play-ability. I also wanted there to be more than two Roombas in a game. Maybe I’ll come back to this game one day and implement these features but for LD37 I just ran out of time
  • Controls
    • I had intended for the controls to be a little clumsy. I had wanted the controls to be a little clumsy, like an old school tank controls type game. Unfortunately I don’t think I implemented them well. Turning isn’t great, and the camera is locked to the Roomba’s rotation, so turning always feels a little jarring. To make matters worse enemy AI Roomba turns instantly and accurately. It’s hindered b the distance it can travel, but it’s got pin point accuracy making it very frustrating in single player mode.




There’s an inspirational quote floating around on the internet that goes something like “It doesn’t get easier, you just get stronger.”  I feel like that really applies here. I feel like my entry for this Ludum Dare is heads and tails above what I turned in last time, but I don’t feel like it was any easier to create. If anything I feel like it was harder. There are a lot of systems in play for this game that did not exist in the simple survival horror game I made last time, but I don’t think I would have attempted something this ambitious had I not already done the game for LD34. So to answer the question “did this game jam treat you any differently?”, yes. I feel like this Ludum Dare treated me different. Not better. Just different.   @JimmothySanchez

Botanic Balcony | Postmortem

Posted by (twitter: @paigemarincak)
Wednesday, December 21st, 2016 11:25 am

Hello everyone!

This is a small (long?) post mortem for my jam entry Botanic Balcony! This was my first game jam, first time making a 3D game and my first VR game \o/

One Room

To be honest, I wasn’t intending to enter the jam because I’m busy with other things, but when I saw what the theme was Saturday afternoon I knew I had to go for it. The theme, One Room, fit well with a VR idea I had sitting around in my drafts and I figured it was a good chance to get it started.

The VR idea was simple: growing plants on your own private balcony. However, I wanted to make use of room scale VR, and have the game take up the minimum amount of space required. I wanted to make a game where everything was practically in reach and you didn’t really need to teleport around.

Thus, Botanic Balcony was born!

First Game Jam

I was lucky enough to have already drafted out ideas for this type of game months ago, so it was rather easy for me to strip everything down to the bare minimum: growing and watering plants. In that way, even though this was my first game jam, and I was working alone, and I had less than 72 hours, I didn’t really feel lost with what I needed to do. Plus, I started out with grey boxing everything 😉

The grey box ft. walls and rails.

First VR Game

I am so thankful that UE4 comes with a default VR setup. My biggest issue with getting the game running in VR was simply based around getting UE4’s default VR setup to run, which honestly came down to one thing: packing for distribution properly. Once that was out of the way, it was easy for me to run the default, throw some stuff around and get cracking.

At this point, I should mention that I was borrowing my father’s VR system for all of this. My development machine is nowhere near good enough to run VR, so the entire jam I was packing up and transferring the game between computers to test. Which lead to a lot of running back and forth. Which also led to my father not being very happy when I kept kicking him off from playing Battlefield to test. >w>;;;

In any case, getting the VR part of the game to function was easy-peasy.

The growth cycle of tomatoes.

First 3D Game

The real difficulties came in the form of this being my first 3D game. I’ve been messing with UE4 for the past few months from time to time, but mainly I was messing with shaders, learning about blueprints and so on. I’ve also never properly 3D modelled before. (I made a cup once in Bryce 4 or 5 when I was 10.)

It was… an experience…. I feel like I wasted so much time modelling things out, and I wish I could’ve included more plants. I thank youtube videos and those people who helped me out during my short twitch stream where I tried to model a pot. Otherwise I would’ve been 100% lost.

The Pot.


Because of these restrictions though, I aimed for a more low-poly type of thing, and kept most materials to be plain colors. I think it came out pretty well from a design perspective. Definitely the most complicated thing to model was the watering can.


The watering can.

Developing in VR Tips

There were a few things that came up during my development which might come in handy to keep in mind in the future if you ever try out VR development.

  • Make sure you’ve hit 90fps

The Vive headset is normally rather blurry for me because the distance between my eyes is less than 60cm, which is the lowest the headset supports. Because I normally feel some sort of nauseous when I play, I didn’t notice that the frame rate was running at 60fps when I first submitted the game. I had tested the game out on my brother, who happens to just not notice the frame rate drop, so I had no idea until my father tried it out. (My family is my guinea pigs.) My father noticed right away and let me know, and it took a while to figure out what was causing the cap.

In the end there were two things:

  • Steam will automatically cap the game at 60fps if you run it through that instead of opening it on your desktop (probably because it’s missing the VR support flag because it’s an exe and not a game on Steam)
  • UE4 automatically sets a cap of 62fps, and needs to be changed

It’s best to check these things first before trying out the wide variety of suggestions online. I tried changing it through command line arguments, turning off lots of settings in the post process volume and so on. In the end, it was rather simple.

Spawn a pot using a pot card!

  • Scale of your 3D Meshes

I’m a fairly average-sized person (5’6”), so when I was developing the game, everything felt about right for me. However my father and brother are taller (about 5’10”) so things like the fences and walls and so on originally felt rather short.

I was lucky enough that most of the models I made I guesstimated the size correctly, but for things like the door I had to look up measurements to make sure it was about right.

It was rather interesting though how you could easily go from being about average height to being a mouse, to being a giant just by changing the scale of your items.

Lots and lots of POTS

  • Guinea Pigs

Make sure you have some willing to suffer laggy frame rate or other such technical issues lying around. 😉

  • Do as much as you can without VR running

This may be specific to my setup, but the first 12 hours of the jam I was constantly testing things out and having VR running. The VR machine doesn’t really seem to be able to handle that type of workload. At one point while testing the computer started to overheat a bit and the VR headset lagged considerably. So bad that it felt like I was having the symptoms of fainting.

I ended up doing a lot of tests with dragging blocks around in UE4’s editor and flying around, using the VR machine only when absolutely necessary.


And that’s the gist of it! \o/

There’s tons of things I would like to add to the game, so I hope to continue it in the future. Maybe in 2017 😉

For now though, give it a look and maybe a play! There’s a youtube playthrough for those without the Vive.

Thanks for reading!


Post-mortem: My first game!

Posted by
Tuesday, December 20th, 2016 5:38 pm

How was it

Really enjoyed my first jam. I was able to come up with several ideas within couple hours, and settled on one shortly after. Mechanic didn’t take too long, spent significant time on graphics and audio (not that they turned out well).

What did I learn

That I can make and publish a game! This is a big one for me, as I have been writing code for a while, but I never really made anything. I used LMMS and sfxr for the first time, and learned a ton about Unity3D. Feedback on my game is also great.

What will I do next time

I will aim for a game that can be completed withing 5 minutes. My submission doesn’t have a satisfying win state, which makes it a lot less fun. I’ll also be improving my audio and graphics skills, so my next submission will be better polished. While rating, I noticed that many games do not have main menus. I will remember this and not worry about it for my next submission :)

Cure4Life Postmortem

Posted by (twitter: @gipzo_)
Tuesday, December 20th, 2016 8:00 am

Hello again, fellow darians :)

I guess this is my final postmortem post for Cure4Life.
Mostly because I can’t come up with anything new to write about this game :)

Firstly, my two older postmortem posts about this game:

Running out of Hands
Swinging the Axe

In this post I want to show you how our game changed from beginning to the end.

Quick tip: Using some sort of CVS (Git, for example) is very useful for this kind of posts.
It is difficult to find some time and capture game while jam is in progress (and if you’re not making timelapse).
But it is pretty simple to make commits to CVS and then, after the jam, go back in time and make some gifs :)

Day 1

After discussing core gameplay I started making prototype without proper sprites.
Managed to make physics-based shotgun :)



[Almost] One Room Post-mortem – Part 1

Posted by
Monday, December 19th, 2016 6:16 pm

Ludum Dare #36 was very special to me. I was on my town, at 1400m above the sea, with barely no connection to the Internet (only a weak WiFi signal from the town hall, no mobile access). I was alone, and I wanted to use the jam a perfect moment to learn Unity3D. I spent the days before the event day to watch some videos and I was able to complete a little but full game.

By creating [Almost] One Room for this one I wanted to repeat in the sense of learning. But this time I was not alone, I joined forces with Carlos Coronado (@carlosgamedev); he’s the creator of Mind: Path to Thalamus and an unnoficial Unreal Engine evangelist. He is also a friend of mine and one of my clients. Some years ago a guy of barely 16 years came to the gamedev forum I had and asked for a project to join and learn, we made a barricade system for L4D. Now this time it’s me who is asking him for help.

The idea was simple, I’ll “code” (with blueprints) and Carlos will do the art and will show me the basics of the engine and will aid me every time I get stuck and ¡spoiler alert!, it was often.

In fact we have not opened UE4 until the afternoon because Carlos was late and I spent the whole morning taking notes on paper about ideas with the theme in mind. When Carlos arrived I presented the best idea I had and we wanted to spend as much time as we can in the design stage.

We wanted to make a puzzle game playing with the idea of a room escape. For me it’s very important to find a twist to the Ludum theme, to go further than the obvious choice and that’s why I did not want to make a game with a single room. I played with ideas like turning the words, “What’s behind Room One?” or “You’re the room”, tried to think in a twist in the “CounterStrike rats map” making the players not humanoids. Finally we found something in the Room Escape idea that we liked, only one room, but many times.

The initial idea was to be locked in a room like a normal room escape but once you opened the first door you will find the same room again. From this point we started to think how you will need to open the doors, from lockpicks with mini-games to find-the-pieces ones, but it was hard to find something really fun, or something that the player cannot solve by trial and error. And more important, something we can achieve in the given timeframe.

At some point we though we nailed it, the room will be “the same” but in different timelines, past, present and future, and you had to change things in a time to affect the others and unlock the exit door. It was great, but it was impossible to find something readable enough to be solvable and not frustrating.

Time was running out and finally we went back to the beginning and started again to think. Then we decided to follow the KISS principle and we decided to make a simple puzzle game: Find the combination of the exit door. The twist? That the number will be hidden in the room, one number per room on different versions of the same room.

We then started to design how to hide numbers, but I will write about it in the second part 😉

[cache: storing page]