Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 27 Jun 2001
Offline Last Active Yesterday, 01:48 PM

#5230039 tile objects in 2D RPG

Posted by BeerNutts on 20 May 2015 - 08:42 AM

Considering you're making a tile based game, you should have an editor for creating your world.  So, the editor needs to be able to load the tiles, and give them unique ID's.  The ID's could just be numbers, with 1 being the 1st tile it loads, but the ID's need to match the tile persistently (ie, it can't change), so it should be saved in a file somewhere (hopefully with a know format, like JSON).  Then, when your editor creates your world, it just uses the Tile ID for the tile reference.  When your game loads the map, it will look at the tile ID, then look into the tile Id file, and it will know which tile image to load based on the Tile ID.


Alternately, you could use a well know Tile map editor instead of re-inventing the wheel, like Tiled (and use a SFML Tiled map loader too).

#5229878 Communication between objects and systems in Game engines.

Posted by BeerNutts on 19 May 2015 - 12:31 PM

Really depends on the architecture of your system.  You should have a generic system that handles all movable entities (since your npc's will also need to walk on the ground), and that system knows about the entity's location and velocity and will know about the object in the world and can work the physics interactions of those objects.

#5220499 How to implement skeletal animation in 2d game?

Posted by BeerNutts on 31 March 2015 - 09:46 AM

Check out spriter as well, it's seem very useful.

#5219318 How best to represent data required for static and animated sprites?

Posted by BeerNutts on 26 March 2015 - 08:41 AM

Couldn't a static sprite be represented as an animation with a single frame?  With that in mind, create an object that can hold your list of sprites, and the duration each sprite should be shown before moving to the next sprite.  For a static sprite the list would be 1 long, and the duration would be unimportant.


Although, I'm not sure that's what you really should send to an view, since you really should just give the view the sprites it needs to display NOW, which would be the proper sprite at it's current animation state, but I can't really say that since I'm not familiar with your framework.


Good luck!

#5217793 Card game Class Structure

Posted by BeerNutts on 19 March 2015 - 07:55 PM

Thank you very much for the responses everybody! Since i am quite new to this topic (and to programming in general), what would be the correct terms to Google for an example or maybe even a tutorial in C# for a compositional approach?

I think that's going to be the crux of the issue.  Building objects using components, and properly operating on them isn't as easy to grasp as some other methodologies, and, since you're a beginner, it's going to complicate the issue.


I don't know C# very well, but if you google "c# entity component system" you're bound to find a bunch of information to help you along.  Read as much as you can, and try to understand what's going on.


I believe it's going to be tough for you.  You might want to start simple, and limit the number of "options" of your cards, and make a simple, but fun, card based game.  Then, as you grow into game programming, you can build.


You're going to make mistakes, you're going to do things the wrong way, but you'll learn from it.  Read, program, and repeat, you'll get there.


Good luck!

#5217146 Card game Class Structure

Posted by BeerNutts on 17 March 2015 - 02:29 PM

This smells like a good place for using Component Orient Programming.  Build your objects using composition, not inheritance.  Component Based Entity Systems are pretty popular now, but I think, for creating cards, this would be a good place for it.


Good luck.

#5217064 Basic level scripting? (for a 2D shmup)

Posted by BeerNutts on 17 March 2015 - 07:15 AM

My 1st real game I made was a Shump, and my levels were scripted just like you mention, based on time.  Back then (~1999), I didn't know about XML, and json might not have been around, so I made my own script files.  You'll basically want to be able to denote in your level files when, what, where, and some other attributes (speed/direction, extra modifiers) for when objects appear on the screen.


If I were to do it again, I'd use json instead of rolling my own, but I didn't know any better.


You should do the same for all objects i your game, build them with a json script, so you define your enemies, backgrounds, upgrades in json, and, when you create your level script, it just references those tags.


Good luck and have fun, I know I did way back when.

#5216488 space invaders barriers implementation

Posted by BeerNutts on 14 March 2015 - 02:34 PM

I adjusted the bounding box's y size to be the difference between current position and last position.


Now for the algorithm that you posted earlier, there is a chance that the bullet intersects with the bounding rect, and there is black, but in the next frame, there is green and the bullet misses that part that it should hit, because the intersection test  is tested once... how do I fix that ?

You're going to have to work that out yourself, no more holding your hand.  Problem solving is the crux of programming, and you can do this one yourself, you've got all the hints.


Good luck

#5215870 space invaders barriers implementation

Posted by BeerNutts on 11 March 2015 - 11:41 AM


I've been struggling with implementing the space invader bullet to barriers. I wanted right now to blast a circle around, when the bullet hits the barrier and modifies the circle. As shown in the video, the algorithm looks wrong, http://youtu.be/VMBczCsP3J4 I have tried my best to debug it, but I've failed.

here is the algorithm:

// if there is intersection
if (IntersectsWith((*it)->BoundingRect, barrierRect))
// subtract (*it) bullet position from barrrier's rect 
int normX = (*it)->Position.x - barrierRect.x;
int normY = (*it)->Position.y - barrierRect.y;

// barrier image pixels 
uint32* ptr = (uint32*)pixels;
// height of the barrier
int y = 31;

for (int i = 0; i < 31; i++)
int pixelOffset = y + normX * 51;
int color = ptr[pixelOffset];
// look up the color if its not black, it should be green
if (color != 0xFF000000)
// delete the bullet
Bullet *bullet = *it;
it = ship->Bullets->erase(it);
delete bullet;
ship->Canfire = true;
isCollision = true;

// blast a circle around that bullet hit position
int radius = 9;
for (int y = -radius; y <= radius; y++)
for (int x = -radius; x <= radius; x++)
if (x*x + y*y <= radius*radius)
int j = x + normX;
int i = y + normY;
int pixelOffset = j + i * 51;
ptr[pixelOffset] = 0xff000000;
// go up


My guess is your bullet is moving so fast that, on update, the top point of the bullet moves multiple pixels, and it misses where it actually entered the barrier.  You need a method to check vertically along the y-axis from the last bullet's position.  The 1st pixel it hits that isn't black, then it should explode at THAT location (not at the location the bullet is).


Hope that makes sense.

#5214306 Placing enemies in the map/world

Posted by BeerNutts on 03 March 2015 - 03:47 PM

Depends on how you're game works, and how your map works.  Assuming it's constantly scrolling one direction, then the "location" in the map is really just a time from the beginning of a level.  So, you could just have a simple data file (using json, for example), that details when an enemy comes into the map, where it starts from, and possibly other values (it's initial velocity, etc.).


If you're using a map editor (like Tiled), then it should be easy to set locations within the map to place your enemies, and, once they come onto the screen, they become active.

#5212738 implementing entity component system in current engine...

Posted by BeerNutts on 24 February 2015 - 11:45 AM

Take a look at this topic.  We cover many of these same questions there.


Good luck!

#5212116 Help understanding Component-Entity systems.

Posted by BeerNutts on 21 February 2015 - 09:31 AM

One question, though: I want to get an explanation on what exactly is going on in these parts:
TComponent(TEntityId entityOwner) : EntityOwner(entityOwner) {}

TPosition(float x, float y, TEntityId entityOwner) : TComponent(entityOwner), X(x), Y(y) {}
What exactly should I google? The reference on structures does not cover this part. :-/


In this case, I'm using struct just as I would use a class.  The TPosition struct inherits from the TComponent struct.  In the initializer list, I call the parent class constructor (TComponent(entityOwner) in this case) with the entity owner id, so it will set the entity owner, and then I set the other values in TPosition.


Also, you should expound your example.  In your message struct, don't do the std::cout in the constructor.  Rather, create a MessageSystem function call, which would take the entities that have a message component, and do the cout in the MessageSystem.


Also, when assigning Entity Id's, just use a global that is incremented every time you create a entity.  that way it is guaranteed to be unique.


Take a look at this ECS framework, rather than creating your own: entityx

#5212100 Help understanding Component-Entity systems.

Posted by BeerNutts on 21 February 2015 - 07:47 AM

You a little off base on your understanding, but that's OK, considering your a beginner.  Depending on your experience level, you might not be quite ready for a Component-based Entity system.  But, I'll just try and cover the basics.


An entity is really just something that groups multiple components together, and, in game programming, these entities are typically things like can be represented in a game.  It could be represented by a unique integer id (so, every time a new entity is created, the id the entity gets is just incremented), but how the components are tied to the entity can take multiple forms.  For example, it could do this:


struct Entity
  int Id;
  std::vector<TComponent*> Components;

In this case, the entity actually holds the components it is made of.  But, you can also do it this way

typedef int TEntityId;
struct TComponent
  TComponent(TEntityId entityOwner) : EntityOwner(entityOwner) {}
  TEntityId EntityOwner;
struct TPosition : TComponent
  TPosition(float x, float y, TEntityId entityOwner) :
    TComponent(entityOwner), X(x), Y(y)
  float X;
  float Y;


In this case, the entity isn't really defined, just it's type, and each component created knows which entity owns it.


You typically wouldn't have components like "message" or "name".  A typical Entity, for example, an enemy spaceship, might be made up of these compoennts:

TPhysicalObject : This holds the spaceship's physical properties: size, location, velocity, mass, etc.

TEnemy : This component denotes this object as an enemy, and might have properties defining how the enemy moves and acts (does it dive at the player, or just shoot his bullets at a rapid rate?)

TWeapon : This component might define what kind of weapon the enemy has, and defines the type of bullet entities that the ship will create when it's fired.

THealth : This would just define what the health is of the enemy ship.

TAnimation : This would hold the enemy's animation data, which spires to display when, etc. 


Using just those components, you would create "systems" that act on these components, so, you would have a MovementSystem, that acts on all entities that have the TPhysicalObject component, and a EnemySystem that acts on all entities that have the TEnemy Component.


Realize, the gain you will get from using this system will really come from having many different kinds of entities, and you want to tweak them using an external data (json objects defining entities or components, etc.).  I'm not sure I would advise you trying this at an early stage in your programming career, but if you do, good luck and keep at it.


BTW, I have some articles in my journal (in my sig) covering some ECS details if you want to look over it.

#5210519 Enemy Bullets

Posted by BeerNutts on 13 February 2015 - 11:57 AM

I agree 2D shooters are silly if you are a serious person !, thanks for the -1.

Question ? : How many enemys do you have in screen ?, you might not have encountered this yet!


And suppose you explode all enemys at once ?, do you also play those sounds individual ?, i bet your speakers explode to ( especially with 64 or 128 channels playing at once )!

Now you have a -1 back from me, greetings.


Tip : dont drink alcohol, its bad for you.


I'm not sure why you think it's a "serious problem."  It's not.  Have you played a game where there are multiple people firing a gun at once?  I'm sure you have. How did they solve this "serious problem"?


If you are concerned about playing too many sounds at once, you can of course limit the amount of simultaneous sounds you play in your sound engine easily.  Whether 2 enemies or 100 enemies explode at the same time, you can limit the number of explosion sounds playing at once so your speakers don't "blow up to"  (Let me add, playing 128 channels at once won't cause your speakers to blow up, it has nothing to do with it.  it's the amplitude of the sounds coming out of the speakers that would cause them to "low up" not the number of mixed sounds signals coming out of the speaker at once).


Changing your game so enemies can only all fire at the same time is a terrible idea.  You must agree with that.  That kinda of shoot'em up would suck so bad.  I'm sure the OP doesn't want to make that kind of game.


I'm sorry you got upset about having a -1, but think before posting, if what you are suggesting would make a game terrible, there's a chance you'll get a -1.


Good luck.


P.S., drinking alcohol is fine, just don't make it a habit.

#5210498 Enemy Bullets

Posted by BeerNutts on 13 February 2015 - 09:29 AM

The list should make all ships fire at once, so you can play 1 sound, instead of milljon.

That's just silly.  What kind of crappy game has all the ships fire at the same time?


megallion, have your ships fire based on when you think the ships should fire, not because you might play a bunch of sounds around the same time.