Curved Levels

Getting Started Newbie Questions
#1

Hi all,

I’m looking to start a game where the player moves along a curved level - hills and jumps etc. Similar to most motocross / snowboarding etc. games (although of course with my own special twist!).

My question is: what is the best way to go about creating levels like this? I’ve had a look at levelhelper and the karnak games SVG parser, but they’re not really aimed at that kind of thing and I’d rather not have to pay out money if I don’t need to.

Can anyone point me to any examples?

Thanks for any help! [import]uid: 74917 topic_id: 14528 reply_id: 314528[/import]

#2

This might interest you, it has hills and jumps and is provided as sample code (so it’s free!) by Ansca :slight_smile:

http://developer.anscamobile.com/forum/2011/06/11/tiny-penguin [import]uid: 52491 topic_id: 14528 reply_id: 53717[/import]

#3

Ah yes I have looked at that before - thanks very much for your reply.

However, that sample code generates the hills randomly - I’m looking to be able to design the maps with ascending difficulty so random won’t do unfortunately.

Are there any known SVG parsers that I don’t know of, or is the Karnak SVG one the only option?

I’m starting to think I need to get my old maths textbooks out (probably a good idea anyway!), but there are so many games out that have non-random levels made up of curves / jumps / line segments I thought someone might have come up with a good workflow…

Thanks anyway Peach - also for your CfN tutorials they were very helpful! [import]uid: 74917 topic_id: 14528 reply_id: 53733[/import]

#4

The Tiny Penguin example, which generates lots of slices is not very efficient at all and I think would cause problems on the device.

Saying that though, Corona cannot generate complex shapes, what it can generate are not antialiased ( unless through pref = slow ) and for what ever internal reasons too many vector objects will cause a lot of slowdown.

What you need to do it think old skool, like how would it be done on an Amiga or Mega Drive. My initial though it to use tile maps, where you can build varying degrees of slop angle through combining tiles. [import]uid: 5354 topic_id: 14528 reply_id: 53740[/import]

#5

Pure math would be the most optimized way to tackle given the limited collision boundry options currently implemented (and non-existent pathing), but you may want to look into Physics Editor on the 3rd Party Tools. You could draw your “hill” graphics, and let Pe do the hard work of consructing the complex collision bounds.

Let’s all cross our fingers for improvements in these two catagories (I am!) :slight_smile: [import]uid: 21331 topic_id: 14528 reply_id: 53745[/import]

#6

Take a look at this, each track segment is an image and im using maths to draw the collision boundaries, which can be set to different resolutions.

I would do something similar for your curved hills, if you draw out different curved segments, which can fit together, and you add the physics afterwards coded to fit the shape then building a level is just a case of positioning each segment.

M [import]uid: 5354 topic_id: 14528 reply_id: 53747[/import]

#7

@Matthew Pringle: I quite like the idea of a old school tile based version - but it’s definitely not fit for purpose for this project… thanks for the idea though :wink:

@TheRealTonyK: I had a feeling that might be the case… pure math will be a nightmare for this though - tweaking the steepness of hills / lengths of jumps etc will be a large part of the level design process even visually, let alone with just a huge list of numbers!

The Physics Editor looks interesting - this doesn’t sound like it’ll be very efficient either though?

So I am looking at limitations of Corona rather than limitations of Box2D?

Perhaps I’ll be better off putting the time into obj-c/cocos… [import]uid: 74917 topic_id: 14528 reply_id: 53748[/import]

#8

@Matthew Pringle: Sorry missed your post whilst writing mine. This looks very similar to the method used in Tiny Penguin? [import]uid: 74917 topic_id: 14528 reply_id: 53749[/import]

#9

Last time I looked at tiny penguin ( I helped with the code ) it was generating a lot of objects to build the curved slopes. The physics wasn’t the problem, just the ton of vector segments used to create the image.

In the racing game, old version, a lot different now, I originally tried to build a track with pure maths but Corona just couldn’t generate the objects needed and keep the framerate. The above image, a simple test, uses blocks of images with the maths generated by code and applied to each segment. It then went and positioned the next segments as the maths knew the exact ending point of the last curved segment.

The idea was to build 6 or 7 different curved segments, each with a different angle of curve, but that would all connect together to form a track.

I can’t see why that idea couldn’t be used for your idea, except you are using just 1 curve per image instead of 2. [import]uid: 5354 topic_id: 14528 reply_id: 53750[/import]

#10

As far as efficiency, I don’t believe anything would be more efficient. You would auto-trace, adjust to your liking, and the program produces the code-block you need for your levels collision. Re-usability and generisism, well that’s where the mathmatics prevails. As far as memory efficiency, your graphic level will be the heavy. Don’t fear as i did though, there really is plenty of memory and I become more suprised every day how much Corona can handle and remain smooth.

Jump in, give it a shot, I think you will be suprised how fast you can achieve what you are looking at with Pe and Corona. :slight_smile: [import]uid: 21331 topic_id: 14528 reply_id: 53751[/import]

#11

Well, cheers to you both!

I like the idea of drag and drop levels - could work very nicely especially with something like levelhelper, but I also like the more organic approach of designing each level individually and tracing with PE. I’ll have a play with both and see how I get on.

Thanks again! [import]uid: 74917 topic_id: 14528 reply_id: 53752[/import]