[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: intro

Mike Ciul wrote:
} 
} Sourceforge looks good to me, but I don't know the details about how it
} works. What do we need to do to maintain xarchon there?

I've never used SourceForge, but they host a CVS repository for each
project, so presumably we would CVS XArchon.  I also lurk on the dev
mailing list for Freeciv, a Civilization II open source project, and they
run their repository like this: They have a small number of developers with
write access to the repository, and general read access for anyone.  People
(including those with write permission) submit patches to the dev mailing
list, which can be eyeballed by anyone interested, and if there are no
complaints or bugs found, the patch is committed to the repository after a
few days by one of those with write permission.

(Freeciv isn't on SourceForge, but their system could still work for a
project that was, I believe.)

} >Another change I made was to make movement in the field (the battle screen)
} >continuous, rather than rounding movement off to whole tiles.
} 
} I'd be really interested in getting that field movement code. And I'd be
} willing to work on the AI.

Ok - I'll have to go through my diffs from 0.50, because I've actually done
quite a lot, it turns out.  Here's my "done" list (including some stuff
that I've already submitted to Ronen); some of the comments are a bit
cryptic, since they were just notes to myself.

    * implement mouse support
    * bug in imprison - if last enemy piece on board is not
	    wizard/sorceress, it didn't target the correct square.
    * take out nasty hack in field.c for weapon_data, give weapons their own
	    structs in the field struct.
    * fights should start with creatures offset by 1 in the y direction
    * simplify field_collision to 4 comparisons.
    * make iface_revive go straight to the target, rather than up to the top
	    and then down to the target.
    * take out hard-coded OS timer resolution in main.c, calculate
	    dynamically.  Account for the time executing code, as well as the
	    time spent sleeping.
    * add double-kills and stalemates
	* immediately abort cloud weapons if their wielder dies
    * undefined keys for human control were automatically hit every frame!
    * Shapeshifter should take the health of an *undamaged* member of the
	    enemy's type, but with the dark side's luminance bonus.
    * Elementals should be unaffected by the luminance cycle.
    * From screenshots of the original Archon running on the C64 emulator,
	    measure creatures' health and weapon damage inflicted.
    * From screenshots of the original Archon running on the C64 emulator,
	    the luminance cycle gives health bonuses of +0, +1, +3, +4, +6, +7
	    as the cell goes from the opposite colour to the piece's own.
    * use emu to time recharging, bullet and movement speed.  Also, damage
	    rate of phoenix and banshee.
    * move all the hard-coded duration and switch()-ed upon stuff into the
	    ACTOR struct.  Things like the per-frame damage of cloud weapons,
	    the fire delay, the duration of cloud and hand weapons, the speed
	    in pixels per frame of creatures and attacks
    * make phoenix explosion build up in stages.
    * remove whole-square rounding in field mode
    * make diagonal-moving-of-ground-units a general property of diagonals
	    on the board, and remove from mouse-specific code.
    * In original game, combatants could overlap.
    * collision detection is too coarse.  Bitmasks
	* if an image has no mask, it means it's rectangular.  Can still do
		mask testing on the other image.
    * make actor invisible if firing a ACTOR_IMMUNE_USER weapon
    * ensure that field actors don't start on rocks
    * have a lookup table with values multiplied by sqrt(2), used to slow
	    diagonal movement down to the same as axial.
    * clouds should really be circular, rather than oval (oval in the
         original was from the distortion of vertical distances)
    * erase clouds that fall outside the field
    * change layout of human configure dialog - all directions & fire at once.
    * if a chosen key mapping in human configure dialog is already used,
         clear the old mapping to null.
    * wizard/sorceress teleport
    * unselect unit if it finishes in its starting location
    * change facing on light/dark to a separate bit
    * animated board cells: have some bits that can be set which give the #
         to & with frame_time to determine stepping

} I've been eyeballing the C64 version too... trying to get approximate
} ideas of speeds. Have you done that already?

Yup - here's the summary of my 'research' :)  I hacked Frodo (the C64
emulator I used) to help me with timing things; it has the option to 'limit
speed', which normally throttles the emulator to run no faster than an
actual C64, but I changed it to run ten times slower than that when the
'limit speed' button was on, so I could actually count frames, and grab
screenshots of, say, a bullet 10 frames after it was fired, to measure the
distance it had travelled in those 10 frames.

	creature	health	speed	bullet speed	damage	reload
light
	wizard		10	8		48	10	20
	djinn		15	8		40	6	23
	phoenix		12	8	(lasts 10)	2/2	25
	unicorn		9	8		56	7	15
	golem		15	6		24	10	20
	valkyrie	8	8		24	7	20
	archer		5	8		32	5	20
	knight		5	8	(lasts 4)	5	10
dark
	sorceress	10	8		48	8	20
	dragon		17	8		32	11	30
	shapeshifter	var.	var.		var.	var.	var.
	basilisk	6	8		56	9	15
	troll		14	6		24	10	20
	banshee		8	8	(lasts 15)	1/2	25
	manticore	8	8		24	4	20
	goblin		5	8	(lasts 4)	5	10
elementals
	fire		10	8		48	9	15
	water		14	8		24	6	25
	air		12	8		32	5	18
	earth		17	6		24	9	25

Effect of square luminance on health
------------------------------------
    square is	piece is white	black
    black		+0	+7
    dark		+1	+6
    dim			+3	+4
    faint		+4	+3
    light		+6	+1
    white		+7	+0

All times are in 'frames' (there were 12.5 frames/second), and speeds are
in horizontal pixels per frame.  Vertical speeds and distances were halved
in the original, to effectively make the field square.  This is why the
banshee and phoenix's cloud attacks looked oval; they were effectively
circular, once you factored out the vertical distortion.

Health and damage all turned out to be multiples of 8 pixels, so I divided
them all by 8 to get the 'atomic' health and damage values.  For example,
the wizard's health bar was 80 pixels high on a black square, up to 136
high on a white square.

Melee and cloud attacks show the duration for which the attack lasts, in
place of the bullet speed.  The Phoenix's attack grows or shrinks every 2
frames (so 2 frames at small size, then 2 frames at the mid size, then 2 at
the largest, then 2 back at mid, then 2 at the small size again)

Damage from cloud attacks are in (points/n frames)

							Have fun,
							 Rob R.
							  \((/
							  ~oo~
							  /))\