Posts Tagged ‘making of’

R. Lastey post-mortem

Posted by (twitter: @AurelDev)
Monday, September 5th, 2016 3:20 pm

(mirror of article on my site)

This weekend I participated in yet another Ludum Dare. This one was exceptional, however, because there were no ratings. It was also exceptional for me, because it’s the first time I submitted a (mostly solo) Jam entry, meaning I had 72 hours for creating the game. The theme was Ancient Technology, a clear winner compared to the other themes.

Apart from Ludum Dare, there was another important event – moving to our flatshare in London (I’ll study here, woo) from our temporary hostel accommodation. The plan was to move in as soon as possible in the morning, but naturally, got there around 3 in the afternoon. Luckily I could get my hands on a computer for some two hours before that, in a café.

In a way it wasn’t so bad, because for the longest time I wasn’t really sure about what kind of game I was making.

The future idea

From the very first moments I was considering a bit of a twist of the theme – it is the far future, humans discover ‘ancient technology’ (something from our time), completely misunderstand it but are amazed nonetheless. Like discovering ‘windows’, then placing them in the middle of the rooms instead of in the walls, or discovering forks and knives, then using them like chopsticks. You get the gist.

In a way it’s similar to Asimov’s ‘The Feeling of Power’, although that wasn’t my intention!

The alien idea


Internship Adventure – Graphical Making of – Part 3

Posted by (twitter: @bousquetm)
Wednesday, October 7th, 2015 11:22 am

(by Pascal Pouvereau)

This post is the last part of a three part article.
If you missed previous parts, you can read it first :
Internship Adventure – Graphical Making of – Part 1
Internship Adventure – Graphical Making of – Part 2

Our game is Internship adventure and we advise you to try it before reading this post.
Photoshop & Flash source files are given in the end of this article.

My English is quite poor and a French version is able here.


In the previous part, we talked about the way Roxane (the second graphic artist) helped me on the forest background ; she helped me too on the factory by making 3D models that I could integrate and work in the 2D stage.

Intership_3DRaw 3D renders

Intership_3DComposite3D renders composited on Photoshop

Those works were done during the lasts hours of the production, so the compositing is quite simple.

Mr Borbopopo

At the end of the second day, I temporally stopped working on backgrounds to help Roxane on animations. So, I started to work on the second monster and I could realize it at 100% from conception to finalization.

Internship_MrBorbopopoThe first version had little arms

First, I designed a big monster head, but quickly, it looked like a fat cyclops inside a egg shell (but everyone can see it like he want).

I spent a lot of time to find a good way to animate it. I finally decided to realize it as vector art in Flash. My knowledge about cartoon animation helped me to make funny moves.

MrBorbopopo_ConstructionShapes of Mr Borbopopo

The silhouette was very easy to animate thanks to Flash’s keyframes and the decomposition of the character in three main shapes like a kind of snowman. The eye was separated of the head to increase the cartoon animation.
The mouth had been the most difficult part of the process, because drawn on every 72 frames of the animation thanks to vector lines. I had to modify the width of the line on many frames to simulate the opening or the closing of the mouth.

MrBorbopopo_MouthDifferent width of Mr Borbopopo’s mouth

Once animations done, the work wasn’t completely finished.
All frames were exported in multiple png files and recomposed as tiles in one big file thanks to Graphics Gale.

Graphics Gale is a small software that look quite old with it 90’s interface, but it’s a very useful tool for animation  and the best pixel art tool I know.
I really recommends it because it’s powerfull and free (the only limitation of the free version is animated gif and cursors exportations).

The file containing all sprites is opened in Photoshop and quickly completed thanks to automatic effects (white borders). Working on only one file containing all the sprites is a very quick way to work on every frames at the same time. It avoid to use batch scripts.

MrBorbopo_FinalStepsLast steps of the sprite

Some frames had to be manually corrected because of dirty borders like the third step of the previous picture.

This is the end !

MrBorbopopo_JumpThank you for your attention !
As I promise you, here are my sources of the two levels and the character. Have fun !

Photoshop_File The forest

Photoshop_File The factory

Flash_File Mr Borbopopo’s animation

Photoshop_File Mr Borbopopo’s tileset

Internship Adventure – Graphical Making of – Part 2

Posted by (twitter: @bousquetm)
Friday, September 18th, 2015 10:59 am

This post is the second part of a three part article. If you missed the first part here it is : Internship Adventure – Graphical Making of – Part 1.

Our game is Internship adventure and we advise you to try it before reading this post.
Photoshop & Flash source files will be given in the third part of this article.

My English is quite poor and a French version is able here.


The sky wasn’t the longest part of work, it was even fast to build, only asking a little for work for the developer and I.


The artistic direction wanted to be like “done manually”.
Sky was first a simple gradient, but we added a kind of bump effect on it, but this effect was not directly in the gradient sky texture. We added an other map with a “multiply ×2” blend mode that was giving us more flexibility to add other effects in the sky.

Intership_SkySimple gradients and textured sky

“Multiply ×2” is a not enough well known blend mode able to light and dark pixels.
For instance, it is used to simulate lights of lightmaps.

Blend_LightmapLightmap with “multiply ×2” blend mode

In our case, we used it to add details on our original map.

Blend_DetailDetail texture with “multiply ×2” blend mode

This effect look like “Overlay” blend mode, but Photoshop don’t have a “Multiply ×2” blend mode. It’s not practical to simulate it in Photoshop because we have to use additional effect layer.
Happily, in most of game engines, it’s easy because it’s a standard blend mode since the 90s’.

Photoshop_File Example of “multiply ×2” in Photoshop


The sky gradient texture is very lite and allow us to build our day/night system.
Pixels of the original texture (4×64 px) can be smoothed thanks to filtering like bilinear, so our little gradient become a perfect full gradient.

FileringTwo ways to zoom on a texture

To make our day/night cycle, it’s easy, we only have to display the gradient on a two screen height plane and to translate it vertically.

Internship_DayNightA simple gradient allow a smooth transition between day and night


Stars were a little more difficult.
In fact, the most difficult task was to convince the developer because he had  bigger fish to fry. I would like to thanks him because he took the time to realize what I had in my head.

It look like what we did on the gradient, but it was not a translation but a rotation and a progressive alpha blending.

StarsStars rotation in the sky

To optimize memory, we used a looping 1024×1024texture and we made it tile in the plane.

This layer use an other blendmode which is very popular in video-games and FX : “additive”.

Blend_addExample of an additive blend mode without any alpha

Order of layers

The sky has 4 layers with associated blend modes.
We already saw 3 of them, the last is here to emphasize high atmosphere colors thanks to a “multiply ×2” blend mode.

Internship_SkyLayersLayers of our sky


Day/night system don’t affect only the sky. Backgrounds layers are affected too.

Both of the intermediate layers are multiplied with a white color on day and a blue color at night, allowing a better integration of environments.

Internship_DayNightEnvironmentForest environment at night and day


Foregrounds had to look like shadow silhouette but we was afraid that it would not always be visible because of darks backgrounds.
We added a white outline to differentiate active layer and decorative layers.

We first had to use a complex system that allowed to merge shapes without intersection with the white outline but we didn’t had the time to integrate it.

Internship_BorderClassical outlines VS Blended outlines


I admit that I’m not proud of our foregrounds but it’s logical, we did it in the rush of the end of the game.

Internship_GameLayerForest foreground

We finally choose to make a two layer foreground and I’d like to thanks Roxane which helped me for the forest.

End of part 2

This is the end for part 2.

In part 3, we’ll talk about our collaboration with Roxane and my work on a monster animation.
Thanks for your attention.

Internship Adventure – Graphical Making of – Part 1

Posted by (twitter: @bousquetm)
Monday, September 14th, 2015 4:46 pm

In this post, I’ll talk about my experience as a graphic artist in this gamejam and I’ll expose you some graphics process we used in our game.
We were two graphic artists to work on the project but this article concerns only my experience (Pascal).

I’m really sorry because my English is poor and sentences will maybe sound strange.

This is the first part of a long article, other parts will follow.
Our game is Internship adventure and we advise you to try it before reading this post.
Photoshop & Flash source files will be given in the last part of this article.


In this game, we didn’t want to use a pixel art style (well that I really like this technique).
Quickly, we agreed about a graphic style with silhouette foreground so that backgrounds would be very colored and graphical.

ReferencesSome refrences : Limbo, Bandland & Donkey Kong Returns

This artistic direction has first been chosen to simplify our work on characters animations (a very long process when we develop a game) while remaining coherent with our vision of the game.
This choice allowed us to enhance deep environments on which we could spend more time.

Since the beginning, we wanted to build small levels fitting only on one screen (no, we are not in LD31 ^^) like a painting that give us a lot of creative freedom.
Our engine was not adapted for big levels without tilesmaps but I refused to envisage tiles.
That was good because the theme of our game fit with this choice.

Roles distribution

We were two graphic artists in the team : Roxane and I (Pascal).
We agreed about working on complementary tasks avoiding collisions in our work :
Roxane worked on characters and animation so that I concentrated on environments.

Internship_RoxaneRoxane working on the caterpillar

You’ll see it next, we finally both worked on the other tasks too on the second half of the jam.

Work now !

Most of the work on environments was classical and I spend most of my time to paint layers on Photoshop thanks to my graphics tablet.
The finishing of layers in the game is not perfect, but, for a game jam, it’s OK.

Internship_LavaPart of the factory level background

Internship Adventure - Forest Part of the forest middle background

Beyond my artistic ability, I have some technical knowledge and I wanted to use it to go further in the graphical realization of the game.
In next paragraphs, I’ll list some of theme.


Parallax is a very well known technique in animation and video-game allowing to simulate depth in a scene.
The idea is to move different layers with different speeds related to their distance.

ParallaxeExample of parallax in a temporary level

Well that we choose to work on one-screen levels, I insist early in the creation process to introduce some parallax.
This technique offer supplementary depth in a picture, increasing immersion of the player in the game and gratifying backgrounds.
A blur foreground was expected but we had not enough time to integrate it in the game.

Depth layers4 depth layers of the forest

End of part 1

This is the end of part 1.

In part 2, we’ll talk about sky, day/night, blend modes and foregrounds.
Thanks for your attention.

I’m really sorry because my English restrict me.
If you want a most detailed post in French language, tell me in commentary.

Making-of “PONY!” (timelapse)

Posted by (twitter: @PixelProphecy)
Tuesday, August 25th, 2015 3:59 pm

LD Compo 33 PONY! by Pixel ProphecyHere’s the unfinished little time lapse of my unfinished little game, “PONY!”. A written post mortem (with pictures!) can be found

► here.

The Empty: My first time at Ludum Dare

Posted by
Tuesday, August 25th, 2015 11:11 am

After struggling with several bugs, constant black outs during development and a flu, I managed to make it to the compo!

I made this game using solely MagicaVoxel, a free voxel editor that is open source and super kickass!

My game (link to Ludum Dare profile) for this theme is a clone of basic cat and the mouse game. Everything was done by me. You can find out about the story by activating certain beacons when collapsing on them.

HighresScreenshot00000 HighresScreenshot00001 HighresScreenshot00002 HighresScreenshot00003

I’ll be adding a HTML 5 version soon enough. Everything was done in Unreal Engine 4. I wanted to make the game to look like a raycast game from the Doom era. Hope you like it!

Movement: WASD+mouse
Attack: Left Click.

How to run:

First be sure to have UE4 pre-requisites installed. You can find them in:

<Folder Name>\TheEmpty\Engine\Extras\Redist\en-us

Then go ahead and run the game by running the .exe on the root folder.



Source (Project)

PONY! Post Mortem (with pictures!)

Posted by (twitter: @PixelProphecy)
Monday, August 24th, 2015 4:47 pm

LD Compo 33_2015-08-24_02-25-27You don’t want to read the success stories all the time, right? Sometimes you can learn from something that failed more than from what made it, right? So here it is, the little story of PONY! and how it became what it is. For your reading pleasure I included some pictures of concepts of my journey from hating the theme to missing it by a mile. Enjoy!


We created a little making-of video of our creation of Funky Knight last weekend!

  • Look over our designer’s shoulder!
  • Observe the consumption of our coffee!
  • Watch our programmers coding stuff (I added no link to a specific point of time in the video because you can see them coding all the time)!
  • Watch our game designers eat snacks!
  • Spot the pink Ubooly plushie!!!

What you won’t see in the video:

  • how we record the dubbing
  • where the coffee came from (from the recording studio aka our kitchen)
  • the pyjama party

Warning: Something eat you !!!

Posted by (twitter: @molecats)
Thursday, December 18th, 2014 12:27 pm


ENTRY | Postmortem | All Making-of Posts

Hi there! We continue our Visibility Zero making-of posts. Now we will talk about “Something” :)

We have a few environment enemy:

  • Hot Lava Spots
  • Deadly Pitfalls
  • Mysterious Creature Swarm

If talk about Lava Spots and Pitfalls it’s simple mechanics, sphere collider and below Y-cord Instant Death.

So we’ll talk about Mysterious Creature Swarm. In our game we wanted to add something mysterious to killing you, but it should not be instant death was, but rather slow.

And we came up with to use a system of particles Boids. You do not see it at first but if you walk they will eat like piranhas but slowly.




Boids Algorithm based on

flocking in nature


So each Creature is affected by 3 base forses:

  • cohesion
  • separation + collisionAvoidance
  • alignmentForce

But for our game we also add Powerful Force is Player, *** SPOLER *** so when player not near Green Stellar they attack him *** SPOLER ***.


1000 particles – boids

You can find in internet many cool examples how to create and use boids and draw in one Unity draw call, do many Meshes and update it.

This simple idea add awesome experience when people die trying escape from Something and fall into Pitfalls


Play and Rate

Visibility Zero Making-of Part 2: the Environment

Posted by (twitter: @molecats)
Wednesday, December 17th, 2014 4:18 am



ENTRY | Postmortem | All Making-of Posts

Hi there! We continue our Visibility Zero making-of posts. The 2nd one will be about environment assets.

As I’ve already said in the previous article, due to limitations of what is seen on the screen in various modes we had an opportunity to use very simple assets for the environment, still maintaining a nice visual presentation at the same time.

I will start from the list of common rules for the assets, which have helped us to quickly compose the environment almost without worrying about performance:

  1. Lowpoly speed modelling with almost automatic smoothing group assignment (by angle, with minor manual tweaks) to easily receive properly triangulated models for “papercraft” feel.noise
  2. Automatic unwrap, no texture baking, no texture painting.
  3. Simple noise with a very small tiling is used as a texture.
  4. Very simple materials & shaders (except the ones we use for “glowing” objects).
  5. No global lightning & shadows in the scene (we only use red point lights near “HOT” objects).
  6. We don’t really like Unity’s standard terrain (cause it’s not very flexible), but for this project it was just perfect: we haven’t used any textures at all because the player has almost no chance to see them.

As for example assets, I will start with our Planet Rover (just for looks on the frontpage, you know=)):

rover_make (more…)

Visibility Zero Making-of Part 1: the Device

Posted by (twitter: @molecats)
Tuesday, December 16th, 2014 6:44 am


ENTRY | Postmortem | All Making-of Posts

Hi! As promised in our postmortem, we will do several Visibility Zero making-of posts this week, starting with this one. You will find all the posts under the tag vzero_omake.

My name is Stas and I’m an artist / designer in our team. The first post is about the visual side, so I’m the one who will narrate.

As soon as we’ve decided to do the idea with “a screen device with various visibility modes toggle”, I’ve started a visual style research. “The Device” is the central & the most important part of the game. It is always before the player’s eyes. It is an UI and a gameplay mechanic at the same time. As the player doesn’t really see a gameworld without the Device and as there is serious limitations of what is seen on the screen in various modes, then we have an opportunity to simplify the scene assets. Thus we have more time to make the Device itself.


Making of The Monastery

Posted by
Tuesday, April 29th, 2014 3:44 am

I didn’t record a timelapse video but I wrote this post talking about the development of my Ludum Dare game The Monastery. This will be a rather lengthy story of the development process so find a comfortable position and have a cup of tea or coffee. I want to get this out of my system now that the horrors are still vividly in my brain!

The Monastery is a type of game I’ve wanted to make for some time. I happen to like old school games and one game in particular that I have fond childhood memories of is SSI’s Pool of Radiance from 1988. For those too young to remember, Pool of Radiance (or just POR to friends) is a fantasy roleplaying game that features tactical combat and resource management and was one of the first games to fully implement the complex Advanced Dungeons & Dragons rule system. I really liked the game then and even today the battle system and the setting is very good. Naturally POR inspired me to revisit the genre and make The Monastery.

Play and rate The Monastery here



Day 1

From the get go the project was not smooth sailing. On Friday, a day before the compo, I woke up with fever. I had already cleared my calendar for the weekend and had been very pumped up for the compo the entire week so I cursed my bad luck. I had to stay the day in bed and decided to check how I felt on Saturday. Luckily I woke up on Saturday and the fever was gone. Phew! I checked the theme, which was Beneath the Surface. Well, at least it’s not Breaking the Rules or whatever. I began thinking about ideas, mainly background stories, that would fit the theme while eating breakfast and taking a shower. Initial ideas that popped in my head felt too easy: being underground or underwater. I decided to have a walk around the neighborhood while pondering more on the theme. Then suddenly I had a vision of a large frozen pond. Even though it was sunny and warm outside I dreamed of travelling in a frozen landscape passing by a large building… perhaps a wizard academy? No, too Harry Potterish. Let’s make it a monastery!

I got back home and started googling and I found the book Haunted Monastery by Robert van Gulik. It was some kind of eastern horror detective story which gave me some ideas. I started to think how to make the monastery an interesting place for a group of adventurers. The monastery should be an eerie place, maybe abandoned but not empty. There was a mystery that needed to be solved. And I needed monsters to fight… Undead Monks? Then I started thinking what bad things had happened in the monastery and how the monks had been transformed into horrible undeads. And what about the abbot? Why is he missing? Where is he?

I spent about 3 hours working on the setting and background story. It was already afternoon when I turned on my computer and was ready to start drawing the graphics. I hadn’t drawn any real graphics for a loong time so it took me a while to get accustomed to the software and the process. I used Aseprite, a tool which I had never used before, but to my delight it turned out to be a great tool for pixel graphics. I started by drawing the font and then proceeded to make the player sprites. I needed sprites for the player charcters, the Fighter, Cleric, Wizard and… I pondered on the fourth guy for a minute — of course, there had to be a fourth guy — before settling on the Ninja, which I thought was pretty funny. Then I realized that I wanted to have character creation in the game like in all proper RPGs so I made four variations for each character and separate standing sprite and attack sprite. That’s 32 tiles in total, but luckily the variations are only different coloring. (Those who have played the game may have noticed that character creation was a victim at the cutting table and the color variations are not used by the game.)


After the characters were done, I did the enemy sprites for about 10 different enemies. When they were done it was already about 6pm and I had a dinner break. I realized I didn’t have a single line of code written yet so I decided that I had to have at least something on the screen before I called it a day. So I started coding a turn-based battle system. I like the Lua programming language a lot and it was a no-brainer to use it for the project. I had made SDL bindings for Lua a couple of a days ago as preparation work for the compo. Starting from scratch when coding can be painful and no surprises there, I had some problems with Lua error messages and stacktraces not being shown properly. I had no time to tackle the issue properly so I carried on. In hindsight this probably was a mistake because I was suffering from some quirks with the codebase the entire weekend.

At the end of day 1, I had the basics of moving on the battlefield and attacking done, but all the fancy things like spells and stats were missing. But hey I could now move on the battlefield and kill monsters! And the monster could do some simple pathfinding my way too.

Day 2

I woke up on Sunday feeling very worried. I had only 19 hours left and I didn’t have anything ready that resembled the game I had in my head yet. The remaining todo list was daunting: character creation, exploration mode, spell system, healing, items, winning condition, monster statistics, character statistics, dungeon props, intro, main menu, level design, scripted encounters, sounds, music, playtesting, packaging the game for release… I decided to somehow try not to think about it and just start working. But I felt that the mother of all crunches was ahead of me.

I decided to work first on the most crucial parts: exploration mode and encounters. Without them the game would not feel at all like those good RPGs of old. I first considered whether I should make a random level generator but I thought that tuning it would be slower than just drawing a few levels by hand. So I grabbed a sheet of graph paper and started doodling and writing down names and purposes of rooms: entrance hall, storage, dining room, kitchen, lavatory… Upstairs: bedrooms, library… a ritual room! I tried to imagine myself walking in the monastery and thinking what I would need if I was living there. Then I started writing room descriptions and notes that the monks had left behind. I thought about the frozen pond and what has buried beneath its surface. The notes would be crucial in telling the story that I had in mind.


I quickly wrote a system for describing the levels and rooms in Lua. I made a simple encounter system, which was essentially as simple as an anonymous function called per room. The function would be called when the player entered the room. The function would print room description to the screen but could also execute any Lua code for triggering battles, placing items on the map and so on. Later the system would be extended to handle searching the rooms.

When I had the levels and rooms done the clock was already 3pm. Then real desperation struck me. Only 12 hours left and the game had huge gaping holes, important pieces missing everywhere. I really thought more than twice about quitting. I felt that it was impossible to do what I wanted in the remaining time. Besides I needed at least an hour, preferably three to playtest and polish the game at the end. That meant less than 10 hours to implement all the features. Quitting was tempting… But failure was not an option! I had already publicly announced that I would do this game. Damnit! I bit my lip and started furiously coding, banging the keyboard like a madman (my spouse was getting really worried at this point).

I only stopped a few times, a minute or two at a time to catch fresh air or eat a sandwitch quickly. During the coding marathon I consumed several litres of juice and soft drinks. Feature by feature I went through the list, working always on what seemed the highest priority thing. The order was roughly: winning the game, character stats, monster stats, key items, dungeon props (doors, stairs, etc.) and spells. 9 hours later, at midnight local time and four hours before the deadline I finally had a working game. There was still work to do but I was now feeling confident that I could do this. The main menu, sounds and music were created only about two hours before the deadline. I used the excellent BXFR for the sounds and cgMusic for generating the theme music.

Less than two hours left, it was time to start testing and polishing. I was very exhausted from coding and luckily I got some testing help from my brother Erik, who kindly stayed awake late and tirelessly played the game even though he had to go to his studies the next day. Thank you Erik, without your help The Monastery would be much less balanced.

I kept on tweaked the game till the last minute. The last feature, casting healing spells outside of combat, also requested by Erik, was added just about 15 minutes before the deadline! I was nervous about making changes so late and so tired. I quickly packaged the game and submitted it only a couple of minutes before the deadline. I did not have time to play through the game fully before submission. I had only tested the encounters in isolation and made balancing tweaks “blindly” by following Erik’s advice such as “take 1-2 skeletons from this encounter”, “reduce hp of spiders by a few points”, etc.

Now that the game was submitted I finally had time to play it myself. My head hurt from all the coding, I had been coding 19 hours nonstop. My neck was about to cramp and even the muscles in my face were hurting. But it did not stop me from enjoying the game — I think this was the first time playing my own game just after release and it did not feel exhausting. I played through the first floor and the game felt pretty good. Completed the second floor as well. Then the ultimate end fight — hard as a coffin nail just as it should be! I just barely survived it with two of my guys dead and the remaining two barely alive with 2 or 3 hp and no spells left. It had taken me about half an hour to play through the game. I was happy, I was relieved. I was dead tired! Satisfied I went to bed.

End of story. Or is it? After working so hard on The Monastery, I would really, really like to hear what you think about it. I certainly hope you enjoy it, especially if you like tactical RPGs but I can also take brutal honest feedback. I know there are things that could be improved — the UI could use some streamlining. In fact I’m considering making an updated version. Even if you do not like the game, then I hope it at least stands out from the crowd like a relic from a strange forgotten age!

Petri signing off.

Play and rate The Monastery here

Seeds of Wrath – Mini-clip/making of

Posted by (twitter: @OIIOIIOI)
Thursday, December 27th, 2012 3:55 am

Hi everyone!
We would like to thank you for playing and rating our game! :)
For those who did not and would like to, here you go!

During the last night, CAPSLOCK and I put together a little clip from our livestream archives…
We dedicate this minute of sillyness to Juliette, the 3-days-old daughter of Mewine and Fleacontent, who was with us in a way during this LD! 😉
Have a good time you three!

Enjoy! (and sorry for the webcam quality, that’s all we had to work with…)

An online persistent world building game in 48 hours

Posted by
Saturday, April 28th, 2012 9:44 am

I’d been meaning to write this a lot earlier, but I’ve been way too busy to do it until today. Anyways, I made an online persistent world game in 48 hours. I wonder if it’s been done before during LD? We really need a tag system for games or something, it’d be interesting to be able to look up games with
specific elements. This post will be a bit of a combination of a making-of and a post-mortem; I’ll explain how this game came to be and comment on it.

Before Ludum Dare
This was my second Ludum Dare, so I had a decent idea of what to expect. Last time I used Unity, which had both its advantages and disadvantages. But since I’m the kind of person who wants to be able to customize everything and doesn’t want unnecessary things forced into his game, I prefer not to work with Unity. Fortunately, since February I’ve been doing an internship where I’m working on an XNA game, so I got pretty familiar with it. In making that game, I wrote a simple sprite engine which turned out to be very useful, so a week or so before LD23, I took the engine, removed some game-specific functions, added a tiny bit of documentation and released it as VBXSE. A short while ago I’d also been working on a simple netplay engine named GNI in my free time, so I decided to release that as well.

The original idea
After waking up at around 9-10 AM (competition started at 3 AM for me, but sleep is very important if you’re doing a 48-hour solo project), I checked the site to find out the theme was unexpectedly ‘Tiny World’, a theme I hadn’t even considered a possible winner in the poll. After thinking about it, I decided to make a roguelike-ish survival game similar to UnReal World where you and a couple of NPCs were stuck on a tiny island and had to get food and shelter to survive. That’s right, the original concept was nothing like what the game eventually became. I wrote down the basic game design in a text file, if you want details. So, I started working on the survival roguelike…

World and Graphics
Since roguelikes tend to be played in console windows, I decided to keep the area size small enough to fit in one. After some thinking, I decided square areas would make the most sense considering you also need room for other game information, and I ended up at a 22×22 world with each tile having 22×22 subtiles.

After a rough interface sketch, some calculations and some guesswork I decided the tiles would graphically fit best at a 32×32 size. However, I’m terrible at drawing stuff, so I decided to turn ‘lack of skill’ into ‘style’ and went for a pixel art look; I drew every tile and item in 8×8 and then resized it to 32×32 to make it look ‘retro’.

I made all of the art in GIMP because the Paint that comes with Windows 7 tries to be too hard to be a real drawing program and in doing so actually becomes worse for making pixel art…and it still doesn’t have any transparency. Brushes were surprisingly actually very useful when making tiles like grass, sand and sea. Just keep using random brushes and you have good-looking grass. Definitely something I should use more often.

Sound and music
The music for the game was made in FL Studio 9 using only soundfonts from DSK Music‘s HQ Instruments set. Although the effect is very subtle, the game actually contains dynamic music; although throughout the entire game the same track keeps playing, there’s three slightly different versions of them. They play simultaneously, and the volume adjusts depending on where you are.

Normal track
Forest track
Beach track
FLP (FL Studio Project) file

The music used the ‘Celtic Harp’, ‘Ney Flute’, ‘Percussion 1’, ‘Oboe’ (forest only) and ‘Harp’ (beach only) soundfonts. It was inspired by Paavo “Tarantula” Harkonen’s soundtrack for obscure MMORPG Dransik (now a shadow of its former self and named ‘Ashen Empires’) and a random street performer playing on a harp the day before LD23.

The sound was created by rubbing or hitting various objects around my desk against eachother in different ways, recorded with my laptop microphone and edited in Audacity (amplitude change, pitch change and echo). Like the music, it was mainly inspired by obscure MMORPG Dransik, where you would hear a simple but satisfying sound whenever you did things like cutting trees and mining.

But how did it become a persistent world game?
Development started out well. I started by making simple ‘world generation’ (filling the entire world with grass tiles). Then I made movement work, then proceeded to add sea and forests to world generation. I added the axe and item usage, so you could chop wood. Then I also needed support for dropping and picking up items, which also required a menu to let you choose between items. I also made sure you could save and load your world, so I made functions to serialize the entire world to a long string and load it again.

At that point, day 1 was already over (LD goes from Saturday 3 AM to Monday 3 AM here, so it’s 2 days instead of 3 as it is in some time zones), and there was no sign of crafting, construction, the hunger system, NPCs, wildlife, fishing and similar methods of food gathering, liquids, an age system, building recognition or pretty much anything beyond the very basics of the game. Whoops. So, what is the logical thing to do when your plans seem way to ambitious?

I went with the logical solution: I changed my game into a complete persistent world building game. Of course it’s a ridiculous decision to take halfway through development, and even more so when your project is in that state due to being way too ambitious, but all things considered, it ended up being not as unreasonable as it sounds. I had recently created a netplay library, and though network communication is always tricky and it was not tested much, it did seem to work perfectly from the small amount of testing it did get. As a game design decision it was more logical than anything; I was just a tiny bit of code away from making a game where you can build stuff, and games like Minecraft, Terraria, Active Worlds, a whole slew of BYOND building games and many more games have pointed out that just building things for other players to see can actually be fun in itself. Add to all that that I could already serialize any part of the world to a string, and the decision was made overnight to go all-or-nothing for an online persistent world game.

The first thing I did on the second day was finish the crafting and building system (otherwise even having a persistent world would be futile). Then I used my GNI library to write a server program and a client class. The client would ask the server for the serialized string representing the world map, and then for the serialized strings of each of the areas in the tiles (each tile on the 22×22 world map contains an inner area consisting of 22×22 ‘subtiles’, if you haven’t played the game). I found out the serialization had some errors, but after some bugfixing, it actually worked perfectly. Then, to make client changes affect the server and have the server keep the client up to date, instead of at the start the server would send the client the inner areas only whenever he zoomed in or walked to a different inner area, and the client would serialize the entire inner area and send it to the server whenever a tree was cut, an item was dropped or picked up and whenever something was built. It’s an inefficient approach (the reason it lags whenever you switch between areas or do something area-affecting), but it worked great for a 48-hour game. I then proceeded to add functionality for chat, player names, seeing each other, et cetera.

After the netplay features worked, I decided to add what little extra content I could still safely push in (mountains, stone, and anything that requires stone – yes, originally there was only wood) and release it.

What I like about the game
-It’s a persistent world game. That by itself is awesome.
-It’s my first succesful attempt at a non-BYOND online game. There was one other finished game were I attempted netplay, but its netplay was a horribly buggy mess that desynced for any players that were more than 2 meters apart.
-The world generation is nice. I’ve barely done any random world generation before, so the fact that I managed to get a properly shaped island with properly shaped beach and mountain areas out of it is pretty nice.

What I dislike about the game
-Lack of content. And I mean utter lack of content. There’s two kinds of walls to build, two kinds of floor plus four natural floor tiles, one tool to make and one decorative item. Ludum Dare games aren’t known for their extreme length, but it’s very minimal here; it’s a building game, but there’s hardly any variation in what you can build, so you get bored very easily. This is especially disappointing after my previous LD game, which could be played for significant lengths of time and still be interesting.
-It’s buggy and laggy. Whenever you zoom in, lag. Whenever you build something, lag. Whenever you cut a tree, lag. Whenever you move from one area to another, lag. And those 4 natural tiles I mentioned at the previous point? Good luck getting three of those without relogging a minute later, as they mess up something in the graphics (still not sure what causes it).

Things I should do again next LD
-Use VBXSE and GNI again. Especially the latter came as a surprise in how powerful it can be in just a small amount of development time. I was afraid of netplay functionality before considering the debugging hell it can cause, but now I think I’ll just plan for netplay from the start of the theme allows it.
-Use pixel art. I can’t draw, but ‘style’ turns out to work as a pretty good excuse to hide my lack of skill.
-Record random objects using my laptop microphone and edit them in Audacity for quick sound effects. I’m pretty satisfied with how they turned out; they subtly add a lot.
-Be overly amibitious. Partly because I’m just an idiot, but also because going beyond what you know you can do allows you to learn new things. It would be better for the game if I didn’t, but in the long run this is very useful.

Things to keep in mind for next LD
-I should make sure there’s enough content. LD is for games, not for tech demos.
-I should try to get the day after LD off work. Starting a week with a serious lack of sleep hurts your productivity for the entire week.
-I should update and improve VBXSE and especially GNI. They’re awesome, and therefore they must become even more awesome.
-I should make sure I’m used to the the tools and libraries I’m working with. I thought I knew XNA, but it wasn’t until halfway through the project that I realized I didn’t know even how to play multiple music tracks at the same time and change their volume. I also wasted a lot of time debugging an issue that happened because I didn’t take into account that using auto-poll GNI’s client class handles received data in a different thread.

Beyond here
I was initially considering updating the game a bit, adding some extra content and fixing some things I didn’t like, but there are so many things I’d like to change and so many things that need to be changed to make the game actually fun that it’d just take too much time. I think it would be interesting to one day make a complete game based on this, but that’s the kind of plan that will either never see the light of day at all or won’t be used until years later.

By the way, I forgot to do it initially, but I’ve slapped a Creative Commons license on the game so you have the right to mess with it in any way you want. Well then, see you all next LD!

Appendix A: Tools/libraries/etc used
C#: The language the game is written in.
XNA: Engine used for the game.
Microsoft Visual Studio 2010: The IDE I’ve used to make the game in.
VBXSE: XNA Sprite engine, used for all graphics stuff.
GNI: Netplay library, used for client-server communication
FL Studio 9: Used to make the music. I’m a fervent supporter of pattern blocks, even as Image-Line gets rid of its unique features.
DSK Music’s HQ Instruments: Set of amazing soundfonts I use for music. The music for this game was made solely using DSK HQ Instruments, using default FL Studio VSTs as effects.
Audacity: Pretty much the best audio editor around. Used for sound effects.

Appendix B: Network signals
If you’re interested in how exactly the server and client communicate, these signals are sent back and forth. Each signal has a ‘key’ denoting what the signal is about, and a ‘value’ containing other info.

Server to client
(None) – A signal with no information to check if the client is still connected.
identify – Asks the player for his appearance and location, in case some other players requests it later.
goplay – After version check and sending the necessary maps. Tells the client the player can start playing.
gspfinish – Indicates the server is finished sending inner tiles and the client can enter the subterrain the player was about to enter.
message – A chat or system message. Output the value to the displayed messages.
people – A list with the unique player numbers of all players that are currently online. If a known ID is missing, that means a player has disconnected. If there’s an unknown ID, the client sends a ‘who’ signal to ask for information on the new player.
person – Information on a player (ID, appearance, location) as a response to the ‘who’ signal. The client will then add the player to the list of known IDs.
pos|X – Where X is the unique player number of a different player. Tells the client where the specified player is right now.
subter|X|Y – Where X and Y are integers representing coordinates. Replace the inner tile at X,Y with the serialized inner tile in the value string.
subteru|X|Y – Same as above, but the change is vital, so if the player is in the area, it MUST update the inner area before letting the player continue doing whatever he’s doing.
versioncheck – Asks the client to send his version number, to make sure he isn’t using an outdated client.
versionmismatch – Tells the client he can’t play on the server because the versions don’t match. Which version the server is running is in the value.
where – Requests the client to send a ‘here’ signal, telling the server where the player is.
worldmap – Sends a serialized world map as the value. Allows the client to build the same world map client-side as the one that exists server-side.

Client to server
The server automatically sends these signals without the client saying anything to it:
Every 2 seconds – where – Ask for the player’s current location.
Every 2 seconds – pos – Tells the player where other players are.
Whenever a client connects – versioncheck – Asks the player for his client version.

The server can receive the following messages:
cmsg – Client wants to send a chat message.
getsubplus – Value contains X and Y coordinate. Client asks server for the inner area at (X,Y) as well as the 8 areas around it. Server sends them followed by a ‘gspfinish’.
here – Client tells the server where the player is.
ident – Client tells server information about the player (appearance and location). Server stores the information and sends ‘worldmap’ and ‘goplay’ signals to let the player start.
nick – Sets the player’s nickname.
usub|X|Y – Client tells server they updated the inner tile at (X, Y). Server updates world and sends a ‘subteru’ signal to all players.
version – Client tells server what version they’re using. If it matches, the server will return an ‘identify’ signal, otherwise it will return a ‘versionmismatch’ signal.
who – Client asks server for information on a player. Server sends a ‘person’ signal in response.

[cache: storing page]