Game creation

[ac.tomo]

Some time ago I was considering writing a game for the A8 and to get some ideas in how to do it I hacked into a game (Quasimodo), but it didn't seem to work as I expected and so got a bit confused, I was thinking, perhaps, if there are any coders who have created any games who are reading this then maybe they can generalise on some issues they've had, or how they go about different tasks in different types of games.

For instance, collision detection when using software sprites, multi-screen memory saving, screen objects & boundaries etc.

I am actually working on an adventure creator, but when that'll be ready I don't know. Anyway, any information in this thread I'm sure will be helpful to many coders.

 

[Creature XL]

Some time ago I was considering writing a game for the A8 and to get some ideas in how to do it I hacked into a game (Quasimodo), but it didn't seem to work as I expected and so got a bit confused, I was thinking, perhaps, if there are any coders who have created any games who are reading this then maybe they can generalise on some issues they've had, or how they go about different tasks in different types of games.

For instance, collision detection when using software sprites, multi-screen memory saving, screen objects & boundaries etc.

I am actually working on an adventure creator, but when that'll be ready I don't know. Anyway, any information in this thread I'm sure will be helpful to many coders.

 

 

This a broad topic and there millions of answers possible.

 

Collision detection for soft-sprites. I am using soft-sprites in char mode (ANTIC 4). There you have the advantage that you get coarse collision detection cheap.

You have to store every char from the background before you set your soft sprite. Therefore, you can easy check if it is char from another soft-sprite (enemy) or a background tile and then, which kind of background tile. Blocking the player or harming the player or just plain background.

In case of a enemy sprite, I do a simple bounding-box test using width and position of both sprites. If it is a background tile the char-wise check is enough in most cases.

 

Not sure what you mean by "multi.-screen memory saving".

[TMR]

For instance, collision detection when using software sprites

This is often done with bounding boxes; each object has an X and Y co-ordinate and we know the rough width and height, so if Object A strays into Object B's space (between both X to X+W and Y to Y+H) then a collision has happened. Some folks, myself included, do this with hardware sprites too and have a deliberately smaller collision area on the player compared to the enemies or bullets.

 

multi-screen memory saving

If you mean compressing screens in RAM, there's a range of options but tile-based compression is one of the more common approaches where elements are built from, for example, four by four character chunks which can be repeated around the screen. That means there's a block of tile data (each tile is 16 bytes, so 256 comes out at 4K) and after that a full 40 by 24 byte screen needs just 10 by 6 bytes to define.

 

There are other solutions of course, platform games (and if memory serves, the Boulder Dash series) define background elements as a block type and the number of times to repeat that block so a platform/wall can be as simple as storing X and Y start, the platform/wall character and how many times to draw and step right before stopping. My game RG Rampage on the C64 does this and one platform is...

 

!byte $04,$02,$4e,$0a,$0d

...which defines the platform X and Y, which character to use, it's colour and how many characters to draw - five bytes and on the A8 you'd only need four. (It also does a quick EOR £$01 on the character byte each iteration so the platform is actually $4e,$4f,$4e and so on.)

 

Or you can compress the 960 bytes of a screen down with a cross crunchers like Exomizer or PuCrunch, both have options that allow them to spool out squished data a byte at a time. Or if you want to do it yourself, Run Length Encoding is a possibility for anyone at least past the earliest stages of learning to code (i'll write up how my RLE system works if anyone is interested).

 

screen objects & boundaries etc.

Here's the spawn information for one of the enemies from Battle Eagle (all the comments are from the original source, every enemy has them so i don't forget what the functions do!)

 

dta n_fan_ring		; sprite shape
dta $10			; sprite colour
dta $90,$10		; X and Y start
dta down_1,$50		; direction / duration 1
dta down_1+left_1,$30	; direction / duration 2
dta $08			; shield
dta $40			; time to next

In order, these bytes specify:

 

Which animation sequence to use - this is in turn defined as start and end frames with a third byte specifying how many frames to wait between updates so each anim sequence can have it's own speed and two instances of the same anim sequence can run at different speeds.

 

The base colour of the object - only the top nybble is used since the sprite handler manages the lower.

 

X and Y start positions - these do what they say on the tin.

 

Two movement commands - down_1 and left_1 are "virtual joystick" commands, they set bits in a byte which is then interpreted like a joystick-based movement routine. There are nine commands in total, four directions with two speeds each and "stop". Saying down_2+left_1 rather unsurprisingly has enemies moving down twice as fast as they're going left.

 

Shielding - how many hits an object takes before it's blasted (this goes to a counter in the object data, if that value is $00 the object is "dead" and available for a spawning enemy, if it's $01 then the object is currently "exploding").

 

Time to next - how many frames to wait before spawning the next enemy.

 

Boundary checks are simple in this case (and most of my games for that matter); if an object has moved too far into the non-visible part of the screen or reached the last frame of the explosion animation a "house keeping" loop spots it and marks the object status as $00 which means "dead" - when a new object is spawned, another loop checks through the status bytes to see if an object is free and, on those rare occasions when it can't find one (rare because i spent weeks scripting things to make that close to impossible), makes a second pass to "steal" an object labelled as "exploding".

 

Of course, this is only good for certain kinds of game...

Edited December 7, 2014 by TMR

[apemaster]

hacking games from synapse can be tricky. many of them used weird encryption to protect their work. i never found the chset and pmdata in necromancer for example.

[+therealbountybob]

Sounds a bit adventurous (no pun intended)

I found it helpful to look at some the magaine games - the Analog Magazine disks had quite a few assembler programs with the source code on the disks. Some have a breakdown in the magazines too.

 

Out of interest what did you do to dear old Quasi (one of my favourite games) ?

[ac.tomo]

Sounds a bit adventurous (no pun intended)

I found it helpful to look at some the magaine games - the Analog Magazine disks had quite a few assembler programs with the source code on the disks. Some have a breakdown in the magazines too.

 

Out of interest what did you do to dear old Quasi (one of my favourite games) ?

 

I didn't actually manage to do anything to quasi, but I did try to understand it's playfield creation in order to do some displaying differences, but unless it was compacted or such, what was on the display wasn't the same as the display collisions were detected, it was a long time ago so I can't remember that much, all I remember is what I said, sorry if this isn't very helpful.