controls:
B button: jab
X button: punches
----------------
X - reverse punch
downX - reverse punch to midsection
upX - uppercut
Y button: kicks
----------------
Y - front kick
awayY - side kick
downY - knee kick
A button: defense
----------------
A - block(hold/release)
towardsA - counter
A + X Buttons - reverse stance (hold A press X)
right trigger + B button - throw
start button pauses and brings up menu:
- up,down to change choice
- a to toggle chosen option
improvement :
v0.2.3:
Tue Feb 12 21:36:37 EST 2002
added victory counter in player struct so the game can keep score.
looking a lot more game-like...
changing the paused state variable to a more flexible run state... paused, menu, etc.
adding #defines to dcf_globals.c.
fixed MAX_ENERGY to work right... should probably make this a variable.
v0.2.2:
added frame rate counter - dcfg clocks at 60fps.
added toggle for block damage in menu.
Sun Feb 10 22:17:25 EST 2002
- added the position[4] field to the fighter_t struct.
- added a toggle for camera follow...
- added a working direction comparison in the consequence function - for attacks and blocks.
blocks have a wider threshold than attacks; both are stored as floats in dcf_globals.c and changeable.
the threshold represents the angular pie slice of space a fighter may successfully attack and block in.
this angle may be more suitable as an offset angle:
due to the humanoid fighters structure, the back is more open than the chest...
Sat Feb 9 23:59:58 EST 2002
found the problem with the strange-looking sidekick: the design of fighter_carriage.mosh
the x rotation was done before the y, so whether he was tilting forward or back was dependent on his orientation.
the problem has been fixed: y rotation is now first, and z rotation has also been added.
this 3-axis rotation around a single point could possibly give rise to gimbal lock, so i threw in a
TRANSLATE 0.001 0.0 0.0
just in case.
from the dcdev mailing list:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Oops, nevermind. I found the functions I needed in rtc.h. The
function does have some strageness where most of the time it returns
(for example) 0x000031FA but sometimes it returns 0x31FA31FA. Simply
& with 0xFFFF and I have a working frames/sec counter.
Apparently 60fps for a 5k poly scene seems slow because I was used
to getting 3000fps with a minimal scene :) Though theoretically I
should be able to get 50k at 60fps ... time for more optimization.
-Trilinear
> The time.h functions have a one-second resolution, matching that of the
> DC's internal RTC. I've got some plans to make one of the other high-res
> timers supplement this for better timing but it's not done. If you feel
> courageous you could dig in there and attempt to do so manually (look at
> kernel/arch/dreamcast/kernel/timer.c)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
thanks Trilinear
frame rate counter added. dcfighting v0.2.1 runs at 60fps.
working on a menu - trying out printing in different colors.
want to be conscious of screen size/resolution. draw a black box under the text, etc.
the menu states themselves should be cake.
Sat Feb 9 20:04:57 EST 2002
ive been working on the modeling toolchain for this system; integrating mosh into the process.
i feel like it would be simpler to have these models in a pseudo-text format like mosh for maximum tradability,
portability, etc.
right now the model itself can be stored in text as well as parameters, names, and presets.
sub-models contain presets, which could be useful in partial anchors for moves...
but theres going to be a need for human-coder intermediary as long as fighting states are not accounted for by mosh.
maybe mosh could add a few fields to each entity for static "state" variables...
variables which wouldnt need to be interpolated, but would just assume the value of the last state change.
v0.2.1: modeling pipeline : this dcf_fighter.c is totally generated.
Thu Feb 7 00:26:17 EST 2002
importing code successfully from mosh.
fighter model pipeline is almost complete.
this SPACIAL_OFFSET special spatial offset , is the one flaw in the system.
one never knows where the spatial parameters will occur in a heirarchical model file, so this
#define must be changed manually.
working on stamina tweak
added a do_move function to ease the adding of new moves.
now control function calls this, and theres a set of #defines in dcf_control.c for each type of move.
anchorlists reside in do_move.
abstracting all moves into dcf_control.c for now...
this includes the moves from the conequence function...
- be thrown
- stagger high hit
- mid
- low
- block attack- be countered
attack moves moved into dcf_control.c.
the vector calculation in consequence pushes the hittee back...
but it references the player params array directly.
perhaps we should treat spacial params diferently...
thinking of moving the location info into the offset hack...nah, no interpolation there.
grepping for params[0]...
- animation(walls)
- consequence(kickback)
- control(sidestep)
- mainloop init
- mainloop midpoint for camera
so far a #define is necessary to indicate the start of the spatial parameters...
not exactly optimal...
first param of draw_entity() is rotation... add it the the rotation param index of the model when drawing.
Mon Feb 4 01:45:28 EST 2002
v0.2.0:
still needs a lot of tweaking in the timing values (and new moves), but playable.
v0.2.0: colors, textures, playability.
color and texture switching...
glColor3f(1.0f, 1.0f, 1.0f);
glBindTexture(GL_TEXTURE_2D, texture2 );
want to:
- fix ducking (getting exceptions)
- tweak move speeds/strengths and stamina debts
- work on exploiting the speed/strength tradeoff during a game...
- new models and moves. probably a modular design to allow for homebrew fighters.
- at DoomraiderC's and Ralph's request: blocking while being attacked still hurts, ~1/8 as much. make changeable...
- OPTIONS SCREEN
golden mean ratio: Phi = 1.618033.. and Phi2 is 2.618033..
( sqrt(5) + 1 ) / 2
1/phi == 0.61803399
changed the value // p->params[7] for p->opponent_rotation. better for now.
fixed the away/towards inversion bug.
obj support is working in mosh... i ran a version of this with an obj hat on the fighters' heads (al.obj)...
but it took about a minute to compile...
dcf_fighter.c should be entirely generated, so dont read the source(the source actually ISNT the *source*...)
v0.1.9: reboot condition ABXYStart.
attempt to split up source for readability
got the sidestepping in 3d down... find the vector to your opponent.
towards will increment your position by that vector, away decrements.
cross the opponent vector with the up vector.
up and down add the cross product to a players position.
putting in directional forces... punch a guy to the north, he'll move that way.
this should be in the consequence function, as should gravity, walls, and any other
rule-based interactions between entities.
better note where we scope the opponent vector... save some recalculation.
moved the static params array to within the player struct.
v0.1.8: added stamina to moves; a constantly increasing measure of how much speed a
fighter can put into the next move. this way, rapid punching will not be such
an unfair advantage (no chinos).
hacked the glewLookAt() routine into kos. now fighters can easily be drawn from any
angle, and environment integration can begin. it is unclear whether the controller
function will manipulate the fighter's position directly, or it will be a once-removed
request/reply type event, where the consequence function (main loop) will check the
fighter's position against any walls, then apply the appropriate forces to the player.
also added 100 slow motion frames after a player is knocked out.
v0.1.7: added throws into decision logic (which is now a function, should be a macro)
and energy into player struct. energy is deducted on each contact in the
consequence function, 5 for attack, 10 for counter and 15 for throw.
the spatial relations b/w characters and the floor is now really hacky...
ill need a glutLookAt() routine to facilitate the viewing of a more 3d space
to fight in. shouldnt be too hard.
v0.1.6: i have been wrestling this bug that causes an exception and fatal crash only
when ducking. the duck loop uses logic similar to that of the a button, detecting
release of the button for hold moves. but when wrapped by the condition of the left
trigger, perhaps thigs are different... maybe thats a stretch. i havent quite
isolated the bug yet.
working on some new moves for throws, counters, falling...
this should also require a new classification of attack, namely by range (kicks are
longer than punches) and impact height(high,mid,low:an int).
consequence logic will also become more complicated, as a low block is no good
against a mid attack, but a duck puts you under a high attack...
true collision detections might be a little out of this machine's league...
or are they? i guess ill have to get to Dan and Marcus on that one.
the idea is to encapsulate all state information about an attack in an int.
1s place: attack range
10s place: attack height
100s and more: attack strength
the logic will take this into account, and we will have slow kicks that reach longer
than fast punches, as well as the ability to duck under, jump over, and properly
defend against high, middle and low blows.
v0.1.5: relative rotation(dodging)
this version introduces the concepts of rotation to the game. some might call it
a hack at this point:
three rotations describe the fighting situation: the global rotation of the center
line(b/w the 2 fighters), and each fighter's individual rotation about his own
center. using this notation, a strafe counter-clockwise(from above) is
equivalent to a clockwise rotation of the opponent. this rotation is reduced
instantly to 0.0 upon input from the player; maybe that should me more smooth.
the effect is that it is possible to sidestep completely around a player who
does not turn to face you.
additionally, a float is kept to track the fighting_distance b/w fighters,
and a float[2] to keep track of global displacement, which both players
can modify by strafing(dpad).
the illusion is pretty good; check it out for yourself.
v0.1.4: fighting state
refined the notion of fighting state to be more like a power level...
denotes stamina when below 100 (a la hit points) and attack power when
above 130; in between lie the parry,counter,block,move,stand states.
each timestep changes fighting_state by 1 in the direction of their
default state, which is set at the anchor time of each move executed.
so player will spring back to default.
fighting state is also changed by move logic; i.e.attack/block, etc.
^
|
140 throw
130 attack
115 counter
110 block
105 parry
100 standing
95 moving
90 hit
80 stunned
70 staggering
30 falling
20 kneeling
10 down
also, counters seem to work now, although the timing intervals are going to need
much tweaking. an attack duration of 0.1 timestep units(currently set at 0.02:
possible aliasing) is difficult to match with counter with a 0.15 timestep
(with the same 0.07 latency as the jab), but possible. requires more
experimentation.
oh, and no reverses or kicks this time; the logic is being rewritten to an else-if
block of form if ( (A) && (X) ). so it will check every possibility in
sequence; i thought there might be a way to reduce that. maybe later.
besides, it looks like this chip can handle it; and this code could go a long
way toward optimization.
also, switch stance is now A+X.
v0.1.3: touched up interaction
the logic for interaction has been cleaned up; now all conditionals
are compounds (player1==ATTACK && player2==COUNTER). much easier to read.
still needs tweaking for playability; now a stunned player (just hit by
an attack) will have no chance to block if the opponent can
continuously release a flurry of short jabs(B button).
parry and counter should still be possible in a stagger; maybe to
a varying degree (you get your ass kicked harder, you have less
chance/opportunity to pull off a counter).
v0.1.2: interaction paradigm
a new block of code has been added after the interpolation loop:
right now it's a block of if s corresponding to the table below.
using the table's logic, that loop can add and remove anchors of
player1 and player2 according to their states.
add_anchor(fighter_t,double,double*,int) now takes a state as well
(final parameter) and dcf_animate has a list of #define
enumerated possible states.
v0.1.1: fighter structs
each player==fighter now has his own struct(2 of them currently).
now we have 2 players in space (thanks a bunch to Dan Potter for the hint).
there's a loop that goes through the bus and checks each against
MAPLE_FUNC_CONTROLLER. i was neglecting to call maple_create_addr(p,u)
on the unit,port pairs and hence getting unusable addresses.
remember to call :
c = maple_create_addr( players[0][0] , players[0][1] );
before :
if (cont_get_cond(c, &cond) < 0)
