Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles

Excitebike (Heavy Work in Progress)

A topic by ThePurple created May 20, 2018 Views: 572 Replies: 37
Viewing posts 1 to 10

Hello all! Just thought I post a little bit of a sneak peak into what I am working on, and might ask for some help or advise in the process! (Seeing as I am a little new to this tool) 

Here is a screenshot of the original version, and my version. (That is again, a heavy work in progress, almost nothing is done at this point in time, but it should show the perspective I am going for.


While this doesn't show too much, you can probably see that I am attempting to turn this into a flat track, and convert everything to actual 3d, instead of what the pseudo-3d entails. This however, has a few major problems. While the original moves the characters up and down to create an 'illusion' of changing tracks, if I move him to the location shown above, and decide to go left or right, he will still go up and down, and float in the air. My question is, can this be changed, through scripting, or something of the like? Or am I just out of luck?

My other question is that excitebike uses objects in odd ways sometimes, at least, when trying to convert them to 3d, so, I was wondering if there was a way to disable the 'rippling effect' that repeating objects gain, so that a change to one of the objects will not necessarily effect another one. It sounds a bit complicated, and it might be able to be done with some careful cloning on my end... maybe. Let me know in the replies! I'm not sure if the thing I am working on is even feasible...

(1 edit)

i think i've run into the same issue in further probing with Road Fighter that you describe with the rippling effect and i don't have a solution for it either. there again i've been doing a lot that i haven't been uploading as well because they are too messy to show and have run into some weirdness that i can't solve due to game tile weirdness (exerion, rad racer, Mystery World Dizzy).
As for the first question, there's a lot of stuff that you might be able to change with scripting in my experience (still not as good as geod's considering things but i'm getting there) but how you change it might depend on what is readable and writable as far as functions (again, i refer to geod's wisdom there)

Cool. I thought about trying this one but wasn't sure how to turn the flat pseudo-3D ramps into actual 3D objects at the time. Thinking about now, maybe with some cloning, texture editing, and the deform tool, something could be worked out.

You might be able to do do something like what JJXB did with River City Ransom to get the rider to move in and out as opposed to up and down. It is basically translating movement on the y axis to the z axis, and then zeroing out the y axis.

I've done something similar while messing around with Commando. I had a script that rotated all the background sprites 90 degrees and made the player move in and out of the screen instead of up and down.

I'm not familiar with the rippling effect you are talking about. Do you mean what is happening to the ramp in the picture you posted?

Sorry, I didn't explain the rippling effect very well... Basically, any objects that would appear in different locations share different axis locations, so that when you deformed them, they some would go in the correct spots, but others would go in unintended places...

And yeah, that is exactly what I am going to do! I am pretty much going to have to erase all the ramps, and rebuild them pixel by pixel, taking pixel measurements so I get the right height,  and building them that way. It's going to be a long process, but I'm sure I can make it work! Might just take some time... 

Ah. I think I understand what you mean by rippling now.  I think I ran into something similar when editing the Kung Fu title screen. The title uses a pseudo 3D effect on the letters to make them appear like they are popping out. Trying to  use the deform tool to simulate that in true 3D was difficult. The Kung and the Fu used the same texture, but were treated as separate objects. When a deformation was applied Kung it looked different on the Fu since it was a shorter object. Don't know if I am explaining that well...

Anyways, that does sound like a lot of work for the ramps. Hopefully you can get it to work. I wish you luck!

(1 edit)

Be careful ThePurple! Pseudo 3D graphics are generally solvable with a lot of hard work but 3d gameplays are totally another thing.

JJXB already had a bloody lesson with River Ransom City here ^-^

Character moves in 3 dimension but all we have at most is y position of main character. Without y position info we can not transfer other characters to 3d space!!!

Back to Excitebike, that's obviously 3d gameplay because the bikes can fly in the air but with current ram map info, all we have is:

0x03D4 : coord y some kind of vert pos, not quite though

That's even worse than River Ransom City here :(

(1 edit)

Yeah, I can certainly see where the problem would lie! Now, I think with my shift in direction, it will be a lot easier though... But I still need to figure out how to convert y coordinate movement on a ramp, and convert it to z coordinates... And only while in the air, or going over a ramp. However, I'm not exactly sure how I would perform that feat, since the y axis is also used to move around bikes and such while they are on the ground. Is there a script, or an example of one on another 3dn thing that this could use?

Maybe only have y change to z whenever the up or down keys are not pressed? This might allow lanes to be changed without messing up the ramp physics... Much. It might look a bit glitchy if it is possible, but again, I'm not exactly fluent with scripting, to say the least!

Hmm... I think I figured out some version of a workaround, at least for me. The trick is, I think I am trying to convert this to 3d so that it matches the default camera. However, the way I should be going around is the exact opposite, which is by just having us change the camera to a default location. This way, I don't have to edit much of anything from the side perspective, and instead work around the already established top-down look, and just change the camera angle to make it look like you are viewing it from the side! This could work... And get rid of a huge chunk of scripting I would have to do! Haven't attempted it yet, but I feel like that will be much easier than what I am trying to do in the screenshot...

(1 edit)

I get what you are trying to do there but there just isn't any depth effect in that setup no matter where you try to put the camera  at. A 2d paper is always a 2d one whatever view direction you take :)

So there is no way at all to effect z at all using scripting...? That’s all I really need to do for it to look correct... That, or use the distortion effect to make it rise up or down, depending on how high you go... That, or it’s effected by you speed when you leave the ramp... (Maybe use the bike’s shadow, since that only appears when one is in the air?)

Scripting will work for adjusting the Z offset for a shape. The problem becomes all Y movement becomes Z movement. Moving up and down the track will look as intended, but then Y movement from  jumping in the air will turn into Z movement as well. I like the idea of using the shadow as an indicator to when not translate Y to Z, though.

(2 edits)

I believe the shadow COULD solve it because every bike has its own shadow. In fact the shadow is the bike projection to xz plane so the convert formula is something like that:

- Input: bike 2d position: bx0, by0 ; shadow 2d position: sx, sy

- Output: bike 3d position bx1, by1, bz1

Convert formula: 

bx1 = bx0;

by1 = by0 - sy;

bz1 = sy

That's the idea. In detail it's a little more complex because there are multiple bikes and shadows in a scene so we have to match/ pair a shadow with a bike. But that's just implementation detail.  

Ah, I see! That might work as intended... While wouldn't  work while going up ramps, that would just be something rather minor, I believe... (Or you could also try linking that to specific instances of the bike's motion, seeing as when going up a ramp, it needs to switch over to different sprites... Implementing this would be the difficult part though. 




Here are a few images in two instances, where they go up a hill and change a sprite while also moving along y. The second one shows the shadow sprite, and how it moves sideways along the sprite. Will that script help solve this? And if so, how will I implement it...? (I wish I had more experience with scripting, but stuff tends to blow up in my face when I attempt it...)

(1 edit)

You should regroup all ramp tiles into a pattern.

In script we could detect if a 2d bike  intersect with a ramp shape or not, from that intersection we could estimate its 3d y and z. It's still a trial and error process though.

Other things will complicate the situation for example: 

- two bikes one on ground, one in the air have the same x  and a shadow, how to matching? 

- the bike goes through and intersect with two consecutive small ramps, how to interpret?

In principle it's doable but it's still very big challenge scripting wise at least for me.

Just  pass me your wip  3dn, i will see what can i do with it.

It certainly sounds doable, but I agree, very very complicated...

And yeah, I will adjust the ramps to do that, I haven't even started messing with those yet though, I am focused on making sure this works for the most part, before I pu t more work into it.

And sure, I can pass that along! Just know that like in the screenshots, it is rather messy, as I haven't gotten that far into the process yet!

- 3dn Excitebike File -

I said you should regroup the ramp with the meaning that later on we can detect intersection between a bike and a ramp :D

I will give it a try tomorrow. Gonna take a sleep now.

Good night to all of you!

Ooohhh... Alright, I getcha! x3 I should have done that before sending it in... Hmm... There are also a lot of ramps and hills in the game, will that need to be done to all of them? But sure, go get some rest, goodnight! 

(7 edits)

First scripting version for just one bike, ramp interaction is not handled yet: 

function UpdateS()
    shadow = Frame:GetShapeWithTag("shadow")
    if shadow then
        shape.Offset.z = shape.Offset.z - (shape.BottomLeft.y - shadow.BottomLeft.y);
        shape.Offset.y = shape.Offset.y + shadow.BottomLeft.y - shape.BottomLeft.y;
    end
end

The result is promising:

Quick setup tip for top down game:

Layer1: depth = 0 Align Bottom -> for on ground objects

Layer2: depth = 0 Align Top -> for ground objects

For x axis rotated objects, set pivot y = 0 

With that setup, we will save many pattern adjustment steps.

PS:  Damn it, the ramp f*cks up everything. The lane and shadow path become diagonal on ramp .

Ah, I see! That does look promising! Even if it looks a bit wonky while jumping, but I expected that... (Since ramp implementation is not completed yet.)

Oh yeah, I forgot the shadows change to different sprites as well if it hits a ramp, which caused the strange lurching effect... Whoo boy. Take your time working on it if you wish, there is no rush! Thanks again for working on this... It certainly looks quite challenging! 

It's not the problem. With auto tracking i tag all shadow sprite "shadow" with one click. The problem is on ramb the shadow changes y value.

Oh... Yeah... I could see how that would be a problem. The y value is a big problem during most of this, it seems. Have you discovered a possible way to work around it...? I’m not sure how to even begin tackling such a problem... Thanks again for looking into this, don’t push yourself too hard though! This file is not the top priority, I would imagine. 

(1 edit)

i suspect that if there's multiple shadow sprites you could use tags and then in the code have tags change y things accordingly? i did consider trying that in RCR but it'd be too inconsistent in that considering how sprites got split up in that compared to maybe this. plus this seems like there's less sprites to tag here if you were to try that approach anyway.

edit: by this i mean multiple shadow sprite tags like maybe "shadowground" and "shadowair", then taking slightly different action from ramps by using the said tags.

(1 edit)

I got what you mean. With a quick observation i see that there are three types of shadow sprite: on ground, up the ramp, down the ramp. So the sprite types only tell us if the bike is currently running straight or climbing a ramp, it doesn't contain the ramp height info at that specific location

(1 edit)

Ok so i don't rush anymore and start working by book. I select custom road, add all possible objects to the road then define patterns. We mush define pattern in a way that the realtime shape segmentation process works correctly and segments all the shape as we intended.

After that i run several rounds to recheck the result.

Whoa. nice! It is looking better every post! Good idea using the course designer to get all of the ramps you needed. Certainly seems like a slow and arduous process though, but still, it’s looking better every post! 

I tried to decode game memory using Mesen but didn't find out any valuable information. 

Posted  on RomHacking  asking for help but didn't receive any.

I think i will pause the work here and upload the profile.

Download

Ah, alright then! Thanks for all the effort you put in anyway! The point is that you tried, at least, so it’s all good! Now I know not to mess with games on here that are pseudo-3d... I should pick something less intensive in the meantime... maybe Kirby! 

Good call!

(1 edit)

3dn


me being the fool that i am, decided to work on trying to modify your 3dn. while nowhere near perfect (jumping being a problem still but more on that later), this is how it came out. 

that jumping problem? my only idea on that is to use the Z position of the shadow itself and then use that to work out where on the Z plane the bike itself should be since logically the shadow should be underneath the bike. plus this modification makes the ram mapping issue moot mostly. Edit: fixed a couple of errant ramps and excluded any air tagged elements from the actual y algorithm (neither change reflected in the video)

either way, give it a go and see if my modification has made it easier for you to handle things.

(1 edit)

What's your modifications pattern-setup wise?

Ok viewing it now

Guys, i will just let it here and say nothing ^-^

Some issues remains but the biggest challenges have been solved! 

damn that's good. i notice the rotation and stuff i did isn't in there but that's fine because most of the stuff i do with scripts is on a testing basis anyway. did my attempt inspire/help you to get it going again?

I did take your idea of ramp rotation but i didn't use your script. After trying deformation and object cloning, i realized that it was the best and simplest solution. My philosophy is we must solve the most critical part - object 3d positioning - first before event think about other things like object apparence or whole scene rotation.

(1 edit)

After all your script did help me resuming the work. I had said i would gave up but i couldn't help thinking about it. And after your post i finally decided i must solve it at all cost so i could focus on other things :)

glad to know my weird experiments on things helped spark some sort of solution, especially since i'm finding less weird stuff to experiment with that i know is doable as is (exerion being an odd thing to try and work with and solstice being an example of screwy tile work getting in the way of things)

I guess hard and weird stuffs are your preferred style :)