Hello everyone,

after many Ludum Dares of just watching others creating great games, I’ve decided to try my luck as well. I won’t prepare for a specific theme; there are too many themes available, and that’s probably on purpose. I’m not very experienced in making games, nor really proficient in coding, so I’ll try to keep it simple this time. Maybe a simple platformer is what I’ll be going for (I know platformers are quite popular among Ludum Dare contestants), or a puzzle game. The 3D MMO will have to wait for now, it seems.

My tools:

• Programming language: Java
• Art: GIMP (or plain Swing commands, if I can get away with it)
• Sound: Probably nothing, but might check out some programmes on the Tools page
• Libraries: No libraries, I’m not familiar enough with external libraries, and I don’t really have a good private library
• Code hosting: Probably GitHub. Dropbox and GoogleDrive are alternatives

What I won’t be able to do yet:

• Web play. This is something I regret not learning before, but right now I have no experience in making a game playable in a browser. Which is bad, because it’s really more convenient to just open a new tab to play the game.
• Sound. I’ve never programmed anything with sound in Java. I’m aware of some libraries that handle sound, but unless they’re easy to pick up, I won’t be able to add sound. This should detract much from the atmosphere.
• Elaborate graphics. This will all be pure programmer art. You have been warned.

I’ll probably wait until the theme is announced and start brainstorming until a good idea crosses my mind. That is, after I wake up – it’ll be 3 a.m. in the UK when the compo begins, and I’m not planning on being awake this early (or this late, depending on your perspective). I’m planning to stick to the following timetable as much as possible:

Saturday:
8:00-9:00: Wake up, have some breakfast, watch the keynote again, and get started!
9:00-10:00: Come up with a realistic game idea.
10:00-11:00: Design the programme. This should save me from quite some headache afterwards.
11:00-14:00: Get a prototype working. It seems like incremental development is the way to go in this competition.
14:00-16:00: Cook and eat lunch. I’m a slow cooker, and eat a lot, so 2 hours are justifiable.
16:00-20:00: Get the prototype closer to a “game” status. All core mechanics should be implemented.
20:00-22:00: Iron out as many bugs as possible, and compile a Todo-list with enhancements to be made.
22:00-23:00: Have dinner, and take a break by looking at what others are up to. Maybe already play some games.
23:00: Go to bed. By now I should have a properly working, unpolished game with placeholder art.

Sunday:
8:00-9:00: Wake up, have breakfast, have a look at the Todo-list.
9:00-12:00: Three hours time to implement some extra features off the list.
12:00-13:30: Create original art. I’m no good as an artist anyway, so I’d better not spend a lot of time on that.
13:30-15:30: Cook and eat.
15:30-16:00: Import all created art into game.
16:00-17:00: Upload test version of the game. Might get some feedback, but more importantly I won’t be bothering with upload issues in the last minutes.
17:00-18:00: Add game start and ending. Because I guess I won’t have bothered with them till now.
18:00-21:00: Last timeframe to add new features.
21:00-22:30: Bug hunt.
22:30-23:00: Dinner. Most likely consisting of a bowl of cereals sitting next to the laptop while I continue looking for “this last bug“.
23:00-24:00: Last hour of polish to the game.
24:00-1:00: Submit the final version of the game.
1:00-2:00: Make sure the submitted version works, and go to bed. I’ll probably be too tired to play other games at that point.

That’s my plan, I’m curious to see how good it turns out to be, and if I can follow it. The outcome is unknown, but it’ll surely be interesting, and I’m honored to be competing against, nah, rather together with so many talented individuals.

Good luck everybody, have a nice Ludum Dare!

So, the theme is Minimalism, which seems to have annoyed many people here (although that would probably happen with every theme to a certain extent). The Ludum Dare just began, and I’m going to start by… sleeping.
No, seriously, it’s 3 a.m., and it’s best to get the most out of one of my two sleeps over the two days. Besides, I usually need a lot of time to fall asleep, time that I can now spend on thinking about the theme. It’s really the only thing I can do entirely in my head. Let’s see how far I can get with my thoughts, before nodding off. Dreaming about the theme would be perfect, since I’d relax and work at the same time, but I doubt it, especially with such an abstract theme.
Well, that’s all for now. Good luck everybody, I’m sure you’ll come up with something, no matter how difficult it may seem right now. Have a great Ludum Dare!

Saturday, 11 a.m. (8 hours in):

Thinking about the game while trying to sleep proved to be a very good idea. So even though I woke up one hour later than planned, and also went to the super market, I’m not entirely out of schedule.
Compared to others, the theme is suiting me a lot. It means that I can get away with minimal graphics and consider that even a bonus (if done right, of course). My first idea while laying in bed was to have minimalistic controls, but I didn’t really want to make an endless runner aka Canabalt. I then thought about what minimalism is – a reduction of the information we receive, distilled to only the essential bits. So how about reducing the player’s information by limiting his senses?
Somehow, I remembered a game called Batcave or something like that, which I had seen at a previous Ludum Dare, which lets you control a bat in the dark using its sonar. I liked the idea back then, and it fits quite well into Minimalism. Of course, I can’t just redo something somebody else did, not on purpose at least – that would take the whole imagination part out of the contest. So, what other places are dark and have animals?
The depths of the ocean are pretty dark – like, really dark. And I guess there’s an animal operating with sound waves or similar (or I could just make one up). But this would mean that I’d have to draw fish, which far surpasses my artistic skills. Maybe something simpler in form?
How about the universe? Except the various stars, the universe is dark, and most planets are round. Great, I have the setting – and also the gameplay. But more on that when I actually get it to work.

Timeplan: 1 hour behind.

Saturday, 3 p.m. (12 hours in):

I’m still not as advanced as I wanted to be by this time. But I have a clearer idea of what I’d like to see in my game. Cutting features is probably the most difficult part, but I should really stop acting like a kid on a Christmas buffet (“I want that, and that, and that. And that. Really, it’s not worth the entire buffet if this is left behind”).
Behold, my first rendering of the game!

Okay, it’s not that revolutionary. But I hope the pace picks up now. I don’t want to end the Ludum Dare with circles and rectangles. Well, actually, I do, but they should look more decent than my first render. Oh, and it should also be playable.

Timeplan: Hmm, it’s not a playable prototype, just a still render. 4 hours behind.

Sunday, 2 a.m. (23 hours in):

It’s 2 a.m. and I guess that was it for the first day. I now regret not narrowing the game further down, but there’s still hope that I can finish it.
Below you can see the random soup I had for lunch – onions, celery, fine beans, mushrooms, prawns, garlic, broccoli… many things had to go, and it tasted lovely.

The programming aspect didn’t really go well, and I’m falling more behind by the hour. I just got a basic prototype working. The gameplay is reminiscent of Osmos or Flower – move your object on a plane with other objects, incorporate the smaller ones and avoid the bigger ones. The absorbing works well, thankfully, but the only one moving is the player. The other objects (planets?) are standing still. Another problem I have is the framerate. I don’t know why it is so low, but I’m proud to have reduced the computation time to a fifth of the original. Here are the most expensive methods per computation cycle, along with their improvements. Especially the first one was unacceptable.
updateBodies: 300ms->20ms->15ms->13ms
collisionCheck: 30ms->14ms
updateWorld: 20ms->8ms
calcColor: 13ms->11ms
drawCanvas:42ms->46ms

As proud as I am, it still takes around 100ms to refresh the screen, a noticeable delay. I know I must have done something very wrong somewhere, but I have no idea how (or, it might just be because Java runs in a Virtual Machine and might not be able to access the GPU). I found a way to reduce this time by half by only painting the bright parts, but this makes the player planet look funny when moving. I’ll see if I’ll keep it that way.
What about tomorrow? Well, I’d like to have the other planets move as well, and set a border around the screen. But what I’m most looking forward to, is to play a little with the illumination – which was my original idea after all. It’s going to be interesting.

Timeplan: It’s definitely a prototype now, but not yet a “game”. I’d say, 10 hours behind.

Sunday, 9 p.m. (42 hours in):

The day has mostly been spent with debugging and optimizing code. Especially the optimizing was a lot of fun, trying to think of ways to only compute what’s needed – and being able to see each change reflected in performance right away was a huge motivation boost. I’m happy to announce that compared to the optimizations made yesterday, the code is 3-4 times faster now (and also has less bugs). It’s not perfect, and far from what grand visions I had for it, but it’s at a stage where I can offer a copy to anybody interested without having to run and hide. You can get the game here : https://github.com/Pab0/LudumDare26/blob/master/SpacePrototype0.2.jar

You control the golden planet and try grow bigger. Controls: WASD

No start or ending screen has been coded yet, I hope I’ll have time to add that later on. It’s still more prototype-y than gamey, but you can give it a shot, it’s 1-2 minutes long. Here’s a screenshot to show you how it looks like:

Timeplan: It’s 9 p.m. and I’m going to cook lunch now, so…yeah.

Monday, 3 a.m.

Phew, 3:01, and I was still able to submit it. I should’ve made a test submit earlier on to learn the procedure. I didn’t know that I had to make a screenshot, for example, nor that I’d need to host the game on another site (only the code). Small things, yes, but at 2:57 a.m., seconds are quite valuable.
But hey, I finished! It might not be complicated, or what I had envisioned, or beautiful to look at, and is extremely unpolished (sorry for that, the start and ending screen were added in the last half hour). But, hey, it’s a game! An actual playable, finished game! And my first jam entry as well! I submitted something playable – that means that the jam was worth it. This was a great experience, but I’m too tired to write about it in detail now. Expect more in my post-mortem, though.

Good luck to everybody, both in compo and in jam. I hope Ludum Dare was as exciting for you as it was for me. Goodnight/day, people of the world!

So, my first Ludum Dare is over, and it’s time to reflect on my experience. I made a simple collision-based game and named it, in a demonstration of true novelty, “Planets”, for the 48 hour jam. It is a very basic game, but just completing it made me very proud. This also happens to be my first game ever, if I’m not mistaken.
This means that there were a lot of things to learn, not so much code-wise as more general project- and time-management related. While I did learn a thing or two about Java I didn’t know, 48 hours just aren’t enough time to allow for a good study. Though it serves as motivation for more study after the competition.
The most important aspect I learned about was performance. Up until now, performance had never been an issue for the small, simple programs I wrote, mostly because unlike in games, nothing was in real-time. Having the game running is nice, but if it’s running at 5-10 FPS it becomes not only ugly, but also unplayable. Trying to minimize overheads and finding as many optimizations as possible was not only a whole new challenge, but also a joy to code. Gaining a 20% performance boost out of simple changes taught me how wastefully I had coded in the past (and am sure I still do). In the end, it turned out to be a game between me and the compiler, trying to squeeze as much power as possible from the CPU without sacrificing the gameplay.
As for the gameplay itself, it turned out quite well, albeit in a much simpler form than originally envisioned. Originally, it was supposed to be visibility-based, with the player emitting light in order to see the objects for a brief amount of time, but as time didn’t suffice, I had to settle for something less ambitious. It was a good compromise in the end, since a simple but finished game-mechanic is much more enjoyable than a bigger but broken one. The game was fun albeit too short, something reflected in the comments. I couldn’t have asked for more for my first game jam entry.
Now, onto the “what went well/bad” feature:

What went well:

• The timeplan was helpful. It turned out to be very realistic, more so than myself, and as long as I followed it to a certain degree (which was probably only the first day) I had a good, reassured feeling. During the second day, I tried to convince myself that I could pack more stuff into the programme despite the timeplan, and it didn’t work.
• Sleeping after having the game announced was probably the best idea. Normally, I’d spend at least half an hour to come up with an acceptable game idea, but this was time spent in bed, so I didn’t really fall behind. Plus, it helped me sleep better once I had an idea and not worry about the contest until next morning. The time zone surely helped though.
• Incremental development. Limiting the game’s scope is a necessity for these jams, it seems, and incremental development allowed the game to stay at a simpler stage without any additional effort. It’s probably not the best approach with bigger projects, but for short jams it really helps in staying within a reasonable scope.

What went bad:

• Free schedule. 48 hours is barely enough time to create something playable, so it’d be good to get the most out of it (which by the way does not mean to cut back on sleep). Some things, like going to the supermarket in the first morning (1 hour), arranging a Skype call (1 hour), or working on the assignment due two days afterward (4 hours) could’ve been done before the jam (or at least afterwards). Time management isn’t only about the two or three days, but also about the whole time period that affects them.
• Not sticking to the plan. Everything was working out relatively well as long as I was following the timeplan I’d laid out for myself. It was only when I thought I could squeeze two or three more features in during what was supposed to be debugging time, that time really started to run out. I made it eventually, but with more stress than needed, and with less time to polish. Most bugs were luckily dealt with, so the gameplay was more or less stable, but the presentation was just plain bad. The welcome and ending screen were coded between 2 and 3 a.m., and this shows.
• Preparation. The game was coded from scratch. When I say from scratch, I mean every single class and method. While it was interesting to see the program evolve from scratch to game, I’d prefer having the basic set of classes pre-coded next time, at least the canvas and the timer. Things shouldn’t be practiced just for practice’s sake, as soon as they’re learned. Having a small library, along with some general design patterns about rendering, should save me another couple of hours.
• Contest familiarity. This was not only my first Ludum Dare, but also my first game jam in general. As a spectator, I was familiar with some aspects such as the journals, but not with things like the submitting process.  For example, I didn’t know I had to submit a screenshot. It took me 20 minutes to submit the game, up until 3.01 a.m., and were by far the most stressful minutes during the competition. This couldn’t have been averted, really, but I’m positive that I won’t have this problem in my next jam.

The future

So, what are the future plans? I really liked the game idea, especially the parts that weren’t implemented. I think I’ll keep working on it on my spare time (as a welcome change of pace form the competition). It should keep me occupied at least until the next Ludum Dare. I loved the contest and am looking forward to joining again.

Thanks to everybody who participated!

It’s been one year since my first Ludum Dare, and I’m excited to enter the contest once again, this time as part of the Bl@ckDuck Java Team, represented by Fudge_Supreme.

It’ll be interesting to compare the Jam with the Compo, and see what new challenges arise and opportunities appear when you’re part of a team as opposed to working alone. Good luck to everyone!

One year has passed since my participation at Ludum Dare 29, and it’s high time I wrote a post-mortem.

This was my second go at the competition, but also my first group experience, and thus a lot different. Both types – solo and group entries – pose a different challenge. I feel like the solo competition focuses on time-management and is psychologically more demanding (being solely responsible for both every achievement but also every setback results in greater ups and downs), whereas the group competition demands first and foremost a good co-operation and distribution of tasks, as well as good communication throughout.

How did my second Ludum Dare go? I’d deem it a success, despite not getting anywhere near a finished game. The two goals of a Ludum Dare are:

• Have fun.
• Learn.

Having also finished a game is of course great, but it’s just a nice bonus to the two aforementioned goals – an excuse, if you will, to achieve the two “real” goals. After all, some months later we won’t remember the game itself as much, as the time spent making it, and the stuff we learned. At least, that’s how I like to view it.
And judging by my own, but also by the rest of the team’s feedback, we achieved both goals.

My role was that of the coordinator/”mentor”, since I happened to be the oldest and thus most experienced with game dev and Java (not by much, mind you). Here are some things that went right/wrong, from my point of view:

What went well:

• Motivation. I had the feeling like every member of the team was motivated throughout the competition. Even under harsh conditions and with the deadline approaching, we still kept going. Much of the initial enthusiasm lasted until the end.
• Cooperation. Everybody cooperated well in a friendly atmosphere. Confronting a non-cooperating team member had been one of my biggest fears, and thankfully it never came to that. I doubt that this is to my own credit; it just happened that every single team member was well-mannered and pleasant towards the others.
• Flexibility. Although we didn’t make it in the end, we still managed to overcome a lot of obstacles. We had to move 4-5 times to a different place during the competition, experienced flooded streets, power outages, the Internet going down, health-related issues, locking ourselves in, etc.. A less flexible team wouldn’t be robust enough to carry on after all those, yet we managed to stick to the end.
  Our original artist (who’d also be our host) got sick one day before the competition started, yet another team member emerged as the “Joker”, taking her place in the artist department while teaching himself the tools as the competition was well underway. He was also able to offer us a place to stay during the first day.
  Another member found us a place to stay during the second day, and continued working on the project even though it was his birthday.
  Team members who’d learned new things about Java programming on the first day, taught them to other members during the second and third day. The overall teaching and learning culture that emerged was as I’d hoped it’d be, and were it not for the constant interruptions, we could’ve accelerated the learning and teaching rate even more.

What went bad:

• Coordination. The lack of a basic workflow was apparent. We only thought about our current task, and chose our next task based on what was needed at the time. Needless to say, that not following a concrete plan gave us a very bad estimate on the amount of work done/still needed.
• Time management. Regardless of the many obstacles, we were running out of time even during the afternoon of the first day. Things like setting up Git ought to have been dealt with before the competition even began, not in the middle of it. A “feature freeze” would’ve also helped us, as we tended to change basic gameplay features (tile-based vs. continuous movement) up to the last day. Sometimes a mediocre solution is better than no solution at all.
• Role distribution. This was my fault, and falls in the same category as a lot of things I didn’t do right in order to establish a thoroughly democratic model of communication.
  We were switching roles as we pleased, from coder to artist to level designer to coder again – which obviously was detrimental to any kind of specialization, and also harmed our overall organization. Roles ought to be clearly defined and distributed among the team members. Below is a rough plan of what kind of roles one might expect at a Ludum Dare team.
  As for the democracy part: Democracy is wonderful, but when time is of the essence, it shouldn’t be spent trying to get everyone’s explicit agreement before moving on. In those times, it’s much more efficient to designate a trusted person (or group of persons) once, and let it decide within a predefined set of restrictions. Hello, Indirect Democracy.

Here’s the rough role list/workflow I made based on my experience in last year’s Ludum Dare. Obviously, it’s doesn’t fit each project, and some roles might not even exist depending on the type of game. This is more of a template for anyone who wants to take it and adapt it to his/her game.

Roles:
I came up with 12 roles: 6 require coding, the other 6 don’t. Obviously, one person can have more than one role, as long as the roles don’t change too often during the competition.

• [GDsg] – Game Designer
• [LDsg] – Level Designer
• [Wrtr] – Writer
• [Artt] – Artist
• [Snd] – Sound
• [Blog] – Blogger
• [Core] – Core (Class Diagram, Game Loop)
• [Grph] – Graphics (Rendering,Animation)
• [AI] – AI (Pathfinding, AI Behaviour)
• [Phys] – Physics (Collision, Movement)
• [Inpt] – Input (Keyboard, Mouse)
• [Nctr] – Encounter (Battle/Puzzle system)

Workflow:
0. Before the LD starts:
[Blog] Write “We’re in” blog.

1. Settling on a gameplay idea:
[GDsg] Design general gameplay.

2. Determining the overall game/program structure:
[GDsg] Design details – \w [LDsg].
[LDsg] Think of level structure – \w [GDsg].
[Wrtr] Think of a story.
[Artt] Start making general art assets (like hearts for Player Health etc.)
[Snd] Record general sound samples (like a general sound that could be used for jumping, or opening a chest etc.)
[Blog] Maybe write about gameplay idea.

[Core] Make Class Diagram – w\ [GDsg],[LDsg].
[Grph] Talk about what approach to take about the graphics – \w [LDsg],[Artt].
[AI] Determine a world\level representation for AI purposes – \w [LDsg].
[Phys] Determine a world\level representation for physics purposes – \w [LDsg].
[Inpt] Determine types of input – \w [GDsg],[LDsg].
[Nctr] Think of battle/puzzle system – \w [GDsg],[LDsg].

3. Getting to work:
[GDsg] Feature freeze. Refine existing gameplay mechanics – \w [AI],[Phys],[Nctr].
[LDsg] Design levels.
[Wrtr] Write story/dialogs – \w [LDsg].
[Artt] Make art assets for the levels.
[Snd] Make the music/sounds.
[Blog] Blog about progress from time to time.

[Core] Make game loop, calling methods made by the rest of the team.
[Grph] Program renderer & animation.
[AI] Implement pathfinding and general AI Behaviour.
[Phys] Implement collision detection, movement etc..
[Inpt] Implement types of input.
[Nctr] Implement battle/puzzle system.

4. After the competition:
[Blog] Write post-mortem.
[Rest] Play games!

The future
We might not have finished the game, but we had a good time, and learned a lot. I’m looking forward to entering this year’s March competition, and so are a lot of the team’s members. Let’s hope that we learned our lessons and will be proud enough to show you our game, after 72 hours of fun and learning.