next »

[JobLeonard]

EDIT: quoted because pagination

Sure shot, I think I got a solution, at least a path.
See, the way it is, works and the game flows, but in a very static rhythmic way, like whoever was doing the game wanted to try the best to keep to speed! :D

I think I will break the moves in a way to have 1 or 2 extra frames per pose. It will slow them down, and I think if done in a way to promote the motion, it will work better. I might need to redraw stuff and the game pace will be a bit slower, but I just might be able to add the "movement prediction" element I wanted to get from Karateka. I will keep the fast going punch though.

I have seen similar techniques on the modern King of Fighter´s series on the NEOGEO, it should be possible on this resolution.
Let's see.

Sure shot

Cause fuedhq can't and he won't and he don't... STOP!

[fuedhq]

Well Hello! Long time no see!

Let me sum it up...
Check the topic's title, add to that "commercial quality" a triple A (AAA) to make it more clear

If that was ever to happen, I'd need to be sure of graphic performance. Did a bunch of tests and came up with a good solution. Other than that, memory usage (~25kb) and the game idea, closes up a tripod of primary features.

Went on a prototype, went full heads on with those features, came out with a neat promising game. Performance took a bit of a hit, but that was just because I wasen't quite caring for that at that moment, no problem. Developed a neat game idea and also a good code structure to compose both. Memory usage failed horribly. No problem at this point I thought.

Decided to go for a second prototype, this time, keeping up to performance and idea, and attempting to do it using the very least amount of possible code and memory usage. I got the code structure superbly fine tuned, managed controls, kept performance in check and a whole bunch more... but for 2 thing... memory was still busted, not able to support the game idea in no proper level, but even worse, the game came out boring... yes, very boring.

That was about 3 months ago and was going to lead me into a third prototype attempt to mix it up but I sensed a "major boss approaching" warning out of it

See, we have limited amount of will power and a certain amount of managing motivations(self and external).
Those things can't be wasted. The death circle I was going to head the project towards would have been unsolvable and thus the project would go dead. That can't happen. We can learn from good and bad, but nothing from what never was.





Still, much good has also happened, time to get into it.
Welcome to Season 2!  

[fuedhq]

First I would like to try to explain what a BORING game my second attempt became and some of the outcomes.

While the first one got to a fun game potential, for it was close to Karateka, my main reference, the second took a path towards Yie Ar Kung-Fu. While I like the later for its variety, its gameplay is not really a thing for me. What I came up with was a poor attempt on that but without response time and speed. A game that you bash anything for the sake of luck.

I intend the player to be able to perceive personality on the opponent. One has to be able to see the motions on the way so to take proper counter action, even if one has to play it over and over to master it. It must be about building technique, never pure luck. I clearly have strived away from my goals, and did so because of the memory beast I have grown.

Together with that monster, performance is ace and so is the idea. I have also polished the code structure, something that goes right under that tripod, that is so beautiful I'm in love with it(more about this in future posts).

And that is it, facing the memory monster has been one of the highest priorities and here goes the outcome:

My last attempt dictates I can have about 6 characters. Sure one can go about managing that to feel like it sports more, but let's face Barbarian, it has plenty of the very same character and one boss so that is a 2, let's face Karateka, 18 enemies but in reality they are all the same but for the hawk and the girl. We can look at all those 80s and 90s beat em ups and they recycle enemies like hell... heck that is one thing I sure want to avoid, and with 6, I won't be able to do so.

6 boring characters is within 22kb, how could that increase?
I could pester the coco masters to help me use 64kb. That would mean machine language stuff and most likely code restructuring. I can't do either, and worse, I can't pester the masters for cleaning up my acts as their knowledge is not for bringing crap to ok but maybe very good stuff to a higher level, it feels offensive to currently ask for so.

Let's just remember what memory is about here. It gets consumed by creating variables and by the code list. The former is under control for I need very little, but the later is where trouble happens. I need a longer code list and my code structure dictates so, otherwise performance is blown.

Few months ago I stumbled into a facebook coco group post about a command only available to Dragons, it was something about disk loading basic code to merge into the current one while keeping the code running and that got me thinking...

While I never thought deeply into what kind of media this game would go about, I sure kept a romantic faith in tape k7.
Heck, who does use a coco nowadays with tape?? That is a good question to bring to the community...
I think the current users are going on with an SD solution or/and a direct to PC wired connection, and both are for disk access, including FPGA and EMU users.

Never owning a disk system on my late cp-400, I had to request community guidance (to be continued).

Result: A wall of text post that will be able to be seen from Perseverance on Mars in a few days...:D

[JobLeonard]

There's a bit of jargon in there that I can't quite follow, but it looks like you're really hitting the constraints of the current system you're using. Why stick to this particular framework?

[fuedhq]

More like dealing with the constrains of the target system, the TRS-80 Color Computer (COCO).
BASIC is the only language I can work with. I think I let the game idea fly too high without thinking better about the memory use. But now I refuse to bring the idea down.

Time to learn to deal with disks on the COCO.
Remember I was working with Extended Color Basic(ECB)? Now I will have to use Disk Extended Color Basic(DECB).
That means the graphic performance solution I´m using will need to be tweaked, since it does not work on the later.
Probably foreseeing it back on the project start, Erik Gavriluk and Simon Jonassen both shared code to fix that front, so I should be good to go as soon as I add that.

My current code pipeline uses Atom IDE and Xroar emulator, code is loaded by the emulator simulating a k7 tape out of an ASCii file from the IDE. Since I will be using disks instead of k7, how to do so?

With the marvelous tool RSDOS, by Sheldon MacDonald. It is a quite complex disk tool a pro can examine tracks and whatnot, stuff way above my knowledge, but for the little I need, pushing code from my IDE into a disk image to be loaded by the emulator, it works perfectly and is very simple. Here is an introduction video by the author:





One can even edit the basic code directly in it! Super! Keep in mind it is a work in progress.
If you are interested on it, you can download it from here:
http://www.smotion3d.net/downloads/rsdoswin.zip

Sheldon keeps an FTP with his tools, you may examine it here:
www.smotion3d.net

Still, going through this process every time I want to test a code means a lot of clicking and waiting.
My current k7 loading means I just hit ctrl-s on the IDE, click on the emulator, hit ctrl-l, load the file, type CLOAD and RUN.
It is fast enough, but as the game progresses, I will eventually be needing to test it through disk, so all is fine here.

Let's get back to the memory dilemma and how the disk stuff may solve it.

Thinking about that MERGE command on the Dragon, here is what I thought.
My code structure is very linear and modular, so enemies and stages are well set apart.
I could load the game containing the first stage. If one advances, the code loads the second stage over the first stage and resumes from there. So with such stuff, I won't be limited to ~25kb for the full game but be free to load in eternal amounts of 25kb code.  

To be a bit more technical, I´m not loading data as with loading a picture, I want to merge code, load in new logic. The prior code is kept, if the new one shares the same line number, it should overwrite, if not, add to code, and if the new line number is blank, it should delete the original one. I would expect the code to resume after that as if nothing happened.

Someone told me that Disk Extended Color Basic has a MERGE command that may just do that.
It does merge the code as I wanted but I got kicked out of the program back to the BASIC prompt.

Erik Gavriluk then said:

Someone mentioned the merge command but forgot the ",R" which means "run after merge"
MERGE file,R             Merge a program and start it running
Try: MERGE "LEVEL.BAS",R

And so I did, but by running after merge, it started from the code beginning, it did not resume.
Also, run clears all variables...

So what about keeping some variables through? I may not need many.

Here is what Richard Kelly said:

You might just have your variables put into the cassette buffer instead.
First POKE474,A:POKE475,B:POKE476,C then in the second program have A=PEEK(474):B=PEEK(475):C=PEEK(476).
I did something similar with my maze-making algorithm.

That, while a bit complex to me, sounded like a great idea! Now that the game is going on disks, it should be fine.
Justin Poirier also proposed a way using OPEN, LINEINPUT and CLOSE. Other friends also had different solutions.

But here I thought, do I really need to push variables forward? If so, which ones and why?
Well, stage number might be one, but thinking deeper about it, it is quite a static one and the merged stage can have it hardcoded on a sort of head line, so that one is fine. This game has no score, so the troublesome one might be player´s energy.
I may want to keep its value as one advances through enemies. But wait, is it really needed? Maybe within a stage, but not through the whole game. I'm not going to have pickups to increase it, mostly maybe increase it a little every time you beat an enemy, like in King of Fighters, but even then, when you change stages, you get everything back up again, same stuff as in Street Fighter or even the brawlers when a stage is done. So for now, I will go along without it.

With that partially resolved, time to give it a test.
This is what the main program looks like:

Code:

10 GOTO 100
20 PRINT"A="A" B="B" ANY KEY TO MERGE":EXEC44539
30 MERGE"MRGTP1",R

100 B=10:A=1:GOTO 20

200 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
210 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
220 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
230 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
240 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
250 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
260 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
270 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
280 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
290 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

So the main code is made by lines 10 to 30. Line 10 shoots the code to line 100, which is the head line on the data code, and then it shoots back to the main code at 20, prints variables A and B, waits for a key press and then do the merge.
Here is the code to be merged:

Code:

100 A=2:GOTO 20

200 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
210 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
220 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
230 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
240 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
250 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
260 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
270 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
280 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
290 DATA 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

This code has only the head line and dummy datas, head line sets variable A to a different value but does not touch B.
After running this code, this is what I get:

As we can see, A comes out as 2, think of that as the stage variable.
B comes out as 0, it was not kept after the run command, got reset from 10 to 0.

Seems to work! But there is more...

I remade this test with both files having dummy data taking almost the full 22823 bytes available each.
Here is a more detailed outcome:
Loaded the core code and after running and immediately braking the code, memory left was 111 bytes.
Loading it took about 22 seconds. Hitting a key to get to the merge part, it look about 110 seconds to do so. after such, memory left was 123 bytes.

Results: Memory monster seems tamed, disk system seems under control, but what is with that almost 2 minutes to load 22k? I probably won't need to load that much but that is a long time for a player to wait! If I load/merge 10k, then I should be expecting it to take a minute, quite too much. I will need to take a closer look into it.

[JobLeonard]

> BASIC is the only language I can work with.

I dunno man, based on these posts I think you have the chops to pick up assembly quite easily. Especially for an old target with known hardware like the TRS-80

[fuedhq]

It comes to mind very often, there are docs and videos to help that out and a great community all around.
It would definently mean I would have to start with a very simpler project than this.
On the other side, I'm more attached to the art and interaction, my code skills, even within Basic, are very short, just enough to get there. Should I need more speed, I can code for PC/win with GLBasic. So there is a dilemma here on whether I'd put time on learning a programming language or making a new game with what I have in hands, the later seems to always prevail.

Specifically for this game, the graphic performance led to a code structure that led to a sub-project, I will describe in the near future, but needs to be in Basic. I can't move away from that now since stuff is already very advanced.

Tell you the truth I'm a bit full of all these technical samba to fit with the limitations and am very eager to get back to game content, gameplay, etc. I foresee it will be very soon though.

[fuedhq]

This should be a quick one, but a very satisfying one!

Took my test disk to the COCO community for checking those load/merge times.
I had 22 seconds for load and 110 seconds for merge on the Xroar emulator with an RS-DOS cart.

This is what Paul Shoemaker reported:
Erico, on my 64K Extended Color Basic CoCo 2 with a 6309 processor and a CoCo SDC, it took about 24 seconds to load and about 98 seconds to merge.
On another 64K Extended Color Basic CoCo 2 with a 6309 processor, running from an actual floppy disk in a FD-501 floppy drive, it took about 36 seconds to load and about 122 seconds to merge.

Very interesting numbers, they are somewhat close to the emulator. Thanks Paul!

Still, that merge time just won't cut. It would make sense to use it if its speed was similar to loading and I could gain more by merging only what is needed. Not the case.

So, the solution is to use the standard LOAD "LEVEL01.BAS",R.
It will load fast but replace the whole program, even the redundant parts, but the speed is the winner here.

To be elegant with the game, I would not want the user to load the second stage directly for it would work, so I have to look into a few variables going over to the next load. If I can push the energy variable forward, it should be enough to control it all. This, of course, is not a big trouble since the game is in BASIC. Anyone with knowledge on it will be able to play around :D

I made a new test program containing it all and using that technique described by Richard Kelly, the one to send variables to the cassette buffer. It worked perfectly!
I also noted that using my basic program files naturally, it takes about 36 seconds to load. It is when using Sheldon MacDonald's RSDOS tools, with the marvelous tokenize basic program button (BAStoken), that I get it to be 22 seconds.

Now one could think that loading the whole program all the time has no advantage, but I can see a few, like I can change the main player's alpha semigraphics so to be able to have backgrounds with different base colors.

I think this means the memory beast is tamed... I foresee getting back into the fun REAL game making very soon... I can also sleep in peace now

[JobLeonard]

Sounds like a very heavy debugging session!

Get some rest man

[fuedhq]

Lot's of rest later...
...and I'm finally back home, so the more creative part of the game can advance.

I need to strip the game structure to a point of a final form, also add required routines into it, like the semigraphics fix for all modes of color computer roms proposed by Erik and Simon, and the area to deal with loading newer stage/code. This will be used as base to all code load blocks and will also help stating the real available memory for content.

As for content, the first game file might have a little intro and title screen + menu, roof top for sparring and 3 street views. The roof is for the tutorial and training, also for a one on one 2 joysticks bout.

As for enemies, a downtown gang, I plan 2 enemy types to sport about 7 gang members and 2 bosses.
The gang type means one type of enemy with a lot of moves but each of the 7 ones presented have a suitable combination, none uses all moves. The final boss is a knife thrower dude on the building and when confronted, he is as the gang members but performs some hardcore moves and is very smart. The other boss, a mid boss, may be a bigger punk dude with a blunt weapon.

The least I will be looking at to cover for it is 4 characters and if considered 5kb each, we would already be at 20kb.
Add about 4 screens at 600b each and we are at 22.4kb. Out of a total possible 27.4kb... we would be left with 5kb for the structure routines, sound, music and extra animations. Sounds a bit tight but it would be nice to be able to fit all this into a single file so that you can play this much without a disk load, which will take 20s and as you loose, another 20s to get back to the first block. Another solution is to create a smaller file for intro and tutorial and a larger file for the first stage should content space be needed.

Here is a WIP on the first stage and rooftop.

[JobLeonard]

Is that 5kb for enemy type or enemy on screen? In the latter case you have some redundancy issues I think

[fuedhq]

ah, ~5kb for enemy type. The picture is showing 3. Main player, second player on the roof and the punks all around.
I wanted them all visually unique, but it would prove a bit too hard on the current resolution and memory block size. I also don´t want to have a full 20s load every 4 characters you beat, so this scheme shall work.

[fuedhq]

Researching a bit of gameplay.

[fuedhq]

Let's start with the roof.
First create the hero and his friendly opponent, all joy controlled, then create the enemies brain and his AI, then create the tutorial. This step stone is pretty much the game, the rest is content.

Everything up there, but the tutorial, kind of have to be built together, mostly the first and second players joy controlled.
To keep track of that, we have 558 bytes for the code structure and 182 bytes for a simple test background.
Total 740 out of 27,431 bytes.
Here what we are looking at:

Notice the number 2 under it. it means the processing time per frame, actually at ~1.5.

This value would be cool if stable at 15 or less.

[fuedhq]

Some jumping animation getting cooked...

[fuedhq]

Like said before, the translation of the players are the most important thing, core element of the gameplay.
I spent the past days working it out. Sounds simple at boot for what I have achieved so far, but it does get very complex and I have already rewritten it about 20x :D

First, lets think about the game style. A side beat em up where you don´t perform overhead jumps neither change sides or go through  opponents. Do you happen to know games that were designed this way? Apart from Karateka, it becomes quite difficult to think of one and they might mostly be underdogs.

The arcade Gladiator

Sword of Sodan on the Amiga

The former a very unique fight game, the later, more like a tech demo.

So here is my idea:

Standard motion is walking back and forth, there are 2 types, stepping and walking. Stepping will move you 2 blocks and last 4 frames.You can´t cancel this motion and it is triggered by tapping the joystick left or right (might not be a good idea for the original analog joy of the coco :I). If you hold the direction till 2nd frame, you start walking, speed is the same 1 block per 2 frames and you can instantly change directions if you push the joy the other way, release the control and the player will take an extra 1 block and 2 frames to halt. You can perform tricks like half stepping forward and then a back walk, etc.
Notice stepping moves you per 2 blocks, so at closest distance to the enemy, you will always be either 1 or 2 blocks away from him. That is a catch on stepping. You can change this 1-2 "dimensions" by doing a walk. Finally, keep in mind that the player´s motions also incorporates the defense, that is, there is no defense here as like in street fighter, you have to dodge. On this aspect, walking backward moves your collision pivot point 1 block back instantly (1 frame).

Ducking and crawling. Players have 2 collision points, lower and upper bodies. Ducking gets you out of the upper in an instant, 1 frame, and then you can crawl either direction 1 block per 2 frames, notice that while crawling you may change that 1-2 dimension thing from the stepping. Release the joystick and it takes 2 frames for the player to stand back. Both the moment of ducking and standing can only happen with the player still, so if in the middle of a walk, it will cut to change. As for defense, ducking gives an instant upper defense. If you intend to duck and crawl back, it will take 3 frames. Crawling also does not have a defense priority like stepping, when you move, your collision pivot will only do so after 2 frames, so you are more exposed.

Jumping. Exposes you through the first 2 frames then 5 frames of flying (invincible) and 2 frames exposed while landing. If side jumps, it moves you 3 blocks, yeah, inverting the proximity 1-2 dimensions      

I´m currently working the blending of these states and fluidity on controlling the player.
Say, maybe ducking and standing while crawling/walking should not halt the motion, or maybe if you are ducked, you may instantly jump...

edit:little info fix. You actually currently can cancel the stepping by holding opposite direction as it gets to change to walking after 2 frames, it will then walk but towards the other direction.

[JobLeonard]

It looks really good man. I think not being able to walk through your opponent can be an interesting design choice, really. If designed around properly it forces you to deal with claiming territory and freedom of movement, like whether or not you're able to retreat to avoid attacks and counter-attacks.

[fuedhq]

Yep, and the very first attack to add is going to be a push back to wrap the motions.
There are some other interesting elements, like, the resolution is so low and the pixel takes so much space that makes it very clear and fast to recognize if you are at attacking distance. It is pretty much instantly. While on, say, street fighter, you are never sure if you are not a pixel away.

Thinking deeply on the matter, if it is an instantly yes/no, there wont be skills to build but luck.
This is partially the reason last prototype was boring.
I'm hoping to tackle this issue with that constrained a/b positioning on stepping, the pushing action, attacks that advances/retreat ground and lots of animation frames where possible.

The act of pushing won't damage but please, dont think about that Barbarian roll, it was very annoying, In this case here, I'm hoping to build it to fully add to the gameplay basics, hence it is the firt attack move and the game must be fun with that alone. Pushes are the fastest of the moves if you are face on the enemy, it is performed by bumping the enemy but they are under a priority rule. This all also have to solve the corner dilemmas.

[fuedhq]

So I made the push, and also made the jump perform a push too if you jump onto the enemy.
Jump push prevail over walking pushes that prevail over being duck.
The catch is that you can´t be jump pushed if you are ducking.
Jumping now bounces back if for any reason it collides with the enemy.

There was a lot of not funny work done on things like borders and "what happens if I repeat this move forever" stuff.
I believe the thing is balanced now missing just a few bits.

At this point, in order to further test the configured gameplay, I thought to wrap around a simple finished game with it as a quick side project, but one to help the main one.

So I made a "push your friend to the water" 2 player joystick game, using the current mechanics. Here is what it looked like while deving:


Added a few bits to it as test, like background animation, and bloated the whole thing trying different stuff...to the point of having to use the speed poke.
Here is the latest version with me punishing my housemate...





Time to get back to the main project, the side project helped a great deed on tuning the gameplay, I'd tell you

[JobLeonard]

Very nice!

(what's the music in the background?)