Jump to content
  • Advertisement
Sign in to follow this  
space_traveller

Controlling entities

This topic is 4842 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Yesterday I decided to use MVC for my game (after long time of struggling with entity hierarchy design), and as I'm finally getting some grasp of it, it's starting to feel a very natural way of doing things. The game is a 2D-space shooter, but it's gonna be quite a complex and changing one, so I really wanna good design. Now at this point of my game design, I know that I'm gonna have only Astronauts and SpaceShips that the player can control. But i've noticed that my game has already changed a tremendous amount from what it was originally gonna be - so I've really decided to make things as flexible as possible. I'm using Java, and trying to use interfaces & abstract classes heavily (though I'm still in the process of understanding the interfaces - or using them correctly). Currently all SpaceShips implement the Firing interface, even though there are spaceships - like transports - that can never fire. And the SpaceShip class has a Cannon (which isn't necessarily used). Is this bad? My idea would be to make these end-of-the-hierarchy classes final (SpaceShip, Asteroid, Astronaut) and define the actual entities in XML and customize them through Cannons, Thrusters, Generators etc. I also thought of having these methods in Entity-class: add(Entity); remove(Entity); Entities extending AbstractEntity would simply throw a RuntimeException("Illegal operation) and AbstractComplexEntity would add them to list and manage them. ComplexSpaceShip would implement SpaceShip and have an SimpleSpaceShip I think this was a Composite pattern, but I've never used it in practice, but it feels like a good way to build large spaceships/stations etc..? Now thinking about the design of controllers, to be honest, I'm not actually even sure how I'll implement them yet. But I guess that AIControllers just use the my (forthcoming) AI-package (which has low-level AIPatterns and higher-level Tactic(?) objects - which consist of AIPatterns) and PlayerControllers simply control the model from the input they receive from Keyboard and mouse. Does this sound good? Now i'm already worrying where do squadrons and formations fit in, but I guess I should do first things first. I was thinking to make controllers like this: Controller ---AIController -----AIThrustableController (shared functionality for thrustables) -------AIAstronautController -------AISpaceShipController ---------AIFiringSpaceShipController (???) ---PlayerController .... Controllers would be created by ControllerFactory which would have: - registerController(Controller controller, Entity entity); - createAIController(Entity entity); - createPlayerController(Entity entity); Should I pass entities to Controllers, or define a Controllable interface? Now of course I could then make Entity implement Controllable, but I don't know if I want to make all my entities Controllable (I guess not). Maybe I should create an interface ControllableEntity but then I'd have to create another abstract base class like AbstractControllableEntity because I guess controllables have many things in common, that I dont want to reimplement in each Controllable. Wow, I wonder if anyone has patience to read through all this but I'd be very interested in any kind of feedback/expericences/pitfalls of the above.

Share this post


Link to post
Share on other sites
Advertisement

Hmmm, I'm not OOP expert etc., but I have some experience in coding games using OOP, so maybe what I'll say will be useful to you (and maybe not).


IMHO you have planned just too many classess.

I.e: Controller, AIController, AIThrustableController, AIAstronautController, AISpaceShipController, AIFiringSpaceShipController, PlayerController etc. <--- that's hellovalot, they're too "vertical", and I have some suspections why you ever thought about it that way.

Sorry for stupid question, but... do you know what virtual functions are and where they should be used? If answer is yes, then how often were you previously using them? I mean, you've written nearly ten paragraphs about interfaces, classess, OOP etc., and there's no word virtual in them! And polymorphism is generally, to what you should strive in your OOP designs.

As for controlers, IMHO, there should be three controllers: IController, PlayerController and AIController. IController would be abstract class, with pure virtual methods, especially: Update().
That Update() method would be implemented in PlayerController to update player ship, according to keyboard data, physics etc. stuff. OTOH, AIController would have some additional member variables, that would tell you with what type of ship you're updating, and then, dealing accordingly.

Or, hmmm, better not - keeping type variables in classess is similiar to RTTI, and should be avoided if possible. Maybe try to construct your ship moving algorithms in a way, that they can take input variables, ie. ship_speed, ship_armour, ship_can_fight, ship_laser_power, shit_has_thrusters etc. and output what ship should do, regardless of its type.


General tip: When designing your class hierarchy, think whether it will be useable, will you loose to much time managing all those classess, and do they help you in anything, or do they actually cloud the issue. OOP is not the Holy Grail of programming, and if over-used, Bad Things may happen... ;-)


Btw, how long are you programming generally, and how long are you programming in Java?

[Edited by - Koshmaar on August 9, 2005 5:16:33 AM]

Share this post


Link to post
Share on other sites
Quote:

IMHO you have planned just too many classess.

I.e: Controller, AIController, AIThrustableController, AIAstronautController, AISpaceShipController, AIFiringSpaceShipController, PlayerController etc. <--- that's hellovalot, they're too "vertical", and I have some suspections why you ever thought about it that way.

Sorry for stupid question, but... do you know what virtual functions are and where they should be used? If answer is yes, then how often were you previously using them? I mean, you've written nearly ten paragraphs about interfaces, classess, OOP etc., and there's no word virtual in them! And polymorphism is generally, to what you should strive in your OOP designs.

Sorry, I was supposed to make interfaces/abstract classes italic but I forgot. So the Controller, AIController and PlayerController are supposed to be abstract classes and contain more or less virtual functions only. The idea of AIThrustableController was to define just basic functionality for both astronauts and spaceships, as they both can be thrusted. And in Java, every method is virtual unless explicitly made "final". ;)

Quote:

General tip: When designing your class hierarchy, think whether it will be useable, will you loose to much time managing all those classess, and do they help you in anything, or do they actually cloud the issue. OOP is not the Holy Grail of programming, and if over-used, Bad Things may happen... ;-)

Yeah, I've been thinking of that too lately - that I should just hack a half-finished version of the game together so I'd get more insight of things, this is my first game after all. Oh and I guess I've been programming for something like three years now.. and Java's the only language I know and started with.

Share this post


Link to post
Share on other sites
IMHO, MVC does not fit well with games. The "model" is complex and dynamic, there is usually just one "view", and the "controls" and their interactions with the "model" are complex and dynamic.

Compare that to an archetypal MVC app -- Maya. The "model" is simply data -- the DAG and its contents, there are dozens of "views", and the "controls" directly modify the data contained in the "model".

Share this post


Link to post
Share on other sites
Sorry for my first, incompleted reply - pressed "Reply" accidentaly, and couldn't modify it, because GameDev server hang up. Now it's been fixed.


Quote:

The idea of AIThrustableController was to define just basic functionality for both astronauts and spaceships, as they both can be thrusted. And in Java, every method is virtual unless explicitly made "final". ;)


Yes, I know Java :-) But if you start defining classess for combinations of all things that your objects can do or what they contain... that would be BAD. Though generally inheritance and classess are good to use, sometimes it's better to use plain member variables.

Of couse, those member variables can be objects of other classess - and you'll be using aggregation - what generally, is the preffered way of doing OOP. Not kidding.


Quote:

Yeah, I've been thinking of that too lately - that I should just hack a half-finished version of the game together so I'd get more insight of things, this is my first game after all.


First game? Man, you start high... my first game was pong for 4 players, without any complex OOP, using C++ and Allegro - and it took me half year to finish it. Second game was tetris - my skills improved, I used more OOP, library changed to SDL etc. and it took me 3 months to finish it.

Now, if I was you... hmmm, I would read this. Don't know, maybe you've read it before. I did ;-) and it helped me tremendously.

Quote:

Oh and I guess I've been programming for something like three years now.. and Java's the only language I know and started with.


Your 3 years of programming show that you're ready for game programming, but sorry to write it, you only know Java, you think in Java, and it's visible :-/ Java has not so very good reputation among programmers who use other languages - one of reasons being that it's way too much OO. You learned for 3 years this language, and unfortunately, it spoiled your desings.

Don't know, if you have time, maybe learn a little bit of C++? You already know Java, so learning C++ will be piece of a cake. If not, then I recommend reading more sites like this one: Game Architect and you'll quickly know, when it's good to use OOP, when it's not advised, and when it's absolutely evil to use OOP. Yup, sometimes procedural programming also has its uses.


Btw, sorry for giving so much general answers un-connected with your original space-shoter questions, but IMHO first you need help in getting rid of Java's mentality, and then - help in game design :-)

Share this post


Link to post
Share on other sites
Quote:
...Yes, I know Java :-) But if you start defining classess for combinations of all things that your objects can do or what they contain... that would be BAD. Though generally inheritance and classess are good to use, sometimes it's better to use plain member variables.
I disagree defining classes for what objects contain or in what combinations of functionality they have is very OO Design. The point of the patterns he is attempting to use is to allow for an extendable program. If his ships will do things like warp to different locations or pickup bonuses like new engines an such then he is heading the right direction. If he has a limited number of things that a Ship can do i.e a Ship can move, fire, be damaged, and hold hardware. Then he would want to make Firing an Interface also he would want to make a Movable interface since he would want customized ships which will act differently when firing or moving. (ie. Ememy dreadnaughts have increased speeds compared to scout vessels. )

space_traveller: a good principle to think about when designing and Object Oriented Program is where is your code going to change and what functionality is likely to remain the same. Will your setup code remain the same every time the game is run or will you have different options. For the entity system, will your ships have many different actions that they can perform ie. firing, moving, recieving damage, warping, colliding. Are you going to have many different types of ships that have similar behavior.

For your transport you do not want it to implement an interface that really doens't belong to it. So a Transport would Extend or inherit from AbstractSpaceShip and implement Movable, Damagable, Collidable. For the AI you would probably want like Koshmaar suggested a limited number of Controller objects. Perhaps one Controller to handle the movement and calling the Movable interfaces move method. The controller would probably be abstract and come in two concrete flavors HumanController and AIController you would then register a SpaceShip with the concrete Controllers that way they will be able to move, fire, recieve damage, check for collisions, and warp to new locations, etc...

If you require some more design help I would suggest posting in the Software Engineering Forum.

Quote:
Your 3 years of programming show that you're ready for game programming, but sorry to write it, you only know Java, you think in Java, and it's visible :-/ Java has not so very good reputation among programmers who use other languages - one of reasons being that it's way too much OO. You learned for 3 years this language, and unfortunately, it spoiled your desings.

That was a little harsh! I'm sorry to say it but you only know C/C++ but think that since you do you know Java. Your reference to him not using the term Virtual functions is a big giveaway. He stated that he was using java! In java virtual functions are replaced by the abstract key word. Interfaces are comprised of all abstract methods. Or in C/C++ language pure virtual functions.

Quote:
Don't know, if you have time, maybe learn a little bit of C++? You already know Java, so learning C++ will be piece of a cake. If not, then I recommend reading more sites like this one: Game Architect and you'll quickly know, when it's good to use OOP, when it's not advised, and when it's absolutely evil to use OOP. Yup, sometimes procedural programming also has its uses.
The only time would be evil in my mind to use OOP is when you don't plan on making any additions to your work whatsoever or you don't want anyone able to make modifications to your program. In general if your program/game is easily modifiable at the coding level it almost certainly implements an OOP design. Because without a modularization of your code it will be extremely hard for anyone to just come in and change something without knowledge of your coding style.

Share this post


Link to post
Share on other sites

Quote:

That was a little harsh! I'm sorry to say it but you only know C/C++ but think that since you do you know Java. Your reference to him not using the term Virtual functions is a big giveaway. He stated that he was using java! In java virtual functions are replaced by the abstract key word. Interfaces are comprised of all abstract methods. Or in C/C++ language pure virtual functions.


I know I must watch out for what I'm saying, sometimes I say not very nice things. Sorry. But that wasn't intended to insult.

As to me, I have much experience in C++, Delphi, Pascal, also I know Java and assembler - and I *know* that all functions in Java are virtual. But he concentrated on listing all those classess and interfaces, and I started being suspicious - does he have experience in using virtual functions? Also, it doesn't matter if functions are virtual, when they aren't used at all.


Quote:

The only time would be evil in my mind to use OOP is when you don't plan on making any additions to your work whatsoever or you don't want anyone able to make modifications to your program. In general if your program/game is easily modifiable at the coding level it almost certainly implements an OOP design. Because without a modularization of your code it will be extremely hard for anyone to just come in and change something without knowledge of your coding style.


[rant]
Believe me, everything is evil if overused. All methodologies - OOP, procedural, functional, generic, linear, structural etc. have their uses, places where should, and places where shouln't be used.


But lets stop that before we'll start another OOP vs. Rest Of The World flame :-) In fact, I'm a big fan of OOP, and from my experience, it's very good Good Thing to use. But don't overuse it(ie. like Java creators did), or you'll never end coding clean, flexible, functional, easy-to-use, properly structured, documented code, full of classess, interfaces, patterns, idoms, paradigms etc. which turns out to be absolutely useless, since you could write the same thing without all that stuff, in 3 days in C using functions and some structures ;-)

Once upon in time I was OOP fanatic. But after writing some games, it turned out that (over)using OOP everywhere isn't the wisest thing possible.

Btw, have you heard of Occam's razor and KISS?

Ok, ok, I'm ending ;-) sorry for hijacking this thread.
[/rant]

I agree with modularization, modification etc. part you said - that's certainly true. Space_traveller - using XML to store entities is also good thing. Three first paragraphs of 5MinuteGaming post are also good to read.

Share this post


Link to post
Share on other sites
Quote:

Yes, I know Java :-) But if you start defining classess for combinations of all things that your objects can do or what they contain... that would be BAD. Though generally inheritance and classess are good to use, sometimes it's better to use plain member variables.

Of couse, those member variables can be objects of other classess - and you'll be using aggregation - what generally, is the preffered way of doing OOP. Not kidding.

Yeah I guess you're right, I already dumped many irrelevant classes like Thrusters, Generators and replaced them with simple ints or floats and it made things a lot simpler.

Quote:

First game? Man, you start high... my first game was pong for 4 players, without any complex OOP, using C++ and Allegro - and it took me half year to finish it. Second game was tetris - my skills improved, I used more OOP, library changed to SDL etc. and it took me 3 months to finish it.

Well I made some silly tetris like year ago and a half-made arkanoid clone and then decided that I'm ready for something larger:)

Quote:

Your 3 years of programming show that you're ready for game programming, but sorry to write it, you only know Java, you think in Java, and it's visible :-/ Java has not so very good reputation among programmers who use other languages - one of reasons being that it's way too much OO. You learned for 3 years this language, and unfortunately, it spoiled your desings.

But the thing is, I like to think in Java :) I think the too much OO is just my problem - as I'm still unexperienced, and anyway, you could use static fields & methods for procedural style programming (what I use for some stuff).

Quote:

Don't know, if you have time, maybe learn a little bit of C++? You already know Java, so learning C++ will be piece of a cake. If not, then I recommend reading more sites like this one: Game Architect and you'll quickly know, when it's good to use OOP, when it's not advised, and when it's absolutely evil to use OOP. Yup, sometimes procedural programming also has its uses.


I'm trying to avoid c++ as I really like how clean and simple Java is, and I'm just gonna do indie stuff and not planning to get in the industry. And thanks for the link, I like to read that kind of stuff.

Quote:

a good principle to think about when designing and Object Oriented Program is where is your code going to change and what functionality is likely to remain the same. Will your setup code remain the same every time the game is run or will you have different options. For the entity system, will your ships have many different actions that they can perform ie. firing, moving, recieving damage, warping, colliding. Are you going to have many different types of ships that have similar behavior.

Yeah this is what I've tried to do, and I think this becomes a lot easier after finishing a first game.

As a matter of fact, after some thinking, I dumped the MVC and re-organized the whole entity hierarchy. I think that now I've gotten quite nicely the basic functionality covered. I'm too lazy to type the methods.

interface Asteroid extends VisualEntity, Damageable
interface Astronaut extends VisualEntity, Thrustable, Damageable
interface Beam extends VisualEntity
interface Bullet extends VisualEntity
interface Cannon extends VirtualEntity, Fireable
interface Container extends VisualEntity, Damageable
interface Damageable
interface Entity
interface Fireable
interface Mine extends VisualEntity, Damageable
interface Missile extends VisualEntity, Damageable
interface Moveable
interface SpaceShip extends VisualEntity, Thrustable, Damageable
interface Thrustable
interface VirtualEntity extends Entity
interface VisualEntity extends Entity, Renderable, Moveable, Comparable

There's also an abstract class for each of them (spaceships have few more). Now I also decided to completely dump the data-driven approach to load entities from XML, and thought to hardcode everything. After all my IDE compiles only the classes that have been changed in just a few seconds and with Java's ClassLoaders I should be able to easily reload them in the game, so I'd get kind of free scripting within a nice IDE. What do you think? Has anyone done this?

Oh and no I'm not offended of anything, after all I am still a noober and havent been discussing much of these things with anyone + I'm completely self-taught so there are probably many things i've missed or learnt the wrong way.

And thanks for the help!

Share this post


Link to post
Share on other sites
I always separate the model from the view because I want to have the flexibility to change the view once I have a working game. ie. the first view would be to test that the game mechanics work, the second view might be a basic view for a non-commercial release, and a third view might be needed if I wanted to fund a commercial version.

Share this post


Link to post
Share on other sites
There's also an abstract class for each of them (spaceships have few more). Now I also decided to completely dump the data-driven approach to load entities from XML, and thought to hardcode everything. After all my IDE compiles only the classes that have been changed in just a few seconds and with Java's ClassLoaders I should be able to easily reload them in the game, so I'd get kind of free scripting within a nice IDE. What do you think? Has anyone done this?[\quote]Using the Java Classloader to load in the Entities is a very good approach. I did the same thing with a Shape editor where the Shapes were a composite pattern and you could create a new class extended from AbstractShape class implement the paint method and then add the name of the shape as the next line to a file and vualla you have new shapes as well as a button on the toolbar. Now you don't have to use that exact scheme you can just search for all files within an entities directory or jar file and once you know the file names load all of them throught the classloader.

As far as the list goes, I'd probably go with making most of them abstract classes now you said you have abstract class for all of them. But if that is in addition to the interfaces then that is a little to much. I would go with the following approach where all your actually Entities are either abstract or concrete classes, and by concrete I mean you can instantiate the object.

--Interfaces--
interface Damageable
interface Thrustable
interface Firable
interface Moveable

--Abstract Classes--
abstract Entity
abstract VisualEntity extends Entity
abstract Container extends VisualEntity implements Damageable

--Either Abstract or plain Classes--
(abstract/concrete) Asteroid extends VisualEntity implements Damageable
(abstract/concrete) Astronaut extends VisualEntity implements Thrustable, Damageable
(abstract/concrete) Beam extends VisualEntity
(abstract/concrete) Bullet extends VisualEntity
(abstract/concrete) Cannon extends VisualEntity implements Fireable
(abstract/concrete) Mine extends VisualEntity implenents Damageable
(abstract/concrete) Missile extends VisualEntity implenents Damageable
(abstract/concrete) SpaceShip extends VisualEntity implements Thrustable, Damageable, Movable

Also, you can me the Cannon extend Container to hold Bullets of Missiles or Mines or a Beam. And SpaceShip would probably also extend Container. I would probably keep SpaceShip abstract as there are no generic SpaceShips. Also I'd keep Cannon abstract in case you wanted to make other cannons like:

-ParticleCannon extends Cannon
-AtomicCannon extends Cannon

Well, thats just how I see things would work you may have another way of the classes working together.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!