| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Advanced C64 Gameprogramming Manifesto
Advanced C64 Gameprogramming Manifesto
A kind of minirant, not informative enough to be included on the BitOps site but I hope this raises some thoughts, or even flames (considering the mild scene-bashing :) ) Originally posted on Lemon64 scene forum but I thought I'd post here too...
An advanced C64 game could contain:
- Sophisticated AI system (it is good enough when entirely CPU-controlled "battles" between two or more factions can be staged, and it looks good)
- Scripting language for controlling storytelling & action; running on virtual machine(s)
- Dynamic memory allocation, for example dynamic allocation of spritedata
- Loadable code modules; each module can have "methods" that can be called (a bit like object oriented programming)
- Challenge yourself!
- Push all limits!
- Forget oldskool traditions and limits, if they're not useful!
- Remember that during C64's early times, games adhering to these "advanced" principles were written (for example Maniac Mansion ). The "scene" approach usually forgets this pioneering work, focusing on graphical & aural excellence and code optimization while ideas & theory are very limited!
- Gathering experience on other platforms, or of computer science in general, and applying it on C64 can produce devastating results!
( Enhanced Newcomer definitely fits under Advanced Gameprogramming :) ) |
|
| |
Viktor
Account closed
Registered: Apr 2002
Posts: 78 |
OK, lets talk about it. :)
bye.
Viktor |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Maybe there's not much to talk :)
When writing this, I just wanted to call some attention into the great lost arts of past :) Hmm..I guess there are also lots more great examples of advanced gamecoding... Myth at least seems to have a very elaborate animation system, for an action game. And First Samurai has enemies that can do just about anything the player can do too.
I guess making the enemies and player "similar" in a game can actually make the code more memory-efficient, even if some advanced AI is in place (rather than coding lots of specific code for "stupid" enemies) |
| |
Viktor
Account closed
Registered: Apr 2002
Posts: 78 |
Do you know any good source?
What programs are the masterpieces of this way?
Viktor |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
No, not really. The only public source codes (assuming you meant that) of larger C64 games that I'm aware, are my own at http://covertbitops.cjb.net, and I don't consider them very advanced yet :)
Myself, I'm definitely going to explore at least that virtual machine idea next..
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Ah yes, the sourcecode of "Harald the Horrible" exists at www.gamebase64.com (in Turboassembler format on diskimages) Just checked some of it today and it's quite messy - not good for learning I think. |
| |
Viktor
Account closed
Registered: Apr 2002
Posts: 78 |
And what do you think about the JVM (Java Virtual Machine)?
You can read about on the Lunix mailing list.
(There are on the net some small JVM (32k large) and some people talks about it to converting)
bye.
Viktor |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Well, really interesting to see on the C64 :) but I'm afraid it'll be a bit slow. An amazing feat nevertheless. An action-game oriented virtual machine could be very simple, and fast, containing mostly directly game-oriented commands & instructions, like
(example code for an enemy in hypothetical script language)
if (player.distance < VERY_CLOSE)
say("Halt, intruder!");
attack(player);
endif
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Note that of course it's no use using a virtual machine/script language setup just for the sake of it, if it can't bring some kind of benefit, for example less memory use.
That above operation done directly in ASM
ldy #INDEX_PLAYER
jsr get_distance
cmp #VERY_CLOSE
bcs no_alert
lda #<alert_message
ldy #>alert_message
jsr say
jsr attack
no_alert:
would take 19 bytes.
In a hypothetical bytecode, that the hypothetical virtual machine would interpret, it could be for example:
dc.b SET_FOCUS,INDEX_PLAYER
dc.b GET_DISTANCE
dc.b COMPARE_A,VERY_CLOSE
dc.b BRANCH_GT
dc.w no_alert
dc.b SAY
dc.w alert_message
dc.b ATTACK
no_alert:
that would take 12 bytes (slightly less)
|
| |
Richard
Registered: Dec 2001
Posts: 619 |
Quote: Note that of course it's no use using a virtual machine/script language setup just for the sake of it, if it can't bring some kind of benefit, for example less memory use.
That above operation done directly in ASM
ldy #INDEX_PLAYER
jsr get_distance
cmp #VERY_CLOSE
bcs no_alert
lda #<alert_message
ldy #>alert_message
jsr say
jsr attack
no_alert:
would take 19 bytes.
In a hypothetical bytecode, that the hypothetical virtual machine would interpret, it could be for example:
dc.b SET_FOCUS,INDEX_PLAYER
dc.b GET_DISTANCE
dc.b COMPARE_A,VERY_CLOSE
dc.b BRANCH_GT
dc.w no_alert
dc.b SAY
dc.w alert_message
dc.b ATTACK
no_alert:
that would take 12 bytes (slightly less)
What sort of asm is this code referring to? It does not look like the sort of assembler I always use. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
That's the whole idea, it is an imaginary language which a C64 ASM routine will interpret. The point is to create your own language which suits the purposes best! In Metal Warrior 3 for example I used a script language for conversations and initializing the levels, but it can be used also for much more (actual action scenes) |
| |
Richard
Registered: Dec 2001
Posts: 619 |
Quote: That's the whole idea, it is an imaginary language which a C64 ASM routine will interpret. The point is to create your own language which suits the purposes best! In Metal Warrior 3 for example I used a script language for conversations and initializing the levels, but it can be used also for much more (actual action scenes)
That will be a new thing for me to learn :)
....but I prefer Turbo assembler :) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Now I'm just in the process of implementing the virtual machine system for MW4... But in roughly 99% of C64 game projects such system is not needed!
|
| |
RaveGuru
Registered: Apr 2002
Posts: 41 |
One of the most impressive games on the C64 imho must be Laser Squad. It's directly compareable with the Amiga and PC version. It contains great gameplay, advanced AI and decent graphics. I can't figure how they've squeezed allt that in on less than 64kb :) |
| |
CyberBrain
Administrator
Posts: 392 |
Quote: What sort of asm is this code referring to? It does not look like the sort of assembler I always use.
If you're talking about the "dc.b"-thing it means the same in DASM as ".byte" does in turboassembler (or so i've been told). And "dc.w" means the same as ".word" does in turboassembler.
("dc.b" means 'declare byte')
("dc.w" means 'declare word')
(dunno why the DASM-coder thought it was fun to replace ".byte" and ".word" with "dc.b" and "dc.w", but he did) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quote:
If you're talking about the "dc.b"-thing it means the same in DASM as ".byte" does in turboassembler (or so i've been told). And "dc.w" means the same as ".word" does in turboassembler.
("dc.b" means 'declare byte')
("dc.w" means 'declare word')
(dunno why the DASM-coder thought it was fun to replace ".byte" and ".word" with "dc.b" and "dc.w", but he did)
i don't know if it's a matter of replacing them as such, just a matter of adopting a different standard; Zeus 64 has DFB and DFW commands if memory serves (never used the latter =-) and i'm fairly sure i've seen dc.b and dc.w on another assembler... |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
I think dc.b and dc.w etc. are a tradition from 68000 assemblers.
But Richard, don't worry about that VM asm code example, here's something even worse to look at:
8000 pushism 01
8001 storabs 7f
8003 pushimm 0a
8005 pushabs 7f
8007 islt
8008 jfalse 0a (8012)
800a pushimm fa
800c storabs 7e
800e incabs 7f
8010 jump f3 (8003)
8012 stop
Code for a virtual stackmachine (quite Java-VM-like, in fact) Though it's not meant to be generated by hand, but with a compiler instead :) |
| |
6R6
Registered: Feb 2002
Posts: 244 |
Cadaver,
really nice that Rant page of yours.
explaining sprite sorting and stuff. :)
Write more please.
-grg-
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
I will hopefully write more about interpolated movement and frame skipping. But first I should get the MW4 stack-machine working 100% :) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Got inspired suddenly...
Rant #11: Frameskipping, interpolation & re-entrant IRQ code
http://www.student.oulu.fi/~loorni/covert/rants/interp.htm |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Hey, I just uploaded my 1k minigame, which is a data-driven engine. Animations are scripted, graphics are made out of independent pieces which are heirarchically connected in chains, etc. Actually, I found that it's far more flexible, memory-efficient, and just plain easier to write if you have 1 big code routine for handling general cases, and letting the data define specifics, as opposed to having a bunch of little code snippets scattered around, each handling a special case. In the data-driven case, adding new functionality is just plugging more data into the tables, instead of writing, calling, and linking new code.
BTW: I've been a software engineer for almost 10 years, doing advanced OO and r&d, and I fully see the application of the high-end principles for small systems, as well as having the 8-bit upbringing to know when to bit-twiddle a nice ugly hacked optimization into the code. :)
minigame: Invasion of the Color Clashed Graphics |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
OMG! That game nearly made me shit my pants :)
That, if something, is 100% Advanced Gameprogramming. And the char-accuracy movement (not bad looking at all) made me think of software-sprite engines... |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Quote: OMG! That game nearly made me shit my pants :)
That, if something, is 100% Advanced Gameprogramming. And the char-accuracy movement (not bad looking at all) made me think of software-sprite engines...
...that's because it *is* a software-sprite engine. :) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Quote: ...that's because it *is* a software-sprite engine. :)
Yes, naturally :)
But it made me think of other applications, mainly on a bitmap screen... |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Quote: Hey, I just uploaded my 1k minigame, which is a data-driven engine. Animations are scripted, graphics are made out of independent pieces which are heirarchically connected in chains, etc. Actually, I found that it's far more flexible, memory-efficient, and just plain easier to write if you have 1 big code routine for handling general cases, and letting the data define specifics, as opposed to having a bunch of little code snippets scattered around, each handling a special case. In the data-driven case, adding new functionality is just plugging more data into the tables, instead of writing, calling, and linking new code.
BTW: I've been a software engineer for almost 10 years, doing advanced OO and r&d, and I fully see the application of the high-end principles for small systems, as well as having the 8-bit upbringing to know when to bit-twiddle a nice ugly hacked optimization into the code. :)
minigame: Invasion of the Color Clashed Graphics
Ah, I just wrote my first "completely" data-driven musicroutine. Player code is only about $280 bytes and still it can achieve almost any imaginable effect. "Instrument data" consists only of a pointer to a "program" which can then include various commands to set the voice playing, pulse modulating etc. These commands can also exist in the pattern (sector) data. There is no predefined, hardcoded behaviour for example hard-restart, which is kind of cool I think.
Currently takes a little under 16 rasterlines, though it still has to be optimized... |
| |
Viktor
Account closed
Registered: Apr 2002
Posts: 78 |
I am decoding the Infocom Z*code interpreter. It uses the virtal machine idea.
Viktor |
