Once again, I’m going to honest (and critical) and try to make this mega-post interesting!

PLAY THE GAME HERE

My goals for Ludum Dare 22

• Before the competition started, I had some goals in mind that I wanted to make.

1. I wanted to make sure “Fun” was the best category, so that people could replay the game, and have a good time playing.
2. I wanted the gameplay to be smooth and the animations smoother.
3. I wanted to beat Notch in at least one category (knowing how hard that would be).

What software I used

• Unity 3d Game Engine
• Blender 3D Modeling Software
• Pixlr Photo Editor
• Cfxr Sound Generator
• Unitron Script Editor
• Garageband Music Creator
• Text Edit Text Editor

How I made the game

• I quickly had come up with an idea for each of the most likely themes before LD22 started. My theme for “Alone” was a game where you would be sometimes alone, and then all of a sudden, you would be crowded with people.
• After the theme was announced, I decided that the game would be first person (the easiest of all the persons) and that you would have to fight your way through endless hordes of cubes (the easiest of default shapes). You could only see the cubes when your glasses were on, but if you weren’t in a shaded zone when your glasses were on, you’d start burning. This was a way to keep the player moving, and a way to make them constantly nervous.
• I worked on the player controls and LockCursor, etc. But the gameplay does not complete a game. I needed an enemy. One that would appear only if your glasses were on.
• I whipped up a cube model and texture and soon came up with this:

• Whoo Hoo! Now I have a cube!
• Next I worked on making the cube look at the player, and then having it disappear when the players “glasses” (A semi-transparent plane) were off.
• By now my Unity Scene looked like this:

• Soon I got Health implemented, and then it started to look like a Test level.
• I kept at it, knowing it would soon look like a game.
• The cube could soon move towards the player, and deal damage at close range.
• The first “Shaded Zone” was created, (using a Trigger) and the player would not take damage while inside it.
• I worked on making the zone a little prettier, and expanding the floor plane. I added a skybox, and changed the ambient light to near black.

• All along I had been slightly working on a music track, but now I decided I needed to finish it.

• The level was extended, the cube had a spawn code and could replicate itself, and the textures for walls and the floor was created in Pixlr.
• I created a variety of sound effects in CFXR like jumping and enemy death noises (my favorite).
• I worked on making an in-game tutorial, by timing when the music starts with the same time that it tells you that there is no one there.
• The menu was easy, all I had to do was come up with a name and choose the font, and soon my game looked legit. (Sorry for the lack of photos here)
• I asked my friend if he could play a test version on his computer (a windows) and I’m glad he did. The font I chose was bugging out on his computer, so I changed it to something else, and it worked fine.
• Now I knew my game was compatible on Windows AND Mac

• I created another music track for the menu, a helicopter to go to as the goal, and a stats screen so you could try to beat your own score.

Rating Other People’s Work

• I specifically rated the games that had the fewest ratings and tried to give most of them a fair, solid score.
• Mostly I gave 3.0s when I thought something was average.
• For a few people that put little effort into it, I had to give some 1.0s.
• I was sad that Notch had not really implemented the theme and pretty much made a different version of Minecraft. (Most likely this was just because he wanted to, or he felt like it.)

How people rated my game

• I can thank my friends, family, and Ludum Dare community for playing the game and enjoying it, especially DontBeNoobish‘s Gameplay Footage:

• I was proud with how my game turned out compared to most of the other entries.
• People mostly liked the audio and innovation of the game, but there were a few things I could’ve made better (More enemies, options, etc)

The Results!

• Coolness – 52% Bronze medal | At first I thought that the bronze medal meant third place, but then I realized Coolness didn’t have the same rating system. Oh well, it was still good to see that my playing of all those low effort games went to good use!
• # 40 Community – 3.55 | Wow! Community? I didn’t realize I was that popular! I guess this rating makes sense because of all the excited posts I made with links to this game. I did a LOT outside of the game (Time-lapse, post mortem, gameplay video, tips)
• # 108 Innovation – 3.20 | Good, people liked my idea of the sunglasses and whatnot!
• # 113 Mood – 3.20 | I think the music accomplished the overall feel of the game.
• # 118 Audio – 3.00 | Once again, the music, but also the enemy death noises made this count.
• # 113 Theme – 3.33 | Well, you are sometimes alone…
• # 202 Humor – 2.29 | I wasn’t even going for this (other than the ReadMe) so I have no clue how it ended up higher than overall.
• # 323 Graphics – 2.67 | Although mine was one of the few 3D first person games, I guess people didn’t really like the low effort GUI and enemy textures.
• # 435 Overall – 2.50 | Oh no! Overall score seemed like an important one…
• # 487 Fun – 2.06 | Really? This was the category I was focusing on, but yet it got a 2.06! Yes, I guess I did better than almost half of everyone else, and I’m not complaining, but this ended up at the bottom of the list, when I had worked for it to be the top.

Comparison To Notch

• My goal was to beat Notch in at least one category, and it turns out that was too easy:

• I ended up beating Notch in 7 different categories!
• A comment on the community rating: Last LD, Notch won third place (if I recall correctly) in the community category, but now he received a #49! And I received a #40! So after all the years Notch has spent on Ludum Dare and Minecraft, and the entire fan-base he collected from the Top Computer Game Of 2011, I was able to receive a better score than him from 3 weeks of posting on Ludum Dare!

I send out a huge thank you to all who rated my game (yes, even those of you that got me that horrible “Fun” score) and hope to join again for LD 23! Please remember Rob Productions again for next Ludum Dare, and you can expect a post-compo version coming in time!

Links:

TIPS ON MAKING A UNITY GAME

POST MORTEM

TIMELAPSE

THE GAME AGAIN

Eyes of the Exorcist was made as the first collaborative effort
between six strangers from who met through the San Diego Game
Developer’s Meet-up Group. The team consisted of 3 programmers, two 3D
artist, and one 2D artist/musician. We spent the full 72 hours of the
Jam in the living room of one of our member’s home. On a whole it was
an incredibly fun learning experience.

What went Right:
* The Location – Caryn and her family were gracious enough to let 5
strangers take over their living room for the weekend. Sharing ideas,
sketches, and code face to face was far more productive than a more
technology based solution.
* Concept Voting – Once the theme was announced we brainstormed for a
while but had not reached a consensus. We agreed that main proponent
of each idea would do a final pitch, then we would vote on all the
ideas. Voting was handled by anonymous paper ballet. Each participant
wrote the numbers 1-8 next to each of the eight ideas. Eight indicated
their favorite idea and one was the least favorite. Each idea’s ballet
score was added up, and we picked the one with the highest cumulative
value. This process allowed all of us to air our ideas, and choose one
that we could agree on.
* Team Energy – Working face to face and having other people depend on
your output brought about a tremendous energy among the group. Two of
us had participated in prior Ludum Dare’s as individuals. We both had
far more energy and drive working as a team than our individual
experience.
* Using Unity – We used Unity for game development. We were able to
take advantage of the input, GUI, character controller, particle
system, and camera components that unity provides. This saved us a
great deal of time not making basic game control objects.
* Art Asset Naming Convention – Despite using Unity for our project
our artists used the Unreal Engine’s naming convention to organize the
art assets. This naming convention allowed us to keep track of who was
working on what, and what stage it was at.
* Division of Labor – Since our team was comprised of programming and
art specialists the programmers could focus on the scripts while the
artists could focus on the art.
* Food – Prior to the start of Ludum Dare the team acquired a large
quantity of sushi, sticky rice, tea, coffee, and chocolate covered
banana chips. We were able to graze off this bounty over the course of
the contest and only had to go out for food three times.

What went Wrong:
* Ambition – When we selected our initial concept we voted on the idea
that we felt would be the most fun game, not what we could complete in
the time limit. This concept involved a spooky ghost town, two
different vision modes, multiple attacks, power ups, inventory items
and a leveling system. In retrospect this was way too much for a Ludum
Dare.
* Lack of Documentation – We kept verbal and mental track of what
features we wanted to implement and in what order. As development
progressed new features were added to the list, but there was no clear
indication as to which features were vital to the build and which were
nice add-ons.
* Tool Familiarization – Since this was our first collaborative
project the artists and programmers were not familiar with each
other’s tools. As such we spent valuable contest time figuring out how
to get art assets into the game. Also we could not utilize the
artist’s time to do level design due to their unfamiliarity with the
unity editor. These things should have been resolved prior to the
start of the event.
* Lack of Leadership – We did not have one person in over all control
of the project, and instead spent a lot of time debating amongst
ourselves over the proper course of action. Also we were unable to
incorporate some of the art assets since the programmers were too
focused on programming tasks.
* Lack of mile stones – We had an idea of what we wanted the end
result of our project to be and when it had to be done. We did not set
time limits on the intermediary steps to get to that final goal. There
were two attempts to have working builds by a certain hour, however we let
both those deadlines slip trying to get it to work perfectly instead of
Kludging together something so we could move on.
* Wasted time on Kitty – One of our team members (Wilson) was insistent on
getting kitty bonus points and wasted valuable time creating scripts
for an NPC cat that did not do much for the end game experience. This
feature was cut from the contest build and all that time was wasted.

Conclusion:
Ludum Dare Game Jam was an incredibly fun learning experience. Working
as a team kept us incredibly motivated. Sadly we bit off more than we
could crew and the end result suffered for it. We now have a better
idea of each other’s capabilities and what can be accomplished in 72
hours.

[My name is Carlos Leituga and I’m a junior Game Designer / Implementer in a Portuguese company, where I’m working on a Hidden Object Adventure for a year and a half now. So here I am again, creating a game in 72 hours with the Make A Game team for Ludum Dare #22. ]

As we were packing our stuff after making Eggscape, someone said something in the lines of “Let’s do this again in December!”, and since that day in August we’ve been talking about participating once more in Ludum Dare.

As the final week till LD #22 began, we followed the theme voting closely, coordinated our votes and shared the possibilities of each theme that interested us. Having learnt a lot with LD #21, we were confident that this time everything would work out better, even with two fewer members.

 The whiteboard calls the shots

The Idea

Something that we might never get the hang of it is figuring when in our timezone will the theme be announced. Finally, at 2 of the morning, “alone” was crowned the winner. After fumbling around with multiple ideas, it was about 5am and only Manuel, the other designer, and I were still awake while the others slept.

We started talking about a game where you played a kleptomaniac at his girlfriend’s house, having dinner with her parents, and stealing stuff when they weren’t looking. This sounded fun, but there wasn’t much variation, and we suspected it would require a lot of scripting to be interesting.

The best part about that idea was picturing the main character trying to conceal every item beneath his clothes, so that evolved into a shady guy wearing a trenchcoat on a museum, that would stray away from his tour group to steal paintings. You couldn’t remain alone for too long or the guide would start searching for you, but this was dismissed since it could limit the player’s movement too much.

Always great when the artist nails it better than we do

We then settled with a lone shady character walking around a museum, stealing art when he was alone and no one was looking. His trenchcoat would get as large as the concealed art, preventing him from navigating through narrow doorways. If the painting you were carrying was blocking your progress, you could swap it for a smaller one to proceed. There would be security guards on a constant patrol, and visitors walking around and stopping to admire the art, but running away and warning the guards if they spotted you snatching something.

The tour group made a brief comeback, as a moving hiding spot for the player, much like the monk groups in Assassin’s Creed, but that was cut earlier due to time constraints and issues that where delaying the development of more important non-playable characters.

Not even the size of his desk could constrain our artist’s talent

What went right

- An environment that nurtures creativity™

This time everyone was in the same place. There was no design or art by proxy, which made things much easier, specially since the extra hand in art determined the quality of our entry.

There was constant communication between everyone, and when there wasn’t, we quickly rectified that, which help maintain a good mood throughout the development process. If someone started sighing or getting upset, we asked what the problem was and tried to figure out solutions together.

The whole project gained a perfect harmony pretty quickly: the art style match our vision from concept to execution, and our sound choices were on the spot. All this thanks to communication™.

Image soon to be available on all of your favorite stock photo sites

- Good “marketing”

We wanted our game to be different. For that, we decided to keep an eye on the other participants. We didn’t want to steal other’s ideas, we wanted to avoid them, so we set up our Twitter clients to follow #LD hashtags. Eventually we started talking with other ludum darers, giving support and sharing links.

This lead to mutual interest and hype between projects. We can’t be certain of this, but hopefully they remembered to rate our entry as we did theirs.

Our updates at the Ludum Dare blog were also well spaced between to avoid spamming people and getting pushed by other posts. The Tumblr blog we made last time wasn’t forgotten, and we tried to use Facebook and Twitter in a controlled manner. Tried.

And then everything was about notch’s game

- A team of fast learners

For the second time competing in Ludum Dare, there were some amazing first times.

Manuel was in charge of level design, which he never once worked on before. We needed content, a lot of it, and we didn’t have time to prepare the game for multiple levels, so we all though that a huge museum was best. Though we now realize we were wrong, the map he made is still cleverly challenging. He even added color coding for areas that were the most far away from the exit and contain the most valuable art.

To avoid pulling the programmers from their tasks, we decided to use the DAME map editor to build our level. Learning how to use it was surprisingly easy for me but there was still the issue of exporting it to Flixel. We were exporting our map in LUA, but Flixel wouldn’t identify entities like the paintings, so when everything was rendered, it appeared as a solo background. So basically, Pedro, our engine programmer, spent one hour learning the motherf@#% basics of LUA to write an interpreter! Just wow!

Teamwork!

- Adding value

To encourage exploration and add value to the game, we made the Gallery one of our top priorities. This Gallery is accessed through the main menu and contains all of the paintings the player steals. Having classic, well known paintings wasn’t funny enough, so we made our “own”.

We have in total 72 unique paintings in the game, all of them are scattered in the museum, and each have a title on them. Most are nods to other games, while others are Internet jokes.

fArts

What went wrong

- Again with the framework

Last time we had problems with our tools, so this time the programmers decided to research in advance for something that suited their needs the most, and found they Flixel. Unfortunately, this engine turned out to have it’s own brand of headaches.

We had problems swapping animations, changing and rotating the guards’ cone of vision, setting up spatial sound and developing better pathfinding than just by points and that avoided getting stuck in objects. Most of these features had to be dropped to meet the deadline.

But worst of all, it was picky with our sound files. Some wouldn’t play completely, others wouldn’t embed when compiling the SWF file, giving multiple errors when trying to stream external audio files. We nearly missed the submission window because of that, forcing us to release the game without sound. Only on the following morning, after the Jam had ended, that we figured out that the problem was related to file size, so we got back to work and solved some minor bugs.

At least this time we were able to test a prototype early in development

What’s missing

We made our best effort to make this game rich on content. From all the features we had to cut due to unforeseen problems with the engine, the quantity of paintings and the gallery menu were elements that we had to deliver. Though we should have spent some time looking up how to save the player’s progress.

The guards took so long to implement that we had to drop the visitors and change the setting to a museum at night. The placeholder circle around the guards, used to test their cone of vision that we didn’t finish, stayed in the game with a different color and opacity, and we gave a flashlight to the sprite to pretend it was a circle of light.

There’s a lot of art missing from the level, mostly museum props used either as decoration or obstacles, because not everything was exported from DAME.

And after these 17 days of voting, we read your comments about the game and completely agree that it should have had a smaller map or multiple exits.

See? It’s not that big!

Conclusion

Although we had our share of problems, everything worked out better than last time. We took our time planning who would do what and how.

Manuel worked on the game design with me, designed the level and made additional art (paintings and props). Fred took care of the AI and sound. Tiago made all the characters and animations. Pedro and Daniela programmed the gameplay mechanics and menus. And I translated the level into the editor, while also making mockups and acting bossy.

We prepared in advance, setting up a local SVN server instead of using Assembla like last time. We forced ourselves to be original by identifying the theme’s common patterns and avoiding them. We tried to sleep at least 6 hours per day and were well stocked up on food.

There was a lot of stress in the final minutes of the Jam, but it was a great experience nevertheless!

Regarding future Ludum Dare events, we’re talking about of at least finishing Eggscape before competing again, but we also have other side projects up our sleeve. So we can’t decide on Make A Game’s fate just yet. I mean, third time’s the charm, right?

You can play “alone I art” at Ludum Dare or at http://makeaga.me/aloneIart/.

Don’t forget to rate.

Update!

Here’s a video of Banksy that Manuel showed us when we thought of the trenchcoat guy and swaping art. Totally had forgotten about it!

Tools Used

FlashDevelop, Flixel engine, DAME map editor, Audacity, Tortoise SVN, Adobe Photoshop CS4, Google Docs.

Good Points

• I developed more than 22 games (as a contract developer), but this is the first time I took part in Ludum Dare and managed to submit a game to the competition! This was one of my 2011′s goals.
• First time I ever did graphics for a game. All the games I worked before were done by hired artists. I could say I was always scared of doing art, and doing these graphics lighted up a flame inside me, that now wants to make me a better artist.
• I came up with the idea in less than an hour after the competition started and I may consider of taking it further and making a commercial game from scratch with this idea.
• When doing 2D with Unity I always used a 3rd party commercial library. Since I took part in the competition I had to come with a solution by myself, so I ended up learning how to “do 2D” in Unity without external help.
• I liked the concept of a linear comics-style navigation I made.

Bad Points

• I worked only 8 hours, I didn’t use the available 48 hours. For this reason, my entry can not even be considered a “game”. Let’s consider it “an interactive short animation“.
• Due to the short amount of time worked, I didn’t manage to make all the scenes: there are 3 scenes; being 2 playable levels and an animation one. The initial plan to make the game “complete and playable” was to have 6 scenes. So we have 3 scenes that are out.
• The rocket cat was meant to be controllable, so you could kill the dragon.
• In the 8 hours I worked, I coded for only 2 hours. That means there are bugs, mostly on the messages system.
• My lack of knowledge in Unity for 2D without a 3rd party library left some bugs on the graphics, mostly due to scaling.
• The linear comics-style navigation can be confusing, since you can end up going to the wrong side.

Other than that, I had a lot of fun, and I’m feeling fulfilled for completing one of my 2011′s goals: take part of Ludum Dare

Pre-compo prep.
Last year I found out about the Ludum dare competition and was really interested in doing something, unfortunately I didn’t have the weekend totally free to commit to making any real attempt, but I managed to crank out a tiny little endless runner in a couple of hours and catch some of the live recordings (Notch’s one mainly). It was interesting to see the fruits of every-one’s labours, and the community spirit here is really inspiring.
So as I hadn’t managed to make a decent attempt last time, I had planned to jump in properly for LD22. In preparation I had made all the necessary requests for that 48 hour period to be free and started thinking about the tools I would use to make the game.

Physmo is a 2 man team, I do the art and design and @physmotone is the chap with the coding skillz. We had talked a bit about entering the jam as a team but were struggling to both get the time off we needed so I planned to enter solo. This meant coding the game myself; I am a programmer but I’m certainly no game programmer so I realised this would be tough. I’m sure Tony would be shocked by all the fundamental coding mistakes I made while making my entry, stuff he has the experience now to avoid, but I learned a lot doing this, especially about the architecture of making a game, the game states, resource management etc – all that tricky stuff we can take for granted sometimes.

In the week before the theme was announced, I decided I would choose Java as the language, and Slick2D as the graphics library for drawing the sprites (It also does a great job of loading graphics, sound and level data.) I’m not a java programmer but it seemed close enough to C++ to be easy to pick up, but mainly I wanted something that would be multi platform with the vague possibility of embedding in a web page (this didn’t happen). I didn’t know what kind of game I’d be making but assumed it might need level data, and I had heard of a map editor that was supported by Slick2D called Tiled, so I downloaded that and made sure I knew the basics of how it worked. In the prep week I didn’t find as much time as I would have liked to do actual prep but I did get a few hours to find some java tutorials and create a small test application that demonstrated loading and displaying sprites, loading and playing sounds and reading a Tiled level. I didn’t want to waste much of the 48 hours being stuck on some trivial problem like not being able to draw a font to the screen so I investigated the font libraries too (Angel code fonts I think it was). I had the small test app running, the final thing on my list of prep was to actually package the program to be runnable on other computers.
This was a couple of days before the announcement and I could not for the life of me package this thing properly. Eclipse is the IDE I was using and it’s pretty complicated if you don’t know it, and I had no idea about how to create Jar packages (which is what I needed to make the thing runnable). I tried every combination of including the platform specific .dll files, the library .jars for Slick2D and LWJGL, and did a lot of googling for the problem. Fortunately (?) many novices seem to have a problem with this step, and in the end I reluctantly tried using another app to package all of the files up into a fat jar, which worked. i say reluctantly because even though it worked in the end, I still don’t have a good understanding why it didn’t work and why it does now, but hey, it works! This was a real problem just before the compo started though. If I couldn’t find out how to package the game, there would be no point in working on a game. I would heartily recommend anyone taking part in a time limiting game creation competition to build a full app end-to-end before they take part.

The graphic and audio tools were to be Photoshop, SFXR (of course) for sound effects and Audacity in case I needed any sound effect editing. In the end I did install audacity in the final hour to tweak the ship thruster sound effect but that’s all.

Announcement
I’m in the UK, so the announcement came at 2am our time. The plan was to stay up for the announcement, have a think about it and then get some sleep.
The theme is announced. “Alone”. I stare at the screen for a few minutes. My first thought is, “Well at least I won’t have to code any enemy AI”.
At Physmo we have a folder full of crazy game Ideas and prototypes, but we have never really considered a thrust style game. I used to like thrust style games though, and I though it would be within my skill range to make a good attempt at one. Quite soon after the announcement I had come up with some ideas for a decent plot – I wanted to have some narrative in the game that would be explained as you play and I really wanted to have a good twist in there too. I had my general story Idea and style of game I wanted, I could now sleep (and secretly hope to come up with good ideas in my dreams).

Oh, this post mortem is going to be a total spoiler for the game, so please play it first if you intend to… I’ll give you a couple of minutes, just watch out for the spinning sawblades, the collision on them is a bit saucy.

For the plot of the game, I wanted the player to have unwittingly done something really terrible. This idea made it into the final game but was very scaled back. The initial idea was that you would be flying a ship around a room with some kind of reactor in the middle, there would be a cage full of energy capsules milling around that you would have to pick up and drop into the reactor. At some point you would realise that this is not the true reality of the situation, the reactor is actually a horrible mind controlling alien, the energy capsules are really other human members of your crew and the alien has tricked you into feeding your crew to it.
This was the plan until the end of day one, I didn’t think I would have time to code the mechanics for all this, the switching level graphics, picking up and dropping the crew etc, so at the start of day 2 I decided to change it slightly so that you were a security guard of a mining colony, who was going mad. It seems like at first you are being attacked by aliens, but as you progress through the game you can read log files that gradually explain that the aliens are really just the colonists, and by the end of the game you will be alone, having killed them all. It’s nice to end on a cheery, up-beat note.

It was time to start programming. But first I went to my trusty Photoshop and drew some sprites: A yellow ship, some bullets, some white splodges to use as particles and a simple tiling foreground and background tile sprite. The spaceship made it into the final cut of the game with no modifications as I quite liked it. NOW it was time to start programming! First I needed some classes to represent the ship, bullets and enemies. That’s what the game needed, they are an integral part of the game. You can’t have a game without them. That’s why, like an idiot, I spent the first couple of hours making some pretty particle effects.
Ok, Basic particle engine created, I now really HAD to start creating the game objects. I found a nice tutorial about creating game entities, and then creating generic behaviours that could be inserted into them, this seemed like a cool Idea and one I had never tried before so I gave it a shot (I’ll try to link to these tutorials and things at the end of the post). After stealing the code to create the framework of the entities, behaviours and renderers, I derived my own object classes for them, starting with the players ship movement code. This was easy as I had used some basic maths like this a lot in some processing toys I made a while ago. It’s useful to know so I’ll write it out here:
Horizontal Thrust = sin(ship angle of rotation) * force;
Vertical Thrust = cos(ship angle of rotation) * force;
So everytime the thrust button is pressed, I add these values onto the ships velocity on the x and y axis. Every time through the game loop, I add the velocity vector to the ships position, and that moves the ship. And at the same time I dampen the ship’s velocity by multiplying it by a number slightly less than 1.0 (0.98 or something). That reduces the ships motion over time and eventually makes it stop in a pleasing way.

Ok, next big problem. In my processing (processing is a simple java-like programming language) experience, the main loop is locked to a certain frame rate, but in the Slick2D framework it isn’t. This means the loop runs as fast as it possible can – maybe hundreds of times a second – but it will vary from computer to computer and will vary depending on how much is being drawn on the screen too. To handle this, the update loops are passed in a variable that represents the number of clock ticks that occurred since the last update, and using this I could feed it into all the motion equations. Essentially, every calculation that results in something moving on screen needs to be scaled down by the number of clock ticks, so that the movement is nice and constant. I forgot to do this to the scrolling routine though so sometimes the scrolling can be a bit slow if your machine is struggling. That’s a bug but would be easy to fix.

I now had a ship swishing around the screen nicely, with lovely particles firing out of it’s bum (and me making “woosh” sounds) so I flew it around the screen for half an hour thinking how awesome I was to have achieved such a thing. Next I needed some background to be drawn. The Slick2D libraries can load and display level data from Tiled map files, although they couldn’t handle (as far as I could tell) drawing level sprites scaled up, but it was quite easy to parse through the loaded level file, find what tile is at what location and draw it scaled up myself. I got this running surprisingly quickly (well it wasn’t very complicated) and then added some scrolling offset code, and voila! I had a ship flying around a scrolling level. Flying right through the walls though. Next step was to detect collision on the walls, so I wrote a routine that given a point in the game world, would find the foreground level sprite, and check if the pixel was filled or not. It worked and that is the basis of all the collision in the game. To collide the ship off walls, I check around 10 points in a circle around the ship to see if they are touching a solid part of the background. If they are, i calculate the vector from that point back to the centre of the ship and add that to the ships velocity, I was amazed that this works but it resulted in some pretty solid feeling collision (I was worried that the collision would be awful in this game) so maybe this is what real collision is based on.
I created some simple behaviours for the player bullets that I reused for enemy bullets (The entity system worked well here) then I added some basic enemy types. I regret not having the time to make the enemies do more, but in the end I just had static enemies that varied in the speed that they fired bullets at you and the number of shots it would take to kill them.
I added a lot to the game in the last half day, as the main mechanics were there. Different sprites for the enemies, more particle effects and the log file objects that can be picked up. Some trivial looking things took more time than expected, for instance displaying the log file text on screen and making the rest of the game pause while it was displayed. At this point I realised I would have to start thinking about game states, so I changed the main class to be a state based game state using the Slick2D libraries and created another state for the main menu screen, then worked on getting this to transition back and forward and make sure that the player could die and the game would switch back to the main menu. This is something I wish I’d thought about a lot more at the start as game states are a tricky thing to to if you aren’t used to it.

Panic was setting in in the last few hours of the 48, there was a lot to be tidied up. The collision between bullets, player ship and enemies was quite off so I modified the renderers to display the collision box and that helped me track down and fix the issues there. One big problem that I regret not fixing is that the hit-boxes for the circular saw blades is a square, not a circle and this makes for some really unfair deaths in the game. I realised I had no time left to fix this so I modified the level to move the saws and give the player more room to move around them, still it’s disappointing to get unfairly killed by them.

The game was looking quite finished, all the log files were placed and the end could be reached, but it was quite hard, so at the last minute I made the players health slowly regenerate over time. In the last half hour I feverishly added a lot of minor details: The player health bar, more particle effects for killing enemies, more sound effects and a dodgy system for playing the ships thrust sound. Panicking further, I played through the game one more time and hit the build button to build the final Jar file, and opened slick jar (i think) to package it up into a runnable jar file. With minutes to spare I clicked the Jar file and it seemed to work, phew! Opened my web browser, and went to www.ludumdare.com …… wait a … WTF .. oh MAN! Why is the site not working! Through lack of sleep and burnout I thought all was lost, I refreshed the site and still nothing. Thinking that all was lost, I gingerly climbed onto the window ledge, and, oh wait, the site loaded! Wheee! Well, at least, I saw a message from the site saying they would accept entries for an hour or two after the closing time. I eventually uploaded the game and could relax, but those last few minutes leading up to the deadline were some tense minutes let me tell you.

In closing this rather rambling post, I did enjoy the experience. I think I made a decent, complete game that I hope you enjoy playing – it’s quite short. I’ve learned a lot about what should be prioritised next time, and I feel like I was part of something big and crazy

Please try it, it’s called “Fernands War” http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=5349

We have a full game called Mos Speedrun too, for iPhone and Mac/Pc, you might like it.

Thanks!

Nick

@physmo

http://www.physmo.com

What went right:

Music – going into this I was fairly certain that I would be using some sort of chiptunes generator, but when the theme “Alone” was announced I figured there was no way I would get a chiptunes to work with the mood of being alone. I had given up on music within the first hour of production, but at the end of Saturday I got a little tune in my head, nothing fancy but it just might work. Sunday morning I got out a guitar and found a microphone and started recording just to see if I could make something. What I ended up with may not be fancy, but I like it and I think it is definitely better than silence. Though, since I went with live music I don’t think I should have used sfxr to generate sound effects, I think they kind of clash.

“Just do it” Attitude – When the theme was announced, I was at a loss for ideas. Fearing I would just give up if I didn’t do something, I started drawing a little sprite protagonist. After seeing him walk around I thought “he needs to be crushed by a tree.” The act of starting something allowed other ideas to flow and created a game for me, all I had to do was finish it.

I'm about the get crushed. That's what went wrong.

What went wrong:

“Just do it” Attitude – By just starting right away without a plan, towards the end I had to start hacking things together in order to make them fit. Not having a plan before hand meant that I didn’t realize just how many assets I had to draw (as you will see, I’m terrible at drawing assets). And the code it cobbled together and held there with duct tape. I found myself writing the same thing over and over because the base class wasn’t created properly because I didn’t really know what it was going to be used for. Had I started with a decent plan I might have saved enough time to put in a small tutorial.

Theme – I was all prepared to create a tile based platformer and was hoping the theme would present a neat mechanic that could be used in the game. But when “Alone” was announced, all that went out the window. I was at a complete loss for ideas and nearly gave up right there. I actually wrote down several ideas for the themes from round five, but “Alone” was one of two that I couldn’t come up with a decent idea for. In the end, all I had was the vague idea “environment for the enemy” and I tried to make the best out of it.

Lack of instructions – If you watch the timelapse you may be able to see that there was an “Instructions” field in the main menu all the way up until about an hour before the end of the contest. I had intended to include just one screen explaining what type of game this is, what types of interactions the player has with the world, what clickable objects look like, and a hint to where to find the kitten. In retrospect, this really shouldn’t have been cut because without prior knowledge it isn’t obvious at all what the player can and can’t do.

This is what the instructions were supposed to look like

Lessons Learned:

Take time to make a plan – I think next time I will dedicate the first hour to planning out what I’m going to do

Have completed basecode – There were still many things missing from my base code, like collision detection and a way to do fade outs. I didn’t want to look up anything while in the contest as it would waste time, so I made due with what I knew how to do at the moment (and that is why screen transitions are screen wipes).

Be strict about friends/family not bothering me – In the middle of Sunday I was called away by my family by what I expected to only be an hour which turned into five. Whenever I look at this game now I think what I could have done with those five hours.

All in all I learned a lot from the LD22 weekend and look forward to participating again. And please, if you haven’t, could you play and rate my game.

What went right:

• Programming tools: I had no problem with the usual write-build-compile-play-debug workflow
• Chronolapse was very good for the screen capture (see timelapse here)
• I was more focused than the last time
• It was really fun!

Last weekend I made a compo entry called Castaway.

If you speak French, you might want to read my lengthy writeup on Les Forges. Else, here are the traditional bullet point lists :

What went well

• Using familiar tools (custom framework, FlashDevelop, HaXe, Photoshop, Reason, etc.)
• Using project management techniques and tools. I used Asana to handle my ever growing todo list and a mini scrumboard for tracking bugs. Pictures at the end of this post.
• Recording custom sound effects. This was my first time and I’m very happy with the result (especially since it didnt take long). Picture below.
• Testing. Two friends came on Sunday evening and played the game again and again to spot bugs. They were the one writing the scrum post-it and it was very useful.
• Chronolapse. Making a timelapse took no effort and I love the end result.

What went not so well

• Theme. I did not think long enough of the theme and started working without a clear idea of what my game would be.
• Time management. I spent too much time working on animations and art assets instead of making content. Look at this 8 frames walk cycle : . This is wasted time, lots of it.
• Balancing. The game is way too hard ; my testers thought it was funny because of it but I should have considered this as alarming.
• Oops. A critical bug that crashes the game on slow computer was shipped in the compo version. Maybe the test configuration should include a slow computer too.

Pictures

Asana

Bug tracking scrumboard

Sound design tools

Even though my game is way too hard, too short and unforgiving, I’m still happy with what I did. I am satisfied I made some art and music that were not 8bit/chiptune over the course of the weekend and more importantly, I had lots of fun. Next time, I will NOT make a sidescrolling platformer, that’s my objective.

Thank you all for reading/playing/rating !

In between zooming around from NS to NB this past weekend, I knocked out a Ludum Dare game. Neat little randomly generated retro style platformer. Posting this both on the Ludum Dare site and my own blog. So LDer’s enjoy an expository preamble!

Click to play

Preamble

So if you’re unfamiliar with Ludum Dare it’s an online, solo game development competition. They release a theme and you have to develop a game using that theme in a forty-eight hour timeframe.  A large list of themes is created and after a few rounds of voting , the list is culled to a dozen or so final themes to vote on. After the final round of voting is complete, the theme is released and a sleepless, hectic weekend begins. I was rooting for “Randomly Generated” to be selected as the theme and was already salivating at the prospect of making a roguelike.

Over the last few years the only games that really stick out to me as being actually fun and life destroyingly addictive were the new wave of roguelikes. Spelunky, Transcendence, and The Binding of Isaac have taken a mostly inaccessible genre and made it almost casual. If a player can get over how masochistic these games are, it really scratches their drive for mastery. There is nothing that can foster that “Just one more turn…” effect better than these games. But I digress, this is a subject worth a post all on its own.

Spelunky was a harsh mistress

The weekend of this Ludum Dare coincided with a friend’s Christmas party I few hours away. I didn’t want to lose six hours driving back and forth so I opted for twelve hours by train. After packing everything for the trip I settled in and waited for the theme reveal. “Alone” ended up hedging out Randomly-Generated by a few votes.  Even though I was bummed over my pet theme losing, I figured I could still work Randomly-Generated into my concept. What I roughed out, was that you were a monster created by the government, you wanted to escape their pursuit and be left alone. I pegged the gameplay as a platformer with randomly generated level sections. I wasn’t sure about combat and mechanics but I was hoping it’d grow organically throughout the competition. My main goal was to produce something playable that had some random level generation in it.

Could you, would you, on a train?

What went right?

Flixel and Flixel Power Tools

Even with the minor learning curve, Flixel and Photonstorm’s Power Tools were a huge boon. Flixel itself makes blitting ridiculously simple.  Power Tools is so feature rich it covers the majority of your bases. Projectiles, quick controllers, collision, health bars, etc. Really looking forward to having another excuse to play around with Photonstorm’s plug-in, since I’ve only scratched the surface.

Randomly Generated Levels

I feel the time was spent better generating the random levels, than building a few poorly designed levels. As there aren’t a ton of game mechanics the best I could do with level design would have been in the realm of jumping puzzles or a vertical maze. The randomly generated levels toss in a little replay value, and lay a foundation for a roguelike in further development.

In terms of the actual generation it was pretty quick and dirty. Originally I had created a system that would take sections of 5 rows, 10 rows, and 15 rows, each being 13 columns across. You’d pass the length and width (in sections) and it would stitch together the random sections into the full map.

Each section looked like this:

00,00,00,00,00,00,00,05,00,00,02,00,03
00,00,02,00,00,01,01,01,00,01,01,00,01
00,01,01,01,00,00,00,00,00,00,00,00,01
00,00,00,00,00,00,02,00,00,00,00,00,03
01,03,01,01,01,01,01,01,01,01,01,01,01

00 – Empty, 01 – Solid Tile. 02 – Enemy, 03 – Open Tile to Next Section, 05 – Possible entrance/exit door.

Due to the time constraint I wasn’t able to implement the 10 and 15 row sections. It definitely would have made the levels feel a bit more unique, but I think they come across as pretty varied just using the 5 row sections.

Pixel Art

First time playing around with pixel art, probably could have done better with the tiles, as the thick black outline doesn’t work really well. But otherwise everything turned out pretty swell. Animation was a bit of a pain, but I’m content with the results. The choice to make the main character limbless was a big timer saver.

My easily animated friend...

Organic Evolution of Mechanics

Setting out on Solitude my main goal was a Spelunky-esque platformer, but beyond the randomly generated levels I had no idea on what mechanics I’d need. Plopped in the basic melee attack and ranged attack. Bullet reflection when using a melee attack was a happy accident and a great alternative to making a shielding ability. Flight ended up being an accident as well. The terrain destruction was a response to the possibility of there being no direct path to a level exit.

Roguelike Resource Management

I didn’t have any initial plans for energy consuming attacks, but flight and and terrain destruction were easily abusable. Most roguelikes have a few finite resources that you have to manage I feel like I did a good job of integrating this with energy and life. You can only replenish energy by killing troops, and you need that energy to more easily traverse the level.

It doesn’t have a huge impact in the jam game, but I think it’ll be a much bigger deal if I continue on with development. Using a timer to push the player forward and keep the game fast paced, the health and energy trade off will be one of your main decisions.

Music

If I had hit the 48 hour deadline I definitely would not have had a chance to add music to the game, so the running over the deadline was a blessing in disguise. I had a friend put together my music. Ended up far better than what I could have ever produced, and has the perfect pacing for the game.

What Went Wrong

Time

Everything boils down to lack of time. Sparse mechanics, rough art, no sound, having to enter the 72 hour jam instead of the competition. Being tied up with real-life, and travel.

Arguably you could say my scope, goal, and choice of tech that I don’t have solid experience with is the real problem, but I set out to make a randomly generated game, make some pixel art, and learn Flixel. Those motivations went above making a fun polished game.

Difficulty

Seems to happen with every LD entry, but I think Solitude is too hard. You can only breeze through it once you start abusing mechanics. It’s likely you’ll lose interest in the game before you get that comfortable with the game.

It’s something I’m going to have to be more conscious of when pumping out an LD game. My group of friends aren’t the best for feedback in terms of a game’s difficulty. So maybe I should start harassing folks in IRC during the competition…

Conclusion

Unlike other LD’s there isn’t a ton of reflection to do here.  All in all,  really happy with the result of the LD despite my lack of time. Got to play around with Flixel and got to start off a bit of a roguelike. Woop woop.

You can click this link with your pointing device to see it!!

I had a lot of fun, and, after being my first time, I will most definitely do this again.

Here’s the “Proper” Post-Mortem:

How I Spent My Time

Timelapse here if you want to take a look.

Basically I came up with an idea while I was making the game. I had already pretty decided it would be first person. And also I had pretty much decided the enemies would be cubes. (Just to make it easier on myself)

I didn’t particularly like the theme, alone, but it was better than kittens.

Mainly I worked on getting the character movement to be as smooth as possible, that’s where most people messed up, to make the game fun and re-playable. I tried to make the sword animations as hectic as possible, just to make it look a little more stylish. I made the wall and floor textures 8 bit and repeatable. I made the music overdone, with a lot of instruments (using garageband) and very complicated. I did this because I remembered all those 2d games with catchy music but terrible graphics.

I implemented the theme by having enemies appear if you put on sunglasses, but disappear if you take them off. The catch was that in the sunlight, without sunglasses, you burned. So you had to find shaded “safe” areas to take off your sunglasses and regenerate health, while the enemies disappeared.

The sound effects were done in CFXR (I especially like the enemy death noises). The language I used was Javascript. The game engine was Unity Indie. The 3d modeling software was Blender. This cannot get any simpler.

I chose these programs because, well, they were free, and also because they’re proper towards making an indie game.

What I Learned

• The smoother the gameplay and character movement, the better
• Sound is a very important part of game development
• Don’t over-complicate things, keep your main code in as few scripts as possible
• Particle effects make the game seem more complete

What Went Right

• The music was mostly catchy and was repeatable
• The gameplay was smooth and the sword attacks blended together well
• The implementation to the theme (being alone, only when your glasses are on)
• The sound design was okay, especially with the enemy deaths

What Went Wrong

• There should have been more enemies
• The enemies should have been easier to fight
• There should have been more things blocking your path
• There should have been better GUI controls and being able to change the mouse sensitivity
• The level design should have been worked on better
• The game should have been longer

All in all, I think I did an okay job, maybe not the best, but it was fun enough to please my friends, and good considering the amount of time I had. (Less then 48 hours, more like 30, I had to go to some places)

Try it out here.

The last man on Earth sat alone in a room. There was a knock on the door…

Play It | Rate It

Origin

When I heard Alone was chosen as the theme, a set of bizarre ideas immediately appeared in my mind. I really wanted to explore about the feeling of being alone, about the psychological effect of it. Also, I had read The Knock recently so I wanted to explore more about that subject.

Development

The tools I used included:

• Adobe Photoshop
• Adobe Lightroom
• Adobe Flash
• Flashdevelop / ActionScript 3
• as3sfxr »
• Aviary »
• A standard Digital Camera
• Some burned papers
• A friend (lol)

The art is rather simple, I took some photos of my house and I asked a friend to model for me. We did some shots of him walking, but because I lack equipment (tripod, marks, etc) the result looks a little bad. I did my best to correct the photos in Photoshop. The room is a part of my house, that isn’t even a room, but I couldn’t take a picture of a real room because the camera angle was too short. I applied Exposure and Posterize to all the images.

The programming was done entirely in ActionScript 3, using some features of my own library, but the vast majority was to be made from scratch. I used Flashdevelop because I’m really fast with it… Just press Ctrl+Shift+1 and it’s like magic!

What now?

I think I’ll work more time on this game. I’ll add more puzzles, make an easy mode, add language support, and maybe more rooms to explore, or explore more about the story. For example, what happened upstairs?

This was my second time on Ludum Dare, and I think it was a really good experience. I don’t think there’s something that went wrong, maybe next time I’ll add more features to my framework, like effects, sound support and embedding support; but at the end I managed to do what I intended to do.

Good

• My zombie! I’m really proud of my ugly zombie. Yes, I spent a lot of time on it and it isn’t good art by any standard but I don’t care. It was worth it to see it “alive” in my game
• I only realized that after I was done but I kind of made the game I wanted to do for December 2010′s LD. Except then I had found myself making an alien instead of the zombie I had planned to do and then gave up before I had gameplay anyway. So it’s like I tied up a loose end.
• The jam. If not for the jam I wouldn’t have been able to finish my game and the LD would have just ended in bitter disappointment for me.
• My trusty ZBrush was awesome: sculpting/painting the zombie was the most fun part of this LD, Blender was also great for animating it.

Gray Area

• Making the low-poly retopology took more time than I thought. I tried TopoGun which I had just bought a few days before the compo and never used.  That added a few hours of work but then TopoGun worked really well for generating the color and normal map from the sculpt.

Bad

• I missed the compo deadline and had to do the jam
• I was generally not very fast. Lack of concentration maybe? Everything seemed to take just longer than it usually would.
• I spent the same amount of time on the environment than on the zombie and yet it really doesn’t show.  I just wasted time noodling with bits cut from my original hallway model and just made a mess and had to restart again. It was a time sink for no reason.
• Simplistic gameplay. I wanted to make the game more about stealth.
• I still suck at using Modo. It’s a great software I have no doubt of that and I mostly knew how to use it. But somehow I still find myself struggling against it every step. I don’t know how to explain what it is exactly. It’s weird and it’s probably just that I lack the practice to have the right instincts but it’s really annoying when trying to speed model and everything reacts in a slightly unexpected way and I keep having to undo and try again. I’ve got to spend more time using it.
• Still no time for particles effects. I put them on my priority list for this LD and still neglected them.

Time use

• Code: 11.2h (includes setting things up in Unity)

• Model: 9.3h
• Texture: 4.7h
• Animation: 3.5h
• Sound: 2.4h
• Level building: 7.6h (half of it wasted on a discarded version)
• Sleep: 24h
• Doing other things: 3.4h
• Misc: 5.5h (probably 50% actual work the rest being posting WIPs, chatting on the IRC channel, etc)

• Total spent on zombie (including sounds, code, etc):  15.5h
• Total spent on the environment/level (incl. medkit props and ambient soundtrack): 15.4h

What went wrong?

There was an unexpected family emergency that took up the better part of 10 hours. The emergency was unavoidable, and unforeseen. It was unfortunate, but I absolutely do not regret missing the 10 hours.

That said, 10 hours is a lot of time in a 48 hour competition. After sleeping for about 10 total hours and the family emergency, I was left with about 28 hours of total work time. Not bad, but it was not evenly distributed, requiring some energy drinks and long periods without sleep. If I had had the 10 hours, about 4 of it would have been for sleeping on Saturday night, and the rest would have been time spent on polish.

My first time sync when working on the project was going with the sprite.js library — it’s an amazing library, but I hit a wall when I realized the support for Tiled, which I was banking on, was not really all that complete. I was going to use melonJS from the outset, but then a couple of days before the competition, I decided sprite.js would offer a better experience. I had tested it out before the competition, and thought I could get everything to work based off of one of the libraries examples, but you know how that goes.

I ended up switching everything over to melonJS, which has faculties for reading Tiled maps directly. In the end, I think this was beneficial to the overall project, but it did eat up time. If I had just used melonJS from the beginning (like I had originally planned), I would have had at least another 3 hours of work time.

My second time sync was maps. I initially built a small test map, and iterated features over that map. The test map was an excellent strategy I think, but coming off of that I jumped into a really large map — bigger than I needed by several factors. I wasted a lot of time just trying to fill it in and make it playable. I eventually shrunk the map down, but I spent an awful lot of time with a map that I ended up throwing away.

I think if I would have just did a little more level design up front on a piece of paper, I could have avoided this time sync, and probably got several more hours to work on polish and other levels.

More experience with the Tiled editor would have helped to, but it’s pretty easy to pick up.

What went right?

Tools! I knew my tool chain fairly well — I’m certainly middle of the road competency wise, but I have been using gimp, vim,  and javascript/html/css for quite a while and was at least comfortable with how they worked. I think this saved me a lot of heart ache.

The things I didn’t know well were sprite.js, melonJS, sfxr, Tiled and the music generating python script that GreaseMonkey posted about: http://www.ludumdare.com/compo/2011/12/13/if-you-find-it-hard-to-make-music-read-this/

However, I did practice using these tools before the competition, so I was comfortable using them, and they didn’t offer any surprises, or set backs (other than plain inexperience).

melonJS was fantastic to work with, and really easy to pick up with the great examples on their website.

Tiled is an amazing editor — combined with melonJS I think it really saved the project after the 10 hours I spent away from the competition.

And, of course sfxr really added a little something to the game. I’m no sound engineer, but having absolutely no sounds in a game is almost as maddening as eating at a restaurant without background music. sfxr is amazing. On top of that, it’s really easy to use!

And the Autotracker-Bu script from GreaseMonkey gave me something I thought I wouldn’t have. Perhaps the music isn’t perfect for the game, but it does add something.

Summary?

My experience? Positive. I’ll definitely be doing this again. Next time I’m going to hopefully avoid emergencies, pass on the energy drinks, get some nice evenly distributed sleep, and know exactly what my libraries/frameworks are capable of going into the competition.

Happy Hacking, and I’ll see you all in April! (and possibly before that for the MiniLD’s!!)

What went right.

• Graphics. I mean, I usually think very little about my art skills, but this time I feel that my approach was perfect (for me, at least). I’ll admit that simplicity wasn’t something I thought of at first, but at some dead end while coding, I figured I could as well create the graphics. I used a total number of 6 colors, the main being white, with cat being 10×10 pixels and human 10×24 pixels. Then I used FlxG.camera.color to change color tint of the scene, depending on the distance between player and the human. I usually tend to overdo things, so this simple solution (achieved after many hours of experimenting with other options) is brilliant according to my standards. Like the last time, at the beginnig I used placeholder graphics, which is always a great idea and I recommend it to everyone.
• Music. Wolfram Tones. That’s it. Go, check it out if you don’t know this. I’m actually really interested if it’s possible to use this generated content in a commercial game – anybody got any info on this? I mean, I understand the technology is copyrighted, but I don’t think that this also aplies to generated music (I mean, Wolfram doesn’t have rights to every CA there is, does it?).
• Flixel. I have issues with this piece, so read on below. Here I can write that Flixel is a great framework, especially if this is your first contact with AS3, and especially if this is your first contact with game programming framework. Automaticly done collisions, very simple map loading, many options, Flixel Power Tools for GREAT effects and much, much more.
• Mood. I like the overall design of the game, the colors and cat monologues, and the direction it was heading when it was time to finish. I like that there are endings, and that there’s a few of them (last time I didn’t have time to make an ending for my game). It’s definitely not flawless, though – read on, below.

What went wrong.

• Over-coding stuff. I didn’t have any idea regarding the theme, so I started programming some kind of platformer. I wasted a lot of time on nice effects when player leaves world bounds, only to design level in such a way that it’s impossible. I prepared my object model to be very flexible, but in the end it was a waste of time, because I didn’t need this flexibility.
• Flixel. Yeah, when you’re used to programming, doing it with Flixel may be pretty crazy non-intuitive. I mean, collisions are done automagically for you! I know this speeds up the developing process, but this wasn’t something I expected, and made me scratch my head a couple of times (what if I wanted to do something non-standard? – at the end, I stuck to the simple things). I think Flixel’s general design is best if you know what kind of game are you making, and the physics at least resemble something common, like platformer, shot’em up, top-down movement, etc. If you need something else, you CAN program collisions yourself, but this wasn’t clear for me at a first glance – however, this might be due to my idea of learning the framework on-the-fly, during LD event.
• DAME. Well, I definitely want to use it in the future – it’s just that using it during this LD’s was way too much for me to learn. In the end, I did my level design in paint.
• Design. I should’ve cut the platformer elements to the minimum, so that finishing the game would take more like 3-5, not 15 minutes. If someone wanted to see all five endings, he would need to waste way too much time, going again and again through the same story. Yep, didn’t think about that. The worst part is that the level is completely static – so if someone wants to try bringing more fish to the human, or find the special item, he always needs to go up the platforms, using the same path. This is much more boring when trying to see other endings.
• No balancing. That’s mostly why it’s so unnecessarily long. I should know better – I played my game a few times. Now I’ve got some ideas how to make it better: have randomized parts of the story, change level design every time a fish is brought to the human, or at least make time between events much shorter. Also, replaying the game could be much easier, as everyone who will play it more than once, do it only to see other endings.
• I’m not even gonna write about eating, drinking too much coffee and bad time management. It was bad.

Things to consider.

• Are you doing art/ story game? Make it SHORT. As in “5 minutes short”. If you have more than one ending, or some additional things for player to uncover, it can be even shorter, because it can easily be played many times.
• Is ANY KIND of gameplay good for your idea? Do you need that platformer-style gameplay, with enemies, bullets and things to do, if you’re creating a STORY game, or maybe “some kind of interaction” would be enough? Don’t overdo things!
• Is learning stuff during LD event good for you? If you love it, like me – here’s a suggestion. Pick the stuff you want to learn – do some research before LD and check if the amount of stuff to learn suits you. It’s BAD to waste TOO MUCH time on learning, when you’re supposed to create a game.
• Very low-res pixel-art is GOOD. Easier to create, but still recognizable. Manipulating color from inside the code can give great effects. Learn some simple graphical tricks to make your game even more appealing!
• If you’re programming in AS3, learn to incorporate TweenLite/TweenMax into your framework. It’s GOOD.
• MUSIC changes the mood of your game astonishingly. Use anything you can use – be it Wolfram Tones or any other generator, or whatever. For instance, I’m quite sure that without that ambient music, my game would be much, much worse.

Okay, that’s all folks. Big thanks to everyone who motivated me during my development, I’ve had a GREAT time and YES, I WILL PARTICIPATE AGAIN, and again, and again… forever! Last time was Flashpunk, this time – Flixel, so next time… don’t know yet!

What went right:

• Postnatal: I spent most of the time building the engine, and even though some shortcuts were made (mainly the Level Design one below), a lot of aspects of the engine were quite robust and really nice to work with. If you get this right, adding a diverse set of game elements is easy (for instance, the concept of potions took me 5 minutes too add, including making it something monsters can drop and making it available in the town store. I guess my point is that if you take too many shortcuts, when LD48 ends, that will be the end of your game, you’re never going to want to touch that code again. If you make more of an effort to build a sturdy system, the 48 h session might just be the birth of your game and your post-mortem examination will instead be a postnatal one. I’m pretty pleased with my game in this aspect, but there are many improvements I can make until next time.
• Smooth sailing: I like building everything from scratch, so I only had 160×120 pixels to work with, and I did all the pixel manipulation manually. Sure, this meant implementing for instance alpha composition from scratch when I wanted to have that, but I think those things are fun so I didn’t mind that. This also meant that after the canvas was set up, I had complete control of everything. Getting stuck on API stuff can be frustrating, so I’m glad I was able to keep that to a minimum (I got screwed over on sound though, check below).
• Fun factor: I know the fun factor is quite limited, but there were some shimmers in there, and I did catch my girlfriend playing the game several times on Monday (quote: “Okay, this time I’m going to try to complete it with only a steel sword”). I’m really pleased with the enemies and how much technique counts. Also, even if you know the best technique, it still needs precision and skill to carry out.

What went wrong:

• Sound: My sound threads were piling up on me, causing the game to crash. I eventually had to take it all out, even though all sounds were ready. Lesson: make a more thorough warm-up round if you’re using unfamiliar tools.
• Level design: I didn’t have any software for this, and even though the forests are generated, I wanted to create the city and the houses myself. It was either going to be an image or a text file. I went with a text file, so I could easily throw in some some additional information, etc. Much more familiar with text parsing in Python than Java, I decided to just go ahead and acknowledge that some shortcuts have to be made, so I wrote the parser in Python and made it spit out Java code. It was fast, but now afterwards I feel really dirty generating Java code. Lesson: Take some shortcuts, but not major ones like this. It made me feel less proud of my final product, no shortcut is worth that.
• Name: With 700 entries, you have to be more original than “Leave me alone!”. Also, I must’ve been crazy thinking I had a pretty original idea when I decided to have a person who wanted to be alone (as opposed to the more obvious not wanting to be alone).
• Time for final touches: It was really hectic at the end, and I left a few things hanging. The houses in the city are completely undecorated, even though I even had made at least a bookcase sprite that never made it into the game. Adding them is a matter of minutes, but the final hour stress got the better of me. I also had 4 ready sprites for a bomb that never made it into the game, even though it probably would’ve taken like 10 minutes. I also had a lot more in mind for cool effects. I had for instance written a blur effect, that could’ve been used as scene transition, when hurt, or something like that. It was all ready to be used, but you forget all about that when time is up. Lesson: Leave more time at the end! Or at least, if you make an effect/image that you’ll “put in later”, just put it in right away instead. I even had a 10×10 pixel kitten that I forgot to put in!  FUUUUUUUU

SOLILOQY – my LD compo game – you can play it and rate it!

Ludum Dare 22 was somehow pretty exhausting for me, and kind of depressing. I don’t exactly know why, but I think that multiple factors brought in.

The weekend before the compo I made a “warm-up game”, even though I planned to do it long before PoV announced this kind of thing. I just wanted to make a game in 48 hours in order to help a friend (a 3D artist), who needed a programmer for his university project. The programming part wasn’t wasting, but the fact that the game didn’t get finished at this weekend (mostly because of my friend ) left feelings of “incompleteness” inside me, which I hate.

Another thing: I didn’t like the theme “Alone”, and I still don’t think it was the best or even a good theme of the ones in the final voting round. But, as I always have to live up to my own standards I wanted to follow the theme AND make a good game. And this often leads to a status-quo – as long as I don’t have the right ideas I won’t start, and as long as I don’t start I won’t have the right ideas. Or something like that. My mind was blocked and I did other things, like playing Skyrim and chatting on IRC (not in #ludumdare, though, that place was CROWDED). Later, I started Unity3D and tried to play out another idea I had days before, about some time manipulation gameplay. It wasn’t feasible to do it in Unity3D, but due to the fact I did something concrete (game with 3D environment and FPS controls) I could develop another idea in my brain, which became the concept of the final SOLILOQUY.

I still think the best part of my game is this name! I thought of it before I thought of the gameplay (but it didn’t give me any directions,), and I liked it so much, I wanted to use it in any case. I’m quite happy nobody else named his/her game the same, too.

Even though I have some experience by participating at Ludum Dare before, I still don’t really know how to cut back optimally. The concept of SOLILOQUY demands levels, and levels demand content and art and story and design and choosing colours and making 3D models … but I knew this would be hard for me, as it was when I made my Ludum Dare 20 game, “TRI“. So I decided to do NO textures this time, and it didn’t hurt much (on the game’s side), but the benefits weren’t that great either. I mainly put the levels together in Unity3D instead of 3dsmax (in contrast to TRI), but this didn’t help me much, either. Altogether I have six levels now, where I really wanted ten, but at least seven.
The levels don’t look that bad (abstract style for the win), even though I chose the colours quite randomly. On the other side, what I don’t like much, the levels are all tutorial missions only. You just jump around in the first two, learn using your souls in the levels after that, press some buttons and work together with yourself. After this, the real levels should come, but I didn’t have time to do any more content.

I finished the last level three hours before the deadline, and I couldn’t do any more creative stuff. I especially failed in doing sounds or anything like music, unfortunately. I thought about using inudge.net again, but it would sound like my other two Ludum Dare games, so I dropped that idea. At least this frustration encourages me to actually learn how to make simple songs with real tools. (Wish me luck.)
The reason why I couldn’t do more creative work: This time, Unity3D was my enemy. Sometimes I really had to fight the engine, mostly when it came to the text you see in the game (story & hints) – Unity’s GUI system still is awkward to look at, and it has bad effects on the performance. So I used someone’s code which displays bitmap fonts via SpriteManager (the original one), but it didn’t work out of the box with all my bitmap font generator tools (I decided to use “TWL Theme editor”). After those problems were resolved, at the very end of the process, suddenly my white text became gray in the webplayer version. Argh! I needed nearly an hour to find out why that happened – a plane with alpha (the dark overlay) had the same distance to the camera as the text, and somehow the editor sorted it differently than the webplayer. Whyever that is.

After the mixed (or even bad) feelings I had about my own game, I’m really relieved that people actually liked it! The current feedback is mainly positive, and some things that were criticized are fixed in a post-compo version (on Kongregate, for more attention)! Other things, like the jumping height / range being too crass, are somewhat subjective and unfortunately can’t be changed without rearranging some of the levels.
Of course, many people complain about the brain-hurting aspect of the game (gameplay and visuals alike), but that was expected. I could have done the double-soul mechanic with just a picture-in-picture style or something like that, but then the game would lose its uniqueness pretty fast IMHO. Also, as soon as dogbomb does his “I play your game drunk!” video, the whole game visuals will make much more sense, haha.

BTW, if you have a look at the source you will need Unity3D. The indie version should suffice for just reading the C# files and so on, but you need Unity Pro (or its 30 day test version) in order to actually start the game, because I used Render To Texture. Sorry!

Thanks for reading this wall of text, and don’t forget to PLAY THE DARN THING!

Play the game HERE.

Timelapse video:

I’ll make it short and to the point:

RIGHT

- I finished on time

- Interface

- Idea

- Art

WRONG

- I had to leave many stuff out

- No time to make music

- No time to polish

- Some problems with the software (The Games Factory NGE) (Game was supposed to be displayed scaled 2x, not in a small window. Didn’t know it wasn’t possible until I was done).

MISC.

I don’t think the game reflects what I intended, as the content is very limited but it may give imaginative people an idea of what I had in mind. I’ll surely keep working on this to make a proper game that’s more enjoyable.

The results, I thought, were pretty good. By the end of the competition I had something playable. I even had time to write music and insert sound effects.

If you haven’t played the game yet, you can do so here!

The Process

For this project I started with plain LÖVE. I figured I could get a foundation together. Even before the theme was announced I was pretty certain of making a platformer. It’s something I’ve never done before but I implementation ideas in my head. The first night was all writing collision detection code and movement. This was the one thing I was certain about writing, so I plowed through it. I even had time to write a map loader

I implemented an algorithm called Uniform Hash Grid, which let me subdivide my collidable objects to reduce the number of checks per frame. This worked very well, I was able to create a huge map with no impact to runtime performance. (It had a little load time though, which I think I could improve if I had more time.)

My map loader just loaded a bitmap where pixels represented collidable tiles. I did this to avoid having to use any real map editor tool. In my code I assigned colors from the map image to be actual tile sprites. This was my first map:

From there I just added gravity, and assigned a jump button and I had a working platformer.

I spent some time fooling around with ideas. I wrote a basic particle system which I later used for all the shooting effects.

The next day, after waking up I decided to tackle something I thought would be very hard, drawing sprites. I put together a simple (and awful) animated player sprite:

After that though I kind of lost sight of what I wanted to create. I had a working system, but I didn’t know what kind of game to create. I  got lazy and went out to a coffee shop with friends. I think this was unavoidable because I needed time to think. After that I decided I would have shooting and enemies so I started coding bullets. I added minor things and created a tile set. Things were looking okay but I still didn’t have a game mechanic.

On the last day the name Volcanox finally came to me. I coded up until 1 hour before the deadline adding simple game features like title screen, and winning and losing conditions. I added one enemy and wrote the AI. I had no experience writing something like that so it came out very unnatural. I decided that because the game was so simple, I would make the enemy spawning very aggressive. This actually made the game (annoyingly) hard. I expanded the map to make it huge and have lots of enemy spawners.

Here’s the final map: (yes that’s a volcano)

The last hour I rebooted into OSX and recorded some music on my keyboard, and quickly got some sound effects out of bfxr. I submitted my game at exactly 6pm.

The final submission’s sourcode is on GitHub.

Review of MoonScript

Part of this project for me was testing how well MoonScript would work for game development. MoonScript is a language that compiles into Lua. It’s a slimmed down syntax that adds a lot of sugar. Things like classes, list comprehensions, and a lot of other useful stuff. It works great with LOVE.

I wrote 1534 lines of MoonScript, and it compiled into 2880 lines of Lua. Pretty cool!

I heavily used the class system, and the inheritance it provides. It allowed me to quickly scaffold objects in my game. I think if I were writing Lua, a lot of time would be spent designing my object interaction. In that regard, MoonScript was an excellent tool to use.

I strongly recommend it for game development.

What went right

• Using MoonScript
• Using a bitmap and gimp as my map editor
• My tools all worked well together

What went wrong

• Didn’t test on windows, got report of people having issues after submission
• Didn’t know what I wanted to make in the middle of the comp
• Didn’t have any foundation code, had to focus more on getting code to do basic stuff instead of adding game features and polish.

Once again, If you haven’t played the game yet  you can do so here!