Sorry your browser is not supported!

I'm just considering AppGameKit for my next project (I have bought AppGameKit already just haven't used it yet) compared to a couple of other solutions. I have one particular game type I really want to do though and don't know if it's possible in AppGameKit as it stands. So what better place to ask than here?

Anyway years (and years) ago in DBP I wrote a simple game that was a bit like Cybernoid (remember that???) but fully rotated the screen as you turned. So you stayed in the middle of the sceen without the spacecraft moving or rotating at all. It all moved around you.

Obviously in DBP I did this in full 3D giving a pseudo 2.5D type experience. No problems there. But AppGameKit doesn't have 3D commands yet...

So the question is, considering AppGameKit is apparently actually using 3D for it's 2D operations under the hood (much like DBP used to), is there any commands to basically allow a camera view? So obviously you wouldn't want full 3D as everything is flat, but considering it is actually a 3D view behind the scenes then surely a bit of zooming in and out (without zooming each individual object) and possibly rotating of the camera (as in rotating the screen rather than the other axis which would be a bit confusing) wouldn't be too bad. Obviously then if this is possible now then I assume the physics and collision all still work nicely (considering rotated zoomed sprites still work perfectly fine)? I've seen the 2D camera code, but as it changes the angle and size of all sprites in the game world for every change then it won't be as good as just a camera perspective change that comes with a 3D environment.

Failing that, then does any Beta tester or behind the scenes person of AppGameKit know if collisions and physics is still going to work on 3D when it comes out as good as it does currently in 2D? Obviously because then with any luck the same sort of collision mapping code will work on 3D plains that will then basically allow what I am saying.

Cheers

Well the camera view, or world view as it's referred to is very handy, it makes scrolling the screen so much easier.

But I'm not sure if it can rotate - so scrolling and zooming are covered, but I'd have to check to see if rotation is possible.

One other option might be to set all the static backdrop sprites to the same group, then rotate that group - again, not sure if this is possible. If nobody can give you a definitive answer, I'll have a look and see what it can do to avoid positioning and rotating every single sprite individually.

One thing though - why does the screen have to rotate?

I know you'd like to make games like, Menace by Psychnosis - but for a mobile game, maybe it would be better if the screen was physically rotated by the player, like they rotate to the angle they want the ship to fly towards - and your ship does all the rotating. I've done this with a test game I did when first learning iOS and C++, and it works pretty well - kinda like Thrust, but with rotation controls. I added a bit of flair to it, so you could jerk the device to spin the ship as well... by adding some inertia to the rotation, it's possible to get quite fluid control. I think though, a lot will depend on how complex the levels are - if they're made from tilesets, then that might be the worst case scenario - but if you had, like massive bits of ship as sprites, so maybe a level is made from a few dozen big chunks, well that would be a lot easier to code. You could even have bits to fly throught while they rotate, while you rotate, and while the screen rotates, making elegant flight a real challenge, but probably a lot of fun.

Ok that's pretty cool. One off the list.

Ta. Would be good if it can be done and still work with collisions and physics. By far the best thing about AppGameKit in my opinion.

I love 2D games that rotate. Adds a different element. The Cybernoid demo I did in DBP got me into it, and I've a game on iOS/WebOS that does the same sort of thing (but from above rather than from the side) for Snake (see Snake Revolutions; it's free on iOS). I'm just sort of addicted to rotating 2D games.

Yep. A Menace type game where you basically rotate the ship with standard controls (left/right speedup etc) and the whole world rotates instead is cool, and actually rotating the screen around your player (eg. the iOS two finger turning movement) lends itself quite nicely to turn based games I've thought in the past. Strangely I can't seem to come up with game ideas without some sort of 2.5D world with rotation...

And yeah, Thrust was how Cybernoid was going a bit with my DBP code back in the day. Collision was a challenge but I analysed all tilesets by type and created a B-Tree data object (fast but small) for lookup purposes based on the colour of each pixel of the tiles. If any overlapped between types then I adjusted the colour of the pixel on the sprite to be unique. Then checked a couple of pixels on my sprite to see if it hit a wall tile type. Worked pretty well and fast for pixel perfect collision with rotating/zooming 3D sprites (as long as 3D lighting wasn't used, but we are talking 2.5D). Although at the time because of the speed problems of getpixel type commands then I was actually looking at a more flying around a landscape challanging flight game (as you mentioned) or a turn based game (think Worms sort of).

Cheers

Sadly there is no view rotation, so you would have to rotate each sprite seperately, and that's not good news for a tile based map.

It sounds like a cool idea though, isn't there a way to use bigger sprites instead of tile based?

Thing is, you could use a virtual rotation, offset and rotate each sprite according to the 'view' angle, but keeping the actual data in 2D format - so you'd translate the sprites to suit the view. If you did that with a tiled engine, well AppGameKit probably wouldn't cope too well with the sheer volume of sprites required, but having less, but bigger sprites would be workable. When rotating, and slotting the tiled map together, there would no doubt be issues with edges, like defects where the sprites overlap, or don't completely overlap. With bigger sprites this wouldn't be an issue. I think that would work out nicely with a big space environment - avoiding ships and asteroids, even big huge asteroids - stuff that would probably be rotated anyway.

Personally, if I was making a cybernoid game, I'd keep it 2D, maybe have the device tilt to control the ship, kinda like thrust. If I was making a 2D space game, with asteroids and enemy ships etc, even turn based - I'd use an array to control the sprites position, velocity, and rotation - then translate that to suit a rotated view.

Also, there's the option of drawing all the map in 2D, grabbing the image, then using that as 1 big sprite - I haven't tried grabbing the screen yet, I'm not sure how much it interferes with things. Would be ideal if they added ImageKit style commands, do paste images and tiles onto a backdrop sprite, then rotate it any way we want.

That's a shame. Seems to me to be an obvious addition to the 2D feature set. There are not many rotational 2D games out there but normally they are pretty special. AppGameKit is pretty much already there really. The view commands and zooming shows that. Hopefully Lee can just bung it in at some point (along with appropriate Xtoworld type commands for rotation of HUD graphics) as it's hardly going to be hard to add it surely.

Yeah I guess bigger sprites along with the 2Dcamera code maybe the answer. Only downside is physics would no longer be correct. Collision would still be fine I suppose and for the game I have in mind it wouldn't actually really matter. Hmmm. I guess I could use a tilemap, but then translate the whole world on initialisation to be one big sprite. Can that be done in AppGameKit? And is there hardware limitations to such an idea? I know for example in another language I couldn't load a sprite bigger than 1000 or so pixels across on an older iPod because of video memory or somesuch. The individual objects could then be rotated on their own as there won't be that many of them.

A possible rolling window of constantly updated sprites maybe the answer I don't know. And yeah tilting the device is how I imagined it. The 2DCamera code I found here is pretty much as I saw it working in AppGameKit as it stands when it comes to the rotation, running through an array of sprites. No worry there. And I suppose with huge sprites as you suggest then shouldn't be too bad instead of rotating a *load* of sprites in the world everytime you turn.

Hmm, I guess grabbing the whole screen might not be too bad. I'm doubting the speed of it though...

Just would be good if they added the rotational functionality to this viewport command you were talking about. Would completely get around the problem without any issues. Considering it's all in 3D already then is a non-issue compared to some complex coding that might not run that fast.

Thanks for the help though (been hell at work all day and I don't know AppGameKit that well yet). It makes me more interested in AppGameKit for my next project. Either that or hold off for AppGameKit 3D (hopefully will get rotational code for viewports or decent enough physics to allow 3D to work instead with plains) and do a different project in the meantime.

Cheers

This issue has been raised on the issues board: PROBLEM

...and swissolo has provided a solution which might suit your needs: SOLUTION?

Actually so is wath you want wath i have done with my mode 7 engine.
Iam only hiding that effect to get the 3d illusion.
Iam moving and placing all the sprites on one big sprite i rotate around the screen.
Simply shift the offset code to be center of screen instead off at the bottom center.
look 0.27 in to the movie.
Iam simply rescaling and repositioning the sprites before the track is drawn like this.
If you remove that so will they be positioned on the track sprite instead.

Yeah that's the 2D Camera code I mentioned previously. It's just that physics would get messed up with every rotation plus the overhead of turning every object in the world can't be good. It is an option though esp considering the idea of using really big sprites rather than many small ones.

Yeah I previously thought a modified version of your mode 7 code would probably be a good way to do it. Again though would have to give it a good test to see if it is fast enough on mobile devices.

What I might do is if one of the above examples works out to be good for a PC (but not fast enough for mobiles) then I might progress with it anyway and then hopefully at some point AppGameKit will be updated for the view angle command mentioned above, or the new 3D commands will be good enough to allow collision and physics as good as in 2D (using 3D plains which is what 2D does anyway). So testing will be fine on the PC and then effectively switch the engine once AppGameKit gets good enough. Seems like a plan!

Thanks guys!

Cheers

The thing is that its the conversion to fake 3d that slows it down.

Yep. Because it's already actually in 3D then is just adding a whole extra (slow) unnessary step. Will do though until AppGameKit gets upgraded. Good to evaluate different solutions in different languages though.

Cheers