This was my 9th solo Ludum Dare! In the past I’ve made, in order: Ethan’s Bike for LD 25, Consumerism for LD 26, 10 per for LD 27, One Kingdom for LD 28, Ordained for LD 29, Silence … Noise for LD 30, Blob for LD 33, Spaceman 34 for LD 34, and, finally, Monster Village for LD 35.

Over the events, I’ve noticed improvements in

1. Attitude
2. Programming Skill
3. Self management

However, what has stayed the same is

1. Art Skill
2. Music Skill
3. Anti-patterns

Attitude

In terms of personal growth…

I entered Ludum Dare 25 as a self-conscious, anxious developer. Here are a few quotes from December of 2012:

• “I am going to be attempting to make an entry for the famous LD!”
• “I’m a VERY new code writer”
• “I am a bit guilty because how how AWESOME other people’s submissions are”
• “I actually just jumped in with a ‘YEAH THIS IS GREAT’ attitude, and no thought is a bad thing for design”

Underlying these words was this attitude:

• I don’t want to be seen as arrogant for entering the Ludum Dare
• My game sucks, and someone is going to tell me “get out”

This attitude was constructed from my own circumstances in life, and, as a seasoned Ludum Dare-er would know, is not how things are.

Ludum Dare is a community where everyone rapidly develops a game to the best of their ability, and then gives constructive feedback and encouragement to others for their own games. Ludum Dare is a community of learners. When you are learning, there is no “arrogance,” just people sharing their thoughts about each others’ games.

Now my attitude towards Ludum Dare is:

• Let’s make something
• My game sucks because I’m learning
• Look at what other people made!

This is vastly different because it is geared towards learning and looking at what other people made to get new ideas. Learning works best when you aren’t afraid to try.

Programming Skill

I can implement features a lot quicker than before. I have more to say about this under “anti-patterns”

Self management

At the start, my usual routine was:

1. Let’s make an MMO
2. Oh god this is too much
3. Let’s make a decrepit skeleton of an MMO
4. My code is too messy, I’m going to give up now
5. Submit

Now:

1. Let’s make an MMO
2. Let’s scope down to the basic mechanics
3. It’s too small now, let’s make it a tiny bit bigger
4. Finish the scoped down version from step 2
5. My code is too messy, but I have some of what I planned done
6. Submit

You can see that the start and end points are the same, but the middle points have seen a significant improvement.

Art Skill

Compare Ethan’s Bike with Monster Village: it is the same. This is because I focus on programming far more than drawing, and I have not put much effort into improving my art skills. I blame laziness.

Music Skill

Half my games don’t have music, and some don’t even have sound effects. This is due to focusing on programming.

Needless to say, if I ever join a development team, I’ll definitely be a programmer.

Anti-patterns

For all of my games, there is a “PlayState” class that essentially holds the entire game. I’m aware that this is bad design, yet, in the interest of implementing features quickly, this is what usually happens.

1. I have my game planned out
2. I made a few flowcharts and diagrams on how this is going to be implemented
3. Well designed part of the code is implemented
4. I need to implement the rest of my code now
5. I didn’t plan for how a few features were going to be implemented
6. Mud ball

This is a large improvement over my first game, which was

1. Start making game
2. For every feature
3. If it is data, make a “Thing” class
4. If it is an action, make an “ActionManager” class
5. Go back to step 2 until everything has its own class
6. Cobble

A humorous example of this was the all powerful PercentManager class from Ethan’s Bike:

package com.horsentp.ld25;

public class PercentManager {

public PercentManager() {

}

public boolean calcPercent(int stat) {
boolean percent;
if(stat>=10) {
percent = true;
} else {
percent = false;
}
return percent;
}
}

As time goes on, and as I make more stuff, I get a little better at ensuring good design principles, but the PlayState-mud-ball problem persists across all of my projects.

I believe this is due to “quickly implementing features.”

I believe that if I take a step back every time I see a mud ball forming, and make some design changes right then and there, I can avoid the point where my code becomes so messy that I abandon my project.

Type of games

I noticed that most of my games in Ludum Dare and outside of Ludum Dare have the following gameplay elements:

• Management
• Platforming

and I attempt to make this gameplay

• Fast paced
• In depth

Obstacles

But “in depth” usually becomes “why is this so complicated” (See One Kingdom). “Fast paced” becomes, ironically, “slow paced” (See Ordained and Silence … Noise). Over time I have become better at making games “fast paced” (Blob and Spaceman 34), but less so with in depth games. A major reason for this is likely player feedback. Most of the games I make that attempt to be in depth end up being confusing. They’re confusing because there aren’t a lot information sources for the player to use while playing the game. In an attempt to make the game less cluttered, it becomes more confusing. GUI programming and design as well as gameplay design is what needs to be worked on to improve a game’s “understand-ability.” Not surprisingly, bad GUI programming is always because of  mud-ball style PlayStates.

Other notes

• I drink too much coffee during every Ludum Dare
• I feel like I wrote beautiful code until I get a bug that takes 4 hours to fix
• I always implement animation, but I don’t have the time to make them

In conclusion

1. Thank you for reading
2. Patience is key
3. Beware mud balls
4. Keep making games so you get better at managing mud balls and yourself