2 ms·

Thanks for all these links. Will definitely check them out. Per your game dev career, sorry to hear that it's so stressful. I've heard from several reliable so

Thanks for all these links. Will definitely check them out. Per your game dev career, sorry to hear that it's so stressful. I've heard from several reliable sources that the game dev industry extremely overworks and underpays people, and that it has a high turnover rate. As a husband and father of 5 kids, I can't imagine making games in a job like that. Part of the reason my game is still unfinished after 15 years is because web dev is a much more stable income which lets me give my evenings and weekends to my family, and in that time it's either spend time with them or spend time writing a game. So I have like 10 lines of code to show for the choice I've made :D Regarding entity systems, I read a blog post somewhere which discussed a really good idea that I liked a lot for how to implement them. It recommended eschewing the typical OOP concepts and just writing a struct that had slots for each "trait" that an entity could have, like Movable (x,y & controls), Damageable (HP etc), Container (chests, boxes, secret bookshelves, etc) and in the update function, iterate each entity in the active game state and if they have a thing present, run the relevant function on it. Plus it allows things to have multiple aspects, like an "evil gnome" is both Damageable and Moveable but an "evil tree" is only Damageable, This sounds like a really doable approach. Okay anyway, will bookmark those links and look into them more when I have time. Thanks for the recommendations.

optionalparens 10y ago
Regarding entity systems, it's best not to implement as slots in a struct or something like that. Of course there are lots of ways to do it and varying performance. Interestingly, taking a data-first approach and iterating over the same kind of components within a system tends to be good for performance. An entity is an int, long, or something else depending on your needs. It should be light-weight and not cause garbage to be allocated, thus why a long is good. A UUID/GUID is bad because you cannot use the entity id to cheat into pool rosters or other uses, not to mention it is hungrier for memory and slower to generate. Entity IDs should be allocated, often atomically and in one place and from a single thread. A component is the data that you mention and should be a class or map/dict depending on the language. It is just a collection of fields, usually flat. Allocation should be done from a pool. It should be attached to an entity and detached as necessary. This is like a foreign key relationship per component to the entity ID if you want to think of it in DB terms. A system operates on collections of entities, usually per frame/tick. Generally it is looking for one or more types of components per entity and isolating the logic there. You can go outside the entity system for performance reasons like rendering if you must. Purity is good, but a lot of people go crazy and wreck performance. Be smart. The other hard thing is communicating between entities and between components. There shouldn't be any hierarchies or hard-coded things like that. Usually what is best is a queue or mailbox approach that the system can read from and deal accordingly, and then perhaps something more sophisticated beyond that as required per type of game. My advice for getting games done in general if that's what you want to do is to just build a game and not an engine. From that regard, do dirty things like using pre-built engines such as Unreal or Unity. Better yet, just make a simple game. You will learn less, but be far more productive as a single person. If however you just want to muck around and learn things, then go wild. One thing we used to do to test architectures and game concepts that might be of interest to save time and explore me is we would build big chunks of a game with wire frames, stick figure-like things, whatever. If it's fun playing as a cube, it will be fun playing with a fancy sprite or 3d model.

optionalparens 10y ago

Regarding entity systems, it's best not to implement as slots in a struct or something like that. Of course there are lots of ways to do it and varying performance. Interestingly, taking a data-first approach and iterating over the same kind of components within a system tends to be good for performance. An entity is an int, long, or something else depending on your needs. It should be light-weight and not cause garbage to be allocated, thus why a long is good. A UUID/GUID is bad because you cannot use the entity id to cheat into pool rosters or other uses, not to mention it is hungrier for memory and slower to generate. Entity IDs should be allocated, often atomically and in one place and from a single thread. A component is the data that you mention and should be a class or map/dict depending on the language. It is just a collection of fields, usually flat. Allocation should be done from a pool. It should be attached to an entity and detached as necessary. This is like a foreign key relationship per component to the entity ID if you want to think of it in DB terms. A system operates on collections of entities, usually per frame/tick. Generally it is looking for one or more types of components per entity and isolating the logic there. You can go outside the entity system for performance reasons like rendering if you must. Purity is good, but a lot of people go crazy and wreck performance. Be smart. The other hard thing is communicating between entities and between components. There shouldn't be any hierarchies or hard-coded things like that. Usually what is best is a queue or mailbox approach that the system can read from and deal accordingly, and then perhaps something more sophisticated beyond that as required per type of game. My advice for getting games done in general if that's what you want to do is to just build a game and not an engine. From that regard, do dirty things like using pre-built engines such as Unreal or Unity. Better yet, just make a simple game. You will learn less, but be far more productive as a single person. If however you just want to muck around and learn things, then go wild. One thing we used to do to test architectures and game concepts that might be of interest to save time and explore me is we would build big chunks of a game with wire frames, stick figure-like things, whatever. If it's fun playing as a cube, it will be fun playing with a fancy sprite or 3d model.