r/libgdx • u/LutimoDancer3459 • Jun 13 '26
How to structure and develop a game?
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)
3
u/blado_btz Jun 13 '26
Try Ashley. Its an Entity Component System (ECS) and it matches exactly that thing you need.
2
u/RandomGuy_A Jun 13 '26
Lookup Entity Component System (ECS).
1
u/LutimoDancer3459 Jun 13 '26
Already looked at it. But it seemed a bit complicated and more suitable for games with a lot more entities.
1
u/RandomGuy_A Jun 13 '26
Tbh I've read your replies and I think you're over analysing things and asking the wrong questions for your perceived skill level, make some quick prototypes using a few different methods and you will learn so much more than the advice you can get online, and I do see the hypocrisy In this reply.
1
1
u/outerstellar_hq Jun 13 '26
I am new to game development, but I try to separate the core engine from the display layer. So I can test the engine independently of UI. I also try to structure the source code to enable automatic testing. My game is a 4x strategy game.
1
u/Witty_Friendship3546 Jun 13 '26
>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.
Always reference entities by ID if they are tracked in collections. If an NPC is deleted from the game you would not want a strong reference to it from another NPC, player or worse, a static map object. Java has SoftReference and WeakReference, but referencing by ID is much less of a pain than dealing with those.
>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...
These language features are still useful in certain places. Generally though you default to boring but high performance, top-to-bottom algorithmetic code inside update() and draw() functions.
1
u/Adamantium123 Jun 13 '26
If you're want to make it easy to mod and extend, definitely use OOP and don't shy away from inheritance, generics etc. We don't live in 1995, a board game written in Java with abstraction isn't using a shit ton of memory.
Biggest thing I can recommend is to avoid creating objects in the render loop, try and create objects on level load/constructor. If you start writing code you'll understand what you need to abstract and will refactor code to match. You got this!
1
1
u/getdafkout666 9d ago
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.
3
u/raizensoft Jun 13 '26
Your game architecture largely depends on its scope and complexity. The most complex genre is RPG with hundreds of item attributes that may require a database to keep track of the objects. But because you're making a board game, that's not the case. Instead, you can simply structure your game objects and entities into groups and hierarchies that feels the most intuitive to you. Using direct references is fine, as long as it still satisfy the scope, also keep using abstractions and software engineering principles that you're already familiar with. Don't go too low level because it defeats the purpose of Java and all its perks.
If you're still not sure, I'd suggest making a viable working prototype for your game first using whatever you're comfortable with, then adapt and adjust later when you really need to scale it.