Hi all,
I plan on making a simple game using C++ and SDL. The premise is very simple; you have a character that runs around and kills zombies. However, I want to make different kinds of zombies, and I was reading about the Game Component system and it piqued my interest.
Where I usually do the basic Entity->Player/Zombie/whatever system, I realized that creating a bunch of different types zombies may be tedious. So my biggest question is, how could I implement the game component system with making multiple kinds of zombies? They will all share a few attributes (x and y coordinates, animation, health); but I want to make some be more difficult than others.
My current idea of the component system is that I create a base Component class, then make an AI Component class - from there I could make an "easy" AI component, "medium" AI component, etc - and give each respective zombie class a type of component. However, I've read about this thing called a "subsystem" - I'm not entirely sure what the subsystem is supposed to do, and the article I've been reading hasn't mentioned it where others have (the article I'm reading is http://gameprogrammingpatterns.com/component.html ).
So, I'd like to know if and how to use a subsystem with components, and how exactly I would implement say, an "AIComponent" with a cZombie class.
Thanks!
1
9 replies to this topic
Sponsor:
#3 Crossbones+ - Reputation: 1066
Posted 11 December 2012 - 11:58 AM
First, think about what you'd like to achieve with your game. Do you want to know more about programming, game design, patterns etc? Then proceed.
But if you'd want to MAKE a game, C++ and SDL are not the best choices, you are first building your own engine, you spend a LOT of time coding stuff that has nothing to do with your game logic.
Assuming the first, and assuming you know you have 3 years + experience in programming, I suggest you go and buy a book called Game Engine Architecture by Jason Gregory. In there, you find all the different subsystems a modern day game engine has. Yes you won't make the next source engine, but your game engine has to tackle similar kinds of problems, just your solution will be far simpler.
You should also buy a book on Design Patterns, you'll need them more than you'd like.
Because your problem to me seems like you don't really understand what problems the composite pattern should solve, or what it actually is, what you are describing seems more like inheritance to me. Also I think you don't know yet what the code around the game logic actually should do. This is very common with beginners in game writing(I had the same problems just some months ago).
If you have less than 3 years of experience in programming and you don't have that much experience in C++, don't, just don't use C++. Use C#, Java, or anything else. Buy some general programming books, I enjoyed "Pro C# and the .net framework".
E: So, you should tell some more, what do you want to accomplish and why do you think you should use the composite pattern?
But if you'd want to MAKE a game, C++ and SDL are not the best choices, you are first building your own engine, you spend a LOT of time coding stuff that has nothing to do with your game logic.
Assuming the first, and assuming you know you have 3 years + experience in programming, I suggest you go and buy a book called Game Engine Architecture by Jason Gregory. In there, you find all the different subsystems a modern day game engine has. Yes you won't make the next source engine, but your game engine has to tackle similar kinds of problems, just your solution will be far simpler.
You should also buy a book on Design Patterns, you'll need them more than you'd like.
Because your problem to me seems like you don't really understand what problems the composite pattern should solve, or what it actually is, what you are describing seems more like inheritance to me. Also I think you don't know yet what the code around the game logic actually should do. This is very common with beginners in game writing(I had the same problems just some months ago).
If you have less than 3 years of experience in programming and you don't have that much experience in C++, don't, just don't use C++. Use C#, Java, or anything else. Buy some general programming books, I enjoyed "Pro C# and the .net framework".
E: So, you should tell some more, what do you want to accomplish and why do you think you should use the composite pattern?
Edited by Bluefirehawk, 11 December 2012 - 12:06 PM.
Project: Project
Setting fire to these damn cows one entry at a time!
Setting fire to these damn cows one entry at a time!
#4 Members - Reputation: 403
Posted 11 December 2012 - 12:50 PM
What I think you are talking about is parameter driven models (or components). If you want to have a bunch of zombies each with different health values, they all have a health capability, just with different initial values. Same thing with size, speed, aggression, etc.
My system (also a zombie game) uses this approach. In my entity definitions (which are lua scripts) I allow for functions to be used for initialization data, which then return randomized values (within a valid range) each time a zombie is created. This gives various types of zombies, some harder to kill than others with the same game object model and initialization script.
Here's my initialization script for a zombie:
[source lang="cpp"]ENTITY{ type="zombie"; inherits="baseEntity"; attributes= { type={type="string", value="zombie"}; state={type="string", value="wander"}; }; behaviors= { RenderBehavior = { model="../data/models/zombie/zombie.ms3d"; texture="../data/models/zombie/zombie.jpg"; scale={0.2, 0.2, 0.2}; --scale={1.0, 1.0, 1.0}; translate={0.0, 0.0, 0.0}; rotate={0.0, 0.0, 0.0}; animated=true; }; AnimationBehavior= { animations={ {name="walk1", start=2, finish=20, fps=24, loop=true}, {name="walk2", start=22, finish=36, fps=24, loop=true}, {name="damage1", start=38, finish=47, fps=24, loop=false}, {name="damage2", start=48, finish=57, fps=24, loop=false}, {name="fall", start=59, finish=75, fps=24, loop=false}, {name="prone", start=78, finish=88, fps=24, loop=false}, {name="die", start=91, finish=103, fps=24, loop=false}, {name="kick", start=106, finish=115, fps=24, loop=false}, {name="punch", start=116, finish=128, fps=24, loop=false}, {name="headbutt", start=129, finish=136, fps=24, loop=false}, {name="idle1", start=137, finish=169, fps=24, loop=true}, {name="idel2", start=170, finish=200, fps=24, loop=true} } }; CollisionBehavior= { radius=1.0; }; ScriptBehavior= { script="zombieAI.cs" }; AudioBehavior= { sounds={"../data/audio/zombie-brains1.wav", "../data/audio/zombie-brains2.wav", "../data/audio/zombie-brains3.wav", "../data/audio/zombie-moan.wav", "../data/audio/zombie-gurgle.wav"}, period=10 }; SenseBehavior= { range=function() return math.random(200,500) end; acceptTypes={"player"}; }; DamageBehavior= { health=function() return math.random(25,75); end; }; }; reflected= { "RenderBehavior", "AudioBehavior", "AnimationBehavior", };}[/SOURCE]
My system (also a zombie game) uses this approach. In my entity definitions (which are lua scripts) I allow for functions to be used for initialization data, which then return randomized values (within a valid range) each time a zombie is created. This gives various types of zombies, some harder to kill than others with the same game object model and initialization script.
Here's my initialization script for a zombie:
[source lang="cpp"]ENTITY{ type="zombie"; inherits="baseEntity"; attributes= { type={type="string", value="zombie"}; state={type="string", value="wander"}; }; behaviors= { RenderBehavior = { model="../data/models/zombie/zombie.ms3d"; texture="../data/models/zombie/zombie.jpg"; scale={0.2, 0.2, 0.2}; --scale={1.0, 1.0, 1.0}; translate={0.0, 0.0, 0.0}; rotate={0.0, 0.0, 0.0}; animated=true; }; AnimationBehavior= { animations={ {name="walk1", start=2, finish=20, fps=24, loop=true}, {name="walk2", start=22, finish=36, fps=24, loop=true}, {name="damage1", start=38, finish=47, fps=24, loop=false}, {name="damage2", start=48, finish=57, fps=24, loop=false}, {name="fall", start=59, finish=75, fps=24, loop=false}, {name="prone", start=78, finish=88, fps=24, loop=false}, {name="die", start=91, finish=103, fps=24, loop=false}, {name="kick", start=106, finish=115, fps=24, loop=false}, {name="punch", start=116, finish=128, fps=24, loop=false}, {name="headbutt", start=129, finish=136, fps=24, loop=false}, {name="idle1", start=137, finish=169, fps=24, loop=true}, {name="idel2", start=170, finish=200, fps=24, loop=true} } }; CollisionBehavior= { radius=1.0; }; ScriptBehavior= { script="zombieAI.cs" }; AudioBehavior= { sounds={"../data/audio/zombie-brains1.wav", "../data/audio/zombie-brains2.wav", "../data/audio/zombie-brains3.wav", "../data/audio/zombie-moan.wav", "../data/audio/zombie-gurgle.wav"}, period=10 }; SenseBehavior= { range=function() return math.random(200,500) end; acceptTypes={"player"}; }; DamageBehavior= { health=function() return math.random(25,75); end; }; }; reflected= { "RenderBehavior", "AudioBehavior", "AnimationBehavior", };}[/SOURCE]
Halfway down the trail to Hell...
#5 Members - Reputation: 179
Posted 11 December 2012 - 01:54 PM
Hey,
I noticed I posted this in the wrong forum! I meant to post it in Game Programming, sorry. That's what I get for posting five minutes before class, I suppose
Anyway, thanks for the insight. @Telstyn, I suppose that this means that I don't actually understand the concept of the component system - I thought that the whole point of component systems was to make similar-yet-slightly different entities?
@Bluefirehawk, you're right; with this project I'm more focused on the actual programming of the game - not the actual "making" of the game.
@Scourage, that's some good stuff; that sounds a lot like what I'm trying to do.
My main question is if a component system is an efficient design for creating Entities with similar, but not exactly the same, properties. If it's not, then could someone enlighten me with a simple situation where one would use the component system?
I noticed I posted this in the wrong forum! I meant to post it in Game Programming, sorry. That's what I get for posting five minutes before class, I suppose
Anyway, thanks for the insight. @Telstyn, I suppose that this means that I don't actually understand the concept of the component system - I thought that the whole point of component systems was to make similar-yet-slightly different entities?
@Bluefirehawk, you're right; with this project I'm more focused on the actual programming of the game - not the actual "making" of the game.
@Scourage, that's some good stuff; that sounds a lot like what I'm trying to do.
My main question is if a component system is an efficient design for creating Entities with similar, but not exactly the same, properties. If it's not, then could someone enlighten me with a simple situation where one would use the component system?
Edited by johnmarinelli, 11 December 2012 - 01:57 PM.
#6 Members - Reputation: 114
Posted 11 December 2012 - 02:06 PM
Component oriented programming and entity systems have piqued my interest lately. There are quite a few articles online that I think you should read to understand more. One good source is here: http://stackoverflow.com/questions/1901251/component-based-game-engine-design
One implementation of entity system involves separating data from functions. So, components will only contain fields, and subsystems will contain the logic that uses the data from the components. For example, you may have a spatial component (x y position) that zombie entities contain, then you will need a Movement subsystem that updates the zombie's spatial coordinates every game tick.
Subsystems may also manipulate data from multiple components. This is needed for interactions between components. E.g. Change the graphics component's data based on your spatial component's data, so that your renderer knows where to draw your zombie.
I've just provided simple examples based on my understanding, but if you are interested I encourage you to read more about this topic starting with the link above.
One implementation of entity system involves separating data from functions. So, components will only contain fields, and subsystems will contain the logic that uses the data from the components. For example, you may have a spatial component (x y position) that zombie entities contain, then you will need a Movement subsystem that updates the zombie's spatial coordinates every game tick.
Subsystems may also manipulate data from multiple components. This is needed for interactions between components. E.g. Change the graphics component's data based on your spatial component's data, so that your renderer knows where to draw your zombie.
I've just provided simple examples based on my understanding, but if you are interested I encourage you to read more about this topic starting with the link above.
#7 Members - Reputation: 3332
Posted 11 December 2012 - 02:10 PM
My main question is if a component system is an efficient design for creating Entities with similar, but not exactly the same, properties.
The description you gave was entities with the exact same properties, but with simply different values.
Component systems are good for entities that have similar components but sometimes not all of them, or sometimes those and a few more.
#8 Members - Reputation: 1566
Posted 12 December 2012 - 01:39 PM
Hi john,
I've done some work with Entity/Component Systems (check my journal, linked in my sig for some articles). For what you are doing, I think your Zombie Components and Systems would be something like this (where the components are only data):
Zombie Entity:
Physical Component - stores where the zombie is, it's velocity, and any other physical properties that might affect it.
Renderable Component - stores what is used to display the zombie. It might be a single image, or it might be a list of animation images, and it stores the state of the animation
Vitals Component - Stores the vitals of the zombie; health, stamina, etc.
Weapon Component - Stores the weapon the zombie uses to attack, a Claw, Acid Spit, etc.
Zombie-Behavior: This component would store the data about the zombies behavior. This could be Aggresive, Intelligent, Random, etc. but it defines how the zombie acts.
Then you create systems that act on these components.
Rendering System - Handles rendering any entiity with the renderable Component.
Movement System - Handles moving any entity with a Physical Component around on the map
Weapon System - Handles firing of weapons
Zombie System - Handle how the zombies act
Damage System - Handles any entity with a Vitals Component.
That's kind of how I see Components and Systems for your game. My Escape System acts like this. You can find an article on it here
Good luck!
I've done some work with Entity/Component Systems (check my journal, linked in my sig for some articles). For what you are doing, I think your Zombie Components and Systems would be something like this (where the components are only data):
Zombie Entity:
Physical Component - stores where the zombie is, it's velocity, and any other physical properties that might affect it.
Renderable Component - stores what is used to display the zombie. It might be a single image, or it might be a list of animation images, and it stores the state of the animation
Vitals Component - Stores the vitals of the zombie; health, stamina, etc.
Weapon Component - Stores the weapon the zombie uses to attack, a Claw, Acid Spit, etc.
Zombie-Behavior: This component would store the data about the zombies behavior. This could be Aggresive, Intelligent, Random, etc. but it defines how the zombie acts.
Then you create systems that act on these components.
Rendering System - Handles rendering any entiity with the renderable Component.
Movement System - Handles moving any entity with a Physical Component around on the map
Weapon System - Handles firing of weapons
Zombie System - Handle how the zombies act
Damage System - Handles any entity with a Vitals Component.
That's kind of how I see Components and Systems for your game. My Escape System acts like this. You can find an article on it here
Good luck!
My Gamedev Journal: 2D Game Making, the Easy Way
---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)
---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)
#9 Members - Reputation: 179
Posted 13 December 2012 - 12:00 AM
Hey everyone, thanks for all the useful comments! I've decided to first implement a basic Entity system, and then redesign using the component system. I think doing it in this order would help me gain a better perspective on the situation. @BeerNutts, I'll definitely be referencing your post when I start redesigning!
Thanks guys!
Thanks guys!
Edited by johnmarinelli, 13 December 2012 - 12:24 AM.
#10 Members - Reputation: 188
Posted 13 December 2012 - 10:42 AM
Hey, I was just reading this and it made me think of an article I have here in Game Programming Gems 4. The article is called "Effient MMP Game State Storage" by Justin Quimby from Turbine Entertainment Software.
The basic idea of the article is representing entities using what he calls a "Qualities System"
He uses "Key - Value" pairs to represent a set of default settings for, say a zombie... and then when a modified zombie is spawned only the things that are different are added to the zombies "local" settings structure.
I'm not sure if this article can be found online, but if you can find it it could be very helpful. I keeps memory costs low, and seems really good.
Contact me via PM and I can see what info I can send or share that came with this book.
Hope this is helpful
Michael
The basic idea of the article is representing entities using what he calls a "Qualities System"
He uses "Key - Value" pairs to represent a set of default settings for, say a zombie... and then when a modified zombie is spawned only the things that are different are added to the zombies "local" settings structure.
I'm not sure if this article can be found online, but if you can find it it could be very helpful. I keeps memory costs low, and seems really good.
Contact me via PM and I can see what info I can send or share that came with this book.
Hope this is helpful
Michael
Michael RhodesTiger Studios Web Designhttp://tigerstudios.net
