3 ms·

Thanks, if you do nothing else, please (links to follow): 1. Read/watch the naughty dog presentation on Last of Us port where they talk about their time step.

Thanks, if you do nothing else, please (links to follow): 1. Read/watch the naughty dog presentation on Last of Us port where they talk about their time step. I have to say if there's one company who puts out stuff like videos and articles/books you should read, it is Naughty Dog. They know what they are doing optimization-wise, I just happen to find most of their games boring and lifeless from a design point of view, but I can still respect them greatly. 2. Read the GDC presentation about entity systems and the "roster" approach linked below. 3. Read probably everything on the Bitsquid site. Some of it is dated or even not the best, but I pointed some people here before and it really opened up their minds to what I was talking about when they were looking at my code. Changed their view from "black arts" to "wow, that really is simple and makes sense." 4. Read up on Entity Systems. But do not read things written by bloggers, authors of "frameworks," and various Java stuff out there (ex: Artemis). I hate to be so negative, but what I usually found out there is mostly garbage, wrong, and the authors disappear when challenged or asked about the hard, non-obvious parts. If you want good info, read code that's out there and figure out what seems good/bad, and listen to some of the people in the industry like at GDC talking about it. I tried to find one more recent talks, but so far only came across the Amazon one which seems pretty weak (though still interesting) and basic with regard to low-level detail. Games knowledge is a tough thing because everyone is professor know-it-all and usually just hobbyists and throw away mobile game devs. Most people working on games who are competent are too busy or too sick of it to write about it. I hate to sound like one of those people. And that's why I don't blog about it or normally comment much. The only reason I'm mentioning it now is to pass time while watching the election. My games career was making me go insane and it was either family or video game development, so now I have more time in life to rant here. So, yeah. http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh... http://www.slideshare.net/TerranceCohen/terrance-cohen-dynamiccomponentarchitecture http://www.slideshare.net/TerranceCohen/terrance-cohen-dynam... http://bitsquid.blogspot.com/2011/09/managing-decoupling-part-4-id-lookup.html http://bitsquid.blogspot.com/2011/09/managing-decoupling-par...

sdegutis 10y ago
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.

sdegutis 10y ago

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.