Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Is it possible to make destructible landscapes like worms, in AGK?

Author
Message
Zubby1970
AGK Backer
15
Years of Service
User Offline
Joined: 22nd May 2008
Playing: AGK Studio Always
Posted: 31st Oct 2013 02:26
Is it possible to make destructible landscapes like worms, in AppGameKit?

what I would like to do is to be able to cut out a circle where an explosion takes place , but not sure of which command I should use.

Thanks for any advice.

There can only be one
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 31st Oct 2013 03:14
There aren't any commands that do that. It is something you would have to work out.

Having played almost all versions of Worms, I think I know what you are looking for and it might be hard to do in a game timely fashion in AGK.

But, maybe someone else has worked out something like that.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
xCept
21
Years of Service
User Offline
Joined: 15th Dec 2002
Location:
Posted: 31st Oct 2013 05:37 Edited at: 31st Oct 2013 05:41
To achieve the precise effect seen in Worms, you'd have to make use of the memblock commands from 108. With them, you can read through pixel data of a given image or area of the screen and manually update each pixel as needed, such as turning the impact radius fully transparent to simulate destructible terrain.

Note however that memblock commands of this nature in AppGameKit are not very fast so would have to be used very selectively especially if targeting mobile devices. You can't really manipulate many pixels each frame. For added effect, however, you could generate a particle system at the origin of the explosion to mimic their animated destruction while still only calling the memblock command once to actually destroy them.

If you don't have to go into such granular detail, you could mimic this effect by using larger sprites (e.g., a bunch of 32x32 pixel sprites) and then animate the sprites accordingly to destroy them. Baxlash did a tremendous job of this in a Tank Battle concept he was working on. You can check that out here:

http://forum.thegamecreators.com/?m=forum_view&t=203892&b=48

P.S., I developed a pretty extreme form of pixel destruction last year in DBP and HTML5 (with an early start in Objective C as well). Below is a video of this--skip to 0:45 for the fun. But again, the pixel manipulation capabilities in AppGameKit are far too slow for this to be effective.

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 31st Oct 2013 10:08
As xCept says, Memblocks are the answer. But to maintain decent frame rates, you'd be well advised to use several memblocks and sprites, and only update the ones that are affected.

Having 1 massive memblock, sprite, and image would be pretty slow - not during gameplay, but as soon as you need to destruct the terrain, there would be a noticeable delay. If you only have to update 1 or 2 smaller memblock and images, then the delay probably won't be noticable. It would take a bit of work and time, but I think that's the only way - and really it's not a lot to worry about, for the effect you'd end up with I think it's well worth doing.

Just think of your game terrain map as a tiled kitchen floor, and the destruction is like someone spilling soup. But you have to clean an entire tile if any soup get's on it and you have to clean a tile the instant that it get's dirty. Even though you have to clean the whole tile, it's still quicker than having to clean the whole floor every time.

Hope that makes sense!, it has been a whole hour since I had any coffee.

I am the one who knocks...
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 31st Oct 2013 10:42
I agree with above posts.

I find if I split the screen into sprites(images/memblocks) of 128x128 pixels then you can update portions of the screen in real time.

Just remember you can keep the memblocks and use 'memblock to image' on the same image over and over again.

Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 31st Oct 2013 14:50 Edited at: 31st Oct 2013 15:02
While I agree with the above as the best method, a really fast method would be to overlay transparent sprites. So you have your landscape in place to start. If all your ordinance (explosion craters, bullet holes) are of a set size, you could simply place a transparent sprite at the explosion point. With some draw order jiggerypokery, AppGameKit would draw the transparent sprite first, then attempt to draw the opaque sprite beneath it and not draw over the transparent explosion pixels.

I'm not sure if that's possible with the sprite commands, but it's definitely possible with the 3D commands which offer a lot of control over z-buffer read/write.

The upside of this approach is it'd be by far the fastest, but only to a certain point. When the whole scene is filled with impact crater sprites it'd probably start to crawl, so it'd only work for low-medium terrain destruction.

There you go. Call me maverick and also this idea may totally not work.
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 31st Oct 2013 15:03
The problem with using lots overlapping transparent sprites is that it may not run very fast. Personally I'd rather take a split second hit over a general lag, besides the multiple memblock route would be very quick too...

oct(31) = dec(25)
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 31st Oct 2013 15:08
See, I knew others would have good ideas. I had been thinking about memblock usage, but thought it might be too slow.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
BatVink
Moderator
20
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 2nd Nov 2013 09:57
The best point to create your newly obliterated terrain is at the point of fire. Hopefully you can project your explosion point before when the weapon is fired. You can deceive the user at firing point with a slight delay by using a weapon-loading effect, when what you are actually doing is creating the new terrain behind the scenes. When the explosion hits, you already have your replacement destructed terrain.

2D physics may help with the collision detection. Lee once did a demo on how to flood fill an area with colour, the same principles could probably be used to create collision polygons. In brief, it would involve working in horizontal stripes and calculating where your areas must "stop" as a boundary is hit.

Zubby1970
AGK Backer
15
Years of Service
User Offline
Joined: 22nd May 2008
Playing: AGK Studio Always
Posted: 2nd Nov 2013 18:28
ok Guys I took your advice and went down the memblock route, I have the exact same effect as we had at team17, this is how I did it for anyone else, and no lag what so ever, ok a little prep was needed.

I obviously had a landscape then I had a purple circle which will be the hole to be left in the landscape eventually. so at this point the circle is following the mouse , now when you click, we draw the landscape and the circle in that order to the back buffer, we then grab that whole image from the back buffer and make a memblock of this, I then check the memblock for the purple circle colour, I also gave it some leeway either side of the whole value, if this colour is found I then change the alpha state of that pixel to see through. bingo job done. needs some tweaking but as a whole (no pun intended) it works. thanks very much indeed for your time and effort

There can only be one
Zubby1970
AGK Backer
15
Years of Service
User Offline
Joined: 22nd May 2008
Playing: AGK Studio Always
Posted: 2nd Nov 2013 18:30
sorry forgot to include this little lot lol




There can only be one
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 3rd Nov 2013 11:46
I think that the whole move would be pre-calculated, sorta like a time line of events - at least in the later Worms, which had action replays and mind-boggling stuff like that.

The purple sphere idea is nice, and it will work - but my concern would be the delay on slower devices - and devices that don't have that high of a resolution. Might be cool to have a single screen terrain though, make a virtual ant farm for tablets - probably been done though.

I still think that multiple memblocks, images and sprites to make up the terrain as a grid would be the fastest method, no need to re-grab the image, or step through the whole memblock.

I am the one who knocks...
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 3rd Nov 2013 12:34
This is what I was thinking, 1024x1024 terrain, randomly destructs as it's just a test really, scroll around with the mouse.

Should just be able to make a fresh project and paste this into the main code:



I am the one who knocks...
Zubby1970
AGK Backer
15
Years of Service
User Offline
Joined: 22nd May 2008
Playing: AGK Studio Always
Posted: 3rd Nov 2013 19:41
tried changing the code to cut an image up into 8 x 8 sections but creating the memblock is throwing me an unexspected error when creating the memblock.


There can only be one
Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 3rd Nov 2013 20:25
Can't run the code on this machine, but look at this bit ...



Your get image line is wrong. It should be:
getimage(id,x*128,y*128,(x+1)*128,(y+1)*128)

When x and y are zero, you're attempting to getimage a 0,0 size image which is probably causing your error.
Zubby1970
AGK Backer
15
Years of Service
User Offline
Joined: 22nd May 2008
Playing: AGK Studio Always
Posted: 4th Nov 2013 14:18
ok this has fixed the memblock error now lol, but im getting an awful result back in instead of a reconstruction of the original image. ??? any ideas. I've poured over the code for too long got a head ache now lol



There can only be one
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 4th Nov 2013 14:29
I think your asking for trouble cutting the image up with get image. Couldn't you use subimages? - like have a 1024x1024 image, and give it a subimage file cutting it into 128x128 blocks. Then, you'd choose the level image, and load the subimages rather than the whole thing. You would need a subimage file for each level image, but it doesn't have to do much, so you'd just copy and rename the same subimage file each time.

I just don't trust grabbed images with memblocks, seems risky to me... I mean in terms of cross-platform compatibility.

I am the one who knocks...
Zubby1970
AGK Backer
15
Years of Service
User Offline
Joined: 22nd May 2008
Playing: AGK Studio Always
Posted: 4th Nov 2013 17:12
how would I go about making a sub image file?

There can only be one
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 4th Nov 2013 23:58
Awww, subimages can't be converted into memblocks

I will see about making a memblock image splitter though, so you can load the main image, then make the smaller memblocks and images from that automatically. Should do the same job.

I am the one who knocks...
Zubby1970
AGK Backer
15
Years of Service
User Offline
Joined: 22nd May 2008
Playing: AGK Studio Always
Posted: 5th Nov 2013 16:31
thanks vanb

There can only be one
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 5th Nov 2013 18:57
Attached an example, media is just a backdrop image and a test terrain at 1024x1024.

This time, you click to destroy the terrain, and right click to shift the view. As a bonus, I added some particle effects, mainly just to show how collision detection could be achieved, but it looks cool and is a little bit like that video xCept posted.

Here is the code as well:


I am the one who knocks...

Attachments

Login to view attachments
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 5th Nov 2013 19:27
Looks great! Something I probably want to try when I can make the time.

One comment. You should put an 'End' command after the main 'loop' command. If something caused the app to exit the loop, it would re-execute the init subroutine. (One of the reasons I don't use the gosub structure.)

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 5th Nov 2013 19:49
Yeah, thanks for the headsup, will do that.

Here's an updated example, this one lets you destroy with the lmb, and draw with the rmb - scroll with arrow keys, and space to zoom in or out. Seems very fast to me, faster than I thought AppGameKit would be with memblocks. Probably decent on Android as well, although I couldn't test it properly without a mouse and keyboard.

Anyway, new example code:



I am the one who knocks...
Zubby1970
AGK Backer
15
Years of Service
User Offline
Joined: 22nd May 2008
Playing: AGK Studio Always
Posted: 6th Nov 2013 21:39
ok guys i can't thank you enough for all your help with this, I'm going to look into bringing bigger landscapes in and stuff like that but hopefully this will be a great start. and work on some parallax backgrounds and all that should be good. van can i use the collision system for sprites as well or is it just for particles?

There can only be one
BatVink
Moderator
20
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 6th Nov 2013 21:49
Quote: " can i use the collision system for sprites as well or is it just for particles?"


Sprites can use collision too.

VanB also has a DBPro tutorial that introduces parallax backgrounds in the newsletter. Although it's DBP the principles are applicable to AGK. (VanB can you believe it was 4 years ago that you wrote it!)

http://www.thegamecreators.com/pages/newsletters/newsletter_issue_80.html#11

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 6th Nov 2013 22:51
Now I feel old... thanks for that Steve

For sprite collision, I'd just check a strip of pixels in front of the character, but it depends on how the characters etc will work. I mean, a grenade is easy, a missile could have a collision check on it's nose, like a warhead ... so weapons are probably quite straightforward. If you were making a lemmings style game, or worms, then you'd work out the general height of the sprite, and check the length of the sprite vertically. If you limit movements to 1 pixel maximum per loop, then you shouldn't really have too many problems with collision. I'm sure we'll have more advice if you tell us what you have in mind, but for lemmings or worms, the pixel collision checks should be fine - it's exactly how they did it back then... before worms got all 3D and all about the water effect.

I am the one who knocks...

Login to post a reply

Server time is: 2024-03-28 21:56:17
Your offset time is: 2024-03-28 21:56:17