High Score
Last night I implemented most of the planned high score system.
I leaned heavily on my experience with Karl Quappe. Persistent high scores will be possible with:
a) a DS2431a one wire eEprom
b) VecFever
There will be 5 high score entries only, comparing, saving loading is all finished – only thing is – I haven’t done a high score screen yet. So – it is so far not possible to actually see the scores – or enter a name. Its these menial tasks that are annoying – and that I try (often times successfully) to avoid :-).
Starfield
In one of the earlier entries on this blog I mentioned, that the original game sports a “starfield” display in the background. That also was a thing that I tried (successfully…) to avoid. After some thinking I did a first implementation yesterday.
The “beauty” of my implementation is, that is easily scalable (you will see why that is “beautiful” if you read on…).
Since I implemented nearly every entitiy of the game in things called “objects” – I liked to implement the effect also as an “object”.
As you might recall – the original ObjectStructure looks like:
struct ObjectStruct ds Y_POS,1 ; current position ds X_POS,1 ds CURRENT_LIST,2 ; current list vectorlist ds DDRA,1 ds SCALE,1 ; scale to position the object ds BEHAVIOUR,2 ds TYPE,1 ; enemy type ds ANGLE,2 ; if angle base, angle in degree *2 ds PREVIOUS_OBJECT,2 ; positive = start of list ds NEXT_OBJECT,2 ; positive = end of list ds filler, 5 end struct
Reusing the object “pattern” the object structure for one starfield “atom” looks like:
struct ObjectStruct ds POS_1,2 ; ds SCALE_1,1 ds POS_2,2 ; ds SCALE_2,1 ds BEHAVIOUR,2 ds TYPE,1 ; ds POS_3,2 ; ds PREVIOUS_OBJECT,2 ; ds NEXT_OBJECT,2 ; ds POS_4,2 ; ds SCALE_4,1 ds SCALE_3,1 end struct
I must always have the fields “Beaviour”, “type”, “next_object”, “previous_object” – all other fields might be reused by data. So one starfield “atom” has information of 4 stars. One star is described with “POS” (y, x coordinate) and “SCALE” (how far away from the middle).
The spawning of such an object actually does (apart from the usual):
- build a random number and set the scale to that
- set pos to $ffff (initialization marker)
The “behaviour” does:
- if in initialization (pos == $ffff)
– decrease scale as a counter
– if zero do secondary initialization, which is:
– find a random “angle” and its position information
– set the position accordingly
– set scale to 10 - else
– according to current scale:
– add to scale (the higher the scale, the higher the add)
– if scale > max – do another initialization
– else
– set intensity (the higher the scale, the higher the intensity)
– set the actual scale to t1
– move to the position
– draw a dot
With that a not desasterous looking mini starfield (of 4 stars) is implemented.
If I spawn more of these objects – more stars are displayed. If only the starfield is displayed, I can go up to about 120 stars (30 starfield “atoms”) and still be under 50Hz – so approximately one atom takes less than 1000 cycles.
Scaling
As I repetitively said – I like to stay within 50Hz. Apart from collision detection with a large shield I can achieve that most of the time easily. I will not look at collision detection in relation to 50Hz again, since that is a “singular” event.
The “cool” thing about Release is, that there are game elements which are necessary and there elements that are not strictly speaking necessary.
MUST THINGS:
- base
- shield
- enemies
CAN THINGS:
- explosions
- floating scores
- starfield
If there is so much “action” on screen, that the game comes near the 30000 mark – the user (gamer) will most certainly not bother about the “can things”. So if we are in danger to break the 50Hz barrier I can tweak here!
That “tweaking” is what I call scaling…
Within the game I can watch certain information and take actions according to its analysis results, following information I have available:
- number of current objects
- number of starfield atoms
- max scaling of explosion
- max scaling of scores
- time left of last update round
(in case you wonder – I have an own WaitRecal routine, which right befor the T2 wait loop stores the VIA_t2_hi, that value times 256 is exactly the number of cycles I have to “spare”)
If the analysis comes to the result that I am:
- dangerously near the 50Hz barrier
- have only a “few” of my 35 objects left
I can take action such as:
- lower the explosion scale (the explosions take an inapproriate amount of cycles)
- lower the score scale
- forbid new “score object”
- reduce the number of starfield atoms
And vice versa (expand explosion scale, spawn new starfield objects…).
I uploaded a gameplay video on YouTube (my wordpress support of videos is dwindling somehow):
Image with a starfield, Bonus “shield” was captured, the base shows the countdown – 27seconds left.
