• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
sjaakiejj

Character Movement & Animation approaches

7 posts in this topic

Hi,

I wasn't quite sure which section to put this in, so I decided that this was the most appropriate place for it. Having taken a step back from coding for a moment, I looked at my code and found the EventReceiver code completely cluttered with information such as:

if ( key_pressed == 'W' )
then move_forward


An alternative approach would've been a switch statement, which honestly doesn't make much of a difference. Either of these two approaches leaves the code cluttered, and they are not very flexible (though the 'if' way a bit more than a switch) when it comes to custom controls. In addition to that, having this code in the EventReceiver class is, from my understanding, not a good idea to begin with. That made me wonder, and this is something I've had in the back of my mind for quite a while now - How is it usually done?

Say we've got an Event Receiver class, a Player Class, and a Game Manager class. The player class has functions for Animations, can alter the characters position, rotation and scale, and do all sorts of entity transformations. The Event Receiver class has a callback function which is invoked when a key (or mouse button) is pressed, and can then handle the key. The Game Manager class manages the Camera and the Game State.

I'd imagine movement and animation calls go in the same place, though I'm not quite sure what the better approach is. Thanks in advance.

As a side note, I don't know if it makes much of a difference for this general problem, but I'm talking about a 3D game.
0

Share this post


Link to post
Share on other sites
Not sure how it fits in with your program architecture, but a common approach is to simply record keypresses and mouse messages, perhaps in an array of bool's, without taking immediate action.

In your run/update loop, check the array for key/mouse activity as appropriate and take action at that time. That approach separates the user interface from the update and rendering and allows for coincident key+mouseclick combinations.

E.g.,
[code]
bool keyDown[256];

// ... when keypress/keyup detected
keyDown[ key-code ] = true; // for key-down
OR
keyDown[ key-code ] = false; // for key-up

// elsewhere, e.g., during player->Update
if( keyDown[ W-code ] )
{
add-forward-motion;
// if you want a single movement per key-press then
keyDown[ W-code ] = false;
}
if( keyDown[ A-code ] ) add-side-motion; // or similar to above
[/code]
0

Share this post


Link to post
Share on other sites
[quote name='Buckeye' timestamp='1300299849' post='4786668']
Not sure how it fits in with your program architecture, but a common approach is to simply record keypresses and mouse messages, perhaps in an array of bool's, without taking immediate action.

In your run/update loop, check the array for key/mouse activity as appropriate and take action at that time. That approach separates the user interface from the update and rendering and allows for coincident key+mouseclick combinations.

E.g.,
[code]
bool keyDown[256];

// ... when keypress/keyup detected
keyDown[ key-code ] = true; // for key-down
OR
keyDown[ key-code ] = false; // for key-up

// elsewhere, e.g., during player->Update
if( keyDown[ W-code ] )
{
add-forward-motion;
// if you want a single movement per key-press then
keyDown[ W-code ] = false;
}
if( keyDown[ A-code ] ) add-side-motion; // or similar to above
[/code]
[/quote]

Hi Buckeye,

Thanks for your reply. it's an interesting approach, and one that I'm not completely unfamiliar with. Am I right in saying that, if a player has a lot of different movement types (e.g. jump, attack, walk forward, backward etc etc), the player update function will become rather large?

Also, I'm not quite as confident with Animations yet. This is my first time of really trying to use them, and I know that for instance "Walk forward" would use a looped animation "Walk", though would you start that looped animation the moment you press a key and keep track of which key it was you last pressed, as well as keeping track of whether you've released the key? Or is there an easier, cleaner way of doing this?
0

Share this post


Link to post
Share on other sites
It is further meaningful to decouple physical input (e.g. "key w pressed") from logical input (e.g. "forward motion"). It separates input controller (keyboard, joystick, mouse, whatever) from gameplay abilities. So it allows for binding input elements of controllers (that match the respective input mechanics) to the gameplay.
1

Share this post


Link to post
Share on other sites
[quote]Am I right in saying that, if a player has a lot of different movement types (e.g. jump, attack, walk forward, backward etc etc), the player update function will become rather large?[/quote]
It could, but probably no more convoluted or time-consuming than having a separate function called for each keypress. "Large" is, of course, a relative term, and depends on how much you want to do in the update function. Is that a concern?

[quote]would you start that looped animation the moment you press a key...[/quote]
There might be other things to consider such as transitioning from the current animation to the new one, but, yes, I'd start it at that point.

[quote] and keep track of which key it was you last pressed...?[/quote]
No.. not sure what you have in mind. If you check the "forward" key each update, continue the animation until the forward key is no longer pressed. At that point, transition to/begin an "idle" animation. In general, you don't want to consider the "history" of the character, only the current and future state.

EDIT: Just to clarify a bit, rather than "a key has been pressed," I would use "a key is down" or "a key is up" to determine which action ("move forward", "idle") should be considered. E.g., in Windows, I would use the WM_KEYDOWN/WM_KEYUP messages rather than WM_CHAR messages. Edited by Buckeye
0

Share this post


Link to post
Share on other sites
I am by no means an expert but I have found that it is useful to simply keep track of what keys are being held down at what time, and make the event handling portion of my code do nothing but signify that these key states have changed. For example, something like this works for me (pseudocode, of course):

[code]if ( /*a key has been pressed*/ )
{
switch ( /*the type of key*/ )
{
case UPKEY:
upkeyDown = true;
break;
case DOWNKEY:
downkeyDown = true;
break;
//etc.
}
}[/code]

And then, how I handle the fact that these keys are down depends entirely on what is happening within the game at the time. For example: if the player is currently jumping, holding the space key down isn't going to do much, so that spacekeyDown bool won't be dealt with at all. I found that breaking away the actual processing of the event itself from what to do with that processed information helps keep my code less cluttered (even if I do have what some might call a large series of unnecessary boolean variables). I guess, alternatively, you could have case SPACEKEY: call a function like player.jump() which simply does nothing if the player is already jumping, but just looking at your code and reading it logically might have it making less sense.
0

Share this post


Link to post
Share on other sites
[quote name='Buckeye' timestamp='1300301336' post='4786679']
[quote]Am I right in saying that, if a player has a lot of different movement types (e.g. jump, attack, walk forward, backward etc etc), the player update function will become rather large?[/quote]
It could, but probably no more convoluted or time-consuming than having a separate function called for each keypress. "Large" is, of course, a relative term, and depends on how much you want to do in the update function. Is that a concern?

[quote]would you start that looped animation the moment you press a key...[/quote]
There might be other things to consider such as transitioning from the current animation to the new one, but, yes, I'd start it at that point.

[quote] and keep track of which key it was you last pressed...?[/quote]
No.. not sure what you have in mind. If you check the "forward" key each update, continue the animation until the forward key is no longer pressed.
[/quote]


It's not much of a concern, though my general practise is to keep functions short and easy to read. But I'm also aware that larger functions would probably be more appropriate here. I'm also just trying to get a firm starting point, and further complexity is something I'll consider once I've got the basics working correctly.
And you're right on the last one, that was simply my thinking pattern taking a wrong turn. Thanks a lot for your help, it's always nice to get some clarification on how things are done in general.



Also heagarr:
Thanks for your input, it makes sense that decoupling is a good thing, and I hadn't thought of it in that way before.
0

Share this post


Link to post
Share on other sites
[quote]my general practise is to keep functions short and easy to read[/quote]
That's certainly worthwhile. To keep things cleaner, you can incorporate into your update function calls to "PickDirection()" or "ChooseWeapon()," etc., each of which can check appropriate conditions. That further separates non-interacting actions from one another.

[quote].. non-interacting actions..[/quote]
Sorry. That phrase should be taken out to the yard and shot. Edited by Buckeye
0

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0