Jump to content
Site Stability Read more... ×
  • Advertisement
  • entries
  • comments
  • views

4E4 Against Defeatism

Sign in to follow this  


Those who read my previous entry might have picked up that I was pretty pissed off with how the 4E4 game is going. After trying to make a few additions (namely combos) I realised that the current implementation is working because of sheer luck and not because it's well coded, as such it annoyed me and has set me back even more than I hoped.

Here's some information about what was going wrong...

When the player hits a key that's associated with movement, a state is set on the player object (eg: RARROW will set state 'move_right' to on). When a certain state is on, the game will call a scripted event on the object, so 'move_right' will call the script player_MoveRight. This script will move the player's avatar as well as starting the animation that shows the player moving in that direction... Sounds about right, except it is flawed.

A single keypress is echoed across a couple of frames as a 'key held' event (due to the nature of how the events are worked); because of this, the state remains set and the script is called to move the player. Again, this works but isn't how it should be working - this became evident when trying to build combos, a single press of the right arrow key would register a load of single rarrow presses and wouldn't register the 'dead' time in between. When I tried to unset the states (eg: a press triggers the event once) the game would become unresponsive to input and the animation would play on the spot.

- Key is pressed
- State 'move_right' is set on 'player'
- Script player_MoveRight is called whilst 'move_right' is set
- Animation continues to play, regardless of moving right or not

Instead, we need to have the system set up so that the key press sets the state, triggers the initial event (to start the animation) and the presence of the state executes the separate script to actually move the player. The state will only become unset when the animation ceases, requiring the need for a callback event to be triggered at the end of the animation.

- Key is pressed
- Event player_MoveRight is called
- State 'walk_right' is set in script
- Animation started, with parameter to call event player_WalkRightEnd when animation is completed
- Whilst the walk_right flag is set, player_WalkRight is called to move the player
- When animation finished, player_WalkRightEnd is called to unset the 'walk_right' state

The input system also need some rework so that I can register 'dead' time. Specifically, I need to know if a key was pressed once, or pressed and held. I also need to know if there was any 'dead' time between the presses, the most certainly will be - but I need to be able to quantify this with a time value.

My issues come from the age-old problems of organic games/game engines. The system is allowed to grow with little or no control; sure, you may think you know where it's headed, but without things on paper, documented and written down you quickly lose sight of who owns what and where the data is coming from.
Sign in to follow this  


Recommended Comments

I think it's where it helps also to be coding with someone else, because then you can jog each other's memories.
I've taken a rather disciplined approach with my entry thus far, whether that will pay off or not is a different story!

Share this comment

Link to comment
One of the ways to combat organic design is to stick to a set of standards. I don't mean coding standards where all of your variables use the same naming convention, but a design standard where every algorithm or class use a set of rules that you follow all the way through development.

For instance, a simple rule might be: "Every object is referenced by ID. Pointers are not propagated throughout the system."

So when you design, every "manager" class in your software will keep track of some objects and assign them ID's. Whenever another class wants to reference one of the objects in your manager class, it will request an ID and then use that ID to manipulate the object.

If you stick to the rule, then your design is more consistent. The moment you decide to have the manager class return a pointer or some such, you break your design rule and open yourself up to organic design.

Oftentimes, coming up with and following rules like this will expose higher level design flaws more quickly, and you will find yourself designing better software. The trick is to remain disciplined, such that if you find a need to break a rule, you recognize that you probably have a design flaw and instead of breaking the rule you change your design.

Creating a set of rules and following them through to the end has been one of my tricks for design, and it's never failed me. The difficulty is in remaining disciplined enough to not allow your design to breakdown.

Share this comment

Link to comment
I applied that theory this time around and it's made me think about things in a different way. Everything (aside from Entities) are based on Handles; there's a handle for textures, animations, sounds and what have you. It's made it 'difficult' in the way that I've had to plan the systems better; I can't just pass a texture pointer around and play with it because I can't actually obtain any information about the texture without being able to access the Renderer, for example. This is why I've got callbacks and plenty of interfaces around; anything that can be animated will have to implement a specific interface, whichs fires a callback whenever the animation starts, updates and finishes. It's pretty good, but really adds a lot more complexity to the mix - gone are the days that a nice singleton or global variable would 'help me out'.

I guess I'll work through these issues, but I'm getting frustrated that it's not as simple as it should be, especially when you consider the other projects I'm working on - it's likely that this one will slip further behind because it's not as easy to pick up as it needs to be :-/

But we'll see :)

Share this comment

Link to comment
I know exactly what you're talking about. Same kind of situation in my sidescroller, alittle simpler to solve though.


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!