Most indies pay little attention to their purpose, mission, and vision, but then again, most indies don’t have sustainable businesses. The vast majority don’t make $500 in a year.
Rolling the dice and hoping for a hit, or at least something that earns enough to fund the development of another game, is not a serious strategy.
And there are a lot of new new indie game developers struggling with motivating themselves to work on their projects for more than a few days at a time before the pain of the creative effort overwhelms any enthusiasm they had to be a game developer. There are always posts online asking for tips of staying motivated.
At the most recent IGDA meeting, I presented an updated version of my 2014 talk Playing the Long Game: The Vital Importance of Purpose, Mission, and Vision to Your Indie Game Development Business.
I’m running my business part-time as I have a day job, but doing a poor job of running GBGames as a full-time independent game developer from 2010 to 2012 taught me some major lessons about running a business. Other indie game developers could benefit from my experience.
While there is no video of the presentation, I uploaded the slides with notes in a few formats:
Knowing who you are and what you stand for will go a long way towards reducing the stress and pain and fear that can otherwise be a regular part of running your own indie game development business.
At the very least, it will give you the energy and motivation to keep working on your projects for the long haul.
Wow, it’s almost February? I’m incredibly overdue for the blog post in which I give a post mortem of the previous year and talk about my plans for the coming year.
Which isn’t to say that I’ve been doing nothing this past month. I just haven’t prioritized telling you about it over actually doing it. B-)
WHAT WENT WELL IN 2016
As I said in 2015, I improved my ability to remember my goals. I no longer did the equivalent of setting New Year’s resolutions that I forgot within weeks. Throughout the year, I knew how well or poorly I was doing according to metrics I tracked.
Unfortunately, it meant that I was very aware of how poorly I was doing most of the time.
Last year I set out to build on my success with remembering goals by focusing on what’s needed to actually accomplish those goals.
One big and important improvement I had was in the area of project planning.
In the past, even if tried to be formal about my project management, my actual planning efforts never amounted to more than creating a list of tasks.
Now, some developers find that they can do just fine with nothing more formal than a TODO list or two, and it worked fine for me if I just wanted to know WHAT to work on and maybe even in what order.
But when you’re a lone wolf indie game developer, you need to wear a lot of hats. I had no problem with donning the Software Developer Hat, but my Producer Hat was neglected and gathering dust.
So I might spend weeks working on a particular feature or task without realizing it because I never stopped to think about how the entire project’s progress was being impacted.
At the beginning of the year, I spent quite a bit of time in project planning mode. I even wrote about how I approached it in How to Create a Game Development Project Plan. Then I dove into executing the plan.
And I was very pleased at how well following the actual plan worked for me. Even when my project started running late and surprises appeared that I hadn’t planned for, having a more active Producer Hat meant that at any given time I was focused on actually shipping my game.
Which leads me to the next thing that went well: I shipped!
I still need to write the post mortem for it, but it is my first finished commercial project in years. While there are still features and content I wished I could have added, I’m proud of what I put together.
The release of my first commercial game in years also gave me my first sales in years. After earning $0 in 2015, I like this new trend of actually earning money from my business.
Speaking of money, 2016 was also the first time I put together a detailed budget for my business.
I used to track my expenses and income as they happened, and my aim was to ensure I had enough money in my bank accounts to cover everything.
But I got tired of learning that my bank account balance was lower than expected, only to discover that an automatic renewal on domain names or web hosting had occurred. I felt like I should be able to anticipate such regular expenses instead of being surprised by them.
So, I put together a projected budget, which allowed me to see not only how much I anticipated spending in the coming year, but also when my expenses were expected to spike. For example, I knew that my annual web hosting renewal was coming up in August.
And then I tracked my actual expenditures against the budget. It was eye-opening, and not just because I was able to quickly learn that my web host increased its rates without telling me before autorenewing. B-(
As a side effect of being hyper-aware of where my money was coming and going (er, mostly going), I also added to my budget a plan for a monthly investment into my business. I managed to add a significant amount of money into my business bank accounts by the end of the year.
Also, I updated my website, which is something I’ve been meaning to do for quite some time. My blog used to be completely separate from the main site, and now it’s integrated.
WHAT COULD HAVE BEEN BETTER IN 2016
Aside from my newly detailed budget and more robust project plan, I didn’t have plans for much else.
I wish I had spent some significant time on creating a promotion plan for Toytles: Leaf Raking. I had done some keyword research and put together a list of reviewer contacts, but most of my effort was spent on actually finishing the game.
Once it was nearly ready, I struggled to make forward progress on getting it in front of people. I realized quite late that the reason I was struggling was because I had no real plan to make it happen.
I didn’t even blog much about it, so I rarely mentioned it during development. I was a bit too accidentally secretive.
For a long time, I had a TODO item on my list to create a skill development plan for myself. I wanted to direct my learning more rather than pick up things haphazardly, but all of 2016 passed without such a plan in place.
I read 54 books, but only 8 were business related, of which I believe only one was game development related.
My project ran late. I didn’t plan for balancing the design, and so quite a bit of work to make the game feel complete wasn’t in the original plan.
Had I published it in three months, I would have had the rest of the year to figure out how to promote it. I wanted to try earning $1,000 by December 31st, but between the late release and my lack of promotion, I fell way short of that mark.
WHAT I WANT 2017 TO LOOK LIKE
2015 was about keeping my goals in front of me and establishing habits.
2016 was about being outcome focused. I logged more game development hours in 2016 than in 2015, but the more important thing was that those hours were aimed at targets.
In 2017, I want to focus on promotion and sales.
Which means I’ll be putting together concrete, specific, actionable plans instead of hoping and praying, or haphazardly trying to tweet about what I’ve made, which is basically the same thing.
I’ve already started the year with efforts to port Toytles: Leaf Raking to other platforms. More platforms means more opportunities for people to find my game. First up is GNU/Linux, mainly because it is my development platform and is easiest for me.
But what about making other games? Project planning is one thing, but product planning is another thing entirely. I have various ideas for new games, but I don’t want to be random about picking something just because it appeals to me. It will be easier to promote new projects if I do my market research and ensure my projects already appeal to players.
My blog has historically been about running an indie game development business, and so my audience has been other game developers primarily. My customers, however, aren’t going to be other game developers and aren’t necessarily going to care about what happens behind-the-scenes.
The thing is, I like writing what I’ve been writing on my blog and don’t want to stop. Can I address players more directly, or do I need to separate my business from my blog to do so?
I am confident when it comes to creating games, but thinking about selling them is both exciting and terrifying to me, the way new things often are.
2017 is when I challenge myself to be incredibly proactive about putting myself and my work out there.
There’s been a meme going around in which indie game developers have posted photos of themselves today juxtaposed with photos of themselves from 10 years ago.
It took me forever to find a 2006 picture of myself.
Let’s go back in time.
10 years ago, states were passing laws to ban the sale of video games to minors. It was after Bush was elected and everyone was falling all over themselves to prove they had “family values”, so a lot of governors were posing with moms and demonizing the great scourge of video games. In the end, each state had its law struck down as unconstitutional (which is to be expected when you base your law on versions from the other states that had been declared unconstitutional already), and it cost the states a lot of money.
Roger Ebert was claiming that games could never be art. Again. And some high profile people in the game industry were arguing the same. I gave my thoughts back then in What Are Games Good For?.
Games were projected to double in revenue by 2011 driven by online and mobile gaming. Keep in mind that the iPhone wasn’t introduced until the next year, and so everyone was thinking mobile meant Java and Brew or Palm Pilots.
Digital Rights Management was in the news, whether it was about computer hardware, games, or things like the Broadcast Flag. I made my opinion known about how annoyed I was that people were so cavalier about it.
Steve Pavlina’s Dexterity.com shut down that year as he completed his transition from the game industry to the personal development industry. His game developer forums eventually became the IndieGamer forums, and his old game development articles turned up either on his site or elsewhere.
The World Cup was in Europe, and the United States had one of their most epic matches against Italy, with both sides losing players before the final whistle. The US was defeated by Ghana to be eliminated in the group stages. Super disappointing. It took two more tries before they would beat them.
Back then, I was living with a girlfriend in an apartment in Chicago. I was working as a paid intern at the Chicago Mercantile Exchange in the UNIX group, and shortly after I formed my company, I got a software development job at WMS. It was across the street from Midway Games, and I worked on slot machines.
My cats, Diego and Gizmo, entered my life that summer. Before them, I never even had so much as a goldfish as a pet, unless you count the rooster my father brought home one time which I later realized was the dinner my mother prepared the next day.
During crunch time, I would get home feeling dead, and the next thing I knew I would have both cats curled up on me as I lay on the couch. I hated crunch time, but I loved those moments with my cats.
As someone interested in becoming a better indie game developer, I joined the Thousander Club. Back then, everyone was recently introduced to the idea that it takes 10,000 hours of practice to become an expert at something. Seriously, everyone who was blogging was blogging about it. If you work on your craft for a few hours a day, over the course of a year you would do about 1,000 hours, well on your way to becoming an expert in 10 years.
The Thousander Club was a way of tracking my hours and publicly holding myself accountable. Aside from the person who originally started it, I don’t remember too many people joining this club, but I would keep it up for a few years, although I never spent that much time in a given year on it. By the end of 2006, I had only 262.25 hours, only a little more than 25% of the goal.
I was working on a game I codenamed Oracle’s Eye, and I can’t remember what the game was about at this point. I remember a ball that could be bounced around the level by the player.
It was a stick figure in 2005. I actually like the look of the tiles. Eventually I created a business man sprite.
Since I was writing the game from scratch using libSDL, I encountered and had to solve issues most kids these days get for free with their Unity3Ds and their GameMakers. I had to solve my own hit detection issues, such as the ball or the player entering and getting stuck in walls. I spent time learning the wrong and better ways to write code to make objects move around. Thanks to those early efforts, today I recognize certain issues before they become issues. That’s experience.
But I was bad at finishing my projects then. I had plans to submit a game to the Independent Games Festival that year, but I eventually started over with Oracle’s Eye Prime, which I also don’t have much of a recollection of. It was one of those “I’ve learned so much! This time I’ll do it better!” kinds of restarts. I never finished it, and I never ended up getting a game submitted to the festival. I was super frustrated with myself about that failure.
I switched to creating a Pong clone (I should write another one just to see how much faster I could do it today), and later a Space Invaders clone.
I created this desktop image to inspire me to finish my project.
Note the orange “ship” which was originally blue.
I was just starting to learn about Agile software development and wondering how to apply it to my own efforts to make me more effective.
I joined the Association of Software Professionals the year prior and wanted to become more involved so I could get more out of my membership. A lot of indies joined back then, and many of them let their memberships lapse, which was too bad. I attended the Grand Rapids Schmooze and met a bunch of great people I’m still friends with. Eventually I became a board member and then president of the organization, something I didn’t really anticipate back then.
The next year’s resolutions included the goal of selling my first game, but I woefully underestimated how much I still had to learn about making games, let alone selling them.
And today?
Since then, I had saved up a chunk of money, quit my job, moved from Chicago to Des Moines, Iowa, all to go full-time indie and live the dream. I got quite a bit of feedback from people in the industry which I promptly ignored, then ran out of money and got a day job again after about two years. So, GBGames is back to a part-time effort for me.
So four years as an employee at a company making slot machines, two years being a full-time independent game developer, and now another four years as an employee, only now I don’t work on slot machines and the devices are quieter.
I went to GDC in 2011, so I could check that off my list. I met a lot of people I’ve only ever known through the Internet, including a bunch of people from Ludum Dare or the IndieGamer forums.
These days when I learn that someone’s kid is really into Minecraft, I find that half the time they get super impressed when I say, “You know, I met Notch once.” The other half of the time they say, “Who?” That meeting, by the way? We talked about our Ludum Dare projects before he had to go handle some email emergency.
Shortly after GDC, I proposed to my girlfriend on the balcony of a castle in Europe. We got married. I still have two cats. I’m a home-owner now.
My four years working on slot machines taught me a lot about working on big projects, but my experience working on Stop That Hero!, writing and designing everything from scratch, turned me into a pretty good software developer. I leverage the knowledge and expertise I gained from game development at my current day job, which pays me well.
I spent way too long working on this project, but I’m still very proud of what I was able to accomplish with it. It’s currently on the backburner indefinitely.
So, in general, I’m doing great. I’m fairly healthy. I’m getting paid very well to apply my skills and training daily. I’m fortunate to be married to a wonderful and incredible woman. I am living in a comfortable and spacious home. And again, I have cats.
And yet…
But my business isn’t doing well at all.
Part-time efforts means that things run slowly. What I thought would take me a matter of weeks ends up taking many months. And being slow in this industry is death when there are dozens of games being released daily. I learned about the importance of speed at GDC in 2011, so I knew this fact even before the market got flooded.
I once went to a talk by an entrepreneur who said working part-time on a business just isn’t sustainable because by the time you put something out there, others with more resources and time on their hands might have gotten there first. He said there’s a reason why many entrepreneurs end up divorced.
Well, that sucks. My priorities put being a good husband above my business, and I know other people make different choices in this regard, but I love my wife and can’t see ever deciding that my Limited Liability Company is more important than our partnership.
When I was single and younger, I could work a full-time job, then work for hours on my game development without too many worries. I was just undisciplined and unfocused then, so I didn’t take advantage of it as much as I should have.
Today, I’m better disciplined and more able to focus, but now my time is split quite a bit. I’ve learned that I can’t work on my business too much before I start getting rubberbanded back towards other responsibilities or my health starts forcing me to pull back.
The year prior to 2006, I assessed my ability to create at a very low value and identified it as my major weakness. It’s why I joined the Thousander Club, and I wish I put more time into it back then.
In 2006, I did 262.25 hours of game development. That’s about 1.4 hours a day, which isn’t much, but it can work. It didn’t really result in much that year, though.
This past year? I only did 259.5 hours of game development so far, although that number doesn’t include the 40+ hours of writing and 40+ hours of business planning and marketing I’ve put in. Yet, I had a plan, and I managed to publish. 10 years on, and I am still taking too long to work on a game, but at least I finish my games now.
My three month project that took me 10 months to publish. I think it’s a pretty good business strategy game, and I’m REALLY proud of finishing this one.
Yes, it was meant to be finished in three months and took about 10, and even though I spent a lot more time on game design and balance as opposed to infrastructure and technical details, I still felt very frustrated with how slow this project went.
My wife pointed out that had I worked on it full-time, I easily could have done the almost 260 hours within three months.
Fair enough. I felt better. A little. It’s easy to get frustrated when you compare your struggles and efforts with the successes that other people publicize, or with the future possibilities. Saying things like “I’m a failure because I spent a year making a dinky game while this highly polished mobile game is making millions” is a good way to get yourself stressed. I went through that with my previous project.
You need to measure your progress looking back at where you came from. And compared to how I was in 2006, I’m way more capable as a game developer, as a software developer, as a partner in a relationship, as a business owner, and as a leader. I mean, I know terms like “the Dunning-Kruger effect” now.
10 years goes by quickly
But in 10 years, I’ve only published less than a handful of games commercially? Oof. I still haven’t submitted a game to the IGF. It’s not that I haven’t worked on games, but unless I take my Ludum Dare or One Game a Month projects and polish them up for release, they kind of don’t count except as ways I’ve gained experience with making games.
But again, when I think about what I have accomplished since 2006, it adds up to a few commercial attempts and over 20 different published projects that are more or less playable. Each Ludum Dare game jam or experiment adds to my expertise. Each finished project makes the next one that much easier.
So, I’ve grown quite a bit. And I did it my own way. And doing it my own way was part of the appeal of going indie in the first place.
I don’t know too much about what my life will be like in another 10 years. My wife and I will be middle-aged then. My cats are getting old and may not be there with us, which makes me sad when I think about it. I’m getting old, and I worry that I’ll fall behind in terms of my technical expertise with artificial intelligence and automation threatening once-secure jobs. I worry about continuing to miss out on opportunities. I feel out of touch with the game industry as it is. I worry about becoming a sad old man who refuses to acknowledge the futility of what he’s doing.
Frankly, I don’t have an exit plan. I don’t have an idea of a situation or point in time when I say, “Well, that’s it. I’ve hit the limit of what I will accomplish in game development for my lifetime.”
Ever since I went back on “corporate welfare”, I’ve been working slowly and trying to build up my business, with the expectation that it will all come together. I don’t mean getting lucky with a hit game, but that the business will eventually become sustainable as my full-time employment.
I have been aiming to build up streams of income, rather than hope for a big jackpot. But for a few years now I’ve been worried that the premise isn’t workable, that it’s not possible to do what I’m doing and expect great things eventually. I’d hate to think I’m limiting myself to mediocrity.
But I chose my current approach because there are certain things in my life that I value as more important. I’m trying to be the tortoise and shouldn’t get frustrated when the hares around me are sprinting by, often off cliffs.
Many of the game developers and blogs I followed back in 2006 are no longer around. Some retired. Some switched industries. Some gave up.
I’m still here, though.
And I expect to be here for another 10 years. In order to have more to show for it by then, I’m making plans to do more rapid and focused learning and hard work now to get me there. Part of that is rereading some of the advice people gave me in the last 10 years and reconsidering what I’ve ignored or misunderstood then.
After over nine months of development, I finally had a game I felt good about brave enough to release to the world.
My major goal was to release the app on the Google Play store first to get a sense of what the process is like and to get direct knowledge about the customers there.
I clicked Publish late in the evening of Saturday, October 22nd. Whew! A big step!
But now I’m in “Pending publication”, and while many unofficial resources mentioned waiting mere minutes to a few hours, I learned that Google changed its policy in 2015 to manually check apps. It still doesn’t take two weeks like it might on Apple’s App store, but it might take a little longer than it used to.
The status switched from “Pending publication” to “Published” the morning of Monday, October 24th. Woo hoo!
Er, wait. Sorta.
For an entire day, and even now the next morning, October 25th, I still see “We’re sorry, the requested URL was not found on this server” when I click on the “View in Play store” link.
I keep finding all sorts of unofficial explanations about caching and how long it can be expected to take for listings to propagate through the system, but the only hint that it might take much time at all is in the Developer Console help article “Issues publishing apps” which asks if it “has been over 24 hours since published”, but then goes on to talk about search algorithm changes and reasons why apps might get filtered out on certain devices.
It doesn’t address a published app not actually being available anywhere.
It’s kind of difficult to feel good about finally publishing my project when I can’t point out any evidence to anyone. As a first-time publisher on Google Play, this experience is confusing and leaves a bad taste in my mouth.
According to someone on IRC, they had emailed earlier in the day and learned that there were some technical difficulties on Google’s end:
“Typically apps can take up to 24 hours to appear on the Play Store, however we are currently experiencing longer than usual delays across a large portion of our system. Our technical team is actively working on a solution and hope to have this issue fixed by the end of the day.”
So, we wait.
I find it confusing because when I self-publish on my own site, I don’t consider the game published until someone else can actually see it.
But this experience is teaching me about the process way more than reading about it ever would.
This time, I’ll address the issues I’m seeing on Android and Windows platforms.
Android: manual code signing
Quite frankly, between running the game on my phone and on my tablet, I haven’t seen any issues since I first tried to get my game built and installed on this platform. The main issue I had was figuring out which directory to save to, and I solved that issue.
Oh, and code signing was another solved issue. I can build and deploy debug builds by turning on developer mode on my devices, but the release build needed to be signed. As I am not using amazing IDEs that have one-touch buttons that do all sorts of fanciness, I had to figure it out myself from the documentation.
Luckily, the Android developer documentation for signing manually was fairly straightforward in this regard. In my CMakeLists.txt, I added a custom target called sign, which requires the location of my keystore and its alias. I created a few environment variables that I pass into my build, and the following is basically what’s needed as per the documentation:
Otherwise, I found porting to Android be very straightforward thanks to using the NDK and libSDL2-based libraries. If anything, I worry about scaling to different screen resolutions and device-specific compatibility problems due to the lack of devices I have to test on.
I’ve already signed up for the Google Play developer program, so the main piece to worry about is actually submitting my app to their store. How hard could it be?
Windows: persistence and font rendering
While GNU/Linux and Android are more or less the same, Windows is the odd duck.
I can easily cross-compile to create a Win32 build, and with my limited testing I found that the 32-bit version runs smoothly on a 64-bit system, so that’s good.
Since I don’t need to use a lot of memory, there’s no real advantage I can see to building a 64-bit version of my Windows port. The main downside would be an inability to support people on 32-bit systems, requiring that I provide both 32-bit and 64-bit binaries as I might need to do for the Linux-based package.
However, I did have to fix a few issues this past week that I didn’t know were there until someone tested it for me. Thanks, Rick!
I knew of an issue with using MinGW to cross-compile to Windows in which using std::cout would result in a crash. I never looked too hard into it because I only used cout for my own logging in order to find out what is happening, so I just commented them out when I released for Windows, usually for a Ludum Dare game.
Well, it turns out that there was still a crash, and I found that if I commented out the code that saved the current game state to a file, it would run just fine.
Was the known issue applicable to file stream operations, too? Luckily, gdb can be downloaded and run as a standalone applications on Windows, so I ran my game on Windows through gdb and read through the stack trace. It pointed to yaml-cpp.
I use yaml-cpp to save and load my game data, and it works very well. But why does it crash on Windows?
I found this thread on GitHub that mentioned a similar stack trace: Crashy shared object
It was closed without really being addressed, as the original poster gave up after seeing the issue disappear when using a later version of gcc.
Luckily, someone else found a different solution involving a change to a few lines in yaml-cpp’s code, although they said more tests are needed. I tried it, and it seemed to solve the problem for me, although I am a bit wary about not knowing what the change does or how it solves it. B-(
The other issue I found on Windows was that resizing the window results in the text looking completely wrong:
All the other graphics look fine. Under the hood I am using SDL2_ttf, but using it directly isn’t showing this problem. I am using NFont, which does some caching, and I wonder if it is somehow being corrupted. I need to do some more tests, but this issue does not occur on my Ubuntu system, and Android doesn’t allow you to resize the screen dynamically at runtime, so it’s a Windows-specific issue so far.
I’ll continue looking into it, but updating to the latest version of NFont didn’t help. I tried updating my SDL2-related libaries next since some Windows 10-specific updates were made between the initial Windows runtime binaries and the latest release.
NFont’s creator Jonathan Dearborn has been running test apps I’ve sent him and sending back updates to try, and so far it seems we’re nearing a solution. Thanks for being so responsive, Jonny D!
The main major issue is signing my game’s binary. Windows 10’s SmartScreen puts up a warning about how they have protected your PC because they prevented the app from starting. It shows the binary as coming from Unknown Publisher.
That’s scary. I need to look into how to make it less scary. Does it require buying a code signing certificate, or is it similar to how Android’s code signing works? I don’t know yet, but I’m looking into it.
The other issue with Windows is that saving the game is sloooooow. In my game, I persist changes each time the player makes a major decision. Basically, if you click a button that switches to a different screen or causes something to happen in-game, I save so that if you shut the game down and reload it, it takes you back to where you were.
My Linux-based and Android-based builds are zippy. I can click, click, click, and any changes are instant. As a result, the game has been feeling very responsive despite the lack of a real-time need for it.
My Linux-based system does not have an SSD drive, and my wife’s Surface Pro does, and yet her system takes forever to save a file.
So on Windows, it feels less like click, click, click and more like click, wait, see screen update, then click. Because of the delay, sound effects are playing too early as well. It’s a lesser experience on Windows.
I haven’t ever needed to do multithreaded programming before as a single thread was usually plenty for the work I’ve ever done, but now I am wondering if I should spin of a thread specifically for writing to a file due to this issue that seems to be Windows-specific.
How Much Longer?
Ok, so there’s some technical issues, and some are easily surmountable, and some require some more investigation, and it’s possible there are some I haven’t run into yet.
Since Android seems the simplest to release, perhaps it goes into the Google Play store first, and I worry about the Linux and Windows versions later.
But I do not want this three month project to get to the ninth month before its first release.
The good news is that the next project will have a much clearer release plan, and many of these issues will be already solved. B-)
I started a three-month project at the beginning of the year, and I’m now in the eighth month. I reported on the reasons why it was taking so long last month.
But I’m feeling pretty good about it, and while I still have some balance issues to work out, and it’s a bit ugly, I’m preparing for the actual release.
The thing is, I haven’t really done a serious release before, and since I want to do a simultaneous cross-platform release, I’m finding issues unique to each platform.
The platforms I currently support:
GNU/Linux
Android
Windows
What I want to support:
Mac OS X
iOS
I’ll start with Apple platforms, then talk about the environment I use natively. Other platforms will be discussed in the next post later this week.
Mac/iOS: no development or testing environments
I would love to create a Mac port. I know it is theoretically possible to create a cross-compiler to generate a Mac version, but it seems I need Mac-specific libraries, which requires owning a Mac.
I don’t own a Mac, and while I know of virtual Mac services you can subscribe to online, I haven’t bothered to look too seriously into them. I would also like to be able to test the game, and so I would need to use a Mac in order to see how it really runs, especially after running into the Windows-specific issues above.
As for iPhone or iPad, I’m in a similar position. I don’t own an iOS-based device. As I’m using libSDL2, I know it is possible to port to it, even without a Mac, but I would need to look into how to do so, and I would still need to invest in the devices to test on.
I am saving up for these things, but at the moment I don’t have them and I don’t want to spend time on them until I know what I’m doing.
And in the past it’s been difficult to hear back from people willing to be paid for porting a game for me, and volunteers have had difficulty figuring out how to put my project together on their system. I might look into it again, because that was years ago, and it’s a different world today.
GNU/Linux: distributing dependencies and architecture compatibilities
I develop and test the game on my Ubuntu GNU/Linux system, and the main thing to worry about there is that I can distribute the game and have it work out of the box on other distributions.
My game uses libSDL2 and related libraries. While I installed them on my system using my package manager, I can’t assume that my customers will have them installed as well.
Quite frankly, rather than worry about an installer to put everything in the correct locations on someone’s system, I think providing a basic tarball might be fine. Rather than provide .deb or .rpm or customer shell installers for each type of system, and then worrying about following the correct Linux Filesystem Hierarchy Standard, you allow the player to put the game in the directory of their choosing, extract it, and play.
But then I need to worry about how the tell the system to load the libraries. Running an application on Windows, the system generally looks in the local directory for libraries to depend upon. Unfortunately, Linux-based systems don’t do so, and while there is a way to point it towards your libraries using the LD_LIBRARY_PATH environment variable, I also know that it is frowned upon to do so due to the security and compatibility issues it can introduce.
On the other hand, many popular commercial games on my system do just that. For instance, looking at the directory for Don’t Starve, I see:
The fact that it is in this shell script wrapper is better than the original concern of changing the default environment variable in a more or less permanent way, which can cause version conflicts and such. It’s your program. You know what it needs, and any other applications that run will not be affected.
Still, supposedly the better way is to tell your binary at build time where to look, which isn’t very difficult. It requires -rpath=\$ORIGIN/[directory where you put your libs]. $ORIGIN expands into the directory that your binary is located.
So if the extracted tarball would have the following structure:
– foo-bin
– libs
– libfoo.so
– libbar.so
Then I would build foo-bin with -rpath=$ORIGIN/libs.
Of course, now foo-bin MUST be in the same directory as libs, but in practice, it’s fine. When was the last time you moved parts of a game’s files to different relative locations and expected it to continue to work?
I’m sure there’s issues with this approach as well, but with these two approaches, there’s plenty of precedent.
The only unknown I have is dealing with 32-bit vs 64-bit systems. Ubuntu has multiarch support, but I’ve seen comments on forums about people not being able to run an application due to architecture issues.
Don’t Starve distributes separate 64-bit and 32-bit builds. FTL, on the other hand, distributed both the 64-bit and 32-bit binaries and libraries together, and using a shell script, it determined which platform you were on at runtime to point LD_LIBRARY_PATH to the appropriate directory.
And other games distribute all desktop platforms together in one file, so if you bought the game, you bought it for Windows and Linux and Mac, whichever one you wish to play on. I like this option, especially since I hate the idea that I have to pay for a game twice in order to play on two different platforms.
In 2009, when I was running my own indie game development business full-time, I thought I would invest in my own education and paid for the premium subscription content of a popular Internet business and marketing podcast.
I thought that I would get through the material quickly as I had the freedom to dedicate all of my time to it. Then I could cancel it after one month of payments. Maybe two.
I ended up sticking around for much longer, and I can’t say it wasn’t useful, but the entire time I felt frustrated by the format. I can’t quickly peruse audio and video, and that was what most of the content consisted of. And as for the content itself, I felt like I had to get through lots of “witty” banter between the hosts to get to the gold nuggets, if there were any.
But I can’t complain too much about the content. I was clearly not their target customer. It was meant for people who might have no experience with software or computers, so it might work for other people just fine.
There were forums populated with such apparently satisfied customers who wanted to learn what it takes to run a successful business, and some made some good success based on applying what they learned.
Except it seemed like almost each and every one of them was making their success by taking what they learned from the premium subscription and repackaging and selling it to others in their respective niches.
One person was doing OK with selling on eBay before she took up the lessons, and by the end of it, she was making a good living selling an info product on how to run a successful Internet business with basically all of the same lessons from this premium subscription. You know, but geared towards eBay.
And she was just one example. It seemed like no one wanted to apply the lessons to run their own existing business more effectively. Instead, they seemed to have stopped doing whatever they were struggling with before and started their new business as Internet marketing experts based on what they learned from a premium subscription information product about being an Internet marketing expert.
To be fair, in the land of the blind, the one-eyed man is king. To the right audience, these people WERE experts. They now knew something that most other people didn’t. I’m not a C++ expert when compared to the people who speak at CppCon, but I am expert enough when it comes to where I am employed, and especially when it comes to my family who are “not computer people” at all.
But the thing that bothered me about the other subscribers to the premium subscription was that their expertise wasn’t really theirs. They learned some tricks and techniques from somewhere else, but they didn’t apply it to their own businesses. So what do they really know?
At least I spend a significant amount of time actually using my expertise, so when someone asks me something about C++, I have some real authority and experience to back it up. They basically turned around and shoveled their new marketing know-how to the ignorant people who were willing to pay them for the information. “If you want to be successful, uh, here’s what these other guys told me.”
And boom. Now not only are they experts, but they’re commercially successful experts with a paying audience, which only grows their authority.
The personal development field sometimes has a bad reputation in this regard. Some people are great successes who might be trying to share some insight into how they became great successes.
But other so-called successful people really only seemed to have become a success when they started writing books and giving speeches telling other people how to be successful.
I subscribe to Sunday Dispatches by Paul Jarvis, and in this past Sunday’s newsletter he talked about the “advice gold rush”. Apparently seven years later the problem I described above has only gotten worse, and in many industries. Jarvis linked to a colorfully-titled article complaining about it called The Creative World’s Bullshit Industrial Complex:
Being industry famous should be the result of some contribution to the world that the industry respects and wishes to learn from. Or insights unique and useful that it genuinely makes people’s lives better.
Increasingly “creative coaches” and people with “keynote speaker” in their Twitter bios are making their quest to earn authority a higher priority than the very reason they got into this in the first place. Fueling the Complex is alluring catnip that feels like you’re advancing your career the same way answering a bunch of emails just feels productive.
I’m not innocent. I know I’ve done my share of contributing to the Complex on this blog, especially early on. I shared advice as if I had some experience actually applying that advice in my own work, and in reality I was just shoveling someone else’ manure.
But my most satisfying and gratifying work is when I wrote about my own hard-won experiences. When I write about my own failures no matter how huge or my own successes no matter how minor, they’re mine to share. I can say I know what I’m talking about and have some small chance that I’m right.
When I have those experiences, often that’s when I truly understand what someone else was saying all along. That’s when I can make the associations between someone’s advice and my reality.
GDC 2016 is over, and it featured talks by successful game developers sharing what they know.
It’s always tempting to find out what successful people do. The hope is that we can glean some insight into what WE specifically can do to be successful as well.
But what if we’re wrong? What if what they think they did to be successful and what we think they did to be successful is exactly what everyone else who failed did as well?
How would you know?
Most failures aren’t around anymore to share their story.
And so we risk having survivorship bias. We ignore the information we can’t see in favor of the information we can see, and then we make conclusions based on that part of the puzzle.
Steve Jobs, Bill Gates, and Michael Dell all dropped out of college and built huge, world-impacting businesses. So does that mean you should drop out of college and start a business?
Before you make that decision, you should probably ask all the college dropouts who didn’t create huge businesses despite trying. Unfortunately, it’s hard to find them, and you’re unlikely to see read a book or even a blog post about their experiences.
Or if you talk to a financial guru who says, “Look at these stock picks I have! If you look at them, they’ve beaten the market by 12% for the last five years!” What this guru isn’t saying is, “And during those five years, I’ve been removing the poorly-performing picks I’ve also made, which would skew the results negatively if you saw them.”
Or when people talk about music today being terrible compared to music of the past. If you turn on the Oldies station, you’ll hear great music from the 50s, 60s, 70s, and now the 80s and 90s (oh, geez, I’m old), but you won’t hear all of the terrible stuff that was put out during that same period of time.
Why? Because it was terrible, so only the best music survives for the future to love.
The book Good to Great by Jim Collins aimed to find out what were the universal distinguishing characteristics that cause a company to become consistently successful over a 15 year period.
Since the book was published in 2001, many of the companies highlighted got into trouble. Maybe they were great once, but clearly the “universal distinguishing characteristics” weren’t so universal.
But it doesn’t say much about that one coin, does it? There are no insights into the coin’s design you can make. There is nothing about the way it was minted that is unique. All of the coins had a chance of flipping all heads, and this one just happened to be the one to do it.
And yet a lot of business success books are written this way. They look at successful businesses in hindsight, and then the authors try to identify the qualities of those lucky coins that resulted in them being so great, and they often ignore the rest which might be built and run similarly.
That isn’t to say that I think business success is a 50/50 flip of a coin. And to be clear, I think it does help to identify strong successes and see what we can learn from them.
But if we ignore the failures, then we don’t know if what we see successful companies doing is really so different and insightful.
Also, keep in mind that those who fail rarely get paid for advice on how not to fail, which is too bad because despite how it may seem, success boils down to serially avoiding catastrophic failure while routinely absorbing manageable damage.
I gave a talk at Startup City Des Moines in 2014 about lessons learned having failed with running my own indie game development business full-time. I was surprised when one of my friends who worked there kept thanking me. She said that it’s very rare for anyone who has failed to share their experience, which is too bad because it would be so helpful if more did.
So if you failed, don’t shy away or be embarrassed about it. Let us know about it. Tell us what you learned.
Provide more data so that survivorship bias isn’t as easy for us to succumb to.
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.
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.
It was a stick figure in 2005. I actually like the look of the tiles. Eventually I created a business man sprite.
