I'm trying to organised a good OO model for a game (being written in C#/XNA) but am uncertain of the 'best' way to deal with players, projectiles, enemies, and the environment. The main classes involved will be : level, player, tilemap, enemy, projectile. Which of the following would be, in general, the best option?
A 'level' class with a 'player' object, 'tilemap' object and lists of 'projectile' objects and 'enemy' objects, keeping ownership info for projectiles and iterating through the projectile list to check collision.
A list of 'projectile' objects in the base class of the 'player' and 'enemy' classes. These lists can be iterated through in the 'level' class. In this case I believe that dead players and enemies can't be destroyed until their projectile lists are empty.
Option 1's composition of projectiles in the level makes more sense to me, and is my current working method: when a player shoots, a flag is set and the projectile they fired is recorded. This flag is checked in the level class and the projectile is added to the list.
Additionally, in the case of option 1, what is the disadvantage of making the projectile list public shared so it can be easily added to?
Thank you.
Related
Currently I am trying my best programming a little video game in the style of the old Zelda games. However, I am having some trouble with the whole OOP style of thinking. To be more specific, I don't really know how to "design" the screens.
Let's say I have a class for my sprites and loaded a Wall-sprite to have a border for a certain area, should I make an extra "wall"-class, or is the wall being a "sprite" already enough? I thought it might be senseless to define an extra class since it would not have any different variables than the actual sprite class (as my wall IS only a sprite) so I didn't consider it to be a useful idea.
I am asking this because I have a little problem with the collision detection as well: What I currently do is loading a sprite for an object only once and rendering it multiple times at several locations. But the problem is that this causes the collision only to be detected at the last position the sprite was rendered at.
It gives me more problems when I render 2 cave-entrances somewhere but my game only checks for the 2nd entrance if I "entered" it.
So I thought making an extra "entrance"-class and creating 2 completely different objects of it that are treated separately might help, but should I then also create 30 objects for my wall-sprites?
Hmmm, there is really two questions, well three, but the OOP-thinking is too non-specific for a good question. So let's see if we can answer it by answering your valid ones.
Good OO Design is centered around "Patterns" (Common solutions to a variety of Problems) in the case of your sprite re-use in OO this would be known as a "Fly-weight" Pattern. Three important structural elements in good OO and understanding them is key to "getting it". They are:
Interfaces - They are free (relatively) of operational code, and provide only method and constructor signatures(generally) to allow for clean separation of coding concerns.
Classes - Only the reusable parts(ideally) of an object they are "the Mold or Pattern" that objects are instantiated (or patterned) from.
Objects - Instances (this chair or that chair as opposed, to Chair as an ideal) of the same form of Class (the ideal Chair). Objects (ideally) should keep as instance values only that which differentiates it from other instances of the same ideal.
However, because your original sprite is not an object you are having this collision problem, because it actually is the same instance rendered again and again, the graphics pipeline does not keep all of its previous locations as separate things it actual just stores pixels(usually), once they've been translated.
In this case if each instance is an object, each instance would have its location as a local instance variable(s), while its graphical representation and collision detection method would be common to all instances of the class.
Don't think of it as having 30 whole copies in memory at once, you only have thirty copies of the instance variables. This is true if you use OO or not; in a procedural solution to get proper collision detection you would have to maintain an array of all of the places you rendered that sprite and iterate through each time, further your code would be less cleanly separated and you would have to iterate through the array for every sprite interaction as well as for updating moving sprites. With OO you could handle this with one class method call that recurses it children.
A good class structure for this simple example might be:
An Abstract Sprite Class (abstract because you will never use a non-specific Sprite) containing only code common to all sprites
A Concrete Wall Sprite Class that extends Sprite, only the code for non-moving wall sprites.
A Concrete Trigger Sprite Class (whose graphic might be clear or null) for behaviors that need to be triggered in "open spaces"
A Concrete Agent Sprite Class for moving sprites (might implement a movable interface meaning all derivatives of the class have a move() method.
A Concrete Character class that extends agent for a movable sprite that is driven by user commands.
It may seem confusing at first, but it's actually cleaner, simpler, and more maintainable doing it the OO way.
:)
Starting simple, I have two objects -- a Player and a Game:
Game, Player
The Player sends its moves to the Game which processes them and updates the state of the Player (along with all other Players in the Game):
Player.do_move_X:
game.handle_move_X()
Game.handle_move_X:
player.take_damage(10)
Next, I add multiple Game types (subclasses of Game):
GameNormal, GameCaptureTheFlag, GamePractice
It's easy to change the behavior between different Game classes by simply re-implementing relevant methods in the subclass:
GamePractice.handle_move_X:
player.take_damage(5)
Next, I add multiple Player subclasses:
PlayerNormal, PlayerUnregistered, PlayerElite
Now it's getting tricky because the interaction between a Player and Game depends both on the Player's type AND on the Game's type. Now I end up with code looking like this:
GamePractice.handle_move_X:
if player is a PlayerNormal:
player.take_damage(5)
else if player is a PlayerUnregistered:
player.take_damage(5)
else if player is a PlayerElite:
player.take_damage(10)
(Analogously, I could place that sort of logic in the Player classes instead of the Game classes.)
Checking the type of the objects in a big switch or if-else statement is ugly. One option I have is to add explicit methods to the Player class to handle a particular case for each Game type:
GameNormal.handle_move_X:
player.take_normal_damage()
PlayerNormal.take_normal_damage:
take_damage(10)
PlayerElite.take_normal_damage:
take_damage(15)
GamePractice.handle_move_X:
player.take_practice_damage()
PlayerNormal.take_practice_damage:
take_damage(5)
PlayerElite.take_practice_damage:
take_damage(10)
This eliminates the ugliness from above but adds a new ugliness -- it bloats the Player classes with public methods to handle each case for each Game type.
Is there any better paradigm or design for dealing with this sort of case?
I don't know if it's the best possible approach, but I think that the visitor pattern could help here. The implementation depends on the language, but basically you have a Visitor interface with a visit method for Player and every subclass of it. Then, for every class in the Player tree, you would an accept method, or maybe just for the subclasses, if Player is interface/abstract:
PlayerNormal.accept(Visitor v):
v.visit(this)
PlayerUnregistered.accept(Visitor v):
v.visit(this)
PlayerElite.accept(Visitor v):
v.visit(this)
Finally, you would need an implementation of Visitor for Game and every subclass of it - again, maybe just for the subclasses. This could be a private class:
GameNormal.TakeDamageVisitor.visit(PlayerNormal p):
p.take_damage(10)
GameNormal.TakeDamageVisitor.visit(PlayerUnregistered p):
p.take_damage(10)
GameNormal.TakeDamageVisitor.visit(PlayerElite p):
p.take_damage(15)
GameCaptureTheFlag.TakeDamageVisitor.visit(PlayerNormal p):
p.take_damage(10)
GameCaptureTheFlag.TakeDamageVisitor.visit(PlayerUnregistered p):
p.take_damage(15)
GameCaptureTheFlag.TakeDamageVisitor.visit(PlayerElite p):
p.take_damage(15)
GamePractice.TakeDamageVisitor.visit(PlayerNormal p):
p.take_damage(5)
GamePractice.TakeDamageVisitor.visit(PlayerUnregistered p):
p.take_damage(5)
GamePractice.TakeDamageVisitor.visit(PlayerElite p):
p.take_damage(10)
Finally, you could have each Game subclass return an instance of its own kind of Visitor in a get_take_damage_visitor method, and, if you store a reference to the game in each player, you can do:
Player.do_move_X:
accept(game.get_take_damage_visitor)
Pros:
You don't need switchs or if-elseif constructs, and there are no downcasts.
In compiled languages, you get a compilation error if you forget to add some case.
You can define other visitors for similar problems.
Cons:
The logic may be somewhat confusing at first, although it is a well-established design pattern.
It may be a hassle to maintain if you have many subtypes of Player and/or Game - although this may hold for any possible alternative, and at least here the compiler helps you.
Lastly, depending on the language, you can implement a similar idea more easily if you have multiple dispatch (actually, the visitor pattern is kind of a trick to implement something like multiple dispatch in languages without it), or in C++ with a templated function.
I am new to XNA and this is a philosophical question. In most examples I have seen, game assets are defined as private class variables, loaded in the LoadContent method, and then drawn with the Draw method. If I have a large game with a lot of screens, there could be quite a bit of declarations at the top of this class.
With that said, here are my questions
Should I use the content pipeline over Texture2D.FromFile().
What are the advantages other than faster loading.
Should I call Content.Load(Of T)([some asset name]) outside the LoadContent() sub.
How are you handling loading assets for different screens? Are you declaring all assets at the top?
Thanks in advanced,
Eric
Using the Content Pipeline allows you to compile your textures with your binary, which saves space, load time, and protects your assets from editing/unauthorized use if you care about that. On the flipside, if you wanted an asset to be editable (like texture packs), FromFile() is effective. The file must exist in the expected directory with normal use of course.
It is good practice but ultimately your decision on where you choose to load content. Remember that content loading requires reading from disk, which is not something you want to be doing every frame for sure, and not really something we like doing during the game. You will want to set up your Game State Management so that content can be loaded completely during loading screens or game startup and not during the game itself. Of course, this is precisely what level loading screens are for! If you're very clever you can sneak loading in during pauses in gameplay, a la Metroid Prime's 'door loading'. Depending on the scope and assets of your game, though, you shouldn't really need to load dynamically like that.
Finally, about dumping assets: the answer is the great trope of OO programming: abstraction. If you have trouble organizing members then move them into an inherited class or a subclass as necessary (and only when sensible). In my game design I rarely have more than 2 Texture2Ds, 1 SoundBank, and perhaps a VertexBuffer/IndexBuffer per class. If I have designed things well, these are stored in a base class like "Sprite" from which any visual objects inherit. In my latest set of tools, I've gone one level deeper, so now it looks like "Player.base(which is Sprite).Animation.Texture" if you want to access the actual texture... but you don't need to because all animation/drawing is handled completely by the Animation class and updated by Sprite along with Position, Rotation, Scale, Bounding, etc.
So, break down your game into objects. If you are storing a Texture2D PlayerTex and Vector2 PlayerPos in your Game class and in Draw you are drawing PlayerTex at PlayerPos, you are not taking advantage of OO programming. Store PlayerTex and PlayerPos in a Player class which also defines every other aspect and behavior (methods) of the player. Now all you need in Game is Player myPlayer, and in Draw you call myPlayer.Draw(SpriteBatch .. etc). You can take it even further! Here are some classes pretty much every game will have: Entity (base class of all dynamic objects), Level (stores scenery and Entities of each level and handles their interaction), GameScreen (stores and increments its Level member upon completion of each), ScreenManager (stores a stack of Screens to update, like GameScreen, but also MenuScreen, PauseScreen, LoadingScreen)... The list goes on. At this point all your Game1 class does is update ScreenManager, and if you inherit ScreenManager from IDrawableGameComponent, you don't even have to do that.
I hope I haven't dived too far into the deep end of OO 101, but if you're having trouble keeping track of all the members of your main class, you should start to break things down. It's a fundamental OO skill.
If all else fails, learn to use the #region <name>/#endregion tags liberally. Honestly, use them anyway, they make everything better.
Context:
In a game, when each level is completed, a Rating is stored based on player performance: Poor, Good, Excellent.
The ratings are later used to evaluate the game play as a whole.
Question:
Should the Rating object contain a rating choice as an enum {RatingPoor, RatingGood, RatingExcellent} or should I make an abstract base class Rating with subclasses RatingPoor, RatingGood, RatingExcellent.
Other details
Ratings don't have complex behaviors, they are just generated from play stats at a very low frequency like every minute. They're assigned to a collection and averaged at the end of a game to generate a Rank (like Cadet, Pilot, Captain, Admiral). At the end of a level, the rating is shown as an icon (think stars, like in Angry Birds). They also get stored when the player pauses or suspends the game.
I would also appreciate knowing how to decide on enum vs. subclass, given this context.
This situation is basic enough that you should just use an enum. I typically use enum's when something can be represented by an integer (a mode, a setting, or in your case, a rating,). A subclass is only necessary if your ratings would include additional attributes or relationships.
I think that a subclass would be overkill for this situation, as it doesn't sound like you're attaching any particular methods to each rating. I would use an enum.
I'm no expert in software design, but I generally err towards using the simplest data structures that will get a job done-- in general, if the problem doesn't require you to have methods travelling with the data, a class would be more heavyweight than necessary.
I'll be as direct as I can concerning this problem, because there must be something I'm totally missing coming from a structured programming background.
Say I have a Player class. This Player class does things like changing its position in a game world. I call this method warp() which takes a Position class instance as a parameter to modify the internal position of the Player. This makes total sense to me in OO terms because I'm asking the player "to do" something.
The issue comes when I need to do other things in addition to just modifying the players position. For example, say I need to send that warp event to other players in an online game. Should that code also be within Player's warp() method? If not, then I would imagine declaring some kind of secondary method within say the Server class like warpPlayer(player, position). Doing this seems to reduce everything a player does to itself as a series of getters and setters, or am I just wrong here? Is this something that's totally normal? I've read countless times that a class that exposes everything as a series of getters/setters indicates a pretty poor abstraction (being used as a data structure instead of a class).
The same problem comes when you need to persist data, saving it to a file. Since "saving" a player to a file is at a different level of abstraction than the Player class, does it make sense to have a save() method within the player class? If not, declaring it externally like savePlayer(player) means that the savePlayer method would need a way to get every piece of data it needs out of the Player class, which ends up exposing the entire private implementation of the class.
Because OOP is the design methodology most used today (I assume?), there's got to be something I'm missing concerning these issues. I've discussed it with my peers who also do light development, and they too have also had these exact same issues with OOP. Maybe it's just that structured programming background that keeps us from understanding the full benefits of OOP as something more than providing methods to set and get private data so that it's changed and retrieved from one place.
Thanks in advance, and hopefully I don't sound too much like an idiot. For those who really need to know the languages involved with this design, it's Java on the server side and ActionScript 3 on the client side.
I advise you not to fear the fact, that player will be a class of getters and setters. What is object anyway? It's compilation of attributes and behaviours. In fact the more simple your classes are, the more benefits of an OOP you'll get in the development process.
I would breakdown your tasks/features into classes like that:
Player:
has hitpoints attribute
has position attribute
can walkTo(position), firing "walk" events
can healUp(hitpoints)
can takeDamage(hitpoints), firing "isHurt" event
can be checked for still living, like isAlive() method
Fighter extends Player (you should be able to cast Player to Fighter, when it's needed) :
has strength and other fighting params to calculate damage
can attack() firing "attack" event
World keeps track of all players:
listens to "walk" events (and prevents illegal movements)
listents to "isHurt" events (and checks if they are still alive)
Battle handles battles between two fighters:
constructor with two fighters as parameters (you only want to construct battle between players that are really fighting with each other)
listens to "attack" events from both players, calculates damage, and executes takeDamage method of the defending player
PlayerPersister extends AbstractPersister:
saves player's state in database
restores player's state from database
Of course, you game's breakdown will be much more complicated, but i hope this helps you to start thinking of problems in "more OOP" way :)
Don't worry too much about the Player class being a bunch of setters and getters. The Player class is a model class, and model classes tend to be like that. It's important that your model classes are small and clean, because they will be reused all over the program.
I think you should use the warpPlayer(player, position) approach you suggested. It keeps the Player class clean. If you don't want to pass the player into a function, maybe you could have a PlayerController class that contains a Player object and a warp(Position p) method. That way you can add event posting to the controller, and keep it out of the model.
As for saving the player, I'd do it by making Player implement some sort of serialisation interface. The player class is responsible for serializing and unserializing itself, and some other class would be responsible for writing the serialised data to/from a file.
I would probably consider having a Game object that keeps track of the player object. So you can do something like game.WarpPlayerTo(WarpLocations.Forest); If there are multiple players, maybe pass a player object or guid with it. I feel you can still keep it OO, and a game object would solve most of your issues I think.
The problems you are describing don't belong just to game design, but to software architecture in general. The common approach is to have a Dependency Injection (DI) and Inversion of Control (IoC) mechanisms. In short what you are trying to achieve is to be able to access a local Service of sorts from your objects, in order for example to propagate some event (e.g warp), log, etc.
Inversion of control means in short that instead of creating your objects directly, you tell some service to create them for you, that service in turn uses dependency injection to inform the objects about the services that they depend on.
If you are sharing data between different PCs for multiplayer, then a core function of the program is holding and synchronising that piece of state between the PCs. If you keep these values scattered about in many different classes, it will be difficult to synchronise.
In that case, I would advise that you design the data that needs to be synchronised between all the clients, and store that in a single class (e.g. GameState). This object will handle all the synchronisation between different PCs as well as allowing your local code to request changes to the data. It will then "drive" the game objects (Player, EnemyTank, etc) from its own state. [edit: the reason for this is that keeping this state as small as possible and transferring it efficiently between the clients will be a key part of your design. By keeping it all in one place it makes it much easier to do this, and encourages you to only put the absolute essentials in that class so that your comms don't become bloated with unnecessary data]
If you're not doing multiplayer, and you find that changing the player's position needs to update multiple objects (e.g. you want the camera to know that the player has moved so that it can follow him), then a good approach is to make the player responsible for its own position, but raise events/messages that other objects can subscribe/listen to in order to know when the player's position changes. So you move the player, and the camera gets a callback telling it that the player's position has been updated.
Another approach for this would be that the camera simply reads the player's position every frame in order to updaet itself - but this isn't as loosely coupled and flexible as using events.
Sometimes the trick to OOP is understanding what is an object, and what is functionality of an object. I think its often pretty easy for us to conceptually latch onto objects like Player, Monster, Item, etc as the "objects" in the system and then we need to create objects like Environment, Transporter, etc to link those objects together and it can get out-of-control depending on how the concepts work together, and what we need to accomplish.
The really good engineers I have worked with in the past have had a way of seeing systems as collections of objects. Sometimes in one system they would be business objects (like item, invoice, etc) and sometimes they would be objects that encapsulated processing logic (DyeInjectionProcessor, PersistanceManager) which cut across several operations and "objects" in the system. In both cases the metaphors worked for that particular system and made the overall process easier to implement, describe, and maintain.
The real power of OOP is in making things easier to express and manage in large complex systems. These are the OOP principles to target, and not worry as much whether it fits a rigid object hierarchy.
I havent worked in game design, so perhaps this advice will not work as well, in the systems I do work on and develop it has been a very beneficial change to think of OOP in terms of simplification and encapsulation rather than 1 real world object to 1 OOP class.
I'd like to expand on GrayWizardx's last paragraph to say that not all objects need to have the same level of complexity. It may very well fit your design to have objects that are simple collections of get/set properties. On the other hand, it is important to remember that objects can represent tasks or collections of tasks rather than real-world entities.
For example, a player object might not be responsible for moving the player, but instead representing its position and current state. A PlayerMovement object might contain logic for changing a player's position on screen or within the game world.
Before I start simply repeating what's already been said, I'll point towards the SOLID principles of OOP design (Aviad P. already mentioned two of them). They might provide some high-level guidelines for creating a good object model for a game.