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
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.
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.