My CPCRetroDev2015 entry - RUN"CPC"

[ervin]

Hi folks.

I can't believe it's been a week since my last update!

I've done lots of behind-the-scenes work in order to free up some memory.
My biggest gain has come from implementing cpctelera's randomisation functions.
They replaced SDCC's srand() and rand() functions, and gave me back around 600 bytes!!!


I haven't got much time left (!!!), but I still have the following to do:
- final bits of gameplay logic
- better music and sfx
- create the final set of obstacles
- hi-score table

I'm very stressed about meeting the deadline, but the fact that my lovely 9-year old daughter and my brother-in-law both think the game is great gives me a lot of confidence.
(Though they would say that wouldn't they?) 

[TFM]

OMG! 600 bytes for a ramdom value! That's shocking crazy. For Cyber Chicken I use a random number generator which is iirc less than 10 bytes. Something like read register R and mix it with some other register, then a value from ram. it works quite nice. 600 bytes for that - the curse of high level languages I guess. Great that you freed the space and settled it down. 

[ervin]

Yeah, cpctelera's random number generator is tiny compared to sdcc's.
I couldn't believe the difference.
And seeing how low my available RAM is running, it's a very welcome change!

I don't understand how it works, but that doesn't matter.
That's the point of a good framework - things work well, and are efficient, but I don't need to know how they work.

[ronaldo]

It's always nice to here that algorithms like this one are useful . Uniform random number generator integrated ni CPCtelera is extremely simple and quite known 33*seed mod 257. This is knwon as Fast RND and it's quite similar to Spectrum's ROM integrated pseudo-random generator.

You have to take into account that I've modified the standard algorithm to add an entropy byte. The standard algorithm has a periodicity of 170 numbers. So, once you have asked for 170 random numbers using the same seed, you start getting the same 170 numbers again and again in the same order. However, if you feed the algorithm with an entropy byte (a random byte comming from some entropy source) only once every 15 numbers you can get a sequence of up to 55360 random numbers without repetition. The nice point of this algorithm is that it is fast, simple and takes up only few bytes.

Anyways, this is not enough in some cases. It may be useful for general and simple applications (or most games), but sometimes a better quality pseudo-random generator will be required.

More to come on future releases .

[ervin]

It's always nice to here that algorithms like this one are useful . Uniform random number generator integrated ni CPCtelera is extremely simple and quite known 33*seed mod 257. This is knwon as Fast RND and it's quite similar to Spectrum's ROM integrated pseudo-random generator.

You have to take into account that I've modified the standard algorithm to add an entropy byte. The standard algorithm has a periodicity of 170 numbers. So, once you have asked for 170 random numbers using the same seed, you start getting the same 170 numbers again and again in the same order. However, if you feed the algorithm with an entropy byte (a random byte comming from some entropy source) only once every 15 numbers you can get a sequence of up to 55360 random numbers without repetition. The nice point of this algorithm is that it is fast, simple and takes up only few bytes.

Anyways, this is not enough in some cases. It may be useful for general and simple applications (or most games), but sometimes a better quality pseudo-random generator will be required.

More to come on future releases .

Thanks for the info ronaldo.


It actually took me a little while to figure out the best way to use the random number generator in my game.
In the end I went with this:

Code Select Expand

cpct_setRandomSeedUniform_u8(ni);


ni is the number of while loop iterations that pass on the title screen, as the game waits for the player to press a key.

Then I use this to select the next level:

Code Select Expand

currentLevel=(cpct_getRandomUniform_u8_f(0)*10)>>8;


I've done extensive testing, and I get a nice even spread of numbers from 0 to 9, which is exactly what I want.

[ervin]

Hi folks.

Another update...

I've got the obstacle-passing detection working properly at last!
The idea is that each "level" will consist of one type of obstacle in various arrangements.
For example, you might need to fly "through" an obstacle in order to score a point, and you would lose a point if you go around the obstacle instead.
This was a lot easier than I expected, thankfully.


After that I began work on ending the current level, and starting the next one, once the required number of points had been scored.
But this resulted in nothing but frustration.
After much head-scratching, and game-breaking nonsense, I realised that I'd have to rewrite parts of my existing level transition code, in order to implement this idea.

And I don't have the time left to do so...


So I went to sleep wondering what the heck I was going to do, in order to make the game interesting (now that my main gameplay "hook" was no longer feasible).

During breakfast this morning, I had an idea.
What if I do the following?

- don't reduce the player's score if they "miss" an obstacle (i.e. the player simply scores a point if the pass an obstacle correctly, and that score cannot be taken away from them)
- have an energy level (perhaps 10 units)
- when the player passes an obstacle correctly, their energy increases by 1 unit (up to the maximum of 10)
- when the player misses an obstacle, their energy reduces by 1 unit
- when the player's energy hits 0, the land speeder drops to the ground and it's game over
- of course, crashing into an obstacle is still instant game over
- so we'll have a game where, in order to continue, the player will need to fly through obstacles and play dangerously
- if the player doesn't play dangerously/aggressively enough, they won't last very long!


This might be the best gameplay hook I can implement in the time I have left, considering how much other stuff I have left to do.

[ervin]

I now have a fully operational battle station status panel!
It displays the player's energy level, the score, and the requirement for the current level.

Getting all of that working, without making the speed of the game suffer, was trickier than I thought it would be.
Especially when taking double-buffering into account, as it needs to be printed twice!

The panel is not updated every frame; only when it needs to be.
And when the panel is updated, it is built character-by-character, only printing the characters that have changed.
In addition to that, the panel update is spread across 2 screen updates (one for each screen buffer), so that it isn't being printed twice in the same frame.


I'm glad that part is behind me now.

[TFM]

That's a great idea! Only print on screen what you really need. Some GFX elements may not change at all, so no need to check them for a change anyway. 

[ervin]

YIPPEE!!!

The main gameplay loop is finished!!!
- pressing a key from the main menu takes you into the game.
- your landspeeder takes off.
- you fly about for a bit.
- you accumulate points and gain energy if you pass obstacles correctly.
- you lose energy if you pass things incorrectly.
- if you run out of energy, you fall to the ground and explode - game over.
- if you hit an obstacle, you explode - game over.
- you get a game over screen.
- pressing a key takes you back to the main menu.

I'm so happy right now!
I've still got lots to do, but the actual "game" part of the project is done!


Things to do:
- a bit more information on the game over screen
- high score table
- entry of a high score
- instructions
- better music and sfx
- more obstacles and graphics
- proper level layouts
- a simple loading screen

And I've only got 2 weeks left!!!

[ervin]

The game-over screen now contains some info (i.e. SCORE), and we now have an instruction screen!
Simple instructions that get straight to the point.

I'm running dangerously low on RAM now... luckily I still have a large area of RAM reserved for compressed files.
I might be able to use some of that, but to do that I may need to compromise the number of obstacles.

[Fessor]

If Arkos don't use it, there are a few hundred bytes where the OS stores the definitions of the ENVs and ENTs that could be used. (As you don't use the Firmware-Routines for Sound there should be no Problem)
Only Problem is that the Adresses are different on 464 and 664/6128
464: From &b61a to &b7f9
664/6128: from &b2b6 to &b495

That gives you additional 479 bytes for Data-Storage
The Area before this, where the Soundqueue is stored may be also usable and gives some hundred bytes more.

[ervin]

If Arkos don't use it, there are a few hundred bytes where the OS stores the definitions of the ENVs and ENTs that could be used. (As you don't use the Firmware-Routines for Sound there should be no Problem)
Only Problem is that the Adresses are different on 464 and 664/6128
464: From &b61a to &b7f9
664/6128: from &b2b6 to &b495

That gives you additional 479 bytes for Data-Storage
The Area before this, where the Soundqueue is stored may be also usable and gives some hundred bytes more.

Thanks for the info; I didn't know that.
However, I've got the firmware disabled, and I'm using that area of RAM anyway, for double-buffering.
(I'm using 0x8000 and 0xC000 as the 2 screens).

[ervin]

Alrighty...

- The game-over screen now shows your final score.
- There is now an instruction screen (with a *very* subtle movie reference).
- There is a little feature (I think it's kind of cute) which displays the number of points you score when you pass through an obstacle - I don't want to give too much away so I'll leave this one a bit vague. 
- The high-score table is almost finished (with appropriate movie references).

Yes, we're getting there now...

BUT I've run out of memory!!!


I've had to claw back 1K from my compressed files storage area.
I don't yet know if this will be a problem, but, as mentioned before, I may need to compromise the number of obstacles in the game.


Still, at least the game is working well, and is actually a proper "game" now!

[Gryzor]

Thanks for the update mate

[ervin]

Thanks for the update mate

Always a pleasure.

Although I probably spend a *bit* too much time talking about this project, not only on here, but to my long suffering family as well!


At least my daughters enjoy testing the game.

[ervin]

The high score table is almost finished now.
I know I said it was almost finished a day or two ago, but it turns out that it wasn't.


It's much closer now.
The player is now able to type in their name (up to 8 characters).
I just need to store it in the correct row of the high score table.

I also tweaked the collision detection, so that the player now has to be within the vertical bounds of a sprite as well (until now they've only had to be within the horizontal bounds). This means (if I have time and RAM) that I will be able to have a couple of obstacles that are off the ground, forcing the player to change their vertical position more often. 

Then I'll throw together a little loading screen.
Then it'll just be graphics, sound, and level layouts.

But yes, I ran out of RAM again last night.


I'll have to be very careful with the space I've got remaining in my compressed files buffer (where the exomize'd graphic and sound data is stored).

Oh the pressure!!!

[ervin]

YEEEESSSS!!!!!


The *program* part of RUNCPC is finished!
I'm so happy right now!!!

The high score table is in and fully functional, and I've been able to put 384 bytes back into my exomized files buffer.
So altogether I've got 8,944 bytes available to store compressed sprite/tile/sound data.
That should be enough for a few more obstacles!

My remaining to-do items:
- simple loading screen
- more obstacles, along with their associated graphics and level layouts
- more/better sound

But as of right now, I have a feature-complete game!!!

[TFM]

Awesome!!! Can't wait to play it! 

[Arnaud]

Congratulations for finishing coding your game !

Now i want to see it 

[ervin]

The loading screen is finished.


Nothing fancy, but it'll do.
I don't have the time (or skill) to make a nice pixel art loading screen.

Onto audio now...

[TFM]

The loading screen is finished.


Nothing fancy, but it'll do.
I don't have the time (or skill) to make a nice pixel art loading screen.

Onto audio now...

Contact MacDeath!

[ervin]

Not a bad idea!
However, the loading screen is all done, and matches the game's title screen, so I'll leave it for now.


Music is half done now.
It's not very good (as I'm certainly not much of a musician!), but it works well enough.
Sort of.

[ervin]

Woohoo! The title screen music is done!
It's only a short composition (and of course I'm completely cr@p as a musician), but to be honest I'm really happy with it!
Who woulda thought?


[EDIT] Also, I've managed to claw back over half-K for my exomized files buffer.
I realised that the music can be uncompressed into the same area of RAM that sprites get uncompressed to during gameplay.
That allowed me to make the music better, and also to reduce the amount of space needed for the sfx (because the audio buffer no longer needs to be as big as it was).
In fact, the sfx can now reside in RAM uncompressed, and no longer need to be uncompressed whenever the player starts a new game.

This is a great result, and will give me some breathing room to finish my obstacles.

[ervin]

Sound effects are done!
They're not particularly good, but they do create a weird, trippy soundscape as you play, as well as letting the player know how they are doing.
The death sound effect is particularly weird (and has some randomness built in), and it's quite shocking to the ears after the sounds that happen before it, but I like it, so it stays.


So at last, FINALLY, I'm up to the last part of the development.
The level layouts and obstacle graphics.

This part should be a bit of fun, as I've written a bunch of tools to assist with creation of the obstacle graphics.
Hopefully this part will be trouble-free (NOTHING else has been so far!).

I won't have a whole lot of time for playtesting and tweaking, so hopefully I make something fairly playable!
It might turn out to be awful (I *really* hope not... I've put so, so much effort into this).

[Gryzor]

Ahhhh not in time for the weekend then. Next week hopefully!