Note: I wrote a significant amount of this post in 2011, back when I was actively working on Stop That Hero!, and enough still resonates today that I decided to publish it.
It’s only in the last few years that I’ve started to appreciate the importance of software architecture, and especially as I write the game engine for “Stop That Hero!” Before “STH!”, I haven’t had much experience with writing entire programs from scratch. Most of the code I’ve written professionally fit into an existing framework or architecture, so high level architectural work wasn’t something I had to worry about in my day-to-day work.
Beginner Programmer Woes
When I first learned how to program, I was focused on getting the syntax correct. Programs, even if they were completely original and not copied out of a book or magazine, were simple. More complex programs usually didn’t get finished before I lost interest. Any non-trivial programs that were successfully completed were the epitome of what we in the biz call “spaghetti code,” which means I was lucky to get something working at all. See my Pac-man clone in QBasic as an example of what teaching yourself how to program can result in.
Then I got to college, and I learned C++, and concepts such as recursion and stacks and objects. I was still using QBasic as a hobby, and my new code was definitely cleaner, but I struggled with putting everything together in a cohesive whole. And programming on a modern OS required a message pump, which meant I had to change the way I did things drastically. You couldn’t add empty loops if you needed a delay anymore.
Ok, so most likely, you’ve been there before, too. My story above isn’t unique. Lots of programmers went from DOS to a multitasking OS. The thing is, I think I fell behind in terms of learning how to program in this new world order. When I stopped using QBasic, I didn’t write a lot of C++ code outside of class requirements until I nearly had my degree. It turned out that I learned C++ wrong at first, which is why I didn’t enjoy programming in it as much as I did with QBasic. Once I read Accelerated C++ by Koenig and Moo, it made a lot more sense and was a joy to work with. That book is a great way to learn C++ for a beginner. Even though C++11 has since been released, I still highly recommend the book today.
Program Design Is Hard
But it still didn’t change the fact that larger applications were hard to make. If I knew what class or function was needed, I could write the code just fine. It was determining what class or function was needed that was the hard part. Or to put it another way, I struggled with “where should this code live” questions. Basically, software architecture was hard, and I didn’t know it was even a thing to be concerned about. Heck, years ago, I was concerned with how to put together a basic game loop. Solving that problem means I had everything I needed, right?
What I knew about game engines is based on what I read. Countless books and articles broke down the anatomy of a game engine by talking about its subsystems: audio, video, input, networking, etc. At the time, I believed this subsystem knowledge was enough to make a game. If you had a way to render to a screen and detect input, you had the bare basics to make a game. It’s just a matter of implementation, right?
Since I taught myself QBasic, and my first projects we isolated endeavors, I thought I knew how to put a piece of software together. I was able to put together an entire game, so how hard could it be? After all, they don’t give 70% reviews to just any QBasic games, right? I’ve even managed to put together complete Ludum Dare entries.
Why Is Everyone Else So Much Faster?
But I was also aware that some of the other Ludum Dare participants were able to make their entries way more impressive within hours of starting than my games end up by the deadline. Ludum Dare was historically a “write your game from scratch” competition, so it’s not as if they had full game engines available (although that’s changed with Unity entries). What was I missing?
Well, experience, for one. Some of those impressive entries are made by people who have been making games for way longer than I have. Even if we started at the same time, I haven’t been working on as many games as they have. They might have worked in the game industry and so know how to make games on a deadline. Even if they didn’t have game dev experience, they might have worked on financial software. Either way, they’ve likely written a lot more code than I have, so putting the software together to implement their game designs is possibly second nature.
Another thing people seem to have is boiler-plate code, such as code for menus, buttons, and sprites. XNA users have a huge advantage here, and Unity users are practically cheating. As I run and deploy to GNU/Linux, neither option is available to me, and since I work in 2D, there aren’t a lot of game engines available. A lot of the libraries that I could piece together also don’t fit my needs. Either they do things in a way I don’t want to do (GUIchan versus IMGUI), or they are not cross-platform. Instead, since my first Ludum Dare, I’ve written a lot of boilerplate code as I needed it. Each competition, I created more and more base code to leverage for the next project.
But I was oblivious to some of the fundamental architecture needs of a game engine, and so I still struggled to put together a finished, playable game in 48 hours. After all, the subsystems were everything. Just tie input to what’s happening in the game, and make sure the player can see feedback on the screen. Why is this so hard?
Learning Software Architecture
Most people will tell you to get a copy of the book Design Patterns by the Gang of Four. It’s a great book and features a number of patterns. Now, if you want to refresh yourself on what a pattern entails, it’s fine, but it isn’t great for learning about them in the first place.
I found Head First Design Patterns to be a great, easy-to-read introduction to major patterns.
But patterns knowledge isn’t enough to know how to organize a major software project. If I want to be able to provide a single interface to a bunch of disparate pieces of code, the Facade pattern is what I need. But what about determining that I need a single interface to those pieces of code in the first place?
And Test-Driven Development is supposed to be about code design. By writing tests, you already have a user of the code you’re writing, so you know how to design the functions and interfaces. TDD can help you design a single class, but it’s not going to help you drive the design of a full application. More and more, I realize that my lack of experience with writing larger applications is making my TDD efforts more of a struggle than they need to be. Uncle Bob Martin wrote about this topic in TDD Triage (the link has since died):
Here’s the bottom line. You cannot derive a complete architecture with TDD. TDD can inform some of your architectural decisions, but you cannot begin a project without an architectural vision. So some up front architecture is necessary. One of the most important up front architectural activities is deciding which architectural elements can be deferred and which cannot.
So patterns and TDD aren’t enough. Some architecture decisions are necessary, and I hadn’t made any. No wonder I had trouble in the past!
Ok, it’s 2014 again. Since 2011 when I first wrote this post, I’ve learned quite a bit about software architecture and designing software. Experience is one of the greatest teachers.
I’ve learned to focus on the data flow. Where does data come from, and where is it heading? I’ve learned to focus on what large pieces I need and worry about how to hook them up to each other later. I’ve learned how to separate the GUI from the internals, and that each has their own massive design decisions to worry about. I’ve learned that software architecture is less about the overall design of a software project as much as it is about the constraints on it.
I also learned that software architecture concerns don’t come into play as much if you are hacking together quick prototypes, but addressing the major software constraints can be huge if you intend to have a reusable set of code to use from project to project.
I’ll write more about the specifics in a later post, but it seemed important to document to struggle, especially as I did not identify my lack of knowledge about software architecture as an issue at first.
If you’re an indie developer, what were your major insights into software architecture? Do it come into play for you, or do you find that it isn’t anything to be concerned about in your day to day?
During the last half of 2013, Ben W. Savage conducted The Indie Interview Series “to inspire those who are considering game development” as well as those game developers looking for practical advice.
He asked the same series of questions of everyone, and prominent indies such as Christer “McFunkypants” Kaitila and Chevy Ray “Chevy Ray” Johnston spent anywhere from five minutes to a quarter of an hour answering. The topics ranged from how to get started in the game industry to who were major influences and what are major mistakes new developers make.
Adam “Atomic” Saltsman, creator of Candabalt, suggests that taking too big of a bite is a common problem. “Learning how to do a project is its own discipline … Start small, learn about the process, and then refine. That’s the key.” Nina “[insert nickname here]” Freeman of Code Liberation Foundation agrees in her own answer to the same question, repeating “simple prototypes, simple prototypes, simple prototypes” and suggests working in steps.
These are bite-sized nuggets of wisdom, and I wish there were more.
What’s your favorite interview? Did any of the answers resonate with you?
(Photo: https://www.flickr.com/photos/39781145@N00/254759786 | CC BY 2.0)
Fom April 11th through the 13th, I’ll be at the Extreme Leadership Summit in Chicago.
Last year, I met Steve Farber, author of The Radical Leap and The Radical Edge and founder of the Extreme Leadership Institute.
His books are novels about the nature of leadership and what’s needed from it in today’s world. According to Farber, LEAP stands for:
Being a leader “is intensely personal and intrinsically scary” so you have to love what you do and love the process of making change, even if you don’t know how things are going to turn out. “Do what you love in the service of people who love what you do.”
Energy comes from having a good purpose. Without one, you are likely to falter just when you need the energy most.
As a leader, you need to inspire audacity. Are you planning on changing the world, or the world of your customers? If not, are you holding back your potential?
And you need to walk your talk. Do what you say you will do.
Farber isn’t a fan of passive conferences with a lot of fluff that make you feel good but leave you the same person as when you came in.
It’s described as a “hands-on, entertaining, productive, and interactive experience where you’ll learn, develop, and apply profound leadership practices to your current work and life opportunities.”
I’ll be there. Will you be there? If so, let’s meet up!
Sometime back, I read the article How to Be Prolific: Guidelines For Getting It Done From Joss Whedon.
The interview was published shortly after Whedon’s Much Ado About Nothing, filmed while The Avengers was still in post-production, hit theaters. Being able to put together a second film on the side while working on a major Hollywood production is impressive enough. Whedon is also active in comics and television shows. The guy is just everywhere.
The main points, from what I gathered:
- Get specific with what you’re trying to accomplish
- Reward yourself for doing even one small thing
- Get exposure to diverse ideas
- Ensure your friendships support your purpose
- Don’t make excuses because there aren’t any
You can read the full article to get the meat of each of those things.
What I think linked everything, however, was his focus on being purposeful. If you don’t know what you’re trying to accomplish, it is easy to let things happen to you.
That paragraph might not sound mind-blowing. Stephen Covey wrote about keeping the end in mind in The Seven Habits of Highly Creative People decades ago. Being results-oriented isn’t a new idea.
But Whedon brings it to everything: his process, his downtime, his friendships, his life.
As a part-time indie game developer, I could say, “This evening is dedicated to game development”, and then find at the end of a few hours that I’ve gotten nowhere. On the other hand, if I task myself with coming up with an interesting core mechanic or introducing a new character, it’s specific and focused work that by its nature gets done. It’s about focusing on results, no matter how small, on your way to get the larger result, no matter how big.
I could spend each night vegging out in front of the TV, or I could schedule time to go to game developer meetups, conferences, seminars, and panels. I could read books, play boardgames, or write blog posts. Or if I am going to watch TV, it should be for the higher purpose of spending time with my wife, or learning about ancient 90s culture (seriously, Frasier is amazing), or something besides merely not being creative enough or motivated enough to think about doing something else.
I could play video games to pass the time, or I could play them to critically analyze the hell out of them for the purpose of understanding game design better. Even better, I could play the heck out of games that are both incredibly similar and incredibly different from what I want to create right now to get a sense of what’s been done and what’s possible.
I knew someone who went to the library after his day job to work on games for four hours a night every night. Over the course of a few years, he went from knowing nothing about game development to being able to publish a number of games in a short span of time. That developer knew what he wanted.
The older I get, the more I realize how precious my time is. Time is the only thing we really have to invest in anything.
If you want to be more prolific, if you want to create well-received works, stop and look at how you spend your time. Is it on purpose? Are you taking responsibility for what you are doing with your limited time, or are you going with the flow, allowing the agenda of other people to exert more force in your life than your own choices?
Doing creative work, you will struggle at times. It’s not going to be enough to say you’re making what interests you. You need that higher purpose to get you through the game developer equivalent of writer’s block. You’ll need to know the results you’re trying to achieve when you’ve scrapped months of work because you find it doesn’t actually work.
And frankly, you’ll need it when you look back and wonder what you’ve really accomplished. Did you do what you set out to do, or did you merely do?
The other day, Dan Cook tweeted about this concept:
It’s fine to have a list of tasks to accomplish for your current project. After all, it makes sense to break down the tasks and get it done.
But did you similarly think about the point of your current project? How does it fit into your vision for the future?
Last year, Notch posted about the news that broke when people found out he wasn’t working on 0x10c anymore. In So That’s What I’m Going to Do:
What I hadn’t considered was that a lot more people cared about my games now. People got incredibly excited, and the pressure of suddenly having people care if the game got made or not started zapping the fun out of the project. I spent a lot of time thinking about if I even wanted to make games any more.
And then there was Dong Nguyen, creator of Flappy Bird. The game was making him $50,000 per day, and he pulled it down. Why? According to this Rolling Stone interview, it was partly because he felt responsibility for the people who blame the game for losing their jobs or becoming isolated from their families.
In both cases, what did these games mean for the developers besides interesting experiments?
Or put it another way: when you think of a company like Mojang, what do you think of besides “they made Minecraft”? When the company publishes a new game, what can you expect? I’m not sure, because there doesn’t seem to be a larger purpose to the organization. It’s a company that happens to have a major hit to fund it, but it isn’t clear what principles or values it has that dictate what they do next other than “This seems interesting today”.
There’s nothing wrong with it, and it is great that they have the freedom to explore whatever they want, but compare it to a company such as Toca Boca, creator of Toca Hair Salon and other fascinating children’s games, including one that seems very similar to Minecraft:
Toca Boca is a play studio that makes digital toys for kids. We think playing and having fun is the best way to learn about the world. Therefore we make digital toys and games that help stimulate the imagination, and that you can play together with your kids. Best of all – we do it in a safe way without advertising or in-app purchases.
If you hear that Toca Boca is publishing a new game, you know in general what you’re going to get. They have a purpose, and they are organizing everything towards that purpose. You won’t see them publishing a very eclectic collection of games. They won’t be exploring survival horror or creating the next major FPS because they would be distractions from their larger purpose.
What you achieve in your life is going to be a direct result of what you do today. At the micro level, you have the tasks you’ve identified in front of you for a given project, but at the macro level, you choose the project to work on in the first place.
Or I suppose another way to say it is that if you execute everything perfectly but you did the wrong thing, you’ve wasted a colossal amount of time.
What’s your common thread that ties everything together? If you want to be prolific, it’s not enough to churn out random work. Having that vision about what you really want to accomplish is incredibly vital.
Do you have one?
(Photo: https://www.flickr.com/photos/revstan/5205092926 | CC BY 2.0)
Last month I came across a GitHub project which is primarily a list of free programming books.
Originally a clone of a StackOverflow listing, it has been updated with dead links removed and is now collaborative. If you know if any freely available programming books out there, you can submit your own updates.
It comes in multiple non-programming languages, too. B-)
Besides the language-specific and math books, there are books on networking, licensing, open source culture, operating systems, and security.
Some books are about professional development. Others are about architecture.
But it’s amazing how many books there happen to be out there, freely available.
The downside? There are two I can think of.
One, many of these resources are somewhat older. To be fair, not all of them are. Still, enough of them are that you sometimes feel like you’re reading a history of computing, which may not be a bad thing if you’re curious about how things have evolved to today’s state of the art.
Two, most of these freely available books require you to be connected to the Internet to peruse. I wish more were available in PDF or epub format, but most are much like Eric S. Raymond’s The Cathedral and the Bazaar: there are a series of web pages to read, but there is no ebook there.
Now, I purchased the hardcopy version of Cathedral back when it was first released, but that’s besides the point. Many other resources linked to from this book list don’t have an ebook version.
Some of the links to free books are to PDFs and are labeled as such.
Others do have either bound books forms or ebook formats, but if you want it, you need to pay. It’s basically shareware applied to books. You get to to try out the free version, and if you like it enough, you can pay for the full version to read on your tablet at your leisure. And some of these links show more aggressive marketing than others, so there’s something else to learn there if you pay attention. B-)
What’s your favorite free book from this list?