Sorry your browser is not supported!

First let me say a huge thank you to TGC - what a great product! Only a week in and loving it. Brings back memories of my days (and nigths) with AMOS - but already with so much more power - muhaha!

I am looking for advice - I want to create a scrolling landscape that physics can interact with e.g. rolling hills that physics wheels will roll over like the wheels of the car on Hill Climb Racing. Creating the physics wheels is easy of course, but I am struggling to find a good way to create a landscape/ground. I cant use large undulating sprites as the convex collision shape will be a) too low res (even with 12 points) but worse will not map the surface of my PNG properly as it is only convex rather than concave.

The only thing I can think of is to make loads of physics sprites (e.g. 100 across the screen) with simpler geometary that the physics shapes can map correctly - bit this sounds like ridiculous system overhead.

Can anyone give me advice? No idea how the 'Big Boys' do this with their landscapes in e.g. Lemmings, Bad Piggies etc where the level has clearly been 'drawn' and the engine is reacting to the bitmap (apparently).

Thanks for any help.

I haven't done it but here's my thoughts.

If you use a spline for the landscape then you can calculate any point on it. Splines are perfect for an undulating landscape because they are easy to adapt and experiment with, while constraining your hills to manageable curves. Because you make splines using interpolation (ie plot all the y points for each x point you supply to the equation), it's easy to work backwards when you need to know the height of a specific location.

As for drawing a spline landscape...that may involve taking a solid image of mud or grass, and using a memblock to make sections of it transparent.



Another idea is to use predefined blocks of terrain and put them together as the vehicle traverses the landscape. Your landscape may be 10 kilometres long, but you only need to show the next 100 metres. Therefore you could probably have quite complex physics shapes and still run at a decent frame rate. If you make them tall enough, you can have a mountaineous terrain,with the excess ground off the bottom of the screen. They don't need to be as tall as the mountain, only tall enough not to show a gap on the bottom of the screen.
With this method, you need to create your sprites before they appear on screen and delete them when they are gone (or rotate and reuse them as they appear and disappear)

Thanks for the detailed advice! Much appreciated.

Your second proposal is pretty much where my mind was - i.e. lots of smaller (convex) physics sprites on the screen lined up beside eachother to create a full-width physical 'ground'...I was just concerned about performance issues, even with only the visible sprites being drawn. Would the average mobile handle e.g. 50 physics sprites on screen without any issues?

As for your first proposal about splines...erm what is a spline and where can I find some documentation on how to use it? I'm assuming it is like a spline that you use in graphic design (i.e. a curve that is defined programmatically). I am perhaps being slow but I searched AppGameKit commands/docs and coouldn't find anything with 'spline'?

Thanks again.

I have a bingo game with 90 sprites, all bouncing around and hitting each other. There are 3 impulses firing away every 200 milliseconds to keep the balls moving. I ran it on my Nexus 4 with no trouble whatsoever.

You are looking at a bunch of static sprites so it should be more than OK. They can be static because you can move the screen offset rather than the sprites.

Splines are exactly what you describe. You need to write a function to create all of the points on the spline based on the start and end point, and 2 other points in space to help describe the shape of the curve.

I have one somewhere(!) which I wrote in DarkBASIC, but will translate directly. I may not find it for a couple of days, but it's very possible somebody will be me to it with some working code.

[EDIT] - Clonkex has already posted the necessary code here.

Thansk BatVink. Looking at the Clonkex's code it is probably a bit beyond me at the moment - but I'll look back again once I feel a bit more confident on some of the other AppGameKit functions.

Thanks again for the help

It's good to have people here from things like AMOS and STOS - nothing beats an idea that's been stewing for 25 years!
AGK really is the language that lets you complete your ideas and hit a large number of devices with it as well.

I think it's worth investigating the manual controls for physics collision. For example, if you made a backdrop sprite, you could add however many 'lines' to it as you need - like a horizontal line with segments at varying heights. It's actually quite straightforward, I had an experiment a while ago using a big planet sprite, and generated it with a memblock and added a collision shape all around it. Theres a game in there somewhere but I'm too busy to keep on it, it serves as a good example of manual collision lines though. It's surprising just how many lines you can add without ruining the performance - for a scrolling horizontal landscape I'd say it's definitely worth a shot. Maybe generating the terrain using a cut down perlin calculation and some memblocks would be an idea - save yourself the trouble of designing levels
Additional obstacles and details can be added as separate sprites... like physics sprites for puzzle elements... maybe a bit like a 2D Pikmin, where you might have to pile a load of critters onto one side of a ramp.

The old fashioned way would be to use the bitmap data, like if you load an image and convert it to a memblock, you can then affect the memblock (to blow bits up if you like) - a lemming might dig into the terrain or even build on it, so you'd adjust the memblock data and convert back to an image when done. AppGameKit would actually make a pretty decent language for a lemmings game.

Really, this isn't a problem you have, it's an option... you could use a memblock image to replicate Lemmings or Worms, but you'd have to deal with collision yourself using the raw data - not a huge undertaking once you know how memblocks work. The other option is to use physics sprites and a chain of 'lines' - but that makes terrain modification in game very difficult. The 2 techniques don't really play well together, but at least they work nicely in AGK.

Personally I'd love to see a Worms style digging game in AppGameKit - and I have an example somewhere that shows the techniques nicely... in fact I have a 2D destructable terrain example and the big physics object with the chain of lines as an example as well, just say if you want me to upload them.

Thanks Van B - loads to chew over in that post! I am less interested in landscape deformation, just want the curves of my landscape to have a physics presence.

If I understand your post then it sounds like the best way will be to make some horizontal line sprites (memblocks? Need to read more about these), place these at heights the loosely follow my bitmap and switch physics on for them? That could work.

As you say if I generate the landscape procedurally then I could created those physics sprites/memblocks procedurally too...if not then I'll need to come up with a neat way of getting the vertical height of my landscape every 5 horizontal pixels or so and putting that into an array that can be used to position the sprites/memblocks. Might need to do this outside of AppGameKit then read in the data into the array.

Thanks again for the detailed post - great stuff