5 hours later, I’m starting to see some light. I’ve started late, mainly because the time zone (I’m from Spain). This is the second time I develop for the Ludum Dare, and the first time I do it solo (time will tell if I can arrive for the compo deadline or if I will give me some time and external resources for the jam).

Shapeshift was one of the themes I did not like from the beggining, too many work to do some early ideas I had when I saw the theme. Then, I’ve spent the first hour and a half brainstorming like hell to find ideas that will be easy enough for a programmer to implement, and more important, to draw… because programmer art, you know.

Finally I’ve decided to make something inspired by Hexagon and it’s dodge mechanic but technically simpler.

The initial idea for the game is simple. You are in a laberinth like level and you can move around. In the background you can see another level, and when a short countdown beats, the background map will switch to the front. If you are in a clear tile, you can continue, if not, you’re dead. The more time you stand, the faster levels will switch. Will you be able to move fast enough to adapt?

Next you can see a first sketch of how it will look like, black walls, transparent floor and in the background the next level. You are the red circle and the line shows a “correct movement”.

I had some technical difficulties because I use a custom engine from a friend of mine and teammate on the last LD and I’m not used to it, but now I have a level loaded and I can move around. Next stop, level switch mechanic.

Tags: level, shapeshift, Spain, switch

After some hours I’ve been able to complete a very first prototype with the basic gameplay working and end condition. You have to survive by being in a safe (black) place because every few seconds the background map will come to foreground, be sure to move to a good (black) position.

I think this time I will work less hours, now it’s 23:36 here and after playing a little bit I’ll go to bed. I prefer to wake up early and continue adding the HUD, sounds and other effects.

Tags: gamedev, java, LD35, linux, shapeshift

Today it was a relaxing day since I’ve decide to go for the Jam and let the Compo for another edition. I’ve learned that I’m not very good with graphics (not a big surprise) and I spent a lot of time doing and redoing the tileset. Finally I decided a vector-like style since I worked a lot of time with photoshop layer effects and I knew it will give me better results.

The gameplay is completed in its simpler form, it has a difficulty curve and and first iteration of the hub. I had problems because I wanted to go from 400×300 to 800×600 and it gave headaches with re-scaling (due to a bug in the configuration I fixed, please, get used to CONSTANTS for every config value).

Tomorrow I will not have too many time but I’ll try to add some Creative Commons / public domain FX and music and will try to clean the code a little bit to get used to the engine we use a little bit more.

Ludum Dare 35 was the second one for me, as a ludum and as a game jam. The last time I joined forces as a part of DarkLight Team, but this time half of the team had a real-life problem and we were only two coders on the team. Then we decide to join the compo and try what can we do all alone. Neon Level Switcher was child.

What went well

The game is finished

From the first hour I decided to go to a simpler project that I could potentially finish in time. And it was a good idea, because I needed to switch to the jam competition to have 24 hours more to have a nicer game. But in the end, the game was completed, maybe not the best gameplay (see more later), but is playable, graphics and sound complete. I had a lot of ideas, lets take a look:

• Rhythm game with shape change mechanic
• Local Multiplayer game with shape change mechanic (rock, paper scissors maybe?)
• Plattformer with a “shape” protagonist that needs to change to beat situations
• Pong like game where you can change your shape to change the ball direction
• Turn based game, every turn you can change your shape to define speed, like Formula D, the more sides, the more speed
• The enemies change shape every time you shoot them
• The side count matters
• Physics based mechanics, playing with the shape you “shoot”
• You can change your shape to hide from enemies
• Worms like game where the player can “paint” their bullet to adapt to the terrain
• Wall of death game, you need to change your shape to fit in the wall that’s coming
• The shape of the scenario changes, move wisely to not die
• Finding the most relaxing “shape” in the sofa

I wrote down every idea I had, no matter how hard or crazy it seemed to me, because some times an impossible idea leads to another one and luckily, it could be THE IDEA. I would love to do a rhythm game (I was very involved in the machine dance scene in Spain), but it will be very hard to do when you don’t have any idea of sound programming. Others involved too many mechanics to code them all alone and in the end, the winner was due to the fact the last game in the ludum dare used Tiled levels and it would be easier to me to develop something. I loved to see some of the ideas appeared as submissions :D.

I did the graphics

I love to draw, but loving something does not means that you will be able to do it correctly. The major fear I had when we decided to go solo were the graphics. They may seem simple, but it was a nightmare for me to generate such a simple tileset. In the end, going simple was the best option, sacrificing a “theme” behind the game and hoping you will not need to know why you are a rotating rhombus that moves through blue levels.

My main inspiration was Hexagon, I think it’s a great title graphic wise. But something I learned is that making something look simple implies a lot of work.

It was relaxing

Too many people tie a game jam to an stressful situation. I think is a great error. You are here to learn, to have fun, to go creating with boundaries. But you don’t really need to crunch in a game jam. I want to highlight the “need” verb I’ve used, it’s OK to stress yourself if you want, maybe you want to test how much you can do in 48/72h. In my case, I wanted to finish without wasting resting time, and it was a success. Saturday night I decided to go to play the Doom beta and leaving the Compo even when I had 3 more hours to finish the game. As a result, it was very fun to me, even when the engine failed to deploy the game with 1 hour left to do it.

Tags: ld35 Postmortem, post-mortem, postmortem

Today was a hard day. The morning was invested in finishing some mechanics and UI adjustments and I’ve spent too many time trying to understand how Unity Joints work.

It was not before 17h that I started working in level design. I’ve been able to create 7 levels, half of them are just tutorial ones showing how the mechanics works, but the problems around some puzzles discouraged me.

That’s why I decided to start working in the graphics for the game. I’m a pure coder, and that usually means you have barely no artistic skills. In my case I tried to learn drawing for years and I did not succeed, but miraculously this time I think I’ve been able to create a good theme for my standards.

I’m very tired now and I’m going to sleep, tomorrow will be a hard day, I’ll have to finish as much as I can before submitting the game. It will not be complete, but I think it was a great experience.

PS: Today I took a break from LD by going 1km far away from the town at 1am to take photos of the stars. Next you can find how 2 minutes holding the trigger looks like 😉

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!

Tags: [Almost] One Room, Carlos Coronado, LD #37 postmortem, postmortem, Theck, ue4, unreal engine, Xavier Borrut

12 hours from beginning the jam I think I'll stop for today. I started late (11:00 in Spain, like 8h after the theme reveal) and I had stuff to do at home, alone (no team this time) and with the idea to practice with Unreal Engine 4.

A page in blank, the hard part

I spent all the morning just brainstorming ideas with the Theme in mind. I always try to go beyond the easy pick and try to find a way to re-interpret the theme to make something special. After starting 6 ideas I finally selected the one I think that technically can achieve. The theme interpretation is not my best one, but I think it could be mechanically interesting.

I'm developing a dual sticker shooter about surviving hordes of enemies. Nothing really original here, keep in mind my main objective is to learn as much as I can from the engine rather than creating a great original game.

The twist is, "the more frags you get, the harder it will get". Basically with every kill you'll get a nerf on your character, for example I started with speed, the more frags you get, the slower will your character be. I have more nerf in mind, but I'll only extend that part if I have time (it will not happen, sincerely).

Where am I now?

It's 23:00 now and I have a core gameplay working and some systems done in an status I did not think possible.

I'm using the Dual stick template from UE4 but my character starts to differ, adding more variables and custom events to be able to manage the nerfs.

But the major part of the development was in the enemy side. I started following an AI tutorial to get a very basic enemy that follows the player and from there I was on my own.

The first I did was give the player the ability to kill the enemies, and next I built the communication channel to nerf the player with every enemy killed.

Lastly I started my "Horde manager". I'm specially proud of this Blueprint class gorup because it's 100% mine. It's composed by an HordeManager, the EnemySpawnPoint and obviously the EnemyCharacter I created in the first place. It's very simple right now, but it works, creates an horde of a random number of enemies and spawn randomly through the spawn points you place in the level.

It's late, I'm a little bit tired of developing and I think I want to play a full game now, see you tomorrow!

Well, just dropping some random thoughts today, not so much done because I spend a large part of the day outside, but even taking that into consideration, not bad, not bad really.

This morning I started adding more features to the horde system at in an hour and a half I had it completed enough, with infinite hordes, wait time between, etc.

The rest of the day until I got out I've been able to complete a full game loop. That means, starting, playing and when dying, starting a new game, including a very basic UI consisting in a progress bar for the enemy count, the countdown between hordes and a results screen. That's for me more than I expected to be able to achieve this Ludum Dare and that's why I decided to give me some spare time.

Now at 23:50 I've added some geometry to be able to test the gameplay with more elements in the scene. That's basically walls and more horde spawns to distribute better the enemies.

Tomorrow I'll have to decide if going further with more features (for example, items), or try to do some kind of art pass to have something "better" than I have now.

Making a game is plan and execution, and with the time constrains of a game jam it's easy to fall into developing too early trying to get things done fast.

But experience shown me that precisely because of the time constrains of a game jam, planning is even more important, because every error you make will be a dead weight, losing lots of time trying to overpass the limits of an erroneous design approach.

That's why I tend to spend nearly all the first day only thinking, writing and looking for a balance between a good game for the jam and a doable game for the jam. I tend to put objectives that will guide my decisions, because you'll have to cut your game for sure, and then, you'll thank any help.

This Ludum I was alone. I have friends that we usually join together from Ludum to Ludum, but this time was impossible to meet due to work and personal reasons. When that happens, I tend to use the jam as an excuse to learn something new rather than trying to make a great contender. Last time I participated I joined forces with Carlos Coronado, a friend and something like an Unreal Preacher, and was a great opportunity to learn the basics of the engine. Please take some time to take a look to Almost One Room. This time, I though that would be great to repeat with UE4, but without the safety net that's a person next to you that will do what you can't.

Now you have some context, I want to share with you the simplified GDD I wrote for Don't Fram 'em All.

As you will read, I started trying to figure ideas for the "major" genres and the theme of the Jam, and then I started evaluating how much difficult would be for me to develop each one. Take into consideration I'm a coder, but I was working mainly in the web-app industry and now I work in marketing and communication for videogames, in summary, I'm not an artist and my coding skills are not trained for how game engines work. So I needed to think carefully about the time needed to make each part.

Finally I decided to go with something where I don't start from zero. Unreal Engine has a top-down-shooter template that will be a good start point because it let me focus into the thematic game mechanics. So next was writing about the Top Down SHooter idea.

I try to cover as many points of the development as possible, but I think it's better to avoid going into details. The idea behind the exercise of writing the simplified GDD is to identify possible bottlenecks and where the major efforts would be needed to plan a good development order.

For example, I was pretty sure the game will need more than one nerf, but to go with a minimum viable product it's enough with one nerf. But taking into consideration that, I coded the system to be extendable from the beginning. Finally I was not able to code a second nerf, but the base was solid enough.

Writing it also helped me to know that the horde system will be the most important part because it needs to control more entities than the other features and also it needs to communicate messages between entities, something I never did before in Unreal Engine and thus, it was a probable source of problems. That's why I started creating the enemy and then, focused all my efforts in the Horde Manager.

Well, I think it's enough. That post is long enough. I think I'll add some cat images to make it more interesting. Many thanks for reading.