Category: Game Development

The Satisfaction of Building It Yourself

Post author By Gianfranco Berardi
Post date 8/8/2016
3 Comments on The Satisfaction of Building It Yourself

I like building my games with my own tech.

There was a game jam in which I used Stencyl, but otherwise, all of my projects have been based on my own hand-coded C++ with libSDL. I spent time figuring out how to write a basic game loop, how to design my software architecture, how to create simple buttons to interface with, and more.

It’s time I could have been spending designing games rather than implementing them. I know this fact.

And yet, I persist.

Over the years, I’ve been told to switch to Flash, or use an engine like Torque 2D or Unity. When XNA was released, I remember wondering if C# was going to become the dominant programming language in game development.

But my C++ game engine is still with me, and still relevant. Granted, it’s not as full-featured as some systems, and the asset pipeline is still a manual effort. But what it does feature is well-tested, and I know how it works.

There’s something about learning how to build it from scratch that makes development more enjoyable. My A* pathfinding algorithm might make oddly suboptimal paths, but learning how the algorithm works and figuring out how to implement it was a fantastic experience.

As you can see from this 2010 development shot of what ultimately became Stop That Hero!, the AI hero should have followed something like that yellow line rather than the path it actually took.

It’s sort of like doing my own home repairs. There are some things I’ll leave to well-paid experts, but other things shouldn’t be too difficult to do. For instance, replacing the toilet’s fill valve and flapper took a small trip to the hardware store to get a replacement part and then a few minutes of work.

A bigger project I finished recently involved putting lockable doors on shelves we have in the basement. My wife and I are getting licensed to become foster parents, and part of the requirements for our home’s safety include keeping flammable materials such as paint in a locked storage area.

Rather than buy a big expensive cabinet, I thought, “We already have these wooden shelves in the basement. How hard could it be to put up a piece of wood with some hinges and a padlock?”

I measured the area I needed to cover. I bought the wood and had the guy at the store cut it for me as I didn’t own a power saw myself. I learned the screws for the hinges were longer than the wood was deep, and I found that you could get 1x4s to frame the wood to make it look nice while also giving the door the thickness needed for those screws.

In the end, the doors looked nice enough and were functional, although they are not perfectly centered, as you can see. It turned out that the dimensions I measured didn’t take into account parts of the shelf protruding in ways that would prevent the doors from fitting perfectly. The good news is that they look homemade. B-)

Now, it took some time. I had to go to the hardware store a couple of times to get all of the materials, and I had to spend time on it when I could have been doing something more important, like working on finishing my game before we have foster children in the house. Did this time and effort translate into a better return on investment than the $90 cabinet I thought we could avoid buying?

No. In fact, we probably overspent on the wood and other materials for other projects.

But there are some benefits to having done it myself.

One, I learned 1x4s are not actually 1 inch by 4 inches. I never knew this fact, but when you buy wood, you need to expect your 1x4s will be 0.75 inches by 3.5 inches. It’s about how the wood is when it is cut and rough versus when it is dry, planed, and made ready for sale. It’s just one of those things that I now know for future projects. Luckily, the screws I had to attach the 1×4 to the plywood weren’t too long, but that could have been another trip to the hardware store since I was expecting the nominal dimensions to be the actual dimensions.

Two, I discovered that I can improvise a carpentry job. I had not made plans, yet I was able to put together some decent looking doors. When I ran into trouble, such as finding out that the doors wouldn’t fit where I expected them, I was able to shift them to different parts of the existing shelf and keep going. I could easily have given up when I found out that the doors were just a little too big, but I made it work. If I was doing kitchen cabinetry, I would have been more careful, but this project was more about the functionality than the aesthetics.

Three, I have the pride of saying, “I built that myself.” There’s nothing like that feeling.

My game development efforts might result in projects that are somewhat askew like my basement shelf doors are. It might take me longer. The end result might be less than what I could have gotten had I leveraged someone else’s efforts.

I know.

But I am a much stronger developer than I was in the past mostly because of all of the from-scratch efforts I have put in. I did the research myself. I explored from first principles rather than taking the shortcut of an existing path. I understand the trade-offs involved in design decisions rather than accepting decisions made for me.

And in the end, when I release a game, I can say proudly, “I built that myself.”

It won’t likely be important to my customers. And it won’t likely be important to you. But as an indie game developer, I don’t have to pay attention to your criteria for what’s the best approach.

I can build it myself, a process I enjoy.

And next time, I will be more experienced and knowledgeable than I was before.

Game Design Game Development

The Seventh Month of a Three Month Project

Post author By Gianfranco Berardi
Post date 7/4/2016
2 Comments on 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.

Game Development

Where Do You Find the Time to Play AND Make Games?

Post author By Gianfranco Berardi
Post date 6/27/2016
1 Comment on Where Do You Find the Time to Play AND Make Games?

Like many indie game developers, I have a day job.

It pays the bills, but in exchange it asks me to dedicate a significant portion of my time to it during a given week.

I am married. I like being married to my wife. Since love is spelled T-I-M-E, in order to continue being married to my wife, a portion of my time is also spent just being with my wife.

We have a house. Now, before you buy a house, everyone is excited that you’re looking. They ask about neighborhoods you are considering and let you know about realtor friends they have.

But once you buy a house, suddenly everyone’s tune changes to the sarcastic song of “Oh, have fun doing all the maintenance on it! That’s home-ownership for ya!”

Like, they knew. They knew the entire time, and yet they never said anything until you joined them in their misery! So a portion of my time is spent mowing the lawn, fixing things like dryer vent ducts and minor plumbing issues, and general cleaning.

I like to sleep a full night. Well, I don’t actually. I wish I could use that time for other things, but I know sleep has a bunch of benefits. So aside from the occasional all-nighter in an emergency, a portion of my time is spent being uselessly unconscious.

So between a day job, commuting, married life, home ownership maintenance, eating, and sleeping, I find it difficult enough to schedule enough time to make games on the side. Cut back on idle time spent on Twitter and Facebook, cut out TV watching, cut writing in my blog, and there’s still only so much time left in a day.

And there aren’t even any children in the picture yet.

So how do some of you find time to actually play games?

It amazes me to read that other part-time indie game developers not only have time to play a new release but to also finish it within a week and give their well-conceived thoughts on it.

I once read about an interview with a prominent game designer who was asked what his favorite video games were, and he admitted that he didn’t play games. I remember wondering at the time how it is possible that someone could be in the industry but not play the games made by that industry.

But if you’re busy, and you are trying to make time for what’s important, then the less important stuff gets cut.

When my choice is to make games or play games, even if the temptation is high for play, making gets priority. I can play later. Or I can make time to play, but it will be limited.

For instance, this past Saturday I played board games with a bunch of people. The evening was dedicated to it, and then it was over.

Other times, I have played Mario Kart or Smash Bros with friends, or I’ve found myself with some free time and decided to use it to play a single-player game.

But those times are rare. They’re definitely not daily, and I don’t find myself playing a game for many evenings in a row until I’ve finished it.

That’s because I’ve dedicated those evenings to making games. Or mowing, but assuming the grass is fine, then it’s dedicated to making games.

It’s not that I don’t want to play games. In fact, I do want to play the many games in my collection, including games I still have from the NES. I have this delusion that one day I’ll have time to sit down and properly finish Final Fantasy and all the Wizardry games. I was playing X-COM, but only when it was released on Humble Bundle, but I never did get around to playing Civilization: Beyond Earth. Heck, I bought Civilization 3 at a physical store many years ago, and it has yet to be installed on my computer. Despite my poor game-playing track record, I love playing games, and I would play them more if sleep wasn’t so important.

Playing games is also good for research. How do you make games if you don’t know what is already being done, or what the trends are, or what conventions to follow to avoid reinventing the wheel?

Playing games keeps me informed. When someone talking about game design refers to Super Mario Bros or StarCraft, I’m on the same page. When they say something about flagpole jumping or Kerrigan’s betrayal, I know exactly what they’re talking about.

But when they refer to StarCraft 2 or Fallout 3 or really almost any major game released in the past couple of years, I’m going to have trouble understanding references if they aren’t explained.

It’s kind of embarrassing. Growing up, I was the “kid who knew everything about Nintendo”, but today I would have no street cred.

But I find myself choosing between making games and playing games, and playing games isn’t chosen often in favor of making progress on my own creative projects.

So if you are one of those people who somehow makes time for both, please write a comment below to let me know: how do you do it? Do you find that some areas of your life are out of balance as a result, or do you somehow make it all work? Do you purposefully take a period of time off from your indie game development to play a new game to completion, or do you play games regularly and squeeze in game development in the time left over?

Game Design Game Development Geek / Technical

A Book on Procedural Content Generation

Post author By Gianfranco Berardi
Post date 6/20/2016

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.

Game Design Game Development Marketing/Business

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

Post author By Gianfranco Berardi
Post date 3/16/2016

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.

Game Development Marketing/Business

Building an Enduring Game Development Business #NotGDC

Post author By Gianfranco Berardi
Post date 3/14/2016

Since so many of us are instead attending the cheaper and easier to get to #NotGDC, I thought we should make a point of sharing our own advice with each other.

Write a blog post or create a video to share a quick tip. Tell us about a cool resource you found. Whatever you do, share it by using the #NotGDC hashtag.

Ernest Adams, author and game design consultant, recently shared an answer he gave to the question “What does it take to build an attractive business in the video gaming space that endures for many years?” on Quora.

Vision, flexibility, and ruthlessness.

Go read his full answer at the link above, in which he talks about what he saw happening at EA before it became the 800-pound gorilla of the game industry.

He contrasts EA with Zynga. When I attended GDC in 2011, I remember noticing all of the billboards advertising games, which isn’t something I was used to seeing in the Midwest. I remember seeing ads for Zynga and its games, and I imagined the amount of money it would take to do so. Zynga had an IPO that summer, and it was huge.

Soon, however, it fell hard. Zynga’s been cutting its workforce and lowering expectations, and last month it announced it was selling its very expensive headquarters in San Francisco.

Adams argues that Zynga was unable or unwilling to adapt to the market.

There is quite a bit written about what Zynga did wrong, but it didn’t really have much to fall back on when people started using Facebook on their phones more than their desktop environments.

Which is interesting because one of Zynga’s supposed reasons for success was that it applied “ghetto testing” to get market data that informed decisions about everything from what game mechanics to add to what virtual items to sell.

It rode one huge wave to success, and now it’s floundering.

EA, on the other hand, has many failures, but only because it sees many potential waves and tries to make sure it is in a position to ride them. If one wave crashes, it abandons it, and it can afford to because of all of the other waves it is successfully riding.

That adaptability is amazing when you think about how fast the industry changes and how many years it takes EA to publish a single game.

Now, as an indie game developer, EA might seem to be the exact opposite of what you want to model, but you don’t have to follow its business strategy. You might, however, learn a thing or two about making your indie game development business sustainable by learning from one of the largest successes in the industry.

Game Development Marketing/Business

Are You Also at #NotGDC? Let’s Share Some Advice!

Post author By Gianfranco Berardi
Post date 3/14/2016
2 Comments on Are You Also at #NotGDC? Let’s Share Some Advice!

I knew this week was going to be both fun and frustrating because so many people on Twitter will be posting about the 30th annual Game Developers Conference, but I didn’t realize how many people would be posting about it the weekend prior.

Kyle Pulver wins with the best tweet so far:

Pretty sure I'm staying at a procedurally generated apartment for gdc. This is the microwave desk. pic.twitter.com/LpnCikFWH6

— kyle pulver @ gdc (@kylepulver) March 12, 2016

GDC is exciting, but for many, it’s also pretty expensive to attend regularly if at all. I attended once in 2011 and since then haven’t made my way back yet.

But since so many of us are instead attending the cheaper and easier to get to #NotGDC, I thought we should make a point of sharing our own advice with each other.

Let’s talk game development. What would you tell your younger self about the realities of indie games if you could? How do you create that special effect you showed off recently? Where do you find your motivation? Where do you stand on the subject of curly braces in your code or screen shake in your visuals?

Go ahead and write a blog post, create a video, or host a podcast. It doesn’t have to be long, or perfect, or anything other than you sharing the nuggets of wisdom you’ve earned the hard way. Alternatively, if you found a cool link to someone else sharing the behind-the-scenes of their efforts, feel free to tell us about it, too.

Whatever you decide to do, share it by using the #NotGDC hashtag.

I’m looking forward to seeing you at our not-a-conference.

Game Development Geek / Technical Linux Game Development

A Better Way to Write Platform-specific C++ Code

Post author By Gianfranco Berardi
Post date 3/7/2016
3 Comments on A Better Way to Write Platform-specific C++ Code

Gaming on Linux reported that Linux porter Ethan Lee’s SteamOS & Linux talk at MAGFest has slides and audio available.

Ethan Lee has ported a number of games to GNU/Linux, and his talk gives some insight into what people can do to make the porting process easier.

Some of it is obvious, such as not accidentally introducing proprietary dependencies. Just because you like using Visual Studio, it doesn’t mean you need to force anyone who wants to build your project to need Visual Studio to do so.

He dug into coding patterns that make it easier or harder for someone to port, and while the slides are annotated, having the audio makes it easier to understand the context.

What I found funny was that the day before I saw these slides, I wrote code that looks almost exactly like what he had on slide 20 under “Bad Idea”.

I was basing my code off of Aquaria‘s, which has a long function filled with #ifdef #else #endif lines to get the path to the user’s save directory, providing a different path depending on if you are using Windows, Mac OS X, or GNU/Linux. While I wrote my version a bit more simplistically, it seemed like a decent approach.

Here’s what my code looked like:

std::string Persistence::getUserDataDirectory()
{
    #if defined (__WIN32__)
    const char *environment = std::getenv("APPDATA");
    std::string homeDirectory = (environment ? environment : ".");

    #elif defined (GB_ANDROID_BUILD)

    std::string homeDirectory = RealInstanceDelegator().SDL_AndroidGetInternalStoragePath();

    #else
    // IF ON LINUX

    std::string homeDirectory(".");
    // See https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
    const char *environment = std::getenv("XDG_DATA_HOME");
    if (NULL == environment || std::strcmp(environment, ""))
    {
        const char *home = std::getenv("HOME");
        homeDirectory = (home ? home + std::string("/.local/share") : ".");
    }
    else
    {
        homeDirectory = environment;
    }
    #endif

    return homeDirectory + "/" + Version::PROJECT_NAME + Version::DEMO_STATUS;
}

Ick. I would have to have to dive back into it and debug it if there is a problem later. Hopefully I got it right the first time.

But Lee’s presentation made me wonder how the “Good Idea” slide works and what was so different about it.

Here’s the code example in his slide:

char path[PLATFORM_MAX_PATH];
const char* GetSavePath()
{
   PLATFORM_GetSaveDir(path, "save.sav");
   return path;
}

It definitely looks cleaner without the preprocessing code, but even with the audio of the talk I didn’t understand what he was actually doing here. To me, it looked like his GetSavePath() was just delegating to a platform-specific version of the call, but how does this code know which one to use?

So I emailed him and asked.

His response:

The idea is that the way you write portable code separates the different paths from each other in a clear way while also being able to debug each path in a way where reading the path is trivial to do. The big problem with defs is that they often make things _crazy_ hard to read and are just error-prone in general, so I try to separate them in a different way.

Basically PLATFORM_* is just a blanket C namespace I make for separating everything; you just have a platform.h that all of the otherwise #ifdefy stuff will go to, then you write different platform.c files. In the case of the slide example I would write a platform_win32.c and a platform_linux.c, and of course you can mix and match if you really need to (linux.c and osx.c might both share a unix.c), and that’s a lot easier to reason about and is easier to share in places where platform code might be the same in certain places. It’s also a lot easier to know what you need to implement later when the linker points to exactly what PLATFORM_* calls it couldn’t resolve for a new port.

Ohhhhhh.

Ok, I get it.

So basically in, say, your CMakeLists.txt, you know which platform you care about, so you’ll build the project with the platform-specific .c file and ignore the rest, and when you read through the code, you don’t have the #if define #elif #endif mess to read through because they’re separated into different files that never collide with each other in the same build.

Nice! Oh, and also nice is that each of these implementations can easily be unit tested because you can create a separate test for each implementation.

So I got to work. I create one header file called Persistence.h and three different .cpp files: Persistence_ANDROID.cpp, Persistence_LINUX.cpp, and Persistence_WIN32.cpp. My project’s CMakeLists.txt would create a list of .cpp files to build. Now I make sure that list includes the platform-specific version of the .cpp file in the project’s sources. So if I am building an Android version of my game, it would build Persistence_ANDROID.cpp and ignore the Linux and Windows versions of the file.

FILE (GLOB GBLIB_SOURCES *.cpp)
IF(GB_ANDROID_BUILD)
    FILE (GLOB PLATFORM_SOURCES PlatformSpecificImplementation/*_ANDROID.cpp)
ELSEIF(GB_LINUX_BUILD)
    FILE (GLOB PLATFORM_SOURCES PlatformSpecificImplementation/*_LINUX.cpp)
ELSEIF(GB_WINDOWS_BUILD)
    FILE (GLOB PLATFORM_SOURCES PlatformSpecificImplementation/*_WIN32.cpp)
ENDif(GB_ANDROID_BUILD)
ADD_LIBRARY (GB-lib ${GBLIB_SOURCES} ${PLATFORM_SOURCES})

And look at it!

std::string Persistence::getUserDataDirectory()
{
	std::string homeDirectory = RealInstanceDelegator().SDL_AndroidGetInternalStoragePath();

	std::string userDataDirectory = homeDirectory + "/" + Version::PROJECT_NAME + Version::DEMO_STATUS;

	return userDataDirectory;
}

It’s straightforward to read and tweak, especially compared to the ugly mix of code in the original version. New platforms would be easy to support by changing the build script and adding a source file.

Thanks for the pro tips, Ethan Lee!

Game Development Geek / Technical Personal Development

Interview with Scott Anderson of Sledgehammer Games

Post author By Gianfranco Berardi
Post date 2/1/2016

Scott “Impossible” Anderson is an engineer at Sledgehammer Games, having worked on Call of Duty: Advanced Warfare, and was recently interviewed at We Are Game Devs, a site that highlights the various unsung and underrepresented talent who help create some of the fastest growing interactive entertainment on the planet.

Aside from his day-to-day responsibilities and advice for people who want to learn how to be programmers, he talked about his time as an indie game developer.

He touched on being part of Chicago’s early indie game development scene before his time as co-founder of Enemy Airship, working with Steve Swink on Shadow Physics.

And did that bring back memories!

I remember going to the Chicago Indie Game Dev meetings and Chicago-chapter IGDA meetings starting back in 2005. Reading my blog posts from that time is kind of embarrassing, but I guess that means I have grown.

Back then, Anderson was part of the duo that was Maw!soft, and I remember him as one of the key fixtures in the scene. If there was a game developer event in town, he was likely to be there.

During those years, he always had advice to share, a lot of which I ignored at my own peril, such as his comments on my goal for trying to use the IGF submission deadline as my project’s deadline or that I should release early and often with quick prototypes to find the fun.

I always enjoyed our meet-ups because if there was a fun idea to discuss, it was probably his, such as what a casual FPS would look like.

I hadn’t been keeping track of what the members of the old indie scene have been doing, but every so often I’d see Anderson’s name pop up in industry news, usually with me thinking, “Oh, I didn’t know he was doing that now.”

And now it sounds like Anderson will be working for Funomena soon?

Should prolly also mention: the Wizard (aka Scott Anderson) is our newest hire @funomena 🙂 https://t.co/iDtm6OJRcr

— robin (@hunicke) January 30, 2016

Good luck, Impossible!

Game Development Marketing/Business

How to Create a Game Development Project Plan

Post author By Gianfranco Berardi
Post date 1/18/2016

In the past, my game development project plans have been little more than to-do lists of tasks and features. I had no real deadlines and no idea when anything would be done. I basically picked a date for the entire thing to be finished without any real sense of how realistic it was, and then I worked on whatever task I felt like working on until I felt it was good enough to move on to the next one.

And then I would blow past my self-imposed deadline, feeling frustrated about how much work I still had left.

I mentioned that I will be focusing on impactful results over progress in 2016, and to help me do so, I decided to create a more detailed plan for my current game.

That plan covers what I’ll be working on and completing for the next three months. I want to release a playable game to at least one player, whether it is a customer or an alpha or beta tester, at the end of March.

I fully expect this plan to be a living document that changes as I identify new requirements or tasks, finish things early or late, and learn more about what I’m making.

Creating this plan was tough at first. I struggled with how to start, and even started searching online for project planning articles.

Then I realized I live and breathe Agile software development, and Agile project planning is a thing.

I’m normally on the tail end of the process, though. At the day job, my team estimates the effort on user stories, breaking them up into tasks if they are too big. We work in two week sprints, and planning the sprint is based on how much effort we as a team think we can accomplish during that time. So, as a developer, I am usually working on directly creating the software that someone else needs me to make, and while I have input to tweak or change requirements (“We can’t do it that way because it will cause problems with the existing architecure. How about if we do it this way instead?”), I don’t generally have the ability to decide what project the company is working on.

For my business, I needed to start from the beginning, and creating this project plan was a great exercise and gave me quite a bit of insight into what I’m actually going to be doing when I say I am working on my game.

I thought about signing up for a service such as Trello or downloading an open-source project planning application, but I decided to create a simple set of spreadsheets. I already have LibreOffice on my computer and didn’t want to sign up for yet another service. Since it’s just me working on this project, it doesn’t need to scale much, but larger teams might need something they can share and update at the same time.

The plan has five parts to it: a product vision statement, a project backlog, a roadmap, a release plan, and the current sprint.

Product Vision

DO NOT SKIP THIS STEP!

This part I already had, but it’s such a key aspect that I wanted to focus on it for at least a few words.

Nothing kills motivation more than not understanding what you’re working on or why you should be doing so in the first place.

A clear statement that defines what the project is, who the audience will be, and how this project supports the overall strategy for your business does wonders for your mental energy and focus.

I can’t emphasize this part enough. I used to gloss over the boring idea of a vision statement or defining a clear mission for your business that I read in pretty much every book about running your own business, productivity, and effectiveness.

Think about it this way: you need to take a trip. How will you travel?

Without a vision or a mission, any mode of travel is a viable option, right? If you want to travel by ocean cruise, you can do so. If you want to fly, you can do that, too. Driving might also be a completely valid option. Heck, not going is fine as well. You don’t really have a wrong answer possible here.

But there isn’t a right answer either.

Now imagine that this trip is an emergency. Someone you care about is in trouble, and you need to go save him/her. A luxury cruise seems like a poor option, and not going at all is pretty much thrown out as an option. Flying is faster, but driving gives you flexibility in travel at the destination. Hmmm…

What’s the difference between the two scenarios?

What happened is that the emergency gave you context for your trip. You had decisions to make in both cases, but in the emergency, your decision-making became instantly easier because options were eliminated and you had criteria you could weigh the remaining options against.

One of the biggest jobs you have as an indie game developer and business owner is making decisions. Without a vision, a purpose, or a mission, your decisions can be random and take you anywhere.

So establishing a vision for your project gives you a high-level context within which you can make key decisions.

My vision for this project involves publishing a simple educational Android game to get more first-hand knowledge about potential customers on that platform. I’m not talking about personal information. I mean I always hear about how Android users are not willing to pay for games and that iOS is a better platform, but I want to confirm this data with MY games and not just the flood of games of varying quality in the market.

My principles for this project include that it should be educational, family-friendly, and have an accessible interface.

I changed my approach with this project last year because I realized the physics simulation I was working on didn’t serve the educational aspect of my vision.

Without a vision, I would have no direction. I could easily have kept working on the physics simulation version of this game because it was fun to try to get leaves to move in the wind just right; unfortunately, it would have been a waste of time as it doesn’t serve my vision for my business as a whole.

Establishing a clear vision for your project and ensuring that it is in alignment with the vision you have for your business (you have one of those, right?) is a hugely important step. It gives your project the context you need to make decisions easier.

Project Backlog

The backlog is basically a prioritized list of features. It’s slightly more involved than the to-do lists I complained about earlier.

The project backlog was fairly easy to make. I thought up a list of features I wanted and wrote them down.

The tough part was writing some of these features out as user stories. I found Mike Cohn of Mountain Goat Software has provided a sample spreadsheet-based product backlog, and I created my backlog based upon his recommendations. Cohn’s website has a lot of great articles on user stories, backlogs, and project planning, by the way.

He recommends the format: “As a <role>, I want to <do something> so that <business value>.”

By focusing on the player’s experience when planning this project, I am less likely to get mired in a fascinating technical problem for months. Not that those fascinating technical problems won’t happen as part of a user story, but it’s like having mini-vision statements to give context to your work.

The context of a user story around a technical problem should sharpen my focus on accomplishing my bigger goal as opposed to merely geeking out over a hard coding problem that my players won’t care about if I ever finish the game in the first place.

Writing such stories is hard if you don’t have experience with it. It’s easy to write user stories that are not really user stories or don’t really do a good job of explaining what the work is meant to be. Just following the format above isn’t enough.

As an example, here is how I started writing the Main Menu theme’s stories:

As a player I want to launch the main menu so that I can start a new game
As a player I want to launch the main menu so that I can continue an existing game
As a player I want to launch the main menu so that I can quit the game
As a player I want to launch the main menu so that I can change options

But it felt awkward and forced. The main menu is what comes up when you start the game, so there it’s actually more of a passive event. I’ve basically taken the notes I made myself “Create a main menu with four options: new game, continue, quit, and options” and tried to force them into a user story format.

Thinking about it some more, I made them better by focusing on what the player was doing and the real benefit or reason why:

As a player I want to start a new game so that I can have some educational fun.
As a player I want to continue an existing game so that I can pick up where I left off last time
As a player I want to quit the game so that I can go do something else
As a player I want to change options so that I can tweak/update my play experience

I kept writing, tweaking, and deleting features and stories until I couldn’t think of anything else I needed. I ended up with 41 stories for this project.

The next step was estimating them. At this stage, there is no point in trying to estimate each and every story accurately. After all, we suck as a species at estimating. I don’t expect to be 100% correct, but this exercise should help me identify roughly how large the project is.

I used the common project planning estimation technique of using t-shirt sizes. Stories were estimated as Small, Medium, or Large.

Finally, I prioritized the entire backlog. Given what I know about the project so far, what should be finished first? What’s less important and can wait? The idea is that whatever I’m working on is the most valuable thing at the time, and yes, I fully expect that priorities can change.

I used values spaced out by 10 so that future stories can be prioritized in between existing stories.

The most important features were assigned 10, and the least important 100, and all stories fell between those two values. Some stories shared the same priority value, mainly indicating that they should be done together.

I didn’t purposefully use numbers between 10 and 100, but it worked out that way. If I had more stories to prioritize, I probably would have kept increasing the maximum priority value beyond 100. You could use whatever values make sense for you, but the main idea is to have everything in your backlog ranked based on priority.

Just by prioritizing and estimating the backlog items, this project plan puts my past project plans to shame. I know at a glance what is important, what features I’ll be working on first, and how much effort I expect they will take. This information is good to know.

Project Roadmap

A roadmap is a rough timeline explaining when certain parts of the game project will be worked upon and when they can be expected to be finished. It’s not about features so much as what value the project will have at different times throughout the project’s life.

I’ve never made a project roadmap before, so I needed to do some research. It wasn’t that difficult. I already estimated the effort needed for the known features in my backlog, and they are already prioritized. I basically needed to look at groups of my priorities and identify high-level concepts based on my features.

I had to take my t-shirt estimates and apply them to a calendar somehow. I have no historical data as I’m starting a fresh project, and so I don’t know how many features I can accomplish in a given week. As someone with a day job and a family life, I only have so much time to dedicate, so things that might normally take a developer a day or two can drag out for a week or more split across multiple short work sessions.

So I guessed that Small features should take me about an hour, Medium stories are about two hours, and Large stories are likely going to need to be broken up into smaller tasks I can estimate as Small and Medium stories.

And given my goals for weekly development hours, I can figure out which features and stories will be done when.

My game puts the player in the role of a child who is raking leaves to earn money. There are a few stories and features around the raking mechanic. Since raking is such a key part of the project, it’s one of the first things I want to finish early. I say finish even though I know game projects can change in development and I might change how it works at any time based on experiments and playtesting, but my roadmap shows I will have the raking mechanic done this month.

Raking requires neighbors and their yards, and so I will also start working on the neighborhood this month. Since I have a number of features involving them, some prioritized later in my backlog, I know I will need to continue working on this aspect of the game through to February. My roadmap reflects this knowledge.

Creating the roadmap helped me tweak the backlog priorities, and the backlog’s priorities helped me create the roadmap. I bounced back and forth between these two sheets in my project plan’s spreadsheet file until I felt I had the priorities and rough scheduling right.

And there it was: a visible communication to Future Me about what I wanted to accomplish with this project and by when.

Release Plan

A release plan explains at a high-level how you intend to deliver working software at the end of XYZ sprints. That is, some teams work for multiple sprints before producing a release. Others strive to ensure their software is always in a releasable state.

I decided to “release” weekly. That is, at the end of a week, I expect to have my game at a certain level of functionality identified at the beginning of the week. So my release plan identifies what I expect to work on each week from the beginning of the project until my expected release at the end of March.

It doesn’t say exactly what I’ll be working on. That is, it’s not like I’m planning exactly which specific stories or features I’ll be working on between February 14th through the 20th.

However, that week I will be working on adding the concept of holidays to the game world’s calendar, which influences things such as whether the general store is open or if neighbors are out of town. I will add a new room to the player’s home that has specific functionality available. And I will also be working on a Large feature that I have designed as a game mechanic. By the end of the week, I expect all of those things to be done.

But I don’t necessarily know what those things should exactly look like today. I don’t have them planned as a set of tasks to work on yet.

And that’s OK. When I get to that week, the project might have changed so significantly that this feature is no longer relevant. I won’t waste time planning the specific work involved until that sprint is my next sprint.

Just like how changes to my roadmap and my backlog could impact each other, my release plan helped me figure out my roadmap.

Given my current estimates of both my backlog and how much I could accomplish in a given week, my roadmap had to be adjusted a few times. At a high level, I overestimated how fast I can finish a given set of features, and my lower-level release planning helped me see it and correct it.

Sprint Planning

Now I have a prioritized backlog, a roadmap to show me how my project will develop at a monthly level, and a release plan to show me what I’ll have accomplished on a weekly basis.

The next thing to do is plan the next sprint’s worth of work.

I first give the sprint a name. Maybe it’s not that important, but it’s another layer of context. What am I trying to accomplish this sprint? A good name helps me remember when I’m waist-deep in the work.

Here is where I take the stories I initially wrote and ask myself questions. Stories aren’t meant to be detailed project documents but invitations to a conversation, but since it is just me, I have the benefit of knowing what I mean but the disadvantage of not necessarily remembering or having thought of the details.

Sprint planning is when those details come out.

For instance, when the player selects New Game from the Main Menu, what exactly should happen from the user’s perspective? In the future I have planned to create a playable introduction to the world of the game, but I don’t want to work on it until I have the core game play down. So I specified that for now the player will start out in his/her bedroom. Suddenly this story requires the task to create an in-game bedroom.

I took each of the stories I planned to work on and broke them into as many tasks as necessary to make it clear to me what I specifically needed to do to say the story was done.

I don’t need to specify a lot of detail before I can start working. If something comes up that I hadn’t thought of before, I’ll make a decision then. You want to plan enough to know what you’re doing but not so much that you waste time on details you can’t possibly know the answer to until you face them.

I estimated the tasks based on hours I thought they would take to accomplish. I didn’t try to get it down to the minute so much as I tried to get a feel for how much time it will take me to get this week’s work done.

My first sprint last week was estimated at about nine hours of work. Some tasks were done within minutes and others took much longer than expected. I ended up doing only 5.5 hours of game development to get all of this sprint done, so I was a bit off.

Each week I’ll do sprint planning again, and over time I’ll get a better feel for how much I can reasonably accomplish in a week’s worth of effort.

Was It Worth It?

Creating the initial plan took me only about a day’s worth of effort, although it was spread over a week’s worth of shorter sessions for me. Each week I can expect to invest some time in planning the next sprint, and each month I expect to spend some time updating the plan as a whole.

That’s quite a bit of overhead for a plan that is subject to change, especially with my limited, part-time efforts. The plan is also somewhat incomplete as it assumes I will be working on the project without interruption. I could get sick, and there is bound to be a weekend trip to visit family in the next couple of months that throws off my release plan if I don’t take it into account.

But even this early in the project it has been incredibly valuable to me.

Having a high-level roadmap and release plan helps me focus on my priorities. Instead of having a vague sense of wanting to finish a game and a list of ideas masquerading as features, I know what my next few months will look like in terms of my daily effort. My work for the day, the week, and the month has a much clearer context than ever before.

I am able to focus on my features from the perspective of the player as opposed to the perspective of me wearing the developer hat, which means my development will be more purposeful and effective. I will always know why I am working on something, which should help me be more conscious with my development choices. I should be less likely to find myself at the end of a year without a game published because I didn’t realize I was spending too much time on some neat algorithm.

And I have a reasonable level of confidence that I will create a first release of my game to at least one player by the end of three months. It will likely still be rough, with perhaps quite a bit of polish needed, but my goal is to get a release out then, and my plan shows me a way to get there.

In the meantime, I also have smaller planned releases of new functionality to test and get feedback on. For example, just by posting a screenshot of my project at the end of the first sprint I got some comments on Twitter that made me rethink the UI element I was using.

While I still believe in low-overhead, lightweight plans over intimidating 300-page documents no one will ever read, I think my past plans were too light to the point that it would be considered generous to call them plans. They didn’t help me figure out what I was doing or assist me in making decisions about the project. This project plan, however, has already helped me quite a bit, and I’ve barely started.

So yes, I believe spending time as a part-time indie game developer on detailed project planning was worth it.

Sources

I did a bit of research as there were aspects of this type of planning I had never done before. Here are some great links I found to articles, book chapters, and other resources that I found valuable:

Quarterly Planning Time and More on Planning by Steve Pavlina: some old articles on the importance of planning. He also had a recent newsletter in which he promoted the value of creating detailed, long-range plans.

Agile Project Management for Dummies Cheat Sheet: I’ve heard good things about For Dummies books. Although I haven’t read this book, the cheat sheet gave me a good overview and summary of the project planning process.

Mountain Goat Software by Mike Cohn: There are so many good free articles here that give you an overview of many aspects of Agile project planning and Scrum.

The Art of Agile Development: Release Planning by James Shore: This chapter portion focused on release planning, and I found it helped me understand what I was really trying to create with my release plan. There is a common idea of the “last responsible moment” to break down things into details, and this resource does a good job of talking about it.

How to do Agile Release Planning by Kent J. McDonald: Another article on release planning with links to quite a few resources on the topic.

We Need Planning; Do We Need Estimation? by Johanna Rothman: A quick read about the idea that detailed estimates aren’t a good use of time. You want to work on the most important thing and deliver results incrementally and iteratively. “This is risk management for estimation and replanning. Yes, I am a fan of #NoEstimates, because the smaller we make the chunks, the easier it is to see what to plan and replan.”