Making Games on Your Own as an Engineer

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!

Reminds me of this:

https://www.newyorker.com/magazine/2008/10/20/late-bloomers-...

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

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!

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.

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!