Hi everyone, I think this is my first post but I''ve been hanging around these forums for quite some time now. I''ve decided it''s probably time to become a little more proactive...so without further ado, I have a question for you . I''ve been thinking about what would be required to develop a streetfighter style beat''em up what I''ve discovered is that there''s more to the task than I thought there would be. The main task comes from the actual game logic itself and I''ve been thinking of some kind of state management system for the characters, however, I wish to avoid full blown finite state machines (for chars) like Mugen uses, so to this end, I was thinking of implementing some kind of internal "scripting" system for the chars that uses a combination of text files and internal methods. This way I could define a (large) set of states that the character could posses (most states would be common over all characters I would assume) and then define a set of conditions that have to be met for each state to succeed. I want the characters to have their own fighting styles of course, so once a state has been set that character would play a script for that particular state. Animations would also be linked into the states via a vector position (so if standing was first in a enum, then the animations for that characters standing state would be stored in element 0 of the vector etc). Now, I said earlier that the scripts would be a combination of internal procedures and text files, the text files (which would later be converted to binary as user extensibility is not a concern here...initially anyway) would detail a bunch of actions to perform for each characters state using a group of prdefined generic procedures. So we could have: MoveLeft 1 Which would move a character left 1 pixel etc. There would obviously be other available movements like DropDown or Bounce etc which would allow as to define moves like a character being hit in the air hard and need to fall down hard and then bounce across the screen. I relize that this probably isn''t the overall "best" way of implementing this, but I think it would work quite well. Anyway, the point of posting this is to see what others think, there really isn''t a lot of info out there on this sort of thing which I found interesting. Erm, sorry for the large post, but thanks for reading if you got this far!

Just to clarify, the conditions that have to met would form a set of triggers that would be checked each frame, this way we set a state when a specific trigger is satisfied.

Sounds good to me, make it happen

http://roninmagus.hopto.org

It may be worth having a search for Mugen, a 2D streety style fighting engine. They have a lot of docs with it that explains how to create and set up characters for it. Might be worth having a look for some *inspiration* On suitable tools and scripts etc.

Well, that''s kinda the way I am expecting to do it, except each move or "action" of a character is represented as one of it''s states, and those states of a character can be triggered depending on the states of others and whether or not there is a collision.

So you would have a "character manager" to manage your character objects and the character manager would execute the scripts and notify the characters of their state changes?

Yes, something similar to that. Except in this case the scripts are made up of functions that return bools based on certain conditions that need to be met. The granularity of the functions should be quite small, so the functions could be inlined and I''m thinking of setting up and array of function pointers to these functions so all the functions for one state can be called and if they all return true then that state is played out.

At the moment I''m trying to think of a way to implement a good way of controlling the characters for each state, some kind of scripting system is also in order, so if the character enters the "FALL_DOWN_AIR" state for example, a script will play that makes the character fall down to ground level in a manner specific to that character, this way we avoid a fighting game that is really generic i.e each character has it''s own style.

"If you have a single class called Character that implements several virtual functions, and then have every specific character type inherit from Character and override the virtual functions, by calling the function for player1.FallDown(), depending on the type of variable that player1 was created as, you will see something different. It avoids a great many case statements and insane logic loops."

I initally started doing it like that, but when I though about it some more I decided that I wanted to be able to just distribute a data file if I wanted to update any of the characters and not the .exe. It would make that particular part easier, but I have decided to go for the data file approach which stores data for all the states, this data relates to the characters attributes such as left movement velocity, right movement velocity, fall velocity (or weight etc). This way, I get a lot of control over specific states in which each character can be in while the state manager class tracks the states for each player and can inform them when they ned to change this way I can have a chain of states to play out for that character.

"For the combat scripting, most of the controls should be the same, or at least similar. The defensive AI should react essentially the same for all characters, but modified to their specialty. For instance, if someone is jumping in the air at you, Ryu would execute a high kick, but Balrog would do an uppercut. You can use the virtual functions that you override for that kind of thing as well."

Hmmm, good point. At the moment that sort of thing is linked to the animations for each state and I''m thinking that the collision detection first checks the outer boundaries of each frame to see if they overlapped and then checks all that animations collision rects to see where and if there is a collision.

So, while one character could play a kick animation for heavy kick another could (like you say) play a uppercut punch.

"You didn''t mention anything about difficulty levels, but a good starting point would probably be to set a timer and count from the time that the player makes an attack. Standard difficulty dictates that the computer must wait 1.00 seconds before reacting. Difficulty ranges from 0 to 100, with each point deducting 1/100th of a second from the reaction time. Anything above 90 or so should be essentially impossible because humans can only react so fast. After that point, the computer reacts faster than you to the point that an instant after you try a move, the computer would execute the appropriate counter move, making the game impossible to win at those levels except through extreme luck."

Yeah, I hadn''t put much thought into diffulty levels yet, I''ve been thinking from mainly a 2-player perspective as these games are always more fun this way, and also netplay functionality.

"Just some thoughts. Good luck."

Thanks .