I don’t think it’s bad advice but having shipped multiple (really bad) games, I think it misses the two biggest/best pieces of advice I’ve gotten: 1. GDDs are probably a distraction if you’re a solo dev - prototyping and grayboxing a lot and looking for the fun mechanics without any art/music/story to get in the way or distract is essential 2. If you’re truly just starting (and don’t already have a sense of fun), absolute best way to start is to carbon-copy a game you find fun, then start adding/tweaking elements. This both builds the mindset required to make games, and helps you get into the “fun iteration” loop quickly without getting bogged down in writing a lot of interesting technical systems that don’t end up contributing to the game in a meaningful way.

I've written some learnings after shipped my first game: https://ruoyusun.com/2018/06/15/guide-for-non-game-dev.html

As a professional software dev, I've noticed that while both game dev and software dev are "writing code", they are done in a very different way.

As a software dev, the value proposition is more or less clear before you start writing code. As a game dev, you can only start to see your value proposition after you have finished your code - that's why game code, especially as an indie without clear distinction between prototype and production phase, tend to become spaghetti really quick - and that's fine. If you spend too much time to make the code look nice, then you are not spending enough time to make the game actually fun.

Software usually has some logic behind it - it has to make "sense". A game doesn't necessarily have to make sense - it needs to "feel right" and "fun". That means your nicely designed abstractions actually won't be reusable - copy & paste is much more pragmatic. You can start to look to refactor after your game is actually successful (or fun at least) but even then you will realize that most of the code is not reusable.

A big part of your game code is actually "content", instead of "systems" - meaning they are closer to a "script" than a well architectured software code. So you write more if-else and less inheritance and encapsulation (unless you are writing your own engine, then in that case, your engine code is actually close to software projects).

And if you hate writing UI for software, you'll hate writing UI for games even more.

Derek Yu, the creator of the Spelunky series among other things, has just published a blog post on his experience with developer archetypes: https://www.derekyu.com/makegames/archetypes.html

Recommended short read, I'm sure you'll find yourself here and relate to your non-indie-game-developer self too!

For an introduction to Unity game programming as an engineer, I can't think of a better resource than Catlike Coding tutorials:

https://catlikecoding.com/unity/tutorials/

They're great for people who are already self-sufficient programmers, and just need to quickly get up to speed on how Unity does some specific things.

The "architecting systems" vs "developing a game" point really hit home. When I've attempted to make a game myself I've ended up developing - a night-sky pixel-art generator based off of night-sky data from SIMBAD. This was seriously overengineered and had an excessive amount of undergrad astrophysics involved. I spent weeks on this and in the end the core gameplay was not even developed!

I'm a developer making a game prototype (full-time at the moment after being retrenched).

If you're a solo dev I think it's really important to focus on the areas where you don't have any skills. For example art, animation, effects etc. All of these could potentially be a big hurdle, depending on the idea that you are developing.

Learning how code works in Unity (as a developer) isn't that difficult, it just takes a bit of time. Say you need to add more advanced elements, for example you need some form of space partitioning? If you know the terms then searching for existing code (e.g. a good KD-tree implementation) on github is also not a problem, and you shouldn't have any issues implementing it in your game.

But figuring out what art assets you're going to need, how you're going to create them (or source them) and integrate them into the engine can be an issue. As per another comment, "juicing" the game up takes you out of your developer comfort area, you need to really tap into your creative side there.

Hey, this is just the sort of thing I'm interested in. I'm an experienced programmer who has no idea what I'm doing with Unity. Unity's tutorials are surprisingly great, but they tend to start with "okay, so a 'variable' is..." and I have to skip forward a bit and just want to know "okay, but say I already know how to program, what's the right way to program with Unity?" I've found very little on that topic, and unfortunately whatever stuff Unity has at that point seems to be behind crazy high pay walls and silly "certifications."

Thanks!

Good article - it's a useful distinction whether you're building something to sell or something for fun.

One resource worth mentioning is: https://www.researchgate.net/publication/228884866_MDA_A_For.... Working backwards from the desired kind of game you want to make based on the 8 categories this paper talks about (sensation, fantasy, narrative, challenge, fellowship, discovery, expression, submission/abnegation) can give you a clearer way of measuring success than whether you did a good job implementing whatever mechanic you thought of.

Another thing the article doesn't mention that I think can be valuable for software engineers is doing paper prototypes. As engineers, we often think about producing code as the only way to build prototypes, but sometimes you can get mileage from testing a game mechanic through much cheaper to produce paper prototypes of the game (or a part of the game).

I've been working on a game in my free time recently[0], and I can't stress enough how important it is to identify a "critical path" for developing. Games are such a visual and auditory medium that you can make a really polished and interesting experience that falls flat on it's face when it comes to depth or game mechanics.

Get to the very core of what you want your players to feel, their mindset, etc... and then build on top of it.

Part of doing this well is playtesting (note that this is not QA or usability testing, and especially not focus testing). Think of game designs as hypotheses and playtests as experiments. You can learn an absolute ton about your game just from doing this every week or two. I've found that using Steam's Remote Play Together feature made this quite feasible during WFH.

[0] Link in bio if anybody is interested.

Start with: “how will I sell it?” This will frame “how do I start?” If you can’t answer how to sell it, then focus on learning and fun. If you are one of the lucky few that has a vision for both sales and hacking, then hack around that sales funnel, from the very start.

I hate what mobile has done to the web.

The text on this blog is huge and sparse, and two of the pictures take up more than 100% of my vertical screen space.

When did people forget about desktop browsers????

TFA has some good points. I'd go even further on the situation where you quit your job to work on an indie game -- if you ever find yourself doing this, and you've never built a game by yourself before, you'd better have several years of runway.

For many years one of my favorite talks about indie games development was Jonathan Blow's speech at UC Berkeley CSUA (2011) (http://the-witness.net/news/2011/06/how-to-program-independe...)

Initially I loved his main message during the talk: "You have to be brutally effective to finish a project in a reasonable amount of time."

But there's a part in the Q&A that later grew to be even more poignant to me:

https://www.youtube.com/watch?v=JjDsP5n2kSM#t=1h13m8s

> Q: You said you worked on many projects before Braid which didn't quite get completed. What was special about Braid which made you complete it?

> A: What was special was it had been a long time since I'd finished anything on my own, and I sat down and decided that "Dammit I'm going to finish something this time". And, "To that end, so I can finish this, I'm gonna make something that is technically pretty simple"...

For some of us, it's REALLY HARD to complete a side-project while working full-time job. For most of my career I had completed a real game only when it was for a job (or for a client) and I worked on it full-time.

The single reason I hadn't made a game as a side project was because I'd quit before I finished. I finally figured out something that worked for me, and it was counter to all the advice I'd heard. I'm sure this is different for other people, but for me the key to working day after day consistently (not quitting) on a project while working full-time was to eliminate all the "shoulds".

When my conscious brain is always telling myself that I should do the project a certain way, my subconscious rebels and suddenly I become unproductive. There's a ton of great advice out there such as: "Don't reinvent the wheel, build your game not a game engine." The problem is sometimes my subconscious wants to build the game engine, not the game. I can coerce it to do the right thing when it's for an employer, but it's a different story for a side project.

Ever since I stopped "should-ing" myself, I've become much more consistent and productive on side projects. If you want to make games on your own as an engineer, but are having trouble forcing yourself to spend a couple hours every day on it, then I'd suggest that you try to just code whatever the hell you want to code instead of the thing you're supposed to code. You may find, like I did, that it's better to gain some coding velocity, because this velocity gives you the momentum fly over humps that you weren't able to overcome back when you were trying to start working on your game from a standstill.

if you are an engineer strapped for time, don't disregard using html + canvas + a canvas game library to build your thing.

html input layer and javascript glue is a order magnitude more efficient than building a guy in a game engine, so unless you specifically want to push into 3d excellence and require full access to gpu performances and features, it can save a lot of tedious work.

I've tried both unity, godot and the previous approach coupled with phaser, and prototyping stuff goes ho so much faster.

Back when I was doing iOS consulting I wrote and published a few games as side projects - almost got sued by Atari for my version of Battlezone.

Doing something polished as a one man band is incredibly difficult unless you are extremely multi-talented. Sound effects, graphics, music, game design are all skills that you probably don't have.

It is an amazingly fascinating world though and you learn a lot doing it. Just don't expect to become rich or famous!

Good tools and resources for indie game devs: Sfxr, Blender, The Gimp, git or P4, Visual Studio, itch.io, TurboSquid, freesound.org

I’ve been working on a game mostly solo now for a bit (my wife helps a bit with level design). It’s a stab at third person dungeons and dragons style play. Working on it is a lot of 7 day weeks and questions that you have to answer for yourself and the technical challenge feels really great.

This build is really out of date, but if anyone is interested I’ll post a link. I’ll have a significantly updated one up sometime in March hopefully https://hertzrat.itch.io/a-few-nights-room-and-board

As a developer in the past, my day job is great, but programming my own games and apps is fun!

My favorite apps and games are my own creations. Since I don't need to make money on them, I don't bother releasing them on the App Store.

I've tried that, and the reviews I get are bizarre. Aside from not dealing with the unruly public, I save a lot of time not worrying about distribution or support or marketing.

So if you want to make games or apps, go for it! Ignore the cries to ship your stuff. It's pretty clear who are in it just to make money, vs. enjoying and being productive programming for yourself.

I haven't read the whole article, but making games on your own is really hard. You are either good designer, but bad programmer or the other way around so. I think the easiest if you are a programmer and know a little bit of Unreal or Unity, you should use free assets and not bother with creating assets as this will eat up all your time. It's better if you pair with someone.

(Exactly) three months ago I quit my job to work full time in my game. I've yet to know how well It'll do. But maybe my input can help.

# Do. Then do it well.

I usually work like this:

  1- Hack something as quickly as possible

  2- See if it "works for the game"

    - If it does, GOTO 3

    - If not, abort and go do something else

  3- Refactor, re-architect and polish

# Make it so that you can iterate FAST

Being able to change and test an element or a feature individually is crucial.

I have taken a data driven approach to some of the game elements. So I have a big JSON file with the data of monsters and moves. When iterating, I simply change values here, relaunch the game and check if I like the result. I also use this file for "design debugging", starting in a later level, making the character immortal, etc.

I'm using Godot, where each custom element can be a Scene. This means that if I, for example, create my special kind of button, this button is a Scene and I can run it on it's own.

I also have code that runs only when running as scene like this. I usually add buttons of keyboard input handlers to "simulate interactions" with the element.

# Everything is a prototype

Nothing is set is stone. Nothing is final. Everything is a prototype.

Many times, a new mechanic changes completely how the others feel. Don't be afraid to change previous elements to accommodate the new one.

The same applies to code. ATM I'm in my third "rewrite" of my game's Battle UI and UI logic. The new UI arrived[0] and it was somewhat different of the old one. I just create a new file named "NewBattleUI" and start copy pasting and changing stuff from the old one.

Don't get attached to anything.

# "Feel" is the objective

woko and yetihehe's shared talks explain this way better that I can: https://news.ycombinator.com/item?id=26247832 https://news.ycombinator.com/item?id=26248964

My game has a Pokemon-like battle system. After watching those talks I implements visual effects for the moves. They changed nothing for the "raw numerical gameplay" but totally changed the feel of battles.

# Post Scriptum

My game is called One Way Dungeon. It is a linear dungeon crawler with Pokemon-like battles. It's being developed for Android, but you can try the latest web build here: https://vaskivodev.gitlab.io/onewaydungeon/builds/2021-02-19...

[0] I've hired a UI/UX designer to help me design it.

As a professional software dev who has approached gamedev a few times, I finally realized it was a theater stage and not a simulation. Every time I tried to start a game I wanted to make a simulation. I dove into graphics more, I realized it was all puppets and cutouts on a string, not some grand design.

I’ve written UIs for various platforms/targets including “UI frameworks” for a games engine and wow you’re not wrong. Made me beg to build web UIs again.

I find the best way to learn is by just building. You quickly run into questions, which can then be resolved one by one. But having said that, here's some tips. There's no single "right" way, but depending on your game idea you'll run into your own challenges and issues.

Learn what GameObject's and Components are and how they work. In Unity you have MonoBehaviour derived classes, but then you might also want some of your own non-Mono classes (for example an Entity-Character-Player/Civilian/Enemy inheritance structure).

For my code framework in Unity I create a GameObject in my scene that I call MainScripts. On this I'm going to attach all my generic Mono classes such as Game, MapList, AudioManager, UnitList etc. I call DontDestroyOnLoad on MainScripts so that it will last through all successive scenes.

Game is the main game class, I use its update to drive as many updates as I can (for performance reasons you want as few Unity Update methods running as possible). So for example inside of game's update I'm also calling my input's update, my own timers etc.

The next big problem is how does code in random class X access another class? For Mono classes you can go through the whole GameObject.Find/GetComponent in your Awake or Start methods and store them; BUT you might not have direct references to all your own code that doesn't inherit from MonoBehaviour.

For that I create a Static class. I'm going to place static references in here for everything global in my game, the previously mentioned MainScripts, Game, etc. As a random example, some Mono class might need to know if the control key is down. Since we're doing all input in our own input class we don't want to test through Unity again if control is down. Our input will already have a flag set, so then we just test something like if (Static.input.isAnyControlDown).

To setup Static we call our custom Static.Create from Mono Game.Start, which Unity will automatically call. Place Game very high (low #) in the Unity Script Execution Order so it will always be created first.

After that you have a code framework to hang everything off of. Hope it makes sense!

I'm glad to hear! My series, starting with "Basic Concepts in Unity for Software Engineers" [0] is exactly designed for this and borne out of a frustration in much of the existing content.

Some folks in the replies mention just starting to code and while I totally agree, it was also helpful for me to understand... at least the concepts.

TBH when I started, the main way I did this was my finding a course on Udemy and watching it at 2x speed, still being bored out of my mind for huge chunks of it.

[0]: https://blog.eyas.sh/2020/10/unity-for-engineers-pt1-basic-c...

I've messed around with stuff and honestly? Unreal + Blueprints is a much nicer set of tools for experienced programmers I think.

It's visual programming, but it's easy to explore around, there's nice debugging interfaces, and the type inference stuff makes it so that you are presented with a lot of the engine details in a nicely digestible manner.

Unity it's like "OK make a bunch of C# classes and coroutines!" and it gets real messy real quick if you don't know what tools are available to you.

Yeah, totally resonates with my experience. I went further and have several, completely independent side projects. That is: Build a game with a custom engine (doing that since 2019 now), do some stuff on my car, do some stuff on my pc, write a blog post from time to time or simply just play games. And I'm alternating between them, as my brain pleases. That, personally, gives me the counter-balance to my job as a software engineer, where I HAVE to stay focus on ONE thing for several hours/days.

This is more or less how I got into programming, I just liked games and wanted to make mine! By the time that I had started to be skilled in writing code, I realised that I found it more interesting to build the foundations (graphics, physics, logic, AI, all those systems) compared to the game itself. It bothered me for quite a while that I didn't manage to finish anything very substantial (a lot of small jam games and whatnot, nothing commercial), but eventually I reconciled with the fact that I'm just interested in building the engine, not the game. And that's all fine!

I can relate. Similarly, I ensure I put some time into my side-project on a daily basis, but don't coerce myself into very narrowed down optimal path. Once I gain momentum, I have easier time tackling the not-most-fun "shoulds".

I know a guy who has a wife that's been supporting him for about ten years now. He's still on his first game.