Making Mario Kart type of games...what's involved??

Started by
26 comments, last by Oluseyi 22 years, 9 months ago
There are a few replies so I lumped them into one.

BoRRel
quote:How big was your team then?


Myself (coding/design and sound effects!!)
Shaun Gadalla Art and track design.
Mark Klem (Music)

We also purchased Jim Dose''s Sound Engine.The whole game took just under a year. Very intense :-)

Arnero
quote:
Wacky Wheels
did not use surface caching,
but instead first looked uo the tile in the map an then the color in the tile for every pixel when rendering.


Correct there was no surface caching. We could though in theory have used sectors like Doom did. This would have helped on cache misses but because the track needed to be very detailed we traded this. Unrolling the rendering loop helped out quite a bit. Plus I figured the trick of writing everything out in vertical strips because of the mode-x plane switching. In fact I had not even read Abrash had done this. Amazing what a simple mindshift can do sometimes.

dmiles96
quote:
There is a significant portion of my life (and my friends lives) that I spent with that game


Thanks It is so satisfying writing a game that other people enjoy. That is what makes writing games so rewarding. Writing them can be so dammed frustrating though!!!

merlin9x9
quote:
I imagine that line segments have the potential to
give much greater accuracy than tiles (unless, of course,you have one tile per pixel in the terrain image)


This is a typical case of temporary code that stayed in the final release Each collision tile was an exact replica of the ground tile. So we made a collision with the ground tile then dug deeper within it for surface info. So we had in effect true pixel collision. No matter how complicated the surface curve was we had an exact hit.

This was a bit over the top

For performance reasons I was worried about doing a lot of point
in poly and line intersection tests. So I traded memory for the
problem. But in hindsight I would go with line segments /polygons right now for all the reasons you pointed out,so yes you are correct to assert :-)

I think the lesson is that we can always make the code better.
When I look back at the Wacky code I know there are several
areas that could be vastly improved. I think John Carmack
said that Wolfenstein would have been better with a BSP
tree.

Cheers
Andy

Advertisement
Hi AncientCoder Im trying to develope a Fzero type racing game for game boy advanced. Ive tried porting your code that you posted earlier and it doesnt work. I justed wanted to know if there is another way to approach displaying a map with perspective or just the basic equation.
You might want to check out http://www.gbadev.org/. There''s a demo of a Mario Kart-type game there, but it doesn''t include the source so you''ll have to ask the guy that made it if he''ll send it to you.

GBA looks to be a very good thing to me. SNES was the ultimate game system if you ask me, and GBA is quite similar, and with so many more people into programming nowadays, there''ll probably be plenty of great games^^ I''m just starting on an RPG myself, but it''s still mainly in the designing stage, and I''m still working on my PC side-scroller, so it probably won''t be done for a long time.


-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)
I''m not actually serious about pointing this out, just joking around.. hehe.. but many of you say switch from 2d looking 3d to real 3d.

making 2d graphics that look 3d is exactly what 3d grahpics do, there is no real 3d.

just like there is no spoon. heh.

anyway don''t bitch at me, I know what you really meant.



CrappySoft - game production team with a punk attitude. Mail me if you want to make levels, art etc.
CrappySoft - game production team with a punk attitude. Mail me if you want to make levels, art etc.
Given a single vector (the view vector), you can use a modified version of Bresenham''s line-drawing algorithm to move across an array of tiles, in lines perpendicular to the view vector. Then, all you need to think of is this: The size of an object is inversely proportional to the distance from the object, and the length of a 2d scanline on the screen in 3d space on the plane is directly proportional to the distance it is from the camera. Then, there is a corrolation between screen y coordinates (starting at the bottom, not the top, as is normally the case), and that is that the distance on the plane corresponding to a given scanline on the screen equals y * y, where y is the distance from the bottom of the screen.

This technique should be easy to adapt to rendering voxel heightmaps, I think.
Here''s an idea that''s been banging around in my head. Use something like OpenGL''s surfaces to create a horizontal Trapazoid (ground) and a large vertical rectangle in the background for distance textures. Then have a vertical surfaces for the players ie...

111111111111111
111111111111111
111111111111111
111111111111111
111111111111111
111111111111111
777777777777777
7777777777777
77777777777
777777777
7777777
77777
^
Camera


This however would require quite a bit of POV calculations to align the textures correctly. Any ideas on whether this would even be worth it, and how efficient it would be?

I know only that which I know, but I do not know what I know.
Hi thanks for the info but I am creating this game on Game Boy Advanced thats why I would like a generic algorithm or a really well explained method so it could be easily ported.
quote:Original post by lower_case
making 2d graphics that look 3d is exactly what 3d grahpics do, there is no real 3d.


As long as you''re using 2D viewing devices. Once holograms are discovered/refined/perfected (your choice), then there will be real 3D. In the meantime the closest we get is VR.

This topic is closed to new replies.

Advertisement