Making Games on Your Own as an Engineer

GDD=Game Design Document

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.

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

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

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.