next »

[fuedhq]

GFXs is ongoing. Ever wanted to see a back room coder´s swamp?
Here is the workshops.

[JobLeonard]

I did, actually! Nice! :D

Did you clean up for the shot or are you just naturally a million times more organized than the average dev?

[fuedhq]

The table is usually clean, the rest of the room, outside the shot, is where the mess lay about. :D

[fuedhq]

Here the layout idea.
8 stages divided into 4 scenes: Downtown, Scrapyard, Docks, Hangar + Roof/Crane.


And here the thing more or less in a stage of progress.
The left ones are more final but may have too much information. The right ones are very early ideas.
This will do as a layout and I will be doing the final touches as I implement them.

[a-k-]

This looks like a fun project! What did you ultimately do with the changing backgrounds, is this still 100% BASIC?

[fuedhq]

Yep, 100% BASIC so far. The routine to deal the bkg color is not in code yet and I´m still wrapping my mind around the code Erik Gavriluk shared to deal this. As far as I understood, his code can can re-route which character is printed. Something like this, say print"A" will draw a black and blue block on the sprite border (the bkg is blue), then, on a stage that the bkg is red, one can run poke and the print"A" will draw a black and red block.

His code in BASIC is full of peeks and pokes and on the right side he REM equivalent ASM code to those calls, so it helps understanding low stuff a bit more.

The thing about the background will get resolved this next days. I needed a background direction and layouts so to know which blocks I will have to deal with. I also certainly need the player full drawn with all of its frames. The color use will be something to keep an eye on because if I shift a block to a different color and the inside part of the sprite has that same block, it will also be shifted. So there is a puzzle here that can be solved by limiting the color use between bkg and main player. I will get into that very soon.

For now I devised a program structure that, while crude, it seems to boost the fastest speed. I will probably try to use ON GOTO whenever I can instead of IFs call within main loop. Here is what it looks like:


Variables need to be declared first thing and most used ones should be a single letter, so I will be limited to ~26 for main loop stuff. I´m currently designing those variables so to use the fewer possible. Then we jump to the end of the code and do TITLE, if game is started, run STAGE DRAW and then jump into the main loop. There we have a state machine for the main player to jump to whatever state he may be in, walking, moving, etc. From those states, I jump to an ENEMY SELECT and then do the same stuff I did for the player, to the enemy chosen.

If speed is ok, I could even add a bit of background animation at the end of enemy state.
Sound will be hardcoded into the states and should you loose or win, those death states (either player or enemy) should trigger a stage advance or game over. The last enemie´s death state should also trigger the OUTRO END, yeah, a victory screen.

In modern BASICs, I´d usually go about creating a system inside code to organize stuff and make it modular and what not, usually full of IFs and ARRAYS. In the case here, such a system will kill performance, so the code structure itself has to be the system. That will create a lot of redundancy, but should be fast enough.

[JobLeonard]

How did you draw that diagram, I really like it!

[fuedhq]

Photoshop, using an open source font from the MSX and palette from COCO´s semigraphics mode.
I normally do them horizontally, but in this case, a vertical diagram seems better fit.
Looks like scratch programming. :D

I´m still working on the variables but I think I have something useful now.
Collision detection was a bit hard to figure in an economic way.

[fuedhq]

Coded in the first scene visuals, it is taking ~740b, and if we consider 8 stages, that would be ~6kb.
It would be neat to reduce that to 4kb, but that at least gives a picture.
One can cut some details or create "tiles", there might be plenty of ways to shrink that down at least a bit

[fuedhq]

Coded in the structure and got the player moving/standing and an enemy displayed.
Made a tap to move a block (2px) and hold to move 2 blocks (4px).
I hope for half this speed at the game´s end.

The added complexity to the walking state is higher with these 2 modes, I´m not quite sure it is needed but seems like a good idea if we think the gameplay core based on player to enemy distance, specially if I can blend movement and attack.

[fuedhq]

Here we have jump, duck and duck walking. I think I´m overdoing it.
Being able to move 2 ways, move while ducking and move while jumping adds a lot to the code, might not be worth gameplaywise.
It does look neat though, maybe it will be possible to, at least, leave the main player that way.

[JobLeonard]

I'm impressed how much animation you manage to squeeze out of those rectangles!

[fuedhq]

Thanks!
Here more haya... the general slow down is another sign that I´m overdoing it.

[fuedhq]

Let´s call what there is so far v.1 and take a closer look.

The game that this is going to be stands at a graphic performance/memory use/design tripod (triffid!).
Design is malleable, memory, in current case, covering for:

Game structure,
1 stage background,
Player stand state,
Player walking state with 2 modes,
Player duck and crawl sideways state,
Player jump, 3 directions state,
Player low kick and combo state,
Player high kick state,
Player punch and combo state,
Player fly kick state,
Enemy 1 stand state,
Collision mechanism

,amounts to somewhere 6k. States are about an average of 500 bytes.
The states were designed in a bashed way, lot´s of experimenting, little optimization and a bit too much wasted variables.
Doing a final clean up will probably get to a 20% increase speed and same decrease in size.

It is safe to say a complete character currently coasts about 4k (4000 bytes).
Having 5; player plus 4 enemies, would hit 20k.

Of course the enemies are not all complete characters as the main player, those who get to be will be the ones I´m going to recycle, ye, use up to 4 times with a different set of moves/AI. Unique enemies will tend to be smaller in size.

Suppose I arrange these 4 enemies this way:

Enemy 1 -> Downtown Punks -> 3 variations
Enemy 2 -> Guetto Dudes   -> 4 variations
Enemy 3 -> Scrapyard dog  -> 2 variations
Enemy 4 -> Scrapyard boss -> 1 variations

There is an hypothetical chance to sport 10 enemies.

Back to the malleable design, if compared, 10 enemies would amount to half the game, at which point I would have to load the next game part, loading in K7 just some 10 minutes :D Just joking, but it is clear the current memory used won´t fit the current design.

About the performance (graphic), each state was made in such an experimental way they vary, but in general, it is dangerously slow. I would like to be closer to an action game than to a simulation game.

So it seems the tripod is falling apart? Sure, I have been abusing it. There are sloppy extra logics everywhere and some are not needed, there is plenty more plotting happening on screen for nothing, even the code structure can benefit some fixing. Notice crawling is faster than walking? :D There is logic to blend every start/end of each movement so the gameplay flows differently. Crawling, direction jumping, flying kick and sidestep were stitched inside existing states, not planned for.

The original plan was to shoot for a vertical slice of the game containing 1 Background, Player Vs. 1 Enemy+AI before doing a project re analyses. Thing is, I ended up experimenting with the player states instead, which I believe gave me a good picture on how to make them better. Since states are fundamental both for player and enemies, I think it was a good move.

I will bring that knowledge in code now but heading towards that original vertical slice.

...at which point, a fairy whispers to me that what currently is could be "Barbarian" in a blink  

[fuedhq]

A curiosity, here is how I best found out to draw that first background:

Code:

10 POKE359,128:S1$=CHR$(&H13):S2$=CHR$(&H14):S3$=CHR$(&H81):CLS0:?"ooqqqqqlb-%%)qpqqqqqqqqqqqqqqqqqb"S1$"qqqqqlb,bb'q"S1$S1$"bqqlloqqqqqqqqqq"S1$"bAA4444b0../A"S1$"b"S1$"AA'.0/A?AAAAAAA"S1$"bAbb1111-%%)Abb"S1$"AA'%-)<"S2$S2$"AAA?>A";
20 ?"b"S1$S1$"bb,'11,!"CHR$(&H1F)"'"S3$"b"S1$"b"CHR$(&H80)S3$"'.0/"CHR$(&H7C)S2$S2$S3$CHR$(&H7F)S3$S1$S1$S3$"bbbbb11110../"CHR$(&H7E)S1$"b1111%-)"CHR$(&H7C)S2$S2$CHR$(&H7E)"b"S3$"b"S1$S3$;
30 ?"1aaaaa111-%%)bbb.bb...."CHR$(&H1A)"bbbb!bb!":FORZ=384TO415:?@Z,"1";:?@Z+32,".";:?@Z+64,"a";:NEXT:FORZ=224TO352STEP32:?@Z,"1\EEEW";:NEXT:EXEC44539:POKE359,126

It takes 569 bytes, it is still a bit too much, somewhere 300 bytes would be neat.

Two tricks I can use, first, use only keyable characters, no CHR$ nor strings, this should bring the size down to 316 bytes, second, I can tile the images, specially every 2 that makes a location. All three options balanced might just get to a better size than current.

I´m also getting a bit worried about how will having say 6 enemies or more will affect the performance, I need a figure on that soon.

[fuedhq]

After having a background load, the game jumps into its main loop, which contains player and enemy states. You run 1 state each and cycle on till one dies. The thing is, that either player or enemy will always be at a single state, so having the fast states is important. A state is a player/enemy action/condition, say 1 is standing, 2 is walking, 3 is low kick, 4 is being hit, etc. I intend a complete character, like the hero, to have about 8 states, it is also safe to say the minimum amount of state a character may have is 4, where 6 is an average. So, another important point is the size of a state, the smaller the better. If a state costs 500 bytes, a full 8 states character will cost 4K.

By now you have probably noticed I´m re writing the code, specifically the code inside states.
So, after having the background in at 569 bytes, time to look at standing and walking states for the player and enemy.

And this is very tricky. I can tell you that these 2 states are the most important ones.
The stand state, while light in animation, has a lot of control requests, it gets heavy.
The walking stand is animation heavy as it has to delete pixels, but most importantly, those two states are the ones the characters will be at 75% of the game time, they are fundamental. The performance I get when 2 players are walking at the same time is the mark 0 to balance all the other states and it will dictate the game speed.

I adapted Allen Huffman timer routine inside the game loop, tried for the most simple stand and walk states I could think of ,and here is what I have:


keep in mind the game runs considerably faster when the timer routine is off.
Notice both standing peak at 9 and both walking right peak at 15.
The game performance will be great if I can keep that number at 20 and below. 10-15 would be ACE!

The stand state is up to grow as I add more control calls for other moves so it might go over 10. Gotta keep an eye on it as there isen´t much I can do to fasten up but to mess with the control scheme, which directly messes with the gameplay. I could only draw the character once to get some speed back in case this goes too high.

The walk state is noticeably faster when both are walking left. Their order of check in game must be fixed in a way walking forward is faster. Even after this fix, it will peak at 14, which is noticeable against 9 of the stand...this will make the player speed change too much whether the other character is still or walking

I also added routines to limit movements, when bumping each other or moving off screen, the later being dynamic as per scene.

These two states are also very flat and done very minimally. I got 250 bytes per state, which could picture a 2k 8 states full single character. It would be perfect!

Before advancing, I need to super fine tune these states. I have ideas for getting it faster and shorter but also have to think hard about the visuals. Being the most seen graphics during the game, it counts if they are rich.

Annnnd before getting back to shape those states, I got feedback from the background code from the last post.
Chaps from discord shared a few hint lists that were great to read and even helps other part not directly related.
George Phillips there also said It's not much, but CHR$(26) is 2 bytes shorter than CHR$(&H1A)

Yep it is, there will be a bunch of calls like that and the combined bytes will eventually amount to some space, say, from some 10 images. Every byte matters, it can only be sacrificed if for performance.

Erik Gavriluk had this to say:


That call will bring back about 4.5k of memory to use in basic.
If running Disk Extended Color Basic, that 27k figure is probably the highest memory space I will be able to use in BASIC while keeping compatibility with all systems.

Simon Jonassen proposed using ASM to deal those background images. If I understood correctly, he transformed the coded image in compressed data, then, a decompressor deals the image back on request from BASIC. Whatever dark magic there goes, he got it to a 202b size. That is around a third of the size I got!

I think from the vertical slice it will be clear to scope the project and think how/where ASM injections could bring great benefits.  
 

[fuedhq]

Finished fine tuning the stand and walk stated for both characters.
I went for simplest, fastest and smallest states I could figure, if space is generous or gameplay calls, I might extend some states as we go along or later up.

Each state was taking 250 bytes, now they take ~180 bytes.
If we were looking at an 8 states character taking 2000b, we are now at 1440b. This is good! I have to keep states at max 250b.

On the performance side, we had 4.5 for each stand state and 7.5 for each walk state.
Now we have 3.5 for all stand and walk states! That is faster and, most important, balanced.


Gotta keep an eye on stand as that is bound to grow later up. Drawing only once instead of constantly can bring it down a point, but best to not go this way yet. For the walking state, I can add a bit of code that will speed it up in exchange of memory use.

All in all this is now starting to look good.

[fuedhq]

With the very basic states done, let´s get deeper into what forms gameplay and how to control it.
I won´t pretend what I have in mind to fit but will now slowly add to the soup, at which point, better take another look at this superb picture :D


Both sticks are moving with joysticks, this is a single player game, I need to start working on the AI.
The AI will eat memory, use variables and affect performance, needs to be very well thought out, an advantage is that it can 
 be recyclable through all enemies, more on this later.

Other than AI, we need the ball, or, an attack state. We will also need a being-hit and death states. Add the energy bar and we start calling this code a game.

[fuedhq]

Now it is a game!

[JobLeonard]

Nice! Also cool how the loser breaks out of then frame and falls onto the health bar