The last couple of “major” updates I did to vectorblade were always boss related. Finaly this is ended (or at least for the major part).
Each boss is sort of a mini game of its own – at least programming wise, since they all sport features that are not common to any other part of the game (or to any other boss).
They are quite memory expansive and (for the most part) rather boring to program. I am glad to have that off my back. I didn’t really try to be memory efficient while implementing the bosses – ‘ cause I just wanted to get them done.
Currently I have about 1300 bytes in bank 0 and 2500 bytes in bank 1 left. Hardly enough to do the rest of the game (with 64kB). I guess “mentally” I am prepared to go for 96kB (see last post) and stop worrying about memory for a while.
Still on my todo List:
- about 75 more levels, this means about 10 more enemies, new attack patterns etc.
- difficulty settings (I have already a rather firm grasp on how to implement)
- options/highscore screens
- nice title screen (prototype in my mind and half coded) and attraction mode
- I have some more enemy features in mind, which I would like to implement
- “progress system”
- and all the small stuff, like more/better sound, playtesting bug removing etc
pretty much this list stayed the same for the last couple of weeks (or months?). But having these bosses of my neck feels somehow “like taking a deep breath – and now…”
Some numbers:
- the source code consists of over 90 “asm” source files
- the combined length of asm code (ascii text) is about 1.5Mb (ok, many data stements in there)
- 2 music pieces – probably some more to come
- 4 bosses with “huge” grafics
- 13 “normal” enemies (more to come)
- 6 bigbugs (more to come)
- 21 different “bonus” to collect/buy (probably more to come)
- 6 different player shots
- 6 different enemy shots
- 10 different attack patterns (more to come)
- 20 different intro patterns (more to come)
- 3 waiting patterns (more to come)
- x number of “bonus” games/secrets
If/when I finish this – it might not be a good game – but I put some serious work and time into it :-).
Some screenshots of the new (last) boss:
“… it might not be a good game…”
Want to play potentially-not-good-game, want to play potentially-not-good-game, want to play potentially-not-good-game!!! 🙂
I hope I can crank out another public alpha one of these days.
I hope I can do that before I breach the 64k barrier – otherwise it will be hard to test…
(or only with an updated VecFever)
How many lines of code are you up to?
How much of your assembled binary is code, how much predefined vector lists and how much music data?
On a different topic, I need to find the time to learn how your smart vector lists work. I’m can imagine how they might work given the calibration routine, but I couldn’t really understand it from your posts on Vector Patrol. Maybe another read our two is needed, or maybe I just look at the Release code, does that use them?
I can imagine using my Forth and some interactive trial and error experimentation to come up with some method that could use an initial calibration and some alternative faster on-the-fly recalibration routines in the game, which as far as I can tell it’s what a smart list is doing.
But right now I’m miles away from that, I’m only just starting to draw stuff and not hitting the 30,000 cycles yet!
Pure code?
I have to estimate – but I guess of the 64kB right now it might be about 1/2 but if anything – than less than that.
Code portion is so huge, since many fast things have to be “macroed”.
Even if I go the 96kB way – the code portion will not significantly change. Most coding is done. There are some bits and pieces left – but mainly cleanup, level design, making it pretty etc…
SmartList:
Get the newest Vide version and export your drawings as “Smartlist” and “Runnable” and hit the edit button – than you see best and easiest how they work.
In Release – while related – I did things slightly (completely?) different.
Although – since I wrote it – I actually think rereading the VectorPatrol might not hurt either – I wouldn’t find other words today :-(.
I don’t know if Smartlists arereally “FORTHy” though…
I watched the big video, now I need to get the latest VIDE, the sample Smartlist code looks perfect to learn from 🙂 I can also see why you need so much ROM, lots of macros and optimised vector lists.
Forth and Smartlists can co-reside, just like Forth can run regular BIOS functions. The amount of Forth that ends up in the final game code just depends on how much you need to optimise, which ultimately depends on how many cycles the game uses.
Here’s a description of how Atari used Forth in the early 80’s, starting with BattleZone. It’s sort of how I do it, except I’m using a PC as my “Blue Box” and the VecFever is my “White Box”. (And I don’t have a VAX.)
Atari + Forth: http://www.jmargolin.com/vmail/vmail.htm
if the game goes past 64k, what is the updating that the vecfever requires?
One of Thomas’ firmware upgrades perhaps “fw_update_v1_11.v4e” or so.

cool ok, was worried we would all have to get our soldering irons out 🙂