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.
As for your first point, I would suggest aspiring devs to try to prepare themselves to take part in "game jams". The constraints (including a time constraint) help focus on important parts.
I've released over half a dozen games as a solo developer and 100% agree with this as well. Using off the shelf assets [0] to quickly MVF (Minimum Viable Fun) an idea really helps get up to cruising altitude.
I totally agree with you. I think there are two types of "Where do I start?" that folks wonder:
- Say, I know what I want to build exactly where do I start? a.k.a -- What's the equivalent to starting at the DAO / API layer and building the integration later, in the gamedev world?
- I know I'd like to make games, where do I start coding?
I focused a lot in the article about that first question (and only briefly alluded to prototyping, etc.) -- mostly because I was interested in the theoretical question of engineering practices.
Doesn’t hurt to jump start that loop iteration by taking in some principles and interrogations.
Two little books that can help:
1. From A Theory of Fun book blurb:
“A Theory of Fun for Game Design is not your typical how-to book. It features a novel way of teaching interactive designers how to create and improve their designs to incorporate the highest degree of fun. As the book shows, designing for fun is all about making interactive products like games highly entertaining, engaging, and addictive.”
”Over 100 sets of questions, or different lenses, for viewing a game’s design. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again.“
I totally agree with you, find something you've liked and reimplement that, and you will soon find yourself tweaking and adding.. That's how SDL-Ball (DX-Ball) and Wizznic! (Puzznic!) came to be :)
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.
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.
The best graphics abstractions allow artists to pretend they’re working with just another pencil or brush. To them, it should be as non technical as possible. Without tools a perfectly functional physics system is useless since it’s only simulation. There’s no content.
You’ve effectively created a new world for the artist to operate in, but have given them nothing to use. “You need a stage to act? Well there’s a tree over there...”
They’re really good at technique and learning things, but they tend to build the work around those techniques and limitations. The tools you give them focuses their energy in the places you want. The absolute best graphics programmers get this too, and it can all end up a creative and cohesive show if done properly. There are many games that intentionally limit the art in some way to create a theme. A way to get a bunch of artists in the same creative space.
The actors work together with the crew and backstage in the best shows. And that’s a game. A tight dance between the artists and technicians. Personally that’s where my love for it comes. Putting on a good show is hella fun. And artists respect tech. They may not get it, but they always respect it. Unlike business.
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.
Wow, this article is great, it could be its own HN submission.
Another archetype similar to "Burrowers" are "Architect Astronauts" - when you try to generalize every problem and create a portable universal solution to it
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!
Likewise, it hit home for me. About 9 years ago (wow, has it been that long?), I started working on a web-based Word w/ Friends competitor. With flash dying out and not really wanting to do it with DOM elements, I took to Canvas.
I ended up engineering a fairly complex system of containers and components with mouse events, layering, conditional rendering and caching, but never finished the game.
Since then, any time I'm itching for something fun to work on, I revisit that code. I've had several attempts at moving it away from using Classes, to functional, to trying to build it in React. The last attempt led me to react-canvas, which while not exactly what I was trying to make, was close enough that I felt defeated.
That helped me realize I was more interested in the system than the game, because I could've just used react-canvas or plenty of other 2d game tools to build it, but I never chose to do so.
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.
Definitely agree about “juicing” your game, especially from a visual perspective. There’s so many graphics concepts that I didn’t know about and didn’t have the eye to recognize.
Things like ambient occlusion, bloom, reflection probes, and physically based rendering/materials were totally unknown to me but were really essential to making a game look “AAA”.
I've found this to be true as well. I'm a data engineer in my day job, and I've been doing part-time game development for about 2 months. It feels early but I'm forcing myself to learn Blender and polish my animations and effects because I don't want to have a "finished" game and then get stuck having to slog through 20-30 animations.
It's going pretty well and I'm happy with what I've been able to do. It'll make it easier to start marketing earlier as well, which is a huge plus.
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."
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 think your first sentence is correct. And that maybe you should have stopped there. Spending ages trying to do things "the right way" instead of just hacking it together and actually learning is what makes it hard to get going. Basically making your own framework on top of Unity (as per your tips) is not the best way to start.
Little HN feature: if you click a comment's timestamp, you'll be able to "favorite" it. You can look at your (or anyone else's) favorites from the profile page.
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.
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.
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.
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.
Sorry to hear that. I write/preview on desktop first and typically like the legibility that comes from the line spacing, etc.
What would you change to make this a better desktop experience for you? Less of the full-width photos? Text that spans wider, or just lest line spacing?
If it was me I'd delete both large photos (neither relevant to article) and zoom out to 80%.
I'm not sure what PC you're using but full-width is not nearly as egregious as full-height. On my 20" 4:3, the first photo is almost exactly 100% height, second is perhaps 120% height.
Are people surprised by this stuff? I can't be just an old coot shaking my fist at the kids on my yard. Compare the blog to HN, side by side. Or Wikipedia. Or Washington Post. Look at the content density side by side.
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.
> 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.
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".
> Ben Fountain did not make the decision to quit law and become a writer all by himself. He is married and has a family. [...] “When Ben first did this, we talked about the fact that it might not work, and we talked about, generally, ‘When will we know that it really isn’t working?’ and I’d say, ‘Well, give it ten years,’ ” Sharie recalled. To her, ten years didn’t seem unreasonable. “It takes a while to decide whether you like something or not,” she says. And when ten years became twelve and then fourteen and then sixteen, and the kids were off in high school, she stood by him, because, even during that long stretch when Ben had nothing published at all, she was confident that he was getting better.
Just a few months ago I read a blurb (in Scott Young's Ultralearning) about Eric Barone's 5 yr effort to build Stardew Valley. Amazing story. Imagine resisting the pressure to take "a real job" for 5 years so you can work on a game.
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.
I've done two major things, both using a 2d engine because I don't have the resources for 3d modelling:
first one was bootstrap with a custom theme on the user layer, phaser.js on the rendering layer. The interesting part is I was able to use the phaser render to texture function to have dynamic maps integrated in the html layer, and ship preview in the ship theme selector. I can send you source and everything, the game is basically completed in regards of the original idea I had. you can see it here https://parkedbits.com/Increstellar/ - it's not obfuscated or anything, but the prestige/bonus thing at start is not really implemented in this version
second one is using vue.js for the html frontend with a theme inspired from the NES.css style (but reimplemented as I didn't like their input widgets), with a phaser.js backend because I don't have time to learn two things at a time (vue being the first one). this just has the unit editor and there's no gameplay in sight, but the code is likewise available for inspection (it's just html, no node backend or anithyng, just static files)
Nice! I've built a little game in Vue.js (IP wasn't mine and it never launched), but I found that the CPU usage was heavier than I'd like it to be when functionality became non-trivial (many things moving at once). Maybe I modelled it badly though.
Can you give more detail on how you hooked vue into phaser? I'm really interested in whether that would have fixed the issues I saw.
> Can you give more detail on how you hooked vue into phaser?
there's many details that might not work for every game, starting from how the game structure is organized (it's the same for both games, except for the library bindings) - for the Vue Game:
- Vuex.Store contains the game world state
- The game has a management phase and a combat phase
- During the management phase you manipulate from Vue components the world state (economy, units, groups, movement orders etc)
- During the combat phase, the UI doesn't provide feedback for the whole world state in real time; the unit groups within a playfield get removed from the global store, moved into a local 'combat' structure, a new phaser scene with a different Vue component root gets drawn, the combat plays out, the effects on units are moved from the combat structure into the VuexStore world
- The combat effect at phaser level are simulated, targets, shooting, damage is all calculated ion the game frame update
- The combat updates are sent with an action to the vue combat component data structure in packets - unit health changes, units killed, unit without ammo etc are collected and the state sent about every second
- The Vue components that represent global unit health and ammo have transitions whose start and end point depends on the relevant stat, so that the damage or supply usage doesn't just change every second, but gets interpolated
> many things moving at once
to answer at this specifically:
- On the phaser combat render side, there's a fixed pool of tweenable effects (i.e. shoot trails); rendering every single shoot animated was too much, especially for not accelerated mobile browser (like chrome/ios - idk if it's still not accelerated today, but back then was a issue) - so even if there's a thousand shoots flying around, only a hundred or so are rendered, picked at random (and nobody ever noticed)
(not your parent poster)
I used P5.js for an Asteroids clone and an add on (P5.game) for a Galaga clone. Both had good primitives and it wasn't too hard to write a game-tick for-loop that ran the game logic.
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!
Seeing posts about Wings3d makes me miss Nendo and what it could have been. I had so much fun playing with that over a decade ago. I just hated that many times it'd end up crashing or a subdiv gone wrong would ruin the model and it had limited undo.
I tried Wing3d, but somehow it never felt the same.
Never heard of nendo, I will look it up. I had to take courses in school using Maya and Blender. I was terrible at both, but had a little more success with Wings3D. I have heard Blender is better now (this was the early 2010s).
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.
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.
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.
