Jump to content

Gorge Express

Member Since 22 May 2013
Offline Last Active Jan 27 2014 07:46 AM

Posts I've Made

In Topic: XNA - Making A Sprite Fire A Projectile

04 June 2013 - 04:53 AM

For something simple like shooting a projectile, i'd just give the class dealing with input access to the sprite manager so that it can create the projectile sprite.  The sprite manager should be able to do the rest, storing the sprite in some structure and iterating over that structure calling each sprite's update method each frame. 


Also you should probably store the player's direction in a variable. If you can only face right or left, you can use a boolean. 

In Topic: What is the best way to keep track of game objects?

29 May 2013 - 07:52 PM

Well, you could use flags I guess. Lots and lots of them. 


Or you could save the state of the world, instead of reloading it anew. Serializing the entire world is one way to do that, though it's inefficient. 


Another option is to reference information from both a "base world" and your save data to construct each object at the necessary location. Your game would keep track of only things about the object that can change, like position or if a button is activated or not or whatever. It would also have some kind of unique id. The id would reference an object in the base world, which contains the rest of the info necessary to construct the object. 

In Topic: Implementing "actions" in an action game

26 May 2013 - 10:23 AM

Thanks for all the input.


fun fact: Not only did Nintendo have to position the sword near Link's hand each different frame, but they also had to determine how to rotate the sprite. There are 36 different frames of the normal sword swinging animation, but only 8 different sprites for the sword. Link himself usually consists of 2 different sprites(he is only 1 sprite in some arbitrary frames) and they just change the x and y position of his head to make it look animated. Must have been fun doing all that in assembly. 


Anyways, what is a good way to deal with the timing of  actions specifically? That is, the activation/addition of a hitbox to the sword after a delay(or the check to see if an enemy is in front of the player), and the removal of the sword+reverting the state of the player back to normal after the action(which lasts an unknown amount of time) is done? The action must also end early if the player is hit. 

In Topic: Implementing "actions" in an action game

23 May 2013 - 05:26 PM

LttP was made in assembly, so they would've had to do things the hard way :P but yea, i was just using it for an example.
FSM sounds like what i was saying I would do. Using only a FSM to address the problem would be a real pain if you need to implement a lot of actions though. 
Using a data structure that takes care of itself makes sense too. Though something in the code would still have have to handle adding and removing the sword entity, adding and removing the hitbox, and changing the player state. You can't just change the player state out of "attack mode" after a set amount of time, because that amount of time isn't always known(imagine the hookshot in any Zelda game. If it hits a wall, you gain control of the player back sooner.)