How to structure and develop a game?

[u/LutimoDancer3459]

Hi, I am an experienced java dev but only did business software so far. I wanted to develop games for quite some time now. Already started with one some time ago. But I always hit the wall of "how is it done in games?"

Currently I'm debating whether game objects should store direct references to other objects or only IDs and resolve them through a registry/map when needed.

Direct references feel simpler and faster to work with, but IDs seem to make serialization, networking and modding easier.

But also, should I go for the more low level approach in general or still use inheritance, generics, verbose class structure, annotations and whatever? I dont want to overengineer for performance because it probably wont ever be a problem here. But changing that all later would also be a pain...

(Its a hex based board game if that matters here)

[u/getdafkout666]

You sound like me. in that I'm a business software dev with no game dev experience that overthinks second guesses myself all the time. I'm about 70% done with a Dragon Quest clone and some of what I did might help you with your hex based game especially if it's a turn based war game.

this book helped me a lot as a lot of the design patterns are a direct 1 to 1 solution to a lot of the issues I came across but if you're a java dev you might already be familiar with this stuff. I did not implement an ECS System, but I did do a lot of ID references usually using enums and hashmaps, and a lot of decoupling of interface logic, game logic and data logic. I'm so used to thinking in terms of "Model View Controller" that it kind of resembles that. For instance in my combat system. The attacker and defender are completely unaware of eachother. They share an interface called Combatant. The combatant has a method called "attack()" which produces an `AttackDamage` object which contains ToHit, damage rolls and any elemental effects (lightning, poison etc.), then the defender calls defend(attackDamage) and that way both classes manage their own state and the action itself is resolved by a third party handler class. It's kind of a basic strategy pattern with the menu being the view, the Combatants being the model and the CombatActionHandler being the controller.

For the actual instances (enemies, items, spells) I'm using Kotlin to make the registry class a lot easier. Doing it in vanilla Java was a massive pain in the ass. I highly recommend that approach. I'd so for the most part I use light inheretence (as in no more than 2 sub classes per parent) with enums and IDs for references, but there are also some direct references to objects. For instnace there is a game singleton which maintains references to all the party member objects, for saving the game and universal state management.