| |
cadaver
Registered: Feb 2002 Posts: 1160 |
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 :) ) |
|
... 15 posts hidden. Click here to view all posts.... |
| |
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: 1160 |
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: 1160 |
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: 621 |
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: 1160 |
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: 621 |
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: 1160 |
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: 43 |
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... |
Previous - 1 | 2 | 3 - Next |