The Physics of Cave Story

Hm. Well, there are functions that determine what side of a tile is touched, right? If so, why not just restrict it? Seems like that would solve most of the slope related issues.

 

there is *one* function for *each* tile collision type (solid, water, slope*8, spike, destructable(?)). The collision doesn't check which side of you hits the tile, it checks which side of the tile hits you. Then it returns the inverse of that (So a hit on the left side of the tile returns 0x4 to the tile collision flags of the entity)

 

That is good to know... I wouldn't know if I would want to fix that or if I would keep the quirk for kicks.

I was just looking through the camera code, hard and soft quakes both add a random value to the x and y position of the camera. However I don't see any checks to make sure the random value doesn't accidentally randomly move the camera very far away. Is this not necessary due to the focus speed or is there a function I'm missing?

Also, what purpose do the constants serve in the camera code? I assumed they were offsets for the focus of the camera, but that sounds illogical and I fail when making assumptions (mathamatical proofs I'm looking at you).

 

The constants are more or less conversion factors (Game units to pixels and stuff) or sizes (Sizeof screen in units, pixels). Maybe something else too, I looked really quick.

Random() can't move the camera very far away because it only returns a value within the given range, and the camera position is calculate from scratch each frame. The camera always "wants" to center on the Focus Object, so even if the quake consistently randoms in one direction for some reason the code will keep bringing it back.

 

I was not entirely specific...

The exact constants I am looking at are the -0x14000 and the one right below it. If you look on the document I posted I have them near the bottom in the camera variables table highlighted in red. I have no idea what they are for, and they happen to be some very big values.

Also, I hear many things about Cave Story having a coordinate system transformation of nine. I see a left bit shift of 9 in that camera code, but that seems an awful lot to shift values. Am I correct? or does Cave Story truly bit shift all it's coordinates by 9 to make pixels?

 

0x14000/0x200 = 0xA0 = 160 = half the width of the screen
The other one I am confident is 120. Each pixel is 0x200 ingame units.. I have said this many times. 1 shl 9 is 0x200. This is done to make smooth fluid motion physics without floating point numbers.

 

*wide eyed*
Now that makes perfect sense! I will go update that document again. It also tells me why Pixel even bothered to work in such atrocious units. Sorry for bothering you with all of this, but as a middling programer (I fear pointers!) my understandings of Pixel's optimized code fall short. Thanks for your time!

[Edit] My head is no longer a pixelated donut!! Joy!..... or maybe I just changed it and forgot.....

 

Pixel's optimized code

You kid.
Pixel's code is beautiful in few places, horrible in many, and optimized in almost none (ie, any handwrit rewrite will always be faster).

 

That is good to know... I wouldn't know if I would want to fix that or if I would keep the quirk for kicks.

You could get upside-down, thin slopes to work like a 'one-way' tile; letting you jump up through, but not back down. (You can sort of do this with a really narrow diagonal double-sided slope, but it looks bad)

You could also get different kinds of tile shapes, like narrow poles, thin walkways, or steeper slopes just to name a few!

 

You kid.
Pixel's code is beautiful in few places, horrible in many, and optimized in almost none (ie, any handwrit rewrite will always be faster).

*whew* That's a relief. I find it hard to work with this and was starting to be concerned that I would have to work like this in the future.

@Dubby
Ya, if I implemented this code in a custom engine I think I might keep that behavior simply for simplicity of the code's sake.

[Edit]
Finally someone looked at my document (okay okay, I admit, I am an attention grabbing hog who needs a sufficiently stoked ego /self ego stoke) and edited, but they didn't realized that I have been editing the Private document without updating the Public one all that much... so if your in the neighborhood, be sure to check the Private one before you edit the Public!

[Edit2]
Okay, so I am totally blind and thought that the helpful user above simply put a 'but the're not' at the bottom to reiterate what I had already known to be false. Good thing I decided to check revision history this morning, because it showed me all the wonderful typo fixes he helped with and also the extra information - apparently putting things in blue isn't enough for my eyes to see!

tl;dr
Thank you anonymous helper, sorry for accidentally editing over your changes, rolled back to your changes, imported your changes to private document.

 

...

I am *very* confused by what you just said.

 

Sorry, must have made that last post incoherent with my last round of last minute edits. It boils down to an anonymous user editing the document I posted on the first page, whose edits I didn't see except for a small comment he/she added on the end. Because I didn't see anything but the comment, only the comment was applied to the private document, which superceded the public. This erased all the other wonderful changes the user gave, which I discovered later when I browsed through the edit history.

I hope to get to do some work on the document today, I find it fun ripping apart code. Maybe I will start a test program using Löve... or maybe java.

[edit] Java it is!
An incredibly early test program has been uploaded to a free webhosting service that currently runs only on macs... because I am a lazy programmer, so feel free to vent your fury at me. It requires some inconvenient terminal usage and only models horizontal movement and static camera position without animation. For the brave and incredibly bored!

[edit] New Version
More tests results in vertical movement! This includes gravity, jumping gravity, and also I added the catch-up style camera movement, with the default focus speed of 16.

[edit] Another Version!
- A tile map made by yours truly
- Real collision detection with hitboxes
- NEW AND IMPROVED STICKY BLOCKS.... ok so maybe that's a bug, but until I have enough time to fix it, it's a feature! This means you must jump in order to move off blocks, and you can also wall jump...

Has anyone even tried them out? Do they feel like cave story does? Have I missed anything glaring?

[MOAR EDIT!] Another version!
Just a simple patch really for "White Honey", thus this one is "White Vinegar"
- Sticky blocks removed, only remnant is sticky map edges.
^--- I know you really really wanted to keep them in, but coding with all that honey around makes for sticky fingers!

Next version will include generic map input, if anyone wants to make their own map to test out my code, they would have to use the oside tiles to make a map using tile 35 for collision. Then save that map as opening.tmx with base64/gzip compression in tiled, and also save the tileset as outsidetiles.png..... then put it in... the jar??? I'm not sure how you could do it without the sourcecode, which I should get to releasing soon, under something very non-restrictive.

I also added the breakdown of the camera code to the private document. I will submit it to the public soon to prevent duplicated efforts.

 

Person
Will the windows version?

 

More updates... and no one replies

Reply.

Seriously though, STICKY blocks? Like... wall jumping maybe?

 

Reply.

Seriously though, STICKY blocks? Like... wall jumping maybe?

Well, I was being lazy and didn't respect which side of the hitboxes collided, and also allowed jumping whenever collision occurred. Thus, when quote hit a box side, his velocity became 0 in all directions (he stuck) and he could still jump and move away!
But version 4 made everything normal again!

Person
Will the windows version?

And the venting starts, rightly so! Version 5 should work for windows (and mac and linux).

I achieved that by adding the native files for all three platforms to the src folder, and I'm hoping that doesn't cause any problems down the line...

Also, it is still a pretty hacky release, requiring some knowledge of how to run .jar files from a terminal of some sort. Perhaps I should look into creating full stand-alone applications sooner rather than later.

This new version (Version 5) adds some more map to the top left to help test the physics. Included is a mirrored copy of the "saving booster" jump from the labyrinth, 1 tile corridor, and some 3/2 tile high roof jumps. This testing reveals some problems:
• either my hitboxes are wrong (very likely) or my implementation for air control is wrong, allowing the impossibility of 7 tile jumps.
• I have set up some sloped tiles that you can see hitboxes for on the top of the map, but I made them 1/3 slopes thinking that was the standard (for some reason) when pixel actually used 1/2 slopes *facepalm*. I didn't implement collision for them yet so it's trivial to replace.

Anything else glaring me in the face?

p.s. @dubby
I am going to implement the slopes in the same way pixel did, because it is easy and arbitrary shape collision will take too long compared to square collision.

p.p.s
forgot to mention I included the source files with this release, when I actually wanted to include the entire netbeans project That will be fixed for next release for the intrepid code monkeys hiding on the forums!

p.p.p.s
Noxid just sent me the hitbox coordinates for quote, and mine are terribly out of line in comparison. I will fix that soon!

 

Well, I don't know about you, but I would *love* conditional sticky blocks in the original cave story. Because, well, wall jumping is sweet.

 

Just to let you all know, the project is not dead. Not far from dead, but not dead. I've bumped up against producing a flexible design for maps, that would allow any java programmer to pick up Tiled and Netbeans and create a new block type in minutes. Been talking about polymorphism and null objects to no end with my instructor trying to think this forward. Hope to get some sort of alpha version of such out this week. Any other block types you people would want to be able to add easy (aside from Dubby's wall jumping blocks of course)?

 

Crumbling blocks
Icy blocks
Slow blocks
Fast blocks
Megaman Disappearing blocks

 

Switch Blocks.
But... if you were trying to duplicate the original physics, why add new things?
As long as your changing things, why not make the physics work like real physics?
(ie, have the vertical acceleration be equal to g - (g/t)v)

 

Switch Blocks.
But... if you were trying to duplicate the original physics, why add new things?
As long as your changing things, why not make the physics work like real physics?
(ie, have the vertical acceleration be equal to g - (g/t)v)

You seem to have taken the idea farther than I expected. I do not want to change the principal portions of Cave Story, only extend them. Real physics do not apply to Cave Story. It would be as if I wished to apply theories of Renaissance painting to the drawings of Escher. How tall is Quote? How far is a meter in Cave Story? It simply can't be done without doing something that is decidedly me, not Cave Story.

Kinematics is not the goal, cinematics are.

Now, for every suggestion, I think the current situation will be sufficient. I have a general class called 'Block' that holds data for a sprite, position, collision polygon, and a couple other things. I also have a map called 'BlockMap' that holds an array of blocks and functions for calling collisions on 'Actors'. Because the 'BlockMap' draws all 'Blocks' it contains and also handles their collisions, any java programmer can extend the 'Block' class and create their own block type. By overriding the onCollision method, the programmer can make the block do *anything* when it collides with the passed in actor.... let's hope there are no oversights on my part!

p.s. 'BlockMap' may or may not take a new name. I haven't decided if maps hold 'Actors' or if maps spawn 'Actors'...

[edit]
This is just an edit because I have no real work to show. After a week of being a selfish jerk (DO NOT participate in psychology experiments, they only make you feel like a jerk), I finally took the time to sprint out the mapping structure. It is held together with tape and netbeans, and I still have to place collisions back in... bleh. Once I get that all set, making new types of blocks will be a sinch, and I could possibly get sloped tiles working correctly and even the dreaded one tile corridor! (which should not be all that dreaded)