Advertisement Jump to content
Sign in to follow this  

character controlling

This topic is 4748 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi Iam planning to do a 2d action game. Right now I need an idea of how to control the characters. I want to know how it is done in games like castlevania for GBA/DS. How much is based on scripts and how much is based on defined data for a char. My idea is to have a charstruct where all different kind of chars can be fitted in, even if its a flying enemy, someone throwing stones from the background or the player himself etc. This is a bit vague, I know! But probably you can give me some hints of how to make a clean and good structure of all this! thanks!

Share this post

Link to post
Share on other sites
This depends a lot on the type of game, and how it all works. Especially in 2D games, the data you need depends heavily on the camera orientation, gameplay, etc.

For example, a 2D side-scrolling platformer would most likely track the player's current coordinates (top-left corner and center of sprite are two common methods), as well as a directional vector that tracks what angle the player is moving at and at what speed. A gravity force is added to the direction each time the physics code runs an update.

A top-down scrolling shooter like Raptor or Major Stryker would probably only track current position, and accelerate/move the character purely based on player input each update. Ditto for games like Pac-Man where you're either moving one of four directions, or standing still.

Personally, I'd split characters into two types: moving and static. Static characters just sit in one spot and do something. This fits for traps, little guys that pop out from behind mailboxes and smack you with baseball bats, etc. These characters only need a posistion and maybe some extra status information (like a flag to record whether or not the character has been blown up, etc.) Active characters would have a position and movement vector, as well as any other important data so that the AI (or player input code) knows what to do with them.

Anything more specific would depend highly on the game, the language being used for development, and the limitations of the platform (e.g. slow processor, low RAM, etc.)

Share this post

Link to post
Share on other sites
Thanks for the reply!
Iam programming in C, system: NDS.

Iam planning to do a game much like castlevania/super metroid in a character point of view.
Iam wondering how much that I should hardcode and how much that I should put in scripts.

For example an attack, an attack can vary much depening on what kind of char it is, from a punch to shooting fire balls. Maybe its best to have a script for each attack?

Another thing Ive thought of: imagine a blob that walks on a platform when it reaches the end it turns around until in reaches the other side, turn around and keeps moving, etc.
Is it best to have a general script that test if it can walk further or if it should turn around or a unique script that only works for this blob.

I think ive to do my own script cause it needs to be fast and pure, just contain what's really needed any tips? maybe they already exist?

Share this post

Link to post
Share on other sites
Heh. I'm also working on a Castlevania/Super Metroid-style game, though I started by writing my own 2D sprite engine with scripted sprites. Thus, my answer to the problems you're facing (of how to control creature behaviours) is to just script everything. Every creature in my engine has an associated Lua script, which contains update, collision-reaction, and input-reaction functions (the last one only if the creature cares about user input). Each frame, the update function is called, the creature does whatever it needs to do (e.g. check vector from creature to player and fire along that vector if timers allow, or move forward, and so on). Since everything is scripted, I don't need to have any hardcoded concept of player versus enemies; the player is just another sprite (presumably one that listens to user input!).

I got to where I am now through something similar to the following thought process:

1) I want to make a game. What's my design going to look like?
2) Well, I'll have a player class and enemy classes inheriting from a generic Sprite class.
3) Ick. That makes it sound like I'll have a distinct class for every enemy type. Ugly. How can I move that outside of the code?
4) I can just have a generic "enemy" class that has scripted behaviour determined by a config file, then have a "player" class that responds to user input.
5) But then the only difference between the enemies and the player is that the player responds to input. And I might want to have other sprites responding as well (e.g. guided shots or interface menus).
6) Might as well just script everything and fold the player/enemy sprites into one class.
7) I've made it this general; might as well make a fully-generic sprite engine while I'm at it.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!