Category: Game Design

Categories
Game Design Game Development Geek / Technical

Toytles: Leaf Raking Progress Report – Having a Dialog

A few weeks ago, I started working on a new set of updates for my leaf-raking business simulation Toytles: Leaf Raking, originally released in 2016.

I wanted to focus on making the neighborhood come to life by giving it some personality and character. I plan to do so by allowing your neighbors to talk about story lines happening in their lives.

My current project plan is in a spreadsheet I manage through LibreOffice, and with the COVID-19 pandemic, it took me quite a few months before I could focus on it. It mostly came together in June.

The original plan was broken down into weekly sprints, and I decided to continue to do so despite not having nearly as much capacity to get much done in a given sprint. Still, having a plan did wonders for my productivity.

What follows is a quick report on how the last few weeks have been.

Sprint 1: Start of personality injection

The first sprint was from June 21st to June 27th, and I wanted to get a few things done:

  • Give player option to accept a client when visiting a neighbor
  • Update copyright date on title screen
  • Chat w/ Mr. Matt at General Store
  • Give each neighbor unique chat text

Before that sprint, visiting a neighbor was the same as asking for work. Effectively, it meant you never visited anyone because you didn’t want to take on too many clients, which meant most of the neighborhood was pointless. This change should open up the way towards future work which will allow the neighbors to have more personality and give the player a reason to chat with them that doesn’t involve cold calling them for business.

I wanted to add the ability to talk to the store owner for the same reason. He doesn’t even exist in the game except for his name being on the store, and I want to make him a living, breathing character, too.

I wanted to update the copyright date to make it dynamic instead of baked into the title screen art, which should make it easier to update in the future. It was a fairly straightforward change.

And once you can visit a neighbor without asking for work, I wanted the ability to hear each neighbor say something unique when you call upon them. This change should mean that the neighbors are no longer essentially interchangeable numbers in a simulation, even if it is only one piece of dialog.

For that sprint, I did 2.5 hours of game development. It may not sound like much, but…well, it isn’t much. But again, we’re in a pandemic, I have kids, and there was some turmoil at my day job, so all in all, I think 2.5 hours sounds like plenty. Well, not really. I still worry when I don’t get much done in any given week, lamenting that if I was focused full time on it that I could probably get it all done in a day, but I’m trying not to dwell on it.

Unfortunately, I only got the copyright update and the visit option done.

Sprint 2: Start of personality injection (continued)

It took the next sprint to get the other two pieces of work accomplished, and that took me 7.75 hours of work, which included putting together the v1.4.0 release for both Android and iOS.

Mr. Cardinal's greeting

Sprint 3: Start of personality injection (continued)

Ok, so my first update to Toytles: Leaf Raking has introduced the tiniest amount of personality to the neighbors. To build upon it, last week’s sprint from July 5th to July 11th focused on writing more dialog:

  • Give each neighbor unique text as clients
  • Give each neighbor unique text as ex-clients

There are 19 neighbors currently in the game. The v1.4.0 release has the neighbors say something unique, and now I wanted them to say one thing as a prospective client, one thing as a client, and one thing if they become an ex-client.

For example, Mrs. Smith is a sweet neighbor who loves it when you visit, so she says, “It’s always a pleasure to see you.”

Once she hires you, she says, “I’m so proud of you. It’s a joy to see you work hard. I’m sure you’ll go far in life.”

And if she has to fire you for doing a poor job of raking her leaves, she says, “Well, not everything works out. I’m sure you’ll bounce back.”

Not all the neighbors are so nice.

Last week I did 3.75 hours of game development, finishing the sprint very late on Saturday night. Considering I also spent 2 hours writing a blog post and a newsletter mailing to announce the published update from earlier in the week, I felt like I did well to make time for the project, all things considered.

I also gained a greater appreciation for the work of game writers.

Sprint 4: More personality injections

Which brings me to this week’s sprint:

  • Give each neighbor unique text as unhappy clients
  • Add variation to weekend flavor text

Currently, if a client is not happy with you, you will learn about it in the morning from your mother. She will inform you which clients are worried that their lawns are not being taken care of, often when over half of the lawn is covered in leaves.

Mom about to tell you bad news

But if you talk to those clients, they will continue to say the same thing they said before. Giving them something to say when they are still clients but are also concerned about your work is once again adding a little more personality and character into the game. Eventually I’d like to get to the point where the way they say something is impacted by your reputation with them, the weather, and possibly anything that is happening in their lives unrelated to your work.

Another area of the game that could use some variety is the weekend text. On weekdays, you wake up, go to school, and then come home to start your day. On weekends, however, you currently get to hear about one of two dreams you have. I want to add at least one more weekend dialog for each week.

Eventually that weekend dialog should have random events, such as a neighbor willing to pay double for getting to their lawn that day, or perhaps you learn that a client has a nephew in town who raked their leaves for them so you aren’t needed that day. But that kind of feature will be for a future update.

Until next sprint

I hope you enjoyed this behind-the-scenes report of my progress on Toytles: Leaf Raking’s Personality Injection updates. I plan to provide a weekly report going forward.

While I would love to have a huge big bang update to release with a ton of changes, I will instead be working slowly but surely, adding a little character each time. Eventually, the game will feel completely different, but I will get there one step at a time.

—

Toytles: Leaf Raking Player's Guide

Want to learn when I release updates to Toytles: Leaf Raking or about future games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

Categories
Game Design Geek / Technical

10 Years Later: Look Inside the Source of Terry Cavanagh’s VVVVVV

Last week, Terry Cavanagh made an announcement with the post VVVVVV’s source code is now public, 10 year anniversary jam happening now!

Collectors of commercial indie game source code have another project to add alongside games such as Aquaria and Gish.

And people are swarming all over it.

A lot has been made of the apparently low quality of the code, with people remarking on the very large case switch statement. To be fair, this is code that was converted from Flash to C++, but it’s apparently quite horrifying and fascinating to read through.

Others are more pragmatic about it:

https://twitter.com/mikeBithell/status/1215939170079821824

In contrast, and as a personal story, I just found some old notebooks of mine from around 2005, and I was very concerned about writing code “the right way.” Now, I wasn’t demanding perfection, but I did have in mind that I didn’t want to just hack together something and hope it worked. I wanted to know it would work. And I apparently wanted to learn UML.

I never shipped that project. But I was also pretty early in my career as a programmer, and I didn’t know much of anything.

Today, I know that I would put something together that works, and then I would iterate and build upon it. I mean, I believe in creating high quality code and using test-driven development to help get me there, but I also don’t spend a lot of time focused on up-front design so much as ensuring my code base is easy to refactor and modify without a lot of pain.

And I know that years of not learning UML hasn’t hurt me.

Cavanagh went on to say:

A decade on, I still feel the same way. I’m incredibly proud of VVVVVV, and grateful for everything. I want to thank everyone who helped me along the way – Magnus for his incredible soundtrack, Ethan and Simon for all their work to bring the game to more people, Bennett for naming the rooms, Stephen for helping me get that mac build out late in launch day. This game is special to me – thank you to everyone who played it and supported me over the past ten years. It’s meant so much. <3

Congratulations, Terry!

Categories
Game Design Game Development

The Seventh Month of a Three Month Project

In January, I said I had created a plan. This plan was to release a minimum viable product (MVP) and get it in the hands of at least one customer in at most 90 days.

My thinking behind this plan was that I should be able to put together a fairly complete game easily in that time, get it in front of paying customers, and get useful data about the market to help me decide what to do in the next three months. Maybe I would flesh out the game more, adding features and enhancements based on customer feedback. Maybe I would switch to a different project entirely if no one cared about this one. When I get real customer data from my 90 day project, I would interpret the data and make an informed decision then.

My project is now past its 180th day. Oof.

What happened?

Pride, partly, and the lack of a relatively satisfying game experience. I didn’t want to release a broken, ugly piece of software, and when my original deadline was arriving, I decided I couldn’t release it in the state it was in.

MVPs are meant to be fairly complete products. They might be missing key features, such as copy and paste in a smart phone, or might have some clunkiness, but they are meant to be something you can hand to a customer so you can get feedback from them. You can ask for feedback about different aspects of the game, but real customer behavior requires real customers, not just people who claim they would pay for something when asked in a survey.

So what was wrong with what I was making? I wasn’t worried about a lack of animations or polish. I was worried about a lack of satisfying game play. Various features were in the game, but they weren’t working together very well.

My plan did not initially accommodate the need for time spent on balancing the game mechanics and economy, and while I knew I would always playtest and tweak, I didn’t realize how far off the mark the initial implementation would be. My game didn’t just feel out of balance. It felt broken. I couldn’t release it in that state.

I’ve been in this situation before. My first major commercial game Stop That Hero! was originally supposed to be a one month project that I woefully underestimated. I worked on it for well over a year before my indie game development business ran out of money. I kept slipping my self-imposed deadlines constantly, and I just kept working harder to try to bring the game to a finish line that kept getting further and further away.

There are other similarities between STH! and my current project. STH! was a Ludum Dare game originally that I decided to flesh out into a full commercial project after getting some good feedback, and my current project started out as a physics-based One Game a Month project with similarly good feedback. Both projects were being built using my own code instead of leveraging an existing engine (eventually Daniel Cook will hug me, and I will check it off of my indie game development bucket list). And in both cases, I worked on them mostly solo.

But there are some differences.

STH! was built when I was running my indie game development business full-time. I spent more time in one day working on that game than I do sometimes in one week for my current project now that I have a day job, am married, and have other responsibilities. Looking at my numbers, I think I could have built my current project in its current state within a few weeks of full-time effort, and I would probably have plenty of time to play other games as well.

But STH! was primarily about feature development, especially since I opted to start from scratch, and it was a long time before I got to the point where I could even play the game, let alone figure out if I need to change anything about it as a result of playtests.

For my current project, I developed a few simple prototypes early on. I created a quick text-based version of the game that took me moments to put together, and I spent a few days tweaking and changing it. I had a few systems that I was able to test out quickly and determine if the concept would work.

And I focused on getting something playable quickly ever since. For many months, I’ve been able to play the game, show it to people, and get feedback, although I haven’t had any serious playtesting sessions.

While STH! was delayed due to missing key functionality for a long time, this game is delayed due to what might be called “informed feature creep”. I say informed because I am not just adding features when I think of them but only after recognizing that they would make the basic game more complete.

But it does have the effect of changing what is considered “minimum” for my minimum viable product. Focusing on the need to ship helps me decide if a new idea is a must-have or not.

While my initial project plan was a good first effort, I clearly missed the target.

But it was more out of underestimating what had to be done than in underestimating what I knew had to be done. Everything I scheduled time for more or less got done when I said it would, but playing the game showed me gaps and problems that needed to be addressed with work I didn’t anticipate at the start.

And that’s to be expected. You should learn about your project as you work on your project, and there will always be changes to the plan as it hits reality. You should expects lots of changes and tweaks to the design of your game.

I knew game development requires playtests and balancing, but I forgot to address it in my project plan. Whoops.

And that oversight is why I’m in my seventh month of my three month project. That, and the fact that it takes me weeks to do what could probably take me mere days if I was 100% focused on the project.

Categories
Game Design Game Development Geek / Technical

A Book on Procedural Content Generation

Sometime back, I discovered Procedural Content Generation for Games, a book about using the computer to create or help to create game content such as levels, landscapes, rules, story lines, or any number of things.

The chapters are available in PDF form on the website for free. Each corresponds with a lecture for a university course the book was designed for, so it is a bit academic. It’s also a little rough, as the point of it being released for free online is to get feedback. These chapters are drafts and not necessarily how they’ll be when officially published.

The book hasn’t been released yet in hardcover, but Amazon’s link shows it as a 2017 edition. And since textbooks are like cars (I once had an accounting textbook that said it was an edition for a year that hasn’t arrived yet), apparently it means it might be released later this year?

I don’t know. There isn’t too much current info on the book. The latest blog post announcing new chapters was from 2013, and the link to the course website is broken.

But the chapters drafts are still available, and they offer some good insight into the algorithms and approaches used in existing games such as Rogue, Spelunky, Elite, Spore, and Minecraft.

Whether you’re interested in the Mario AI framework they describe, or learning how race tracks can be generated to appeal to certain player types, or how to use L-systems and formal grammars in general to generate plants and other features of your games, you could do worse than read through this freely available resource.

Categories
Game Design Game Development Marketing/Business

Should You Work with a Publisher or Self-Publish? #NotGDC

Adam Saltsman is the creator of Canabalt and founder of Finji, which is behind the Overland screenshots you may have seen him post on Twitter.

He’ll be giving a talk today at GDC called “Deciding What to Make: A Greenlight Process for Commercial Indies”.

People who attend will learn how to improve their ability to decide what game to make.

If you think success in indie game development is purely random, that game development is like throwing spaghetti at a wall and hoping something sticks, it sounds like this talk will share some ideas to be more deliberate about it.

For those of us at #NotGDC and unable to attend, we’ll have to wait until his talk is in the GDC Vault and/or for him to upload the slides somewhere later.

But for now, you can read his blog post Publishers and You, a stream-of-conscious indie game development business lesson you can get without shelling out the money for a plane ticket or hotel room or conference pass.

Saltsman’s article gave some good advice about generally working with others, publisher or not:

So: what are your needs, and how can you address them? What parts do you want to work on? What parts DON’T you want to work on? If you can figure this stuff out, you will be in much, much better shape when you start talking to anyone anywhere about helping you ship.

If you don’t want to “do marketing”, that’s fine, but someone better do it because it’s key. And if you follow Seth Godin, you know that your game IS part of the marketing, so whoever does the marketing better be working with you from the start.

I want to focus on the part where he talks about the importance of marketing for self-publishing indies:

I’ve seen other devs call this the “non-game-dev” part of a project, and that’s sort of true but sort of misleading too, and on commercial projects i think it’s counter-productive. If you’re making a commercial game, helping the game find its audience is a part of making it. Sorry.

I’ve written before that indie developers have always needed to treat their businesses like businesses, partly in response to how many people think that running a game development business is just making games and hoping people buy what you made after the fact.

If that’s your business strategy, then yeah, your success in the industry is effectively random, and your goal is to put out as many games as possible before you run out of money.

It’s kind of like a less deliberate version of what Dan Cook wrote about in his article Minimum Sustainable Success.

When Cook wrote about a basic budget an indie might create, he said:

These numbers should look scary. They suggest that the vast majority of indie developers are ripe for financial ruin and are operating primarily on hope instead of any rational financial strategy. I think that’s accurate.

Oof.

But he also concludes “The big lesson is that your exposure to luck is something you can manage.” I would highly recommend reading his article for more details, but one thing he mentions is reducing the risk of any on game release with relatively cheap prototypes to nail the game design down before spending a lot of money on development.

Some people specialize in helping you identify what the market wants. You could become one of those people, or you could pay someone to do it for you, and it’s up to you as a developer to determine which is appropriate for your business. Saltsman argues that to make that determination, look at the needs of your project and not to blanket best practices or a vague sense that you need marketing.

Categories
Game Design

The Systems Design of Tharsis

Zach Gage of Choice Provisions was the System Designer of Tharsis, a turn-based space strategy game involving dice and cannibalism.

Dice? Many video games involve random number generators, and some games such as Roguelikes use random numbers inspired by dice used in Dungeons & Dragons.

But Tharsis doesn’t just use random numbers to dictate results. It allows the player to roll simulated dice, then make decisions based on the results.

In this YouTube video, Gage explains his thinking behind the design of the systems of Tharsis and how the roll of the dice results in tense situations for the player:

And if you’re not familiar with Tharsis, here’s a tutorial video that explains how it works, giving some context to the previous behind-the-scenes video:

Although the Indie MEGABOOTH Tharsis page mentions it is supposed to be available for GNU/Linux, the Steam forums indicate that there are no current plans for a port, which is too bad. B-(

Categories
Game Design Game Development Games Marketing/Business

Making Your Game Accessible to People Who Are Color Blind

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:

Stop That Hero! with Protanopia

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.

Categories
Game Design

Improving a Game’s Design in Mere Minutes

Recently I volunteered at an event in which I facilitated a simple math game for 10 minute sessions with a rotating group of children ranging in age from 4 to 7 years old.

The event I volunteered at was a celebration for refugee children who had just finished taking one of their last math tests in an educational program. There were math-themed games and a potluck after.

We had about eight game stations, each of which consisted of a simple math game at a table with a few chairs and at least one facilitator. Some of the games were made up by the educators volunteering, and others were given or found online.

An Incomplete Game

I was assigned a game called Double It.

Double It Game

It consisted of a die, transparent markers in two colors, and a sheet of paper with a 4×6 grid of even numbers between 2 and 12, with each number repeated four times and placed in some arbitrary order.

I took some time to look at it before the event started. As a game developer, I immediately noticed a problem with the game: the rules weren’t comprehensive.

“Roll the die. Double the number. Cover the answer below.”

So, what’s the victory condition? I felt like maybe it was implied, but there were a number of variations I found that could work in this format.

If it was a square grid, then it could be math-based bingo card, but it wasn’t a square grid. Maybe whoever gets the most markers on the board wins?

But then I realized that with only four copies of any one number, there was going to be a situation in which a player will roll a number, double it, and find that the answer is already covered. What then?

I hesitantly asked the obviously very busy organizer of the event, who said, “Well, just let them roll again.”

Ok. Seems satisfactory.

And immediately after she left to continue her work, I realized that the game would then always end in a tie.

I had mere minutes before the event started, but I was not happy with this game.

On the one hand, I get it. It’s less about the game and more about teaching math skills. It doesn’t have to be an award-winning game. It just has to be a framework to let them practice within it.

On the other hand, the point of it being in game form is to be a compelling experience. As it stood, maybe the children wouldn’t recognize that it was a foregone conclusion that it was going to end in a tie, and maybe they wouldn’t see there was no challenge or conflict involved, but it seemed like chocolate-covered broccoli, and I wanted to do better for them.

Game Design in Five Minutes

So I gave myself the constraint that the original rules had to be the base of the game, but I set to work to make it a real game.

Given that Double It was supposed to be for 1st graders, I made sure not to get carried away with complexity. There’s no sense in turning this game into something like Vlaada Chvatil’s Mage Knight. In fact, with mere minutes to do this work, I only had time to do some simple tweaks.

Luckily, I got a chance to playtest with one of the other facilitators, and it really helped to talk about the rules changes aloud.

So here are the new rules I added:

  • If a player has all four answers covered, then he/she has a monopoly on that answer.
  • When trying to cover an answer, if there is no uncovered answer, and if the opposing player does not have a monopoly, then the player must remove the opponent’s marker from an answer and can place his/her own marker on that answer.
  • The winner is the player with the most markers on the board once the entire board is filled or time has run out.

The second new rule adds conflict and actually allows for the victory condition described in the third new rule to be met. The first new rule came about as a way to reward the player for getting all four answers, as it seemed like there should be a way to prevent the opposing player from taking your markers off the board.

Playtesting

So how was this game? Well, luckily I had a rotating group of playtesters to let me know!

When each game session started, I found that the children were relatively quiet. Some of them were able to double numbers effortlessly, and it was fascinating watching them quietly roll the die, place a token, and pass the die to the other player. Some had more difficulty and needed help, so I held up my hands and tried to let them visualize what it meant to take a number and double it. In general, this early game was somewhat compelling on its own due to the math and it being a novel set of rules.

But once the board started getting filled up, my new rules came into effect, and I was pleased to see eyes lighting up and smiles breaking out. Some of the children got really animated, and you can tell the engagement level changed. Now they had a reason to pay attention to their opponent’s die rolls, and there was this sense of protection over the board.

I was worried that someone would get upset that he/she had a marker “stolen” by the other player, but instead I saw sheepish grins, which surprised me. Even losing felt fun, apparently.

End Results

Given the very little time I had, I think I did fairly well. With some more design iterations, I might have been able to add some skill and decision-making into the game.

The end result is determined by die rolls, much like how the card game War is determined by the order of cards distributed. There was no skill involved, and so my game still lacked something to make it truly a game.

On the other hand, it still seemed more compelling to add conflict to the game. There was a sense of risk, which gave the players a sense of ownership. That they had no control over what happened may not matter as much for a game for children.

The Future

If I wanted to continue to iterate on this game design, I would start with allowing players to choose between covering an uncovered answer and taking an opponent’s covered answer. Now randomness isn’t the sole arbiter of the game. The players would have some agency, and it could make monopolies feel like a real accomplishment, but I feel like there should be a risk involved in not taking an uncovered answer.

Also, I found the grid layout seemed to bias people to expect it to be a bingo-like game, and so I would change the layout to remove that expectation.

Of course, designing a game for children means that the game doesn’t need to be more complicated than it originally was. Maybe. Perhaps if it got too lopsided, one player would stop wanting to play. This is why playtesting with real players is important.

The original focus was on doubling numbers, and I wonder if educational games work better when the educational aspect is presented as a prerequisite for playing in a subtle way.

That is, now doubling numbers was something you had to know how to do in order to play, and it was not presented as the entire focus of the game. Children who struggle with math seemed to be nervous about the early part of the game, but once the new rules kicked in, I noticed they were more quickly getting through the math part so they could see what happens next. It was as if they had found a higher level reason for bothering to do math rather than just doing math for its own sake.

It’s like learning how to read in order to better play The Oregon Trail or learning how to count to play Candyland. These games weren’t ostensibly about learning how to read or count, but as you played, you HAD to get good at those things in order to play the game better.

Another bit of evidence for this kind of education is also anecdotal. On my Apple II C+, I had Stickybear Typing, which was supposed to teach me how to type. I didn’t like it much. Yet, when I learned how to program and started trying to get the computer to do things for me, I found myself practicing key presses to the point that one day I didn’t have to look at the keyboard. Typing was a skill I picked up because I had a context in which to do the typing. When typing on its own was the goal, I struggled.

As I’m not an educator, anyone know if there is already a name for this kind of learning/teaching?

Credits?

Thinking about exploring this game’s design made me wonder where the original game came from.

A quick search online shows that Double It seems to be Doubles Aren’t Trouble, which is a freely available exercise from Jennifer White’s First Grade Blue Skies. The name and design of the paper is different, but the layout of the numbers and the initial rules are exactly the same. White has a number of free and for-sale resources for the classroom, including games and craft exercises for a variety of grade levels.

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

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

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

  1. 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.

    Concept: An imprisoned evil

    Imprisoned Evil prototype

    Imprisoned Mock Up

    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.

  2. 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.

    LD#33 Game Play

    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!

  3. 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.

    LD33 Coolness Result

    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

  1. 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.

  2. 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.

  3. 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

  1. 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!

  2. 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.

  3. 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:

LD33 My Results

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.

Categories
Game Design Game Development Geek / Technical

Visualize Markov Chains in Action

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.

Weather In Markov Chain Form

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.