This is going to be a head to head Schmup over calcnet2.2

It is a indirect port of the game style of The Ika mode of Rrootage. This game also mimics aspects of the game Ikaruga.

The main portion of this game will be rather simple. You have a ship. You have a few lives. You shoot at your opponent and try to kill them.

The Twist: (This is what makes a Ika style game an Ika style game in my opinion.) Your ship has two polarities. One light One dark. The light Side shoots Light bullets. The dark side shoots dark bullets. The catch is that each side can absorb there color bullets. So if you are Light and you hit a light bullet it does not harm you. But the dark color bullets will kill you.

So that's the basics.

Whats planned so far/what I want in the game.

-Head to head
-polarities on the bullets
-different kinds of bullet paths. via selectable weapons.(will balance out some how...maybe I like bullethells to much to not)
-graze
-Different game modes for when your not internet connected

Things I'm not to happy about:

-This will probably be an app. Which means you will need 4 app pages worth to play this game. (Thats dcs for you )
-The scaling that will be needed to keep this Cn2.2 happy

Why does it need to be an app?

It may not need to be current thinking in my head deems it might based on the space that will be needed for the bullet tables. I have to finalize my data notes before I decide on if it will be an app or not. Really just depends on if I can Squeeze all the space I need out of safe(ish) ram

It'll make things significantly more complicated Cn2.2-wise if it is an app, in fact, because you'll have to release a new version every time I improve the CALCnet libraries. At any rate, this project sounds like a lot of fun.

So i spent todasy hashing out what i want my calcnet packets to look like. As well as some crude details for related to each of these things.

I will be posting alot of my notes up here just so I have them electronically as well as written down in my notebook at home. Just for safe keeping.


Misc notes:

-Game has a 24 bit counter for ingame use (if a match last more then roughly 42 minutes we have some kick ass good players lol)
-Playing field will be 64/64 looks good on the calc screen
-3lvl greyscale

Frame types

-Synchronization frame
Send the player X Player Y and game time to the opposing calculator. Is sent every few frames to ensure synchronization.

- Bullet Frame
Sends the player X and player Y. The current game clock. Followed by a table of Bullet generation data. This is Bullet Type ID, Creation Time,X,Y

- Collision Frame
Sends The players X and Player Y. The current game clock. Followed by The Bullet that collided X and Y.

Each frame causes a different branch of code to be run.

the Sync frame updates the opposing games clock and bullet table to match.

The Bullet frame updates the bullet table and iterates all the bullets to there new positions based on the clock info.

The collision frame checks for a collision then sends a N/ACK back depending on if it is a verified collision or not.

All frames update the player X and Y

wow, i think this may make the usual versions of this game look like a bore. great luck with this, geekboy! im guessing; since this has grayscale; that it is in ASM?

That would 100% correct luxen. Going to need every ounce of speed I can muster for what I want out of this game so ^^

ASM is a little too monotonous for me, i wont use it except for my secret projects.

Yeah asm is daunting to start with once you learn it its easy to work with imo. I learned asm working on cadan. Which is a shmup (if you can call it that lol).

Plans for the evening layout data tables and buffers.

More notes.

Bullet table entry structure:

;=========v========v==================v=========\
;+0 | +1 | +3 +4 | +5 |
;X-Pos | Y=POS | Cn-LSB Cn-MSB | Pattern |
;=========^========^==================^=========/

-First 2 are self explanitory.
-Cn is the counter it counts the amount of cycles the bullet has been alive (possibly /2 based on the fact that i will probably be servicing the Bullet table in an interrupt for uniformity sake)
-Pattern Is the bullet pattern (these will be clarified as different bullets to the end user) The pattern is confined to the first 6 bits. The last 2 are used for the bullet color and one is left for any additions in the future.

Patterns are data blocks that specify the path the bullet will take. The exact format is not decided on yet but they will be like a mini script system. With Add Sub Jump Create and Destroy Routines.


There will be 4 bullet tables. 2 bullet tables and 2 Free bullet tables.

The bullet tables hold bullet data each entry is parsed for uniformity across the calculators.

The free bullet table holds a list of entries that point to empty slots in the players bullet table to make sure we only put bullets in empty slots. When the FBT runs out of entries we do not create any more bullets.


Only problem I can see occurring with this setup is a collision happening and the tables being skewed due to small differences in time. THO this should be avoidable if care is taken to make sure any collision frame is handled IMMEDIATELY instead of a bullet frame being parsed overwriting old data. This will allow the collision to be processed before the bullet data gets overwritten. This case will only happen when bullets are ran into when they are right on the bottom of the screen. A simple but hackish solution would be to just expand the play field to a 72x64 field instead of a 64x64 field then bullets will have a chance to leave the screen before being destroyed. thus eliminating this all together.

Sounds like you're making good planning progress to me, geekboy. I hear that you're considering some of the classic distributed computing problems, namely the impossibility of maintaining a global wallclock and shared data access synchronization. Good luck!

With how Kerm phrased that, it got me in the right frame of mind to think of relevant algorithms. Namely, it sounds like a vector clock might serve you well.

Well i Should probably explain my thought on my engine model so ill edit this post with that when I get to a computer.

But in my head the engine doesn't need to have any specific data in sync except player location. Followed by events in priority. As long as bullet creation data is sent in a reasonable fashion of time it should all run smooth with my engine model idea. Idk will explain in detail later as hammering out the main program flow is the goal for tonight

Meh didn't get there. new question

Can anyone explain in detail how greyscale works? I keep forgetting :< (or give me a link to something that does.)

Escuse the poor formatting I typed this up in npp as a comment block



Kerm you said the hooks should go inside the flash routine since saves more space in the long run. I took a look through as to where would be good places to put them. This is what I came up with.
line 266 looks good about for a before interupt hook.
caveats: Runs at 6mhz ix,iy need preserving
Must remain short has a long interupt after it.

After lookign through the code it branches at the middle of your interrupt code Kerm.
I think that putting the end of interupt hook in ram might be best. easier to patch for one and takes less space.
Only one code addon instead of 3. Unless we want to have it set up so that each interupt branch has its own particular hook. I dont think we need that but up to you.
Next how exactly do you want this to check if its hook is active?
as i have no idea what you were describing at hcwp last week.


I also looked into that on bug when I trace the current code in my head it looks fine. Once I get home and settled tonight I will take a look into that and make sure it is properly fixed up.

Oh yes, I'll have to add the code and logic for that hook stuff. I will definitely put it inside the Flash routine, not to save space, but to keep the in-RAM stub at a predictable and small size. I'll try to toss the code for that together this evening, all four-ish lines of it. And yes, my code does branch in the middle, but it's trivial to give all the execution paths of the interrupt a common epilog. As far as code, I meant:


Code:

Even if this were an App, Doors’s libraries wouldn’t need to be copied. Just accessed. But hey, I like this whole thing already. I had a similar idea not too long ago!

Im just hoping i finish it before contest end lol. Life has been hectic lol.

Kerm can you make a post when you have added the code and push it for me?


Ok messing with netpong and the on bug in PTI i cant even get PTI to turn a screen off now. So I have no idea whats going on there.

I added the pre-Cn2.2 hook. Why do you want two hooks, anyway? I think one is enough.

Just makes sense to me. I was going to use it so i could service frames on interrupt end. And little maintenance things that can be tacked on in the remaining cycle count.



EDIT:

question do you think Destroying the graph variables and finance variables is acceptable in a game like this?