Category: Game Development

2016 Will Be Different

I know I’m a bit late to the New Year-themed posts, but I spent the last week thinking and working on my plan for the new year.

But first, I’d like to talk about 2015.

What Went Well in 2015?

First, I learned about a lot of stuff.

I read 54 books, which is a little more than one book a week. In 2013 and 2014, I read around 40 books each, so I’m proud of finally hitting this book-per-week accomplishment.

Audiobooks from the library and a 20 minute commute to the day job helped. Ebooks on my tablet to read during lunch and other periods of downtime also helped. Most of the ebooks were obtained through Project Gutenburg, Pragmatic Programmers, and the Humble Book Bundle. And I also enjoyed reading a huge stack of Terry Pratchett books that a friend lent me shortly before Pratchett’s death.

Only six books were directly related to either game development or personal development. The rest were fairly evenly split between fiction and non-fiction.

That isn’t to say that I didn’t learn much. I learned about the Prohibition era, the Wright brothers, and Charles Lindbergh’s historic flight over the Atlantic. I learned about the history of chess, and I learned about Phil Jackson and Michael Jordan’s leadership on the Bulls. I learned about prostitution in Chicago’s Everleigh Club, and I learned about how humanity’s understanding of information as a concept has changed over the centuries. I allowed myself to get fascinated with biographies and histories, and I think the exposure to all of these ideas and knowledge can only help my creativity.

Another thing that went well in 2015 was that I remembered my goals.

In the past, I would make goals for the beginning of the year, and then I would find myself at the end of the year remembering that I had set goals almost a year prior. I would lose sight of the big picture because I was focused on the actual details of work for a long period of time, or I would just forget that I had a goal and so not remember to make plans to achieve it. Some people hate New Year’s resolutions because they never keep them, and I would feel this frustration with my goals.

If I got sick, it would sometimes set me back so much that I had a hard time getting back into whatever daily habit I had established. It was too easy to get knocked off of my routine and keep me off.

Last year, however, I think I did a very good job of keeping my goals in front of me. I may not have actually MET my goals, but throughout the year I was making progress on them or at least being fully aware when I CHOSE not to give them a priority.

I made highly visible reminders for my quarterly game development and writing quotas I was trying to meet, my monthly “big deals” I wanted to accomplish, and my weekly outcomes.

At any given time, I knew what I was supposed to be focusing on. As an example of one result, I put in a lot more game development hours than I have in the past.

Considering that many business owners say that focus is one of their greatest challenges, I’d say that 2015 was a win in this area.

What Went Wrong in 2015?

Last year was the first year my business made no income.

That’s exactly $0.

It’s not hard to see why. The main reason was because I didn’t publish a game.

An entire year went by without me creating and publishing a commercial game, and a commercial game should be my primary way of trying to earn income for my business.

Now, I worked on a project during this time. I had some false starts with it, though, and I changed direction, and it took me awhile to get the design down to something manageable. I did paper and digital prototypes, and I did some infrastructure/technical work as well.

What’s frustrating is that I made an effort to put in more time towards game development. I have a day job and a family, and so taking advantage of my limited “spare” time to make progress on my game project required discipline and effort.

And quite frankly, THAT part worked out fairly well. As I mentioned above, I set quotas for myself, and I managed to spend more hours on game development in 2015 than on game development and writing combined in either 2013 or 2014. So, good job, Self.

The problem is that I didn’t have a specific plan. I had tried to make a plan, but it was little more than a list of tasks that weren’t necessarily well thought out.

This kind of a minimalist plan might be more than enough for some game developers, but since I didn’t set deadlines or milestones for myself, it was easy for me to take a task and work on it for way longer than I needed to. That game menu could be generalized and data-driven, right? I could write my own “simple” physics engine, right?

I tried not to worry about estimates or deadlines, and instead I focused on just making progress every day. The thinking was that eventually I would finish.

The thinking turns out to have a flaw. Basically, I was focused primarily on effort, and it didn’t get me anywhere very quickly.

In the past, I made some money through Google AdSense and Amazon affiliate links. Not much, but more than enough to pay for my web hosting.

These days, my blog isn’t as popular as it once was, and ad revenue has almost completely dried up. I used to make an order of magnitude more per month, and I could expect to get a check from Google every six months or so. Now, it’s been a couple of years since they last paid me because I haven’t hit their minimum threshold yet.

And according to my projections, they won’t pay me this year, either.

How Will 2016 Be Different?

In 2015, I set a goal of publishing at least one game by December 31st. I fully expected to publish one much earlier, but I gave myself that long deadline as a very generous cushion.

Every month, I would find myself realizing that I was getting closer to that deadline without much to show for it. Then it was December, and then it was 2016. Oof.

So, that generous cushion was stupid. I never felt any urgency.

At dsmAgile in September, I saw Geoff Wilson give a presentation called “Barely Manage to Lead”. He talked about a game project that failed after working for a year and a half before getting user feedback. Today, one of his keys to success is to create and deliver a Minimum Viable Product in 90 days or less.

I found that even though I actually had about 90 days after his talk to focus on creating this MVP, I still didn’t accomplish it.

The lack of a solid plan was my real failing. I erred on the side of too little formality. After all, it was just me in my business. It’s not like I needed to do any kind of formal reporting to a stakeholder about progress or release projections.

But remember, last year showed me that keeping my goals in front of me helped me remember to keep working on them. I realized what I needed to do was focus on impactful results instead of effort.

Since a more laid-back kind of project plan (or the lack of one) didn’t help, I’m going to swing the pendulum the other way and do more formal planning.

I spent almost nine hours over the last week creating a project backlog, identifying all of the features and goals I have for my project. I created a project roadmap for the first time in my life, which helped me identify roughly what I’ll be working on and when. I created an initial release plan based on my rough estimates, breaking down what I’ll be working on each week for the next three months. And I have my first week’s tasks based on the items in my backlog that I will be working on.

I’ve never had such a plan in place for myself. The closest I came was when I was working on Stop That Hero! and had created a backlog with items allocated to sprints, but I allowed myself to slip self-imposed deadlines too often instead of doing the needed reprioritizing and replanning. I felt like I needed to do real work instead, and I never realized how much creating a prioritized plan IS real work.

This project plan, however, fills me with confidence that I will have something to show for my efforts in a few months. For the investment of a few hours, I’m sure I’ll save plenty of time and will be able to hit my goal.

I also want to direct my learning a lot more, and so I will create a skill-development plan.

I want to repeat my book-a-week accomplishment this year, but I want to be more conscious and deliberate about what I read in service of my skill-development goals. For example, if I want to improve my cooking skills, I’ll seek out multiple culinary books and audiobooks and read them all in a row.

My outcome focus also means I’m open to other ways to accomplish this learning besides reading. As another example, one of my goals is to learn more about Machine Learning, and aside from reading about it, I know I can watch Caltech’s Machine Learning lectures that a colleague told me about.

So, bottom-line: 2016 will be different because my focus will be on outcomes as opposed to effort and putting in hours. Those things will still be needed, especially as I’m a part-time indie game developer with a day job and family, but those efforts will be aimed at targets rather than be seen as good for their own sake.

I will take what I did well in 2015 and harness it way better. I’m excited about 2016, and I can’t wait to tell you how I succeeded.

Happy new year! B-)

Game Design Game Development Games Marketing/Business

Making Your Game Accessible to People Who Are Color Blind

Post author By Gianfranco Berardi
Post date 12/21/2015

I’ve written in the past about designing games for color blind players because I believe accessibility is important. It doesn’t take too much effort, and a significant number of players will appreciate it.

Alan Zucconi wrote a multiple-page, interactive tutorial on making your game accessible to color blind players.

He provides a shader that simulates different types of blindness, such as Protanopia (red-green color blindness), in order to help a developer test a game to see how accessible it is.

While the download and tutorial itself is Unity-specific, he provides a good amount of background on the different types of color blindness. That information could be applied no matter what game development tools you use.

Even if you didn’t want to use the shader in question, the tutorial explains the theory behind it so you could always implement your own tool.

For example, I used SDL and a custom engine to create my casual strategy game Stop That Hero!, so adding shader support just to test colors seemed like a lot of work.

Instead, I took a screenshot and the RGB values Zucconi provided, then manually plugged those values into the Channel Mixer tool in GIMP to generate the following image:

If you don’t have Protanopia, you can see the difference. The image on the right looks darker, and some of the colors aren’t discernible. I am pleased to see that my use of contrasting colors mostly worked, as the mountains and trees are easy to see compared to the ground.

On the other hand, key visual indicators are lost. My use of red to represent a depleted health bar is almost indistinguishable from the green part if you have red-green color blindness. Whoops. B-(

The images in Zucconi’s tutorial have a slider that lets you see how different kinds of color blindness may change how your game’s visual will be received. It’s amazing to see a gorgeous, colorful game like The Witness become washed out and almost monochromatic.

And for some people, it’s a permanent filter they can’t opt-out of, so if your game depends on color in order to play, you’ll want to make sure it doesn’t inadvertently leave these people out.

Game Design Game Development Geek / Technical Personal Development Post-mortem

LD33: Free Me, You Idiots! Post-mortem #LDJam

Post author By Gianfranco Berardi
Post date 11/30/2015

Ludum Dare #33 is months old, and the next Ludum Dare is about to begin. It’s about time I wrote a post-mortem about the game I submitted.

The theme was “You Are the Monster”, which, as usual, caused a lot of panic among the participants who worried that it was impossible to make a game based on that theme in two days. And once again, despite such worries, there were almost 2,000 entries submitted, so people found a way to do it.

I ended up making a fairly compelling, somewhat humorous, non-violent strategy game about being an imprisoned evil using its influence to escape. I called it Free Me, You Idiots!

What Went Right

Quantity Over Quality: Fleshing Out Concepts and Designs Early
It’s easy to want to get started right away. You only have 48 hours, and every second counts. But I also knew from experience that it helps to spit out as many concepts as possible early on, then pick the one that seems most promising. You are more likely to have a good idea picking the best of a thousand ideas versus the best of ten ideas.

So I spent the first couple of hours thinking, doodling, and discussing with people on IRC.

The theme had a lot of obvious and not-so-obvious applications. The obvious choice is to harvest ideas from classic movie monsters, such as vampires, werewolves, and ghosts. It’s direct, and you could have monsters who are genuinely scary or you could have them be misunderstood by the populace.

The next-most-obvious choice is to think about metaphorical monsters, such as people who have the most evil and disturbing thoughts. It could be a psychological thriller in game form.

I thought about characters, origin stories, and settings, and I had a lot of fun thinking up ideas as varied as space aliens and beings frozen in the Arctic for centuries.

I went with the idea of the incarnation of evil imprisoned in a tree for centuries. With no previous story, I was free to write my own with no preconceptions.

I fell in love with the idea, which really helped me drive the development of the game. If I hadn’t spent time upfront thinking, I might have settled for a merely OK idea, and I might not have found myself as passionate to work on it.

I spent quite a bit of time thinking about this concept. I threw out a lot of ideas early on and managed to find the core of the game. I had originally thought about having a bunch of stones surrounding the tree that you were imprisoned in that had to be removed by the nearby villagers under your influence. I mocked them up and played with the idea for awhile.

The idea was that rock-gathering was an activity for the villagers, and the villagers would grab these forbidden rocks.

I’m glad I threw it out because I ended up having entities that did hardly anything but explore and pray. I would have run out of time without a way to remove those rocks and finish the game.

I think if I had more than two days that those rocks would still be in the game and the entities would be mining, chopping down trees, and more, but because I had a wealth of ideas to choose from, discarding some didn’t feel like I was gutting the game of its essence.
Iterate Like You Mean It
In the previous Ludum Dare, I spent a lot of my time on animations and art, but not much at all on game play. By the end of that compo, which had a theme of “An Unconventional Weapon”, I had a monster that could chase around the player when you got his attention either by shouting at him or by crossing his line of sight. I wanted the monster’s head to turn separately from the body, and there was going to be this idea that the monster can trip over itself when it is moving in the opposite direction that it was looking. I spent a too much time creating the complex animation system when I could probably have gotten away with something simpler, and as a result, what I submitted wasn’t anywhere near a finished game.

I didn’t want to make that mistake again in Ludum Dare #33. Even so, I didn’t start writing code until the compo was well underway. While I was worried that I wasn’t going to make everything I wanted by the deadline, my approach meant I was always going to have something to submit.

My first focus was on interactivity. If the player can do something, I can build upon it, even if I have to cut most features or change the direction of the game design completely.

It meant I was also playing the game frequently. I would make a change and immediately see how it felt. I can identify things that may be buggy or hard to understand, and I can fix them immediately or prioritize them.

For instance, when clicking on an entity in the game, an arrow appears over them. This was a simple bit of polish that I thought seemed important enough to add early on. With a bunch of entities moving about, this arrow meant it was easy to identify which entity you were looking at.

But moving around the world was a bit jarring. You click, and the camera centers to that location. I knew I wanted to add interpolation to smooth the camera’s movement, but I also knew that what I had was passable and could be fixed if I had time for polish later. So the working yet jarring camera movement stayed throughout the rest of the game’s development.

What was exciting was that by making small yet meaningful changes, it allowed me to add a relatively complex economy without much effort.

The game features a few variables that are interdependent and make it feel quite rich to explore. For instance, the player has Evil Energy to use to influence villagers. Evil Energy replenishes one point every second.

The number of followers influences the amount of maximum Evil Energy a player has. More followers meant more maximum Evil Energy, which opened up options for the player.

When you have followers, they will pray to you. When the total amount of prayer time exceeds 10 seconds, the player gets an extra point in Prayer Energy, which can be spent on upgrades and ultimately on the ESCAPE option, which ends the game in victory.

I originally didn’t intend to add so much because I was worried about spending too much time on balancing all these variables, but without all of these different values and their interactions with each other, the game felt very simplistic.

I’ll admit feeling worried that I might find that the whole thing was unworkable and would result in nothing but wasted time. Learning about and playing with game economies from the book Game Mechanics: Advanced Game Design by Ernest Adams and Joris Dormans gave me some confidence I could pull it off by adding pieces of it throughout development and building upon them iteratively. Each addition was relatively risk free and easy to fiddle with.

I was very pleased with the results, and so were the people who played the game. I was surprised by how many actually played it all the way to completion!
A Goal for Being Cool
I realized that back in pre-20 Ludum Dare compos, it was easy for me to play almost everyone’s games because there was less than 100 entries. There would be a burst of game development activity for a weekend, and then maybe a week of playing and rating games, and then going back to regular life. Plus, back then you didn’t need to rate games to get your game rated.

Today, with thousands of entries, it takes much more of a commitment. Your game won’t show up in the random sampling for entrants to rate if you don’t also rate other games. It’s a fair system.

After the compo, I was on vacation from the day job and so I spent the next few weeks playing games. I set myself a Coolness goal. I figured that if I played a handful of games a day consistently for the next couple of weeks, I would be able to hit it.

And when I rate games, I like to give feedback to the developer. I don’t just post “Nice!” or leave no comment at all, so I wasn’t going to allow myself to speed through reviews in order to quickly increase my Coolness. I was going to play games, give them a fair shot, and give an honest review with constructive feedback.

I only got 63% Coolness, but it was enough to earn me a bronze medal. I don’t understand how that percentage is calculated. I know I didn’t rate anywhere near 63% of the nearly 1,199 games submitted, yet it seems like I could have hit 100% with only a few more handfuls of rated games if my math was correct.

But I know that if I hadn’t set a Coolness goal, I would have either made the mistake of not rating enough games, resulting in my own game not getting rated by many participants as in past recent compos, or I would have spent a lot of my waking hours doing nothing but playing LD games, ignoring my other responsibilities. I think I had the balance mostly right.

What Went Wrong

No Polish and No Sound Effects Again
In an effort to speed development along, I did the opposite of what I did in the previous Ludum Dare compo and ignored animation and polish as much as I could. It wouldn’t matter how cool something looked if the player had nothing interesting to do.

As a result, the game lacks life. The entities move around without turning or animating, and there is no indication when a player successfully influences someone. The grass tiles had markings which were too subtle and resulted in a sea of green that made it difficult to tell if the player was actually moving the camera.

Now, it wasn’t completely bad. The prayer bubbles added a nice touch, as did the Evil Energy ball in the HUD scaling quickly when it replenishes. The flavor text had some humor and lore.

But no sounds, no animations, and no special effects left the game feeling like a lot was missing.
Buggy Engine Code
There were a few problems with the custom engine I was using. One was something I saw in the last Ludum Dare in which tiles would seem to separate as you moved the camera around. It turned out to be a floating point error that resulted in me accidentally scaling the tiles so they would sometimes be one pixel smaller in width and/or height. I must not have pulled in the fix when I was putting the project together, so I easily fixed it, but it still took me some time to figure out what exactly I was missing.

Early on I noticed that entities seemed to walk over the tree. They should look like they are in front of the tree when standing in front of it and behind the tree when they were behind it.

So why were they always appearing on top of the tree no matter where they were?

I recently ported my code from libSDL to libSDL2, and sprite rendering was done differently to accommodate scaling and rotation. Unfortunately, I introduced a Z-ordering bug which, after spending time on figuring out what was going on, I decided to ignore for this compo rather than spend more time trying to fix it.

The risks of using your own code instead of a ready-to-go engine such as Unity or Game Maker is that infrastructure bugs like this are not only likely but also might be something you feel inclined to fix immediately. If Unity had a bug, I’d work around it because I’d have no other choice. If my own code has a bug, I’d feel like I could fix it while working on my game and might underestimate the effort it would take to do so.

So while it wasn’t fatal, I had buggy infrastructure code that slowed me down and prevented me from making a better game.
Missing: Some Features and Any Challenge
One of the upgrades in the game is CAUSE FEAR. Do you know what it does?

If you guessed it caused the villagers to be afraid, you would be wrong.

It does nothing. Why?

Because I never got around to it. I had ideas for what CAUSE FEAR would do, but since so much of the game didn’t get made, such as the mining and wood cutting I mentioned earlier, there was no real reason to cause villagers to be afraid. Maybe it would make them pray harder for a bit, and so CAUSE FEAR was similar to trading Evil Energy for Prayer Energy but in an indirect way.

I had a few ideas, but none of them got implemented. Unfortunately, I left the option in even though it did nothing. Whoops. B-(

Similarly, because there was no real conflict in the game, there was no challenge. There is nothing in the game that prevents you from converting every villager, getting all of the energies you need, and winning the game.

I wanted the good villagers to try to convert back your followers. I wanted different kinds of villagers, such as priests and acolytes, and have their presence force you to change your tactics. Perhaps if your followers got numerous enough, the other villagers would go to war with them.

Something. Anything.

But instead, there’s nothing. There’s enough economy and variety that it seems to hide this lack of conflict, but without conflict, I can’t really say I have a complete game.

What I Learned

A Design Document Is Key
Throughout the compo, I set myself goals. I set an initial goal of settling on a concept within two hours. I set a goal of having interactivity early on instead of waiting until the end. I set a goal for rating games after the compo.

Each goal gave me some control over the outcome. I was able to focus on what was needed and ignore what wasn’t. While the lack of polish hurt, it wouldn’t have hurt nearly as much as having a fairly incomplete experience.

What really helped in setting goals was having a design document for the project. Now, I’m not talking about a 300 page document that no one reads. I’m talking about a living document that changed throughout the 48 hours I used it to help guide me.

Everything I thought of went into that document, which allowed me to assess what was a priority and what was nice to have and what didn’t need to be there at all.

I could see what was left and compare it to how much time I had left, and I could make intelligent decisions about feature cuts and what had to be there no matter what.

I credit Hybrid Mind’s Ludum Dare #29 timelapse for In the Black for showing me how effective a design document can be for even a short 48-hour project. Thanks, Dave!
A Game’s Economy Can Have a Big Impact on the Game’s Appeal
I was glad I decided to risk adding more to the economy of the game. Evil Energy and Prayer Energy play off each other in an intuitive way, which makes the game more compelling.

I think people kept playing because throughout the game there was always something to aim for. Converting a follower resulted in an upgrade being made available, which required Prayer Energy to attain, which in turn allowed more followers to be converted more easily, all with the aim of using ESCAPE to end the game.

I could have had a simpler economy. If I eliminated Prayer Energy and made things more directly available, it could have worked, but it might have felt too simplistic.

What I’m not happy about is that the richer economy hides a lack of challenge. I don’t want to use economic designs to act as a bandage on a fundamentally broken game.

But I did learn that doing a decent job designing an economy can result in a great return on investment.
Keep Your Nose to the Grindstone
During the 48 hours of Ludum Dare #33, I slept, I ate, I showered, I talked with my wife, and I blogged.

But most of my time during the 48 hours was spent on design and implementation.

According to my records, I did a little over 24 hours of game development between Friday and Sunday. Just over half of the time spent on the compo was spent doing actual game development, and I’m pretty sure that because I lived and breathed this project, I was even making progress while showering or eating.

Even with the failings I mentioned, I can see that this laser focus was the real reason why I was able to get a decent game finished.

I’ve done compos in which I was distracted, and they didn’t always end well. Either I was dealing with poor health, in which I couldn’t sit at my desk for long periods of time, or I was going to a party or a soccer match.

For this Ludum Dare, I made sure that I was 100% focused on the compo with no outside commitments to keep me from doing anything but game development that weekend.

It was grueling and exhausting, but that concentrated effort made things move along so much more quickly than if I had spread out the development effort with frequent and potentially long breaks.

I’m not saying breaks are bad. I took breaks.

I am merely saying that my mind was focused on game development and not on how to interact with other human beings in a social situation or how frustrating it is when your team is losing due to the same blunders they always make.

I rested when I needed to rest, but I didn’t allow myself to procrastinate or do much of anything other than participate in this compo.

Summary

The results of this compo were very encouraging to me:

Out of 1,199 entries, my game was rated in the top 36% overall and top 8% in innovation. My only rating that was in the bottom half of the group was for graphics, and even then it was at the top of the bottom half. B-)

I credit my ability to focus that weekend on game development almost exclusively, and all of the tools that allowed me to leverage that focus, such as my design document and setting milestones.

The main complaint from players is that there was a lack of music and sound, followed by the noticed lack of challenge. For future compos, I’ll want to focus on not only interactivity but also adding real conflict.

I may want to experiment with adding audio iteratively. Normally I add it at the end, and an informal survey indicated that a lot of other game developers add it at the end as well. I wouldn’t want to spend time on something that might get thrown out before the end.

Still, the idea is that if I can have a playable game early on in a compo, I can also have a playable game with audio early on in a compo, too.

Game Design Game Development Geek / Technical

Visualize Markov Chains in Action

Post author By Gianfranco Berardi
Post date 11/18/2015

Sometime back I took the Coursera online course “Model Thinking” offered by Professor Scott Page.

It covered modeling to help make sense of our complex world. Since models are often simplifications about what really happens, having multiple models that you can apply means you are better able to make sense of the world. I would highly recommend taking the class if you want to be a better citizen and a better thinker.

At one point the class covered very familiar ground. John Conway’s Game of Life and Stephen Wolfram’s cellular automota studies made an appearance, which got me much more enthusiastic about learning how to combine simple methods for complex procedural generation. Along the way came Markov Processes.

Wikipedia says, “A Markov process is a stochastic model that has the Markov property.” Let’s break that down into something resembling everyday language.

Stochastic essentially means random. We’re dealing with a probability. So a Markov process is a model that involves a random element.

And the Markov property? All this part says is that in order to determine what state you are going to be in, the only thing that matters is what state you are currently in. How you got to your current state, otherwise known as your history, is irrelevant. Your past does not determine your future except to the extent that it somehow got you to your present circumstances.

So the simpler definition of a Markov process is that it is a state machine in which how you get to the next state is randomly determined with probabilities based on your current state.

Why is this idea valuable to know?

Let’s say you have weather play a role in your strategy game. If it is raining, your players can’t launch aircraft.

The thing about real weather is that it’s hard to predict. Weather reports tell you that it will be partly cloudy with a 15% chance of rain instead of saying that it will definitely not rain. Because sometimes even if they think it isn’t likely, it happens. Sometimes when they think there will be 4 inches of snow, we find that it is more like half an inch and the predicted snowpocalypse will hit some other city instead. People can talk about the weather as if it is completely random and wonder why meteorologists can keep their jobs when they are wrong so often.

If you wanted to model weather in your game, you could probably use a random number generator. Let’s say that for each day represented in the game, you create a weather report by getting a random number to represent the chance of rain:

int chanceOfRain = rand() % 100;

So when it comes to determining if it actually should be raining or not, you can create a random number and see if it falls within the value:

bool didItRainToday()
{
    return (rand() % 100) < chanceOfRain;
}

It would work well enough. Players can make plans based on the forecast, but there are problems.

First, you can’t prevent streaks of certain values from appearing. If you have aircraft in the game, but the weather system prevents you from using them, they become less useful. One day of bad weather might be a minor setback for your war plans, but having weeks of bad weather could be seen by the player as ridiculous. With random number generators, it’s possible to get into this situation, and your players can get frustrated with the bad luck.

Second, you can’t prevent initial values from being “bad” either. The beginning of the game is when you are trying to pull new players into your game’s world. If the game immediately starts with bad luck, it might leave a bad taste in the player’s mouth.

Third, it’s not as realistic to have a day of sunny weather followed by a day of stormy weather followed by a day of sunny weather. As unpredictable as the weather can be, and as possible as the wild swings are, people expect good weather to follow good weather, and bad weather to follow bad weather, and that we’ll have good weather days more often than bad weather days.

You can mitigate the above issues by hardcoding non-rain values for the first few days and also keeping a count of bad weather and forcing good weather if that count goes above a certain threshold, but it’s a clunky solution that still leaves a lot out of your control as a game designer.

Enter Markov chains

Instead of treating each day as completely independent of the next, you can keep track of your current day’s weather state.

Let’s say that a non-rainy day today has a 90% chance of producing another non-rainy day tomorrow, and that a rainy day has a 60% chance of a sunny day following it.

So almost all of the time a sunny day predicts a sunny day to follow, but every so often it will predict a rainy day. Rainy days might stay rainy for days at a time, but most of the time it will become sunny again the next day. So players can get a feel for how likely rain is to occur and make decisions based on their own mental model of the system, which makes rain an ever present threat without making it an overwhelming or unfair one.

And as a game designer, you can tweak the probabilities of each state until the weather acts how you want it to without having to hardcode everything, create a hacky bandage for it, or give up control to a random number generator completely. You could add more states, such as partly cloudy days and overcast days, which will have different probabilities for moving to other states. Overcast days can result in rainy days more often than sunny days, just like in real life.

You could also put Markov chains to work for you in other areas of games. What if the population of your city simulation has mood swings? That is, if people are content, they are likely to stay content, but sometimes a situation occurs in which enough people get upset that they influence other people to become upset as well. That is, you could have a Markov chain in which content people are likely to be content but sometimes become discontent, and if they are discontent, they are likely to stay discontent but sometimes become content again, mimicking what happens in real life when there is outrage that dies down after the news cycle stops covering the political scandal. In the city simulation, it might drive the player to take actions to address the population’s concerns before real damage occurs.

Or you could create random terrain with roads. Roads tend to want to go straight, but sometimes they turn 90 degrees. Your terrain generator can start creating a road with a particular direction, and each step it adds another tile of road next to the previous one. 90% of the time the next road tile will be placed by continuing in the current direction, 5% of the time it could turn left, and 5% of the time it could turn right.

If you want to play with Markov chains, learn more about them, and see them in action, then see Victor Powell’s visual explanation of Markov chains.

Game Design Game Development Geek / Technical Personal Development

Development Strategies for Game Jams #LDJam

Post author By Gianfranco Berardi
Post date 8/27/2015
2 Comments on Development Strategies for Game Jams #LDJam

As I play and rate Ludum Dare games, I see that games fall into a few groups:

Highly polished games that feel complete
Highly polished games that feel incomplete
Unpolished games that feel complete
Unpolished games that feel incomplete

By complete, I mean they have all the elements of a game: an objective, conflict, rules, unpredictable outcomes, endings, etc.

By polish, I am referring to the production quality. There’s few bugs, the aesthetics are cohesive, and everything feels balanced when you play it.

So how do you make a highly polished and complete game in 48 hours? What tips and tricks are developers using?

Make It Playable as Fast as Possible

Games are complex systems in action. You can’t design a game well unless you playtest it because it isn’t always obvious how the rules of a game interact. Making something playable early means you have more time to test it as you add, remove, or change mechanics. You also have time to make decisions, such as whether to kill planned features or spend time on making the controls feel better.

I’ve found that when I fail to submit a game to a Ludum Dare, it usually coincides with a game that either has no game play or gets the bare minimum of game play added at the very end. I have no time to play and see how the game feels, which means that even if I get it done on time, it’s more likely to be an unpolished and incomplete tech demo.

On the other hand, when I focus on getting something playable early, such as during Ludum Dare #24, it’s a game from the beginning. It might start out unpolished and incomplete, but by the deadline, even if I don’t get all the features I wanted in there and I can identify glaring problems, I have something to submit. For my entry for the theme Evolution, I didn’t get to add the features that take advantage of the theme, but I recall how sluggish the tank felt to move and I spent a little time tweaking it until it felt better to play. When you killed the enemies, I had points float up above their heads. I’m not saying it was a beautiful game, but it was more polished than most of my entries have been. And it didn’t have everything I wanted in it, but what was in it felt complete.

Ideally, your work in progress will be easy to deploy to other people so they can play test it and give you feedback. You might think the game is fine, but you’ve been immersed in it for hours and might miss how difficult it is for someone who hasn’t seen it before. Your game is ultimately for other people to play, so their feedback is very important.

Know Your Tools

If someone gave you a complex tool you’ve never seen before, you’d probably muddle through how to use it, but it would be slow and painful.

On the other hand, if you were given a tool you’re familiar with, you no longer need to worry about how to use it as it is almost second-nature. You can focus on the task in front of you instead of focusing on how to use the tool.

Years ago, I struggled with making programmer art in GIMP. I wrote code. I didn’t art.

Partly from learning during previous Ludum Dare compos, partly from talking with artists about their workflow, and partly from practicing outside of compos for my own projects, I learned how to do things I normally need to do during a game jam. For instance, I use layers, preferably named ones, to make it easier to create a complex image. I know how to scale images and layers with fewer artifacts. I know how to use an alpha selection to get an online of an image, and I can grow and shrink selections so I can create a silhouette or a border. I even learned common shortcut keys so I can quickly switch from the Pencil tool, the Bucket Fill tool, the Rectangle Selection tool, and the Ellipse Selection Tool, which saves me time.

I remember reading the manual for Applesoft BASIC and learning that instead of typing out:

PRINT “HELLO, WORLD!”

you could type out:

? “HELLO, WORLD!”

And that question mark would automatically get turned into the PRINT command. The manual mentioned that it saved four keystrokes and time. At the time I wondered how much time it could possibly save, but since I was typing PRINT almost all the time, I realized that it added up.

Today, knowing your IDE’s shortcuts similarly helps. As my friend Chris Freeman said in his presentation on refactoring, tools reduce cognitive load. Instead of using the mouse to hunt and click on everything in menus, you ideally should be able to unconsciously move your fingers to the right key combinations to make things happen. It’s like learning how to ride a bike or drive a car. Once you get the hang of it, you no longer focus on where your feet are. When you want to move forward, your feet automatically know what to do.

During a game jam, you don’t want to spend time reading a manual or searching online for help. You want to just DO things that move the game forward.

For my first Ludum Dare, I was learning how to use libSDL, and luckily I kept the scope of the game down because I knew I wasn’t going to be able to do very much. I spent a lot of my time figuring out what SDL provided and how to write code to take advantage of it.

For the latest Ludum Dare, I was often very pleased with how even major code changes compiled on the first try. I was much more familiar with the language and with the interface of my tools such as Vim and Gimp.

Come up with a Plan

You’re two hours into a 48 hour compo. What are you working on now?

With only two days of development, it might feel like you don’t have time to plan. Every moment not working on game development is a lost opportunity.

But planning saves time, and it doesn’t even have to be very complicated to be effective. There’s no need to create a Gantt chart for your project.

Some game developers create entire detailed design documents to keep their thoughts organized, and other developers use nothing more than a list of planned features that they cross off as they get implemented.

But what about time?

You could work on one thing at a time until it is all done, but the risk is that the later items don’t get done at all. What you don’t want is to find yourself with an hour left and realizing that you forgot to implement a way to end the game or that your game is completely silent.

Some people try to get a good chunk of the game done early so that the rest of the compo is spent on balancing and adding polish. Some developers set aside blocks of time, such as a couple of hours, to creating sound effects.

Other people understand that their energy levels are going to be different throughout the day, and when they are too exhausted from programming, they can switch hats to creating graphics or music. Einstein actively relaxed by playing the violin, and you could do worse than emulate him.

No matter how you plan your two days, having that plan gives you more insight into what to do at any given moment so that you have the best chance of submitting a finished game.

Your Tips?

I’m not saying I’m an expert, and I still feel like I’m learning how to pace myself and put together something. But after participating in 10+ Ludum Dare game compos and a handful of other game jams, I think I’ve gotten some worthwhile experience to share.

I should probably invest in The Game Jam Survival Guide by Christer “McFunkypants” Kaitila.

What are your strategies when participating in a game jam? How do you ensure your game is complete and polished before the submission deadline?

Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD33: Free Me, You Idiots! Ported to Android! #LDJam

Post author By Gianfranco Berardi
Post date 8/26/2015
2 Comments on LD33: Free Me, You Idiots! Ported to Android! #LDJam

Shortly after I ported my Ludum Dare game to Windows, I ported it to Android! You can download and install the .apk now and play on your phone or tablet. I’ve updated my LD#33 compo entry.

Here’s a handy link to explain how to install an app outside of the Google Play store.

Warning: it’s not really optimized for mobile yet. It pauses when idle, but it doesn’t pay attention to the back button, so you’ll have to long-press the Home button then swipe it away to close it.

Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD33: Free Me, You Idiots! Ported to Windows #LDJam

Post author By Gianfranco Berardi
Post date 8/25/2015
2 Comments on LD33: Free Me, You Idiots! Ported to Windows #LDJam

I’ve updated my Ludum Dare #33 compo entry with the Windows version of Free Me, You Idiots!. Now most of the world can play it!

Next up: fixing my Linux-based entry so that it uses a non-custom install of SDL2.

Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD33: Free Me, You Idiots! Development Time Lapse #LDJam

Post author By Gianfranco Berardi
Post date 8/23/2015

Want to see the last 48 hours compressed down to a little over 3 minutes?

I uploaded the time lapse video of my development of Free Me, You Idiots!:

You can find the final submission at http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=251. Thanks for playing!

Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD33: SUBMITTED! #LDJam

I did it!

With 15 minutes to spare, I submitted my entry for LD#33, Free Me, You Idiots!

It has no sound, and there is a lack of challenge which makes it hard to call it a real game, and the UI feedback is lacking to let the player know what is going on, but it’s complete and playable.

It’s also quite complicated! I created a simple yet effective goal-based artificial intelligence, a little economy, and upgrades. The thing I wish I had was direct conflict between the good and evil villagers.

But I’ll have more to say when I write the post-mortem.

For now, check out my entry at Ludum Dare, and if you submitted your own entry, please rate my game.

~~I’ll create a Windows port, soon.~~ You can download the game for:
– GNU/Linux (459K)
– Windows (2.8MB)
– Android .apk (3.6MB)

Congratulations to everyone who submitted a game! It’s been a fun weekend, and I look forward to playing your games!

Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD33: We’re Getting Tired, but We’re Gonna Make It! #LDJam

Post author By Gianfranco Berardi
Post date 8/23/2015

I wasted precious time last night trying to create an animated GIF of the game so far, but it was either terrible quality or took up hundreds of MBs, and so I gave up and went to bed.

This morning I had peanut butter, raisin, and banana sprinkled with cinnamon on toast for breakfast with my trademark orange juice. Starting the day off right!

By my calculations, I’ve put in almost 15 hours of development towards this project, 12 of which came from yesterday.

We’re in the last 12 hours of Ludum Dare, and we’re starting to get tired.

And while I have interactivity and have been toying around with it to ensure that things are working correctly, I don’t have a game yet. The player can’t do anything to meaningfully impact the game world, but the AI is having fun, I’m sure.

The AI needs to be there for this approach to the game. If the villagers don’t have their own goals and activities, then the entire premise of the game is thrown out the window because you are trying to influence their activities towards benefiting your own ends. But I can’t build an entire self-running simulation no matter how much fun it is take on that challenge because then there won’t be any time left left to allow the player to do anything but watch.

So my focus today will be on adding meaningful play. What can the player do that makes sense and gives good feedback? I’ve been thinking about and designing this aspect throughout the compo, and now I need to manifest it.

I will add that I do have another concern. This game is about being the personification of Evil and convincing the followers of a good deity to follow and worship you instead, allowing you to break free of your prison.

What it isn’t about is blasphemy, but in my attempts to add humor by poking fun at how moronic the villagers are, I worry that the game comes across as my indictment against organized religion. It’s not, but my intent isn’t necessary for it to be offensive or to act as a model for how people should act, so I need to make sure that I’m super aware of how the game could be received. I’m not the kind of person who throws his hands in the air and says, “It’s not my fault you interpreted this quickly-thrown-together game in this way.”

Games matter, even 48-hour ones.