Iterating through a list of a super class while allowing removal and cast as subtype - list

I am writing an engine for older arcade games. Along with the engine I am writing Space Invaders. The idea is to leave the classes that comprise the engine generic enough to be adaptable to a wide variety of arcade games and then specific games like Space Invaders extend the engine and fill in the specific parts.
I have a game engine developed into two abstract classes that create a game loop and update sprites based on the elapsed time in between loop successions. In a class of the game engine, I have a resource manager that contains lists of Sprites for enemies, enemy projectiles, and player projectiles. The resource manager currently stores these lists as ArrayLists of type Sprite. The game engine then, in an update method, iterates through these lists of Sprites and updates the Sprites.
I then began working on Space Invaders and realized I needed to extend Sprite for my player ship (lives, player states) and also needed to extend Sprite for the aliens(points, alien states). I can still store my player as a Sprite in the resource manager and when I need to work with the player in the SpaceInvaders class I can call ResourceManager.getPlayer() which returns the player as a Sprite, but then I can cast it to a Player.
The problem arises when I try to work with the aliens. I made an Alien class that also extends Sprite. When I create the aliens, I create them as Alien objects and then pass them to the resource manager which stores them in the ArrayList of type Sprite. In my collision check method I iterate through the list of aliens as such:
for (Iterator<Sprite> iter = resources.getPlayerProjectiles().iterator();
iter.hasNext();) {
boolean shotRemove = false;
Sprite sprite = iter.next();
for (Iterator<Sprite> iterAlien = resources.getEnemies().iterator();
iterAlien.hasNext();) {
Sprite alien = iterAlien.next();
if (collision(sprite,alien)) {
shotRemove = true;
iterAlien.remove();
}
}
if (sprite.getY() < 100 || shotRemove)
iter.remove();
}
At this point I would like to use methods exclusive to Alien like writing score += alien.getPoints() below the shotRemove = true line. But the method only knows of alien as a Sprite because iterAlien is an iterator of type Sprite because resources.getEnemes() is a list of type Sprite. If I try to cast alien as an Alien I get a classCastException.
So in summary, I would like to be able to keep the lists in the resource manager as generic as possible (Sprite) because the engine only knows of Sprites, but be able to work with the lists when I iterate through them in game specific classes as the class which extends Sprite (in this case, Alien).
I have tried using generics like E extends Sprite in the resource manager, but I cannot get that to work. I have read a little bit about wildcards (?) but I don't think that is what I want to do. I would think E extends Sprite is what I want because then the list is of some generic type that extends Sprite and could be treated as either a Sprite (in the engine) or as the E (Alien in SpaceInvaders).

You can't guarantee that the Sprite is an Alien, so use instanceof, something like:
if (sprite instanceof Alien) {
Alien alien = (Alien)sprite;
// do something with alien
}
Generics can't help you further here.

Related

Ways to implement a game logic layer into current 2d game architecture

I'm developing a 2d fighting game in c++ (for learning purposes) and I'm having a hard time figuring out how to properly implement game logic. For a quick overview of my current architecture, I have component classes that act as data holders and I have 'systems' which are just functions designed to act on those components. I have a scene class which holds an array of fighters that are currently in game and this scene is passed to individual sub-systems which then can freely act on fighter components, updating fighters state:
//Add a fighter object to array of fighters and set starting position
scene.CreatePlayerFighter(160.0f, 0.0f);
scene.CreateAIFighter(80.0f, 45.0f);
gameWolrd.Init(scene);
Renderer.Init(scene, window);
AI.Init(scene);
//etc...
//Game loop
while (true)
{
Input.Update(scene);
Physics.Update(scene);
AI.Update(scene);
//etc....
window.ClearBuffers();
Renderer.Update(scene, colorShaderProgram);
window.SwapBuffers();
}
Again, inside each sub-system (Renderer, AI, Input, etc.) all fighter components are being passed into system functions and spit back out with new values which are then inserted back into fighters:
void Physics::Update(Scene& scene)
{
for (Fighter& fighter : scene.fighters)
{
//Update fighter position based on fighter's current velocity which has been set by input
TransformComponent newFighterPosition = System::MoveFighter(fighter.GetComponent<TransformComponent>(), fighter.GetComponent<VelocityComponent>());
//Insert new TransformComponent to update fighter's position
fighter.Insert<TransformComponent>(newFighterPosition);
}
}
This current architecture has the advantage of being loosley coupled in that I can add and remove systems very easily without effecting the fighter class or it's components directly. The problem is everything is hopelessly serial, as my scene is passed into each sub-system one by one to update fighters. I mention this problem because one of my thoughts to implement a game logic layer was to have higher level classes just call specific game engine system functions directly like physics.MoveFighter(TransformComponent, VelocityComponent, float amountToMove); where I can add additional parameters to give the user at the game logic layer level more control. Of course doing things this way means system functions would be called and invoked in any order the user of the game logic saw fit. Would there be a way to still implement a game logic layer in this way and maybe queue up all calls and reorder them to run correctly within the game engine? Or would there be a better way to try and implement game logic within my current architecture?
As I see your goal, you could just store movementFactor field in fighter, and allow to change it from game logic layer. In Physics class delta is then mul-ied by that field. If you use component like system you probably do not want to update components manually, only operate with data.
Logic update order is a complex problem: imagine a chicken falling on an egg. It happens that in the same frame chicken touches the egg and egg is ready to show us new little chick. What should be executed first? That depends on what is updated first: physics or eggs, and on the fact whether reactions apply immediately. The best scenario (most fair usually) would be for them not to apply immediately, but form a stack of objects (components) state changes, for them to be resolved independently after the action phase.
Also make sure you do not want to stick with existing entity system like entityx.

VTK - Interacting with multiple objects

I am fairly new to VTK and I really enjoy using it.
Now, I want to interact with multiple objects independently. For example, if I have 5 objects in a render window, I want to only move, rotate and interact with the one selected object; whilst the rest of the 4 objects stay where it is.
At the moment, the camera is doing the magic and as I rotate the independent object, other objects move at the same time and I don't want that to happen.
I also want to store all the objects in memory.
I intend to use C++.
This is my sort of class structure...
class ScreenObjects
{
vtkActor (LinkedList); // I intend on using a linkedlist to store all the actors
public:
ScreenObjects(); // Constructor. Initializes vtkActor to null.
void readSTLFile(); // Reads the STL File
bool setObject(); // Sets current object, so you can only interact with the selected object
}
I am missing quite a lot of functions and detail in my class, as I don't know what else to include that would be of use. I was also thinking of joining two objects together, but again, I don't know how to incorporate that in my class; any information on that would be appreciated.
Would really appreciate it if I could be given ideas. This is something of big interest to me and it would really mean a lot to me, and I mean this deep down from my heart.
First of all you should read some tutorials and presentations like this one for example:
http://www.cs.rpi.edu/~cutler/classes/visualization/F10/lectures/03_interaction.pdf
I say that cause it looks like you're currently just moving the camera.
Then you should look into the VTK examples. They are very helpful for all VTK classes.
Especially for your problem have a look at:
http://www.vtk.org/Wiki/VTK/Examples/Cxx/Interaction/Picking
Basicly you have to create a vtkRenderWindowInteractor derived class to get the mouse events (onMouseDown,onMouseUp,onMouseMove,...).
And a vtkPropPicker to shoot a ray from your mouse position into the 3D view and get the vtkActor.
Now you can store onMouseDown inside your vtkRenderWindowInteractor derived class the vtkActor you'd like to move and the currentMouse position. When the user release the mouse (onMouseUp) just get the new mouse position and use the difference of the onMouseDown/onMouseUp positions to modify the vtkActor position.

Game object with composition and CCSpriteBatchNode

I'm currently developing a game with cocos2d and box2d on iPhone.
I read a lot of articles concerning game code organization, game objects structure etc.
I first started developing my game objects by inheriting from a base class itself inheriting from CCSprite.
I had a CCSpriteBatchNode to draw all the game items, which the player can interact with, in one draw call. This was easy because my Item class indirectly inherit from CCSprite so I could easily add my items to the CCSpriteBatchNode. And on top of that I could rely on cocos2d to retain my objects.
After I read the articles, I understood the need to refactor my code with a more composition oriented style rather than the inheritance style.
So I went with a GameObject base class inherited from NSObject and having properties such as one or more CCSprite, one b2Body etc.
The problem I'm facing now is that I can't directly add my GameObject to the CCSpriteBatchNode anymore. I first thought I could easily fix the problem by adding the sprite property of the GameObject to the CCSpriteBatchNode. It's ok but who retains the object owning the CCSprite ? How can I easily access the original object from the CCSprite (are userData/Object ok) ?
Should I create an array retaining my items ?
I'd like to know how you would use a CCSpriteBatchNode with such a game object structure ?
There is already a thread about that which is unanswered and I'd really like to hear about the subject. Not a straight answer but some elements to go further.
Thanks.
Personally I don't recommend using NSObject as the base class for cocos2d classes anymore. Simply because you lose some cocos2d convenience features such as scheduling and you can easily shoot yourself in the foot, memory-management wise.
What you want is a setup where the scene has one or more sprite batch nodes. You can consider them layers for your sprites. Your actual game objects (consider them to be MVC controllers) deriving from CCNode can be added anywhere, typically directly to the scene.
scene
+ batch node 1
+ sprite 1
+ sprite 2
+ sprite n
+ batch node 2
+ sprite 1
+ sprite 2
+ sprite n
+ game node 1
+ game node 2
+ game node 3
+ game node n
The thing to keep in mind is that each game node has one or more sprites as instance variables, but they're not childs of the node. So for example the game node 1 class might look like this:
game node 1 class
CCSprite* sprite1; // instance variable
CCSprite* sprite2; // instance variable
Now when you init game node 1 and its sprites, you add the sprites to the appropriate sprite batch node. Typically you will want to access your scene like a singleton to get access to its sprite batch properties.
sprite1 = [CCSprite spriteWithSpriteFrameName:#"doodle.png"];
[[scene sharedScene].batchNode1 addChild:sprite1];
sprite2 = [CCSprite spriteWithSpriteFrameName:#"splash.png"];
[[scene sharedScene].batchNode2 addChild:sprite2];
Note that you do not need to retain the sprites as long as they are children of the sprite batch node. The addChild method retains it for you. Actually, it just adds it into an array which does the retaining. Also, if you're still thinking about "retain", by all means start using ARC.
You do not need to figure out how to access the sprite in the sprite batch. It's available as an instance variable of your game node class, and if you wish, you can also make it publicly available to other classes as a property.
The game node class obviously runs all the object's game logic, including positioning and otherwise modifying the sprite's properties. The only thing you need to take care of in the game node class is that you remove the sprites from the batch node, otherwise it may be leaking. To do so, override the cleanup method:
-(void) cleanup
{
[sprite1 removeFromParentAndCleanup:YES];
sprite1 = nil;
[sprite2 removeFromParentAndCleanup:YES];
sprite2 = nil;
[super cleanup];
}
It's important to set the variables to nil because there may be code running after cleanup, including the code in the dealloc method. You could also remove the sprites in dealloc but depending on your setup, dealloc may not even get called because of the references to the sprite the game node class is still holding. Therefore it is generally safer to use the cleanup method if the sprites are not children (or grandchildren) of the game node class itself.

endless runner game like dino rush object placement in cocos2d

My game is mostly already completed, but I need some changes related to the placement of objects. I have the same objects like the dinorush game. Like (fruit, block, missile, ball etc). I need proper placement of all objects like in the dino rush game. Currenly I am using random positions and movement of objects. I have not used any physics in my game. Also if I design placement using a tile map, then can we have magnet effects when my player stands near to the banana object? (I mean all banana automatically are attracted by the player)
Please help me. I am newbie in cocosd. This is my first game in cocos2d.
You can add a new class inherited the ccNode named magnet(banana) then add it to your game.Calculate the distance between the player and the banana.If the distance is less than the number you want, then move it to the player.
-(void)update:(ccTime)delta
{
float distance = ccpDistance(self.position, player.position);
if(distance < d){
CCAction *action = [CCMoveTo actionWithDuration:1.0f position:player.position];
[self addChild:action];
}
}

Game screen management

I am working on a screen manager for a miniature game engine, and so far I cannot find a proper solution to managing screen objects without using the 'blob' for each one of the screens. Is blob tolerable in such circumstances where I need a list of renderable objects in one controller?
I would consider using the MVC pattern in this situation. Otherwise, if you're not careful, it's very easy to end up with a bunch of spaghetti code where the screen code is reaching into the game code, and vice versa.
I have recently coded something you might call a "screen manager".
I started with the idea that, whatever game I make, the render system is going to be pretty much the same in terms of how to render (how to manage the hardware). The thing that changes is what is rendered, and how to draw it (do I want a box or a circle or a bitmap.. representing what... etc).
So basically the "game state" is responsible for knowing how to render itself, and should do so when given a render surface from the screen manager or graphics system (It should also be responsible for other things like knowing how input, physics, etc act upon itself).
I implemented it with a singleton for the GraphicsSystem object, which was called something like this:
GameState gs;
Graphics::System().Init(DOUBLE_BUFFER, 640, 480);
...
while(still_looping) {
...
// When it is time to render:
Graphics::System().RenderGameState(&gs);
}
And how, you ask, does the Graphics::System() singleton know how to render the game state? It knows because the game state is inherited from a listener exposed by the graphics system...
//within GraphicsSystem.h...
class BaseRenderer
{
public:
virtual void Render(BITMAP *render_surface) = 0;
};
//GameState defined with:
class GameState : public BaseRenderer
{
public:
void Render(BITMAP *render_surface);
...
You can do this with nearly all the subsystems... (probably not timing, as it is needed in the game loop).
Why singletons? Well, it is C++ and I'm assuming there is only 1 screen, or graphics subsystem to render with. I'm not sure if you are using multiple screens, or a mobile phone or a console. The other way I would do it is to have the graphics system as static global variables in a separate file, giving them file scope only, and having accessor functions in that file (my old C way of doing things).
The key though is encapsulation. Let your screen manager manage the hardware. Let your game state dictate how itself should be expressed.
If this misses the point, please clear up your question and I can edit the answer.