95% Off for Game Development Course Bundle

A colleague told me about a deal he found online: 95% off for a bundle of game development courses.

After learning how to replicate Flappy Bird and Candy Crush, this bundle will give you an education in developing for both Android and iOS, a beginner’s guide to HTML5 game development, and a quick-start guide to creating a game with Stencyl.

Some people are turned off by the focus on essentially cloning two very popular games, but if you think about it, artists learn to create great paintings only after they all learn how to paint bowls of fruit.

I don’t plan on getting the courses myself, but then I’m not starting from scratch. I’ve made games, and I have in fact worked with Stencyl, and many of the topics I see covered are things I can look up on my own, such as how to sell apps.

Still, the idea of focused courses on topics related to making games that look very much like “real” games and even learning how to sell them is appealing.

But what do you think? Is it a good deal for beginners?

Learning Game Software Architecture

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!

Conclusion

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?

The Indie Interview Series

Interview recording equipment

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)

November #1GAM Entry: Raking Leaves

November’s One Game a Month entry is uncreatively-named Raking Leaves, a leaf raking simulator chock full of leaf-raking action!

Download Raking Leaves for Linux 64-bit (1.2 MB tar.gz file)

The object of the game is to rake all of the leaves into a single pile. The wind will blow the leaves around, however, and if you lose too many leaves off of your lawn, the game is over.

I had a lot going on this month, and so I didn’t dedicate a lot of time to making a game. Still, I wanted to make something for #1GAM. What could I make?

I recently bought a house, and with home ownership comes the oh-so-fun task of raking leaves. I decided to make a game out of that experience, and raking leaves is usually done in the Fall, which goes along with the optional theme of “Change”, so it was a perfect concept.

I started out making leaves and randomly throwing them about the yard.

November #1GAM

I then added a rake, which replaces the mouse cursor:

November #1GAM

I wanted to capture the frustration of raking leaves, and so when you click and move the rake, the leaves will move, albeit a bit slower than the rake. This means you have to go rake the same leaves over and over to move them a long distance. I was pleased that it was working as well as I had planned.

November #1GAM

I had some funny bugs, such as this accident which features the level resetting over and over, except it wouldn’t reset the number of leaves but merely add to them. It looks like a giant set of orange hedges.

November #1GAM

Another funny moment was after I added wind. I wanted early levels be less windy, while later levels would get more wind. Here is what it looks like to rake in a hurricane:

November #1GAM

Wind affects leaves in a radius around it, and the farther away the leaves are from the center of the wind, the less of an impact the wind will have. It works very well, but out of curiosity, I set the level to 1,100, which has over 20,000 leaves in it and has winds every second. It resulted in some cool visual effects, as you can see in this video:

Eventually I think I achieved a good balance, complete with a scoring system to let you know how well you’ve done compared to your best raking.

November #1GAM

Considering I worked less than seven hours on this project, I’m pleased with what I came up with. I had plans for rocks, bushes, trees, and other obstacles, as well as a child running around jumping into your pile and scattering the leaves. Having sound would help, too, but for now, I think I’ve got one of the best games about raking leaves out there.

October #1GAM Entry: Candypreneur

October’s One Game a Month entry is Candypreneur, a candy tycoon game inspired by the classic Apple II game Lemonade Stand.

Download Candypreneur for Linux 64-bit (432 kb tar.gz file)

I wish I had dedicated more time to this project. I had surgery and wasn’t able to work on it while I recuperated, and when I was able to spend time on it, I squandered it.

Still, I learned some things, such as that a best practice for representing money in software is by using integer values to represent cents rather than using doubles to represent dollars.

October #1GAM

October #1GAM

I wish I had time to theme it up a bit more. Some candy icons would have helped.

Also, the economics model is too simple. I managed to add random events that can impact the number of prospective customers, which you can sometimes prepare for if you check the reports screen for the upcoming month.

For this project, I had a much more complex simulation in mind. I wanted competitors, suppliers, customer moods, storefronts, candy ingredients, and research & development.

Even when I scaled down, I still didn’t put in things such as the rising cost of advertising or the ability to take out and pay back bank loans.

I’d say this is probably the project I’m least happiest with. I feel like there isn’t enough there, although some last minute additions make it less certain you’ll sell that candy.

September #1GAM: A Puzzle Game

For September’s One Game a Month project, I wanted to try to use the optional theme: hexagons.

I toyed with the idea of making a turn-based strategy game involving a hex map, but more and more I liked the idea of a hexagon-based puzzle game.

Long ago, I thought of a game involving hexagons that you can trap as they fell down shafts. The idea was that you controlled whether they continued down or got stuck at some point, but I never fleshed it out.

So I’ve been writing down ideas. Should the puzzle area be a grid that just happens to have hexagons? Do I make a hexagonal play area?

More importantly, what is the player doing in the play area? Do I make a match-3? I kind of liked the trapping mechanic, but I couldn’t think of a good way to make it fun.

Then I looked at the calendar and realized that over a week has gone by. So I thought I better steal some game play rather than try to create my own.

I recalled playing a QBasic game by Oren Bartal called Ultimate Super Stack. The point of the game was to trap stars between two objects, and I remember finding it very compelling. Maybe I can make a hexagon-based version of it.

I realized that there was a lot to the game, and I thought back to simpler puzzle games, such as Yoshi for the NES.

So I decided to try to mimic that game instead.

September #1GAM

So far, I have four platforms in an empty play area, with a switcher at the bottom.

Eventually, I will add dropping objects, most likely shapes such as circles, triangles, and squares. If two objects match on top of each other, they’ll disappear. If a hexagon’s bottom piece appears, then it’s top piece can close it, along with any objects trapped inside of it.

The player will be able to move the switcher to one of three positions to swap the platforms and any objects sitting on top of them.

It’s a simple game, but I don’t anticipate having a lot of time to create it this month, what with me going to ISVCon 2013. We’ll see how it turns out.

Aim for Purposeful Artistry, or “Just Be Games”?

Jay Barnson recently wrote Art. Or Not. He drew some parallels between science fiction and indie games. He talked about how older pulp fiction was how many great authors got their start, and some of their short stories became culturally relevant, and some of the authors became bigger names.

If I understand his argument correctly, he believes that they created art without specifically trying to do so, that the designation of artistry came later, after the authors tried to create good reads for the buying public.

The point is… many of the “classics” – the “masterpieces” that are held in such high regard today were simply yarns spun to pay the rent by these authors. Between a combination of good writing, good editing, a story that resonated with the audience, and possibly a healthy dose of good luck, these stories and serialized novels went on to become standards of excellence in their respective genres. The authors certainly did their best to make a great story, but I doubt they set forth with a prevailing desire to create “Art.”

Now, he separates “art” from capital-A “Art” without explaining too much about what he means, but I think it is safe to say that there’s a judgment call being made here on what he thinks counts as legitimate art versus art made out as more important than it really is.

In any case, while Barnson says he isn’t opposed to games having deeper meaning, he is concerned that indies are aiming to make games that are less like games and more like other, more traditionally accepted art as an attempt to make games relevant to critics, such as the late Roger Ebert, who is infamous for declaring that games can never be an art form unless they become more like movies.

Creating great art is difficult, no matter what the medium, but I don’t believe there are any problems with people trying to create art out of game mechanics.

I think one of the things that is difficult as an indie game developer trying to make culturally important works is that there is a perception that games are supposed to be fun, time-wasting playthings for children. To purposely make games that aren’t meant to be fun is hard for a lot of people to get their heads around. Games that aren’t fun sound like bad games to many players.

If you expect to play a game like Brenda Romero’s Train and think you’ll have the type of entertaining experience as when playing Ticket to Ride, you are going to be incredibly disappointed.

But the idea that video games can be more than merely fun is not a new one. Chris Crawford once gave a GDC talk about how, at a higher abstraction, entertainment is what games should aspire to. Fun is just one way to entertain.

As for aiming for art as opposed to letting “games be games”, why does it matter what purpose someone has for creating a game? Why does it matter who they try to please? If you’re an indie, who do you have to answer to but yourself?

F. Scott Fitzgerald was once quoted as saying “An author ought to write for the youth of his own generation, the critics of the next, and the schoolmasters of ever afterward.” He wasn’t writing to make money and leaving the question of his artistry to others.

So what about the idea that you don’t purposely try to create art, that it merely become so later? I don’t think it is necessarily the best way to go if you want to use the medium of games to create art. And some people specifically want to use the medium of games to create art. Or Art.

I’m with Jay on the idea that games are their own medium, that you don’t have to try to make them seem like other types of art. Games have their own strengths, and ignoring them would be much like how early filmmakers tried to record live theatre productions and not realizing how much more they could aspire to.

If you’re trying to make a commercially successful game, go ahead and try to please people, specifically your customers. But in most other endeavors, trying to please other people is a sure-fire way to kill what you’re trying to do with compromises.

If the creator of a game designs it to be art, it’s hard for me to argue that they are not trying to please their true audience.

August #1GAM Entry: Eye Contact

This month’s One Game a Month entry is probably the one I put the least effort toward. I worked around 7 hours on it.

Download Eye Contact for Linux 64-bit (362 kb tar.gz file)

August was a hectic month for me. My wife and I closed on a new house, which meant that most of my “spare” time was spent preparing the house and getting ready to move.

The theme for August was “Philosophy”, and I had originally envisioned a game about making eye contact with strangers.

I wanted to have a very dark room, so you could only see yourself and your immediate surroundings. You can tell where the other people are because their eyes would be the only visible feature, similar to what cartoons did to show people walking around in dark rooms.

I wanted the eyes to be incredibly expressive. They should communicate attraction, danger, and sadness.

I thought that the goal of the game would be for the player to navigate a room, avoiding eye contact with dangerous and creepy strangers while trying to make eye contact with a potential romantic partner.

As you got closer to other people, you would see features besides their eyes: skin color, nose shapes, weight, etc.

And these other features wouldn’t matter at all.

That is, you might find that the potential romantic partner is not someone you might normally be attracted to in real life.

But with even less time to work on the game than normal, I had to scrap most of this design. I kept they eye contact idea, though, and I am pleased with what I came up with.

August #1GAM

I started with an eye that the player controlled, but eventually I realized that for the game I was creating, there was no reason for the player to be an eyeball. It was too confusing when you couldn’t easily tell your character apart.

August #1GAM

I made the eyeball a “guardian”, rotating around while the player tried to pick up squares in the area. When the guardian spotted the player, it would freeze for a second, then shoot towards the location. If the player touched a guardian, it was game over.

To add challenge, when a guardian shoots off toward the player, it would also leave behind a clone, so now there were two guardians looking for the player.

As you can see above, the game got exponentially difficult.

So I made one more change:

August #1GAM

August #1GAM

When smaller guardians touched, they combined into a larger guardian which constantly chased the player. This change solved the issue of too many multiplying guardians while also providing a different challenge to the player.

August #1GAM

Finally, I made the pick up item look significantly different. A white box in a sea of eyeballs didn’t stand out enough, so I made it the same color as the player and also pulsated it. The animation made it stand out nicely.

I would have liked to have added a third type of challenging guardian, or added some way for the player to remove guardians. I would have also added sound effects and particle effects, but I ran out of time.

Despite not having a lot of time to dedicate to it, I really like Eye Contact. It’s one of my favorite #1GAM entries. There is something disconcerting about all of these eyes looking for you.

July #1GAM Entry: Shipwrecked

I’ve been working on Shipwrecked since June. Even then I realized that it was very ambitious, but rather that continue to work on it throughout the rest of the year, I’m going to call what I have done and move on.

Download Shipwrecked for Linux 64-bit (562 kb tar.gz file)

It’s amazing what a deadline can do to productivity, though. In the last few days of the month, I managed to add the ability to create objects, sleep, and go fishing.

I created a number of new objects, including sharp rocks, fishing poles, and opened coconuts.

July #1GAM

The crafting screen tells you what you can make and what you need in order to make it.

July #1GAM

Fishing doesn’t work quite as well as I’d like.

July #1GAM

It’s too easy! Fish seem to sail onto shore for you, and I would rather it be more difficult, requiring patience and time.

If I had more time to develop this game, I know of a number of things I wanted to add:

  • Daily stamina, which reduces as you take actions, such as walking with heavy items or swimming, and requires rest to recover. Right now, sleeping simply fast-forwards time.
  • Food spoilage.
  • Encumbrance. I added weights to the objects, but the player can still carry an unlimited amount. I would like it if swimming was more difficult with too many items, for instance, so drowning is more likely.
  • Disease.
  • Weather, such as extreme heat, rain, and bad storms.
  • Other entities, such as sharks to pose as water hazards and crabs to be dangerous food sources.
  • Injuries.
  • Thirst.
  • Caves to explore.
  • Debris, such as crates floating to shore from presumably sunk ships. Suddenly life on the island is more interesting when combing the beach results in finding bottles of wine or magazines.
  • Morale and sanity. I had a vision of the player going insane the longer he/she survives. Insanity would manifest as coconuts being the heads of people walking around the island, for instance, or objects such as rocks suddenly being seen as edible.

I took cues from Harvest Moon and NetHack primarily, plus I always liked the book Robinson Crusoe.

I learned that surviving on a desert island is a very common theme in games. For example, Stranded by Unreal Software was released in 2003.

Most recently there is Wayward, and when I learned of it, I almost lost motivation to continue work. Here was a game that was a very in-depth, turn-based version of what I wanted to make, although I had no intentions of adding bears and giant spiders.

I also felt bad because I realized that I needed to provide a way to create objects, and adding a crafting element to the game made me feel like I was copying the big trend since Minecraft became famous. It seems as if every aspiring indie game developer is making a procedurally-generated world in which you have to use nearby resources to survive.

As for this game, despite working on it for almost 50 hours across two months, I’m afraid it doesn’t have a lot of depth. The island has its objects randomly generated within it, but it’s not a very interesting algorithm. I would have liked to have created an expansive island to explore, with jungles and cliffs, but for now, the island is populated with random trees, boulders, shells, branches (where are the trees that made those?), and empty nets.

Of course, it’s only 50 hours. I’m sure if I worked on it full time in a given month, I could have accomplished much more, and if I dedicate multiple months to working on it, I could have something richer.

So on that note, I got quite a bit accomplished for this project. B-)

What I learned, however, is that even if I have plans for a lot of inter-dependent systems in a game, I should implement one to completion before moving on to another. It took way too long after I coded in a system for hunger and starvation for the player to have a way to avoid such a death, for instance. If I added hunger, I should have added food right away. In a similar way, I created a lean-to because I had plans for a need for shelter, but I never did put in any reason for a shelter to exist. A number of items become merely ornamental as a result.

All that said, I really enjoyed making this project. I hope I come back to it in the future and flesh it out more fully.

July #1GAM: A Hundred Thousand Bottles Washed Up On the Shore

First, a reminder about my Stop That Hero! Birthday Sale that’s running all this week.

Get 40% off of my strategy game that puts you in the role of the villain by using coupon code BIRTHDAY2013 at http://www.StopThatHero.com to help me celebrate my birthday tomorrow!

Next, you can finally eat something in Shipwrecked, my July One Game a Month project.

While the game has let you starve to death slowly for some time, there’s been no way to avoid it until now.

I had a vision for an entire inventory system to manage, but in the interests of finishing this project, I’ve decided that pressing Tab is enough to cycle through any items you are carrying.

If you have an edible object in your inventory, and it is the currently equipped item, you can now use the Eat action.

July #1GAM

I also added a few more items to the game, such as bottles:

July #1GAM

My plan is allow you to fill bottles with liquids, but you shouldn’t fill it with sea water, which will actually dehydrate you. Which means I’ll need to make some fresh water somehow.

Which brings me to the problem I’ve been having with the creation of this game.

I have less than a week to get this project done by the end of the month, but there is still nothing really interesting to do yet in the game. I think if I learned anything from this project so far, it’s that you shouldn’t try to address an entire game’s features at once.

For example, when I added hunger to the game, I should have followed through with creating food, and then creating the ability to eat that food. Instead, I had various aspects of the game in various states of completion.

I have a lot of ideas and plans for this project, and I might be falling in love with it, which makes it hard to let go.

I’ll have to finish a minimal version of Shipwrecked for now so that I can come back to it another day.

No, no, Shipwrecked. Don’t speak. This thing is bigger than either of us.