General Programming Discussion / Help Me!

[Brad]

So... animated sprites used in games.... if the frames are not all the same size and the sprite/object is represented in the game world by (x,y) coordinates which is better:

Making the origin for the sprite by the bottom left rather than the upper left (which is not the default for anything) because most things grow up rather than down. Someone crouching and uncrouching, makes them go up from the ground not into the ground. Bottom left is not defualt for anything though and lots of logic must be changed.

Or...

Leave the (x,y) in the upper left but adjust the y value everytime the sprite changes frames so that the bottom of the sprite remains at the same point (ie on the ground).

How is this done "in the real world"?

[Nick]

You mean upper left not bottom, right?

[Brad]

Fixed to be actually what I was trying to say.

[Brad]

I think the real answer is to store an anchor location with each animation. That way you can choose depending on what makes the most sense for each animation.

If you were doing it "right" then you'd save an anchor point for each frame of the animation. But that is waaaaaayyy too much work. So I'll just use an enum to give 5 options to choose from. The four corners and the center. That should handle 99.99999999999% of all cases that I'll run into.

And... as all collision functions should be using a function call to get a "bounds" rectangle, it really doesn't matter where the anchor point is. I just have to make sure I don't make any dumb assumptions by doing straight (x, y) coordinate comparisons between objects (as they may not have the same anchor point).

Regardless of whether or not anyone actually reads it, I guess just trying to explain my problem to someone else allows me to figure it out. Thanks!

[Nick]

I often find that in trying to explain something that I find new perspective on it. Sometimes I explain the problem to imaginary-onlooker-A when I get stuck.

How is whatever you are working on going? From what I gather I would think it to be a 2D side scroller with some crouching involved. 

[Nick]

What would be a good way to store a world map of arbitrary size? It will be a 3d grid, more or less with each unit in the grid being solid, liquid or empty. I will need to be able to find an arbitrary point in order to test if there are world-blocks in a region for something to collide with.

I was thinking of just using arrays of arrays of arrays to just make a multi-leveled grid, but was afraid of that getting slow when trying to do collision detection with the ground. Or should I really be looking at only loading local-areas for detecting collisions? I am thinking about this all wrong?

[Brad]

It depends. How "full" is your world? If it is mostly empty you can get away with just specifying each object by its position and filling in the rest with generic stuff (grass,dirt,sand,etc)

If all the tiles are full with a large variety of stuff then yeah it'll need to be a matrix or array of matrices. Each cell representing a single tile in the game world. This eats up alot of memory but not actually much CPU power for collision detection and response. Each character, object, whatever only needs to check the immediate adjacent cells. How many that is depends on how big each object is relative to the size of the tiles. So its not too bad.

[Brad]

Does a player have a character... or is a player a character?

If a player has a character, then you can load up all the characters at the beginning and then just pass one to the player constructor when they start the game. Also you could do things like allow tag teams (you can switch characters).

If a player is a character then you could apply logic directly to the player without having to reference the character every time. However... when creating a player from a character you'd need to use a copy constructor of some kind and if multiple players chose the same character you'd have to duplicate copies of all the code, animations and whatnot...

I think I know the answer to this question, unfortunately that answer requires some code refactoring which is what is making me ask the question in the first place.

[Nick]

Is it a networked game, or split screen? If networked I would think the server would see everything as a character and each client would differentiate between the one they control and all the others. But I think I might be misunderstanding the question.

[Brad]

Is it a networked game, or split screen? If networked I would think the server would see everything as a character and each client would differentiate between the one they control and all the others. But I think I might be misunderstanding the question.

It actually neither, local play only and you share a screen. The issue is that there are bunch of characters to choose from and you have to load all the characters to allow the players to choose one. After they choose one if the Player class inherits the Character class you have to recreate all the character code and assets for the player by using the Player classes copy constructor.

Unless the Player class has a Character in which case you can just point the Player's character variable to the instance of the Character they choose that you have already created. Some variables can't be shared though like health and ammo. They need to be in the player class.

That probably still doesn't make any sense.

[Nick]

It makes sense. I think having a player class have a character that it's using is the way to go. But I have to experience to make that recommendation from.

[Brad]

Here is an example, in the game Metal Slug, when you die and the continue you are given an opportunity to choose a different character. If a player was a character you would have to recreate a whole new player for that probably losing useful stuff like score.

Anyway I have to refactor a bunch of code.

[Brad]

Gaaaaaarrrgh... that still isn't going to work.

OK... I have a multiple inheritance issue.

There are three classes involved:

CollisionObject -
An object which can have a collision with another box. Includes a bunch of standard functions and variables for collision detection... including location.

Character -
A character is the player's representation on the screen... there are a bunch to choose from. Think of a fighting game with a player select screen... Everything you can select on that screen is a "Character". A character also has states (Think Fire Mario, Big Mario, and small Mario) which are handled in it's set of CharacterStates (a class which doesn't really matter for this discussion).

Player -
A class representing a player. Can be more than one in the game. Has all the stuff relating to a player which isn't a character (which isn't a heck of a lot....)

Now the problem is off the stuff which is really Character state... health, the various animations (which have to keep track of what frame they are on, etc...), location, velocity, etc...

Now I need to load all the Characters before creating a player... but I can't just put those state variables in the Character class because due to the "Player has a character" relationship players with the same character would share state variables... not so cool when you are talking about location and velocity.

And the CharacterState class has all these animations... which have state... so they need to be different for each player.

And there is no multiple inheritance in C#... so a Player cannot be both a CollisionObject (which has location and velocity) and a Character (which has all the non-state data plus the CharacterState class)...

GARALKJFDKLJFSDFLKJ... I need to rethink all my Character/Player/Whatever/Stupid/Frustrating/DAKDJFLDK#$#$@# classes.

[Nick]

Could your character just have those objects stored within since they can't inherit those properties?
Player.Character.collisionbox.bounding
Player.Character.velocity
player.score

And so on?

[zourtney]

An interesting question. My gut reaction is the Character is a Player. But that does raise pretty significant state problems...so the more I think about it, the Player has a Character because Player info (by definition?) transcends game/character state.

What are you storing in Player? If it's limited to stateless data, I gotta say a Player has a Character (despite the fact I set out to argue the opposite!)