Game dev diary -sort of-

[LeCaravage]

I start a game and instead of making it alone in my room, would be more fun if I share infos here, something like a dev diary. Entries won't be daily, but more probably like every second week.
It could be good for me to post here regularly as finishing a game needs a lot of effort. And also, because, it could, may be, push other persons to write their dev logs.
All version short infos, screenshots, videos, etc... will be added here in the first post, to make things more easy to follow. Other details will be written in the future in new following posts.

So, let's start :

Here are the first specifications as I imagine it.

- Game must work on a Amiga 500 - 512Kb/512Kb. But will try to make it work on AGA machines.
- Style and gameplay, heavily inspirated by the game Snow Bros.
- 320x224 pixels screen. This resolution would I hope makes the game run on NTSC machines.
- No scrolling (let's make it simple).
- Nbs of colors is not defined yet. 16 or 32 ?
- Game refresh Frame Rate : 50hz (or 60Hz on NTSC). Not mandatory though but, still enjoyable as 25Hz is nice too.
- Music + Sfx in game.

To add enjoyment, coding sessions will be all on a real Amiga 500 + HD. I know cross dev is more confortable and faster, but typing on a real Amiga keyboard is pleasurable.

I have already worked on this game for Amiga 1200 several years ago, but it was a big failure -not enough tech skills and experience-. So I decided to wipe all and work from scratch.
For the moment I'm alone to work on it, but I'm in touch with a graphic designer who could be interested to work on anims/gfxs but, he wants to see the first level finished before saying no or yes. Logical and understandable as many projects are never finished. I hope I will have the stamina and motivation to finish it.

[mcgeezer]

Great idea and pleased you are starting a project!

I know you commented a few times on my development journey to Bomb Jack in the coders section so hopefully I might be able to offer some tips to make it a success.

Time.
Ensure you prioritise time for the important things in life like your family.
Have the conversation with them that you'll be working on a game and it may take several months to finish. It may not apply to you but it did to me and if I'm honest I eventually had to set a deadline on my project due to family commitments that I didn't quite get agreement with upfront.

Love.
Make sure you love the project enough for it to want to succeed. This is very important, if you don't love the project (and you'll definitely not be doing it for money) you'll likely lose interest mid way through when you come up against something that is hard to code.

Patience.
Coding can be extremely frustrating. I found what worked best for me was setting out the elements of the game into priorities and hours of work to complete them. I broke all the components down into a spreadsheet. Most of what goes into a game is boring to code and non-visual, so code a non-visual thing and then visual thing to keep you interested and keep that sense of achievement going.

Peers.
As you're doing here, post your progress through video. When I first started it went six weeks without someone giving me any feedback or encouragement in the thread, but I kept going all the same posting every day. I think i could attribute that to being new to the forum but soon after I got a lot of encouragement from other coders which helped massively get the project over the line.

Design.
I imagine porting an arcade game is much easier than doing an original game. It becomes even easier when you have the graphics to go with the game too. If you're not doing a port then work to a really solid game design template otherwise you'll get scope creep and never ever finish it.

Achievable.
Make sure the game is technically achievable to make it a success. The Amiga has lots of technical limitations so try to make your game work within them. Also try and code something that you can achieve, for example I would never dream of coding a 3D game because I am shit at math.

Climb the hardest mountain first
If you tackle what you perceive to be the hardest things to achieve in the game first then everything else will be achievable. For me it was things like collision detection and sprite routines out of the way first as they can be challenging to code. At the end of your project you can start polishing things up.

Fun
If you're not having fun coding your game then take a break from it. I've worked out that I seem to do things in seasons where I start in October after the family holidays and the dark nights are coming in. In England we've had the hottest weather in 40 years and had a great World Cup... no way could I have coded in these months as it would not have been fun.

Development IDE
I know you mentioned this but I found that working on a real Amiga to do development was very hard and frustrating, especially as I hadn't touched an Amiga for 25 years. At first I used WinUAE which was great but then moved to a tool chain and didn't look back.

Split your source
Put your source code into include files. This saves tons of time moving up and down assembler source and makes sure you optimise your time well. Split your copper, sprite, scrolling, enemies into separate assembler files.

Backups
Backup your code regularly. I created a little BASH script to backup my code to the cloud quickly. It saved my project on numerous occasions after I had broke things beyond repair. (usually after too much Peroni)

Good luck on your game - I hope you find this useful.

Geezer

[ovale]

I love Snow Bros. Good luck!

[Ian]

Why don't you enter the game development competition with it. This is exactly the sort of posts I am asking for in the entries thread

[LeCaravage]

@Geezer : Many thanks for taking the time to write so many advices. I'll try to implement them to my project.

@ovale : Thanks.

@Ian : I thought it was cancelled and let down ? Anyway, I'm sure a lot very talented coders/artistes will enter, I know there are a lot here hanging around here ^^

[Ian]

Hope not but it has gone very quiet.

Plenty of donators and quite the pot of money to be won. If you are the only one to enter you are guaranteed to win

[LeCaravage]

Well,

After some study, I need to stop thinking and make frozen decisions and stick to it.

So the game will be dual playfield, 3 background bitplans for the scene and 3 foreground bitplans for the bobs.
One player only as I need to make the game animation the more smooth possible. So I decided to use 4 hardware sprites (16c) for the main character and 4 more for the projectiles.

Rough calculations tend to make me try up to 40~50 levels. All the game + sounds need to fit in a single file.

Fastly coded a mapeditor. Not a fancy or sophisticated one, no mouse, only keys but it makes the work : generate a map binary file. Need to study more the amos instructions for potential improvements though.

I need to generate a 20x14 map. Each tile is 16x16 pixels. But in the main program the map needs to be 22x16 sized. This is because of the sprites need to be clipped. They can't escape sideways but could fall in a hole and reappear at the top. Just like bubble bobble.
I have now a not so nice screen displaying a screen full of squares with numbers in it.

Each tile owns a colision code :

* 0 no collision at all
* 1 horizontal + bottom collision
* -1 bottom collision

Played Snow Bros and Rodland on my Amiga. Great games. A bit presomptuous to dare making better but need a hard target for motivation.

As already said, all dev is made on my real Amiga, but I need security backup. So after each coding session I need to copy project folder on a disquette using Diskmaster1.4
Dangerous utility DM is, because no warning when deleting, moving or copying files.

My calculations makes me feel I don't need more than 64 tiles per world.

[LeCaravage]

I'm nearly convinced it already happened to you, you drive in town and all traffic lights are green when you reach them. Pretty rare.
For the game coding progression, this week looks like this car ride, I mean, I didn't met any bug, everything I wrote was working without visible bug or crash. It contrasts with the beginning where I met a lot of bugs -stupid ones, most of them- which took me a lot a time to fix.
The result is, a nice progress this week :


- All levels maps -not yet designed- are depacked, and copied so the ingame loop could handle and use it. The depack option is yet disabled as only one test map exists. No need to lose time in packing maps as it could be done at the very end once.

- A 1 bitplan background graphic with a copperlist rainbow in it added. So, 1 color is reserved and can't be used in the scenery. All 1bpl backgrounds will be packed and depacked on the fly before each level starts.

- All hero/scenery collision detections are working fine. No need to add (x,y) hero comparisons to make sure he stays between map limits and can only escape by falling in a hole and appears again falling from the top map. And more important, same goes for future ennemies bobs.

- The tiles with collision attribute = -1 could now handle diagonals colision -not only pure horizontal ones-. I mean I added tiles/plateforms with slopes and the hero sticks to it when walking on. In fact, the collision detection routine handles the same way these tiles, they could be perfectly horizontal or sloping. Of course, obviously same will be for ennemies.

- All hero animations are prepared and seems to work -32x32pix squares with numbers in-. Need to confirm it by including the real graphics but all the tests are passed ok. Looks good. But, as I don't know if the game will run at full frame yet, it could be possible to meet the need to change all anims delays/speed. As when the game drops from 50Hz to 25hz, it could look so slow if you don't adapt these parameters.

- Added projectiles. The hero can throw projectiles. I used the same hero/map collision detection for the projectiles. Added an 'explosion' animation when a projectile meets a wall or tile with collision attribute=1. It avoids the projectiles looking to suddlently disappear when they meet an obstacle. Need to scan the projectiles table at every loop when adding or removing a projectile type from it, as a projectile could disappear before a previous one (You're an alien if you did understand).

- In Bubble Bobble or Snow Bros, the hero can't go down from plateform to a lower one. Looked to me disturbing, so I added it. Now the hero can do down just by letting the joystick pulled down during approx 1s -delay needs to be confirmed by future tests-. Needed to add a special collision test as when the hero is a the very bottom of the map, if the joystick is pulled down, the hero could cross the plateform and get lost in random tiles outside map limits. Fixed.

- Now the hero, can walk, jump, go down, fall in holes and reappear at the top, he can also throw projectiles. Great.

- Until now I didn't need backbuffer -remember the hero and projectiles are hardware sprites-. Added backbuffer swap routine.

- Added a bobs erase/display routines. The erase subroutine reads the previoous frame bobs table and erase the bobs. The bobs display subroutine uses a current bobs infos tables and display the bobs.

So, now the more harder to be done come :

For the moment, I have something like :

-step 1 : erase bobs
-step 2 : AI/collisions ennemies
-step 3 : fill bobs tables
-step 4 : display bobs

The steps 1&4 are done. Still to write steps 2&3.
Step 2 is the harder to do.

But before starting it, I need to add graphics. So I will have a lot of graphics tiles, hw sprites and bobs to transfert using Iffmaster. Because for monster I need to see more precisely what's going on concerning animations and behaviours.

So far, the whole object code is 190Kb. 140 Kb fast ram, and 50Kb Chip ram.
Tough.

[phx]

Good progress! Congratulations.

Originally Posted by LeCaravage

- The tiles with collision attribute = -1 could now handle diagonals colision -not only pure horizontal ones-. I mean I added tiles/plateforms with slopes and the hero sticks to it when walking on. In fact, the collision detection routine handles the same way these tiles, they could be perfectly horizontal or sloping. Of course, obviously same will be for ennemies.

Wow! That's huge! Slopes are the holy grail of tile-based games!

In fact I gave up on slopes in my current game project, because my head exploded while trying to implement them in the most efficient way.

But, as I don't know if the game will run at full frame yet, it could be possible to meet the need to change all anims delays/speed. As when the game drops from 50Hz to 25hz, it could look so slow if you don't adapt these parameters.

It's a fixed-screen game, without any scrolling? And you are coding in assembler? You really should be able to keep 50Hz, if you don't make very stupid mistakes.

hero/map collision detection for the projectiles. Added an 'explosion' animation when a projectile meets a wall or tile with collision attribute=1.

BTW, how did you encode the tile attributes? In an additional table, referenced indirectly by the tile-code? Or included in the tile code?

You wrote in the previous posting that you don't have more than 64 different tiles in a map, so there would be 2 bits left in a byte. Using the MSB for the most important attribute would allow you fast checks with the N-flag.

Need to scan the projectiles table at every loop when adding or removing a projectile type from it, as a projectile could disappear before a previous one (You're an alien if you did understand).

Indeed, I didn't understand.

But as soon as you have a certain amount of objects to handle, a list may be better than a table.

- Until now I didn't need backbuffer -remember the hero and projectiles are hardware sprites-. Added backbuffer swap routine.

Does every BOB get its own backbuffer, or do you have a pool of buffers which you assign to active BOBs?

Other solutions would be triple buffering, with the third bitmap dedicated for restoring the background. Or using a bitmap with a set bit for every dirty tile on the screen (I used this method in my latest project - works best with lots of foreground tiles and BOBs).

So far, the whole object code is 190Kb. 140 Kb fast ram, and 50Kb Chip ram.

140K for code and data is a lot. Uninitialized data (BSS) not included?

[LeCaravage]

Hi Phx,

Concerning tile attribute, I used this method -probably used thousand times before- : Let's say we have #n tiles per map. The mapeditor generates a map binary and also creates a #n bytes table length for each map -of course you decide during map design the attribute type of each tile-. This #n bytes table contains the tiles attributes, index #0 get tile attribute for tile #0, index #1 -> tile attribute for tile #1 etc...
During ingame, depending of the sprite coordinates we get the tile code under him. This returned code is used as an index to the #n bytes table, so we finally grab the tile attribute.
If the code attribute allows the sprite to walk on this tile, we use another table. We access this table using as index the tile attribute + the lower 4 bits of your sprite x coordinates (4 bits for a 16xH pixels tile size, 3 bits/8xH size etc...). This table will return you a #dy signed number . This #dy is to add to your sprite y. So the sprite sticks to any tiles at any angle of the slope.
My english is sometimes imprecise...

On the point of backbuffer, I'm not sure I used the right word, I simply wanted to say I use 2 screens, which I flip every time the ingame loop is finished. I don't need graphic backbuffer for restoring background as I use dualplayfield. I just need to erase the previous bob area. Makes things much more easy ^^

Yes, a lot of memory used until yet, but the graphics, tables etc... are all stored in fast ram. I depack, flip and make mask only for the sprites/bobs used in a level. I used this method because I wanted to use rawblit bobs and also to the hope of using more bytes for music/sfx.

[phx]

Originally Posted by LeCaravage

During ingame, depending of the sprite coordinates we get the tile code under him.

Do you take the tile code under the bottom-left or bottom-right sprite-edge? Or from the middle?

If the code attribute allows the sprite to walk on this tile, we use another table. We access this table using as index the tile attribute + the lower 4 bits of your sprite x coordinates (4 bits for a 16xH pixels tile size, 3 bits/8xH size etc...). This table will return you a #dy signed number . This #dy is to add to your sprite y. So the sprite sticks to any tiles at any angle of the slope.

When falling into such a sloped tile, does it immediately stick to the surface when touching it? This could mean an abrupt movement by #dy=15 in the worst case?

What happens when moving from a plain tile into a sloped tile from the side? When #dy is 0 on the side you move in, it should probably block movement, but not when #dy is 15, because it has nearly the same level as you are currently on...?

On the point of backbuffer, I'm not sure I used the right word, I simply wanted to say I use 2 screens, which I flip every time the ingame loop is finished.

Ah, ok! You just wanted to say you are using double-buffering (to avoid flicker while updating)!

I used this method because I wanted to use rawblit bobs

What are "rawblit bobs"?
BTW, did you consider using interleaved BOBs and planes, or are you blitting plane by plane?

[LeCaravage]

- My sprite is 32x32pix high, so I take for the hot spot at (x+16,y+32).

Originally Posted by phx

When falling into such a sloped tile, does it immediately stick to the surface when touching it?
This could mean an abrupt movement by #dy=15 in the worst case?

Indeed, in my case as I don't need very steeply angles (=<45°), my leaning tiles are always composed of 2 tiles for each 16pixle row, one up and the second juste at the bottom of the first. But, one of the 2 owns a 'no collision' attribute. The one with more empty space got a 0 collision attribute. When sprite walking I always test these 2 tiles, 2 hot spots with 16 pixels vertical difference tests.
Not perfect and doesn't allow acceleration or crazy angles but works quite fine for my needing.

Originally Posted by phx

What happens when moving from a plain tile into a sloped tile from the side? When #dy is 0 on the side you move in, it should probably block movement, but not when #dy is 15, because it has nearly the same level as you are currently on...?

I'm not sure to understand well. Please correct me if I'm wrong but you can't block horizontal mvt if the sloped tile don't have any side collision attribute and also the graphic artist must create joint tiles with no too much vertical difference, so your sprites will always stand on the tiles without entering in or have too much abrupt vertical correction. And in the worst case if the sloped tile is too high and doesn't allow side go through, the sprites can't pass it -like Turrican 2 if my memory serves right-.

I think normal people call it interleaved. Rawblit is the icon name in Kefrens Iffconverter

[Photon]

Loved gamedev diaries in Zzap etc back in the day

[LeCaravage]

Yup, especially Martin Walker's Citadel diary is one the best I have ever read -Sorry Andrew-.

[Photon]

Hehe, his diary is what made me play it I remember it as a quite difficult game. Also, a mere mention of Gribbly's Special Day Out was what made me play that. Tons of fun, and difficult towards the end with the crazy crab. Also tried Morpheus, but could never wrap my head around it instinctively. Still might!

[LeCaravage]

In my previous entry, two weeks ago, showing off attitude wasn't a good idea.
During the last week I was stuck tracking down a nasty bug.
Despite numerous breakpoints, tracing, logs constructions, I was unable to
find why my bobs were flickering, as if the double buffering
was not there at all. Before, I couldn't see it because it only occurs when bobs move.
At last fixed it. And it was a pure luck -facepalm-. Pain in the ass because
it makes doubt of you, one week to fix one bug...

- Converted two ennemis bobs animation set, incomplete as yet but usuable for basic attitude like
pause, walk and explosion.
- Converted all animation set of hero, including projectiles. Works fine.
- Drawn and converted a tiles set. Not bad for a non profesional graphic designer. May be will be kept in
final release. Not the highest priority for the moment, though.
- Checked again code to make some optimisations. Sometimes, optimisations
could screw up everything and have to go back. The problem is, I always overwrite my
last source during a coding session. Back up on disquette is only made before turning off
the Amiga.

Now, it seems obvious, the big part of cycles eater will be blitter data transfert.
Until now, 16 bobs, 32x32-7 colours per frame are drawn. But it's irrelevant because it doesn't
take in account, music/sfx, bobs objets IA/collisions detection, score, special events (bonus etc...).
Expecting a drastic bobs number shrink soon.
Looking at the code of Snow Bros -again-, he seems to use rawnorm format, for obvious memory
save preoccupation, but still, he manages to blit 32 colors 8 ennemis max + all little blits.

Speaking of optimisations, during this process, I noticed something strange :
Normally a loop would look roughly something like :

- Erase bobs
- Calculations
- Draw bobs

But if I make :

- Erase bobs
- Draw bobs
- Calculations

it's faster. Puzzled.
The pb with the second solution, gap in bobs animation or colision could occur.

I just realized : @phx is the author of the replay managing sfx during music.

Now, I need to write on paper all ennemis behaviour and animations needed.
All slots are ready, just have to fill it with code.

[phx]

Originally Posted by LeCaravage

The problem is, I always overwrite my
last source during a coding session. Back up on disquette is only made before turning off the Amiga.

You should really find a way to implement some source repository and versioning system. Or at least make more backups. It could already help to backup the source everytime before doing new changes.

A loss, even from minor parts, of an already working project can harm your motivation extremely.

Normally a loop would look roughly something like :

- Erase bobs
- Calculations
- Draw bobs

But if I make :

- Erase bobs
- Draw bobs
- Calculations

it's faster. Puzzled.

Strange, indeed. I would have also guessed the first is faster, because an Erase operation only needs a single source channel, so there should be some more cycles for parallel calculations.

The pb with the second solution, gap in bobs animation or colision could occur.

Why?
It should make no difference where you calculate new positions, besides that the visibility of the new positions may be delayed into the next frame.

Usually you will save the bitmap pointers for the BOBs while calculating them in the draw-step. So the erase-step doesn't care when a BOB's coordinates were changed in between.

I just realized : @phx is the author of the replay managing sfx during music.

If you have any questions, or need special features, just ask.

[LeCaravage]

It should make no difference where you calculate new positions, besides that the visibility of the new positions may be delayed into the next frame.

Sorry, my english is not perfect, I wanted to say what you are explaining.

Usually you will save the bitmap pointers for the BOBs while calculating them in the draw-step. So the erase-step doesn't care when a BOB's coordinates were changed in between.

It's what I'm doing, filling a list with blitter datas and after writting them to blitter registers. The erase section uses the same datas than the draw one.

If you have any questions, or need special features, just ask.

Thanks, I will

[LeCaravage]

Ok, good progress the previous days.

I managed to almost finish IA for the first monster and also collision tests with scene.
Now, the first monster, the purple one, called "Marcel" is able to :

- Walk left right
- Make pauses
- Fall from a plateform
- Jump to a upper plateform

For this monster, left to do :

- open mouth wide to let escape from inside him another moster (fly monster)
- eyes blink during a pause attitude
- adding a animation attitude just before the monster jump up for a plateform. This will let the time to the player to avoid a going up monster
- hit by a hero projectile


The last point needs the collision part done. Collision will be done at last after finishing most of the objects IA.

In general, to do :

- Displaying scores, nb of life
- Hero/projectiles/monsters/bonus collision detection


As it is a big step as been reached, here is a fast screenshot of the ingame screen :

[/url]

[Predseda]

I totally love its look!!!!