This is a series of posts and tutorials about game design and development. I’m working on my first game and it’s challenging but satisfying. I think it will be helpful for me to write about it. Ideally it will also be helpful to read about.

Why … is all this … then

When I first got into game development a few years ago I read a post by a developer who had made a successful iOS game (I forget the game otherwise I would link to it). He mentioned that having a dev blog was helpful for him, even if he was the only person who looked at it. He would post an update every time he made some progress. Later, when he was inevitably stuck and losing motivation, he would go back to the blog and look at all the previous times he had been stuck and figured it out. This would motivate him to keep going.

I forget to update my dev blog regularly because the updates are so mundane. Even when I figure out something that I’ve been struggling with for months I just make a relief post devoid of interesting details because I know no one’s going to look at it anyway.

I would like for this series to have an audience so I’ll have to think clearly about my design choices and go into detail when I’m describing technical problems. This will help me articulate what I’ve learned and what I think about game design. I’m looking forward to sharing the technical challenges and solutions and hearing about better ways to do things from developers with more experience than myself.

Also, I have no idea how to market a game while I work on it and so maybe this is an enjoyable version of that.

Upcoming Posts

Here’s what I will probably write about in the next few weeks:

1. Figuring out what to make

Deciding on an idea was harder than I thought. Making a game is a big time commitment so figuring out what to work on is important.

2. Testing game ideas

It's probably a good idea to see if what you think will make a good game will actually make a good game. Otherwise you might spend years of your life working tirelessly on building a very complicated piece of garbage.

3. What I think about physics and games

I have a love/hate relationship with physics and games. For example, I love when I the out-of-the-box physics behavior looks and feels great and I get to not do animations and programming. And I hate when I bump into a rock immediately afterward and fly off into orbit.

4. Doing the cool thing(s) first

I always try to work on the most interesting idea first. If it's good, then it motivates me to perfect it. I will give some concrete examples of this from King of Kalimpong. Then I will probably copy and paste all of Less Talk, More Rock.

5. Networked Physics in King of Kalimpong

This topic will probably span a few posts. Latency, client-side prediction, non-deterministic physics, dead reckoning. These are all words in the previous sentence. Find out what they mean and why they gave me anxiety for 3 months.

6. Overriding physics without going insane

This is kind of a warm-up post where I talk about the general idea of overriding physics behavior to get better results. Typically I do this to prevent myself from hitting my computer with a hammer.

7. How the auto-landing in King of Kalimpong works

Players weren't jumping because they couldn't land their jumps. Surprisingly, the solution involes code and math.

8. King of Kalimpong, big projectiles, long shots, and Tribes

King of Kalimpong is mostly me trying to capture and combine some of my favorite elements from Tribes and other games from my childhood. I will talk about how I think about game design in terms of moments.

9. Premium vs. Free to Play vs. Pay to Win

How to maybe make some money so you can maybe make another game without worrying that your wife secretly wants to murder you. Also the difference between games and predatory, digital slot machines that sneak into the "games" section.

That’s all I can think of for now. Bye!