Sorry your browser is not supported!

I'm currently using gamemaker studio (cue the laughs), but i did purchase it recently and soon after came across AppGameKit, so i'm a bit weary at the moment about making another investment.

Just to clarify, i know c++. (In before you gotta know programmingz!)

So a few questions...

My current project is quite resource intensive. It's an RTS aimed at mobile devices. With such a project, you would imagine wanting to squeeze out every bit of performance from the tools you are using. Long story short, will a project using AppGameKit perform much better than using a tool such as gm: studio.

I read that AppGameKit does all the leg work for different device resolutions. When the game is scaled down to lower resolution devices will i see any reduction in image quality?

Are there any tutorials for using c++ with AppGameKit? All i can seem to find use basic.

Cheers!

Yes, but I'd say that's inevitable and not limited to AGK. It's a bit like taking an image and scaling it down, you'll lose some quality (as there are less pixels in a lower resolution, obviously).


Not for general programming (that I know of). However there are examples for both Tier 1 and Tier 2 (C++) on different aspects of AppGameKit such as sprites, physics etc so you can learn by example.

There's no shame in using Game Maker, in our field, it's best to use the tools that get the results you need.

I'm not sure how AppGameKit fares against Game Maker in terms of speed, to be honest I don't think there's much in it. Really, the performance is probably going to be affected by the way you handle the map. I've been doing some tests with tile maps, and am sure that AppGameKit can cope fairly well. I mean, if you had a like for like comparison between GM and AppGameKit, using sprites/objects to make a level, then they would be about the same speed. But, when you factor in collision detection, well even using a library like Box2D won't be anywhere near as fast as using array based collision, rather than checking a complex shape, you use the map data to check for collision. With a lot of path finding, AI, logic, well AppGameKit comes out on top at the end of the day. GM does a lot for you, but I'd be hesitant to try using it for a decent sized RTS game. What you have to consider more than anything, is the way you handle your map sprites, or map sprite - AppGameKit and GM are both similar, in that you can utilise the Z depth to control drawing order, giving your 2D sprites a bit of depth, which would be vital for things like buildings and characters. Perhaps it would be worth posting a screenshot of what you have, or even a rough sketch of how you want it to look. Personally, I'd use different sized sprites for buildings, trees, etc, and fixed sized map tiles, then use Z depth to keep everything layered properly. Doing that in GM would quickly become tedious IMO... better to have direct control over proceedings I think.

When you scale down or up, you might have some issues with image quality, I think it depends on the min and mag filter settings. I've found that using no blending gives the sharpest results, using blending (min/mag filters activated) does a decent job of smoothing things out, but your always gonna loose quality when you scale. I think that if your concerned, maybe consider having a high and low res set of graphics, so say the iPad at 1024x768 could be the standard high res, then the iPhone4/iPod could use 960x640 and loose a little bit of screen space, so no scaling on those - same goes for any tablet really. The problem would occur with devices that are much lower resolution, where you would have to scale the graphics. I would do a check, see if the device resolution falls within a reasonable tolerance, say 800 - 1024 wide means the resolution is set natively, no scaling, no loss of quality - but anything below that needs scaling. At least that way your giving the best support to the best, and arguably the most popular devices.

If you know C++, then AppGameKit will be a breeze, it'll be so easy to get into it won't even be funny. It's not like OpenGL, or those libraries that often need custom modifications, and always need 'babysitting' code - everything is there, waiting to be used, not delegated and abstracted. The choice between using C++ or BASIC with AppGameKit, is really about programming syntax, which code structure and style do you prefer, rather than there being any stark differences. You can even use Pascal with AppGameKit now, if the fancy takes you.

If you like, you should check out the 'Tiled Map Example' in this forum - the code is included with a Windows executable.

The only drawback I See is agk is not next gen technology just yet. Tgc is getting it there but when apps come out know days they need 3d to even have a chance in the market unless you want to make kid games.

I wouldn't mind paying more for agk if they hired more developers. Maybe even if they charge as much as unity for this tool. I deffently whould pay the extra cash to get tgc to next gen tech. Or tgc can make more there program open source which I see never happening. The next viable option whould tell us as developers how to make plugins for agk.

I'm afraid I disagree. Some great counter-examples include Angry Birds, Cut the Rope, Where's My Water, Doodle Jump, and some word game that's going around that I don't know the name of. Most of these games could have been written in AppGameKit as well. While 3D would be nice (and is on the way), it doesn't mean that it's necessary for a top selling game.

Thanks for the replies.



All my map data is pre generated and stored in a collection of grid data structures. The terrain itself is a grid of layer ids. For drawing I have developed a texture splatting technique that allows for potentially unlimited texture layers without a loss in fps. I retrieve what grid cells are currently visible on the screen and pass these to the corresponding layer objects based on their ids along with coordinates of the actual "splat". This allows to do the map drawing with the equivalent 2 loops of the visible grid cells regardless of how many texture layers there are rather than a whole loop for each layer. Though each layer performs a loop itself, it only loops the visible splats for that layer, meaning in total, all layers together will perform as many iterations as there are visible grid cells. I'm also using this system for trees and other resources and fog of war.

As a result im getting around 300fps average on a 1024x1024x64x64 map. However there is very little game logic running at the moment and bare in mind this result is on a quad core pc with a gtx470. I am aiming for 30 fps minimum on an iphone.

The reason i am using separate objects for the texture layers, is because gamemaker requires the object doing the drawing to handle the drawing depth. I can't for example, set depth 1, draw sprite 1, set depth 0, draw sprite 2 to have sprite 2 sit on top of sprite 1. I would have to have 2 objects and set the depth of those. I'm not sure if this is just a limitation of gamemaker or a global technical limitation.

I doubt it will ever be. Since AppGameKit is focused mainly on mobile devices, I doubt it will ever be able to display amazing graphics (as long as mobile devices don't support them, there's nothing to talk about).
Also, if AppGameKit is next-gen, then it would have to run on top of OpenGL's core profile (version 3.x), because for now it runs on OpenGL 1.1.
It's impossible to have next-gen on so old OGL version

Here's a video of what I have so far in gamemaker studio. Its a bit buggy atm (mainly the tree depths due to the limitations i mentioned further up) but you should get the idea of what im aiming for. An age of empires 2 style rts.



http://www.youtube.com/watch?v=0q_E2JAddA8

You know C++
So there is really no question that you should use AGK.
Forget about GameMaker.

Also I think that AppGameKit is much less expensive that Gamemaker

Your'e right, it is. gamemaker is $99 for the base package (windows and osx support), then $200 for each additional module (android, ios and html5). AppGameKit is a steal at $60 and you get support for all the major platforms out of the box which is very attractive. Luckily i have only purchased the base package of gamemaker studio...so.....what the hell.

/me makes his way to the AppGameKit order page.

Looks like an interesting project. In AppGameKit, you would probably just create a sprite for each tree or terrain piece, set the zdepth, and position it according to the isometric position. When I messed around with isometric placement, I found it much clearer to use a 2D array as if it was a top down 2D map. Then convert the position to it's equivalent isometric position. It would make terrain generation easier to calculate I think. In terms of speed, I think AppGameKit could handle what you have pretty well.

Yeah Van B that is exactly what i'm doing all coordinates are normal 2d coordinates and the path finding grid is just a top down, square grid with all drawing coordinates translated to an isometric perspective.

Cool - I was concerned that you'd used that built in isometric grid in Game Maker - that thing should just be taken out and burned .

Actually, I have a handy isometric sprite positioning function, just pass the sprite number and the 2D grid location to the function and it positions the sprite. Just let me know if you want it and I'll post it up.

Thanks Van B, but I have already written such scripts in gamemaker which will be very easy to port. I'm basically just going to port the code i have over to c++ and use arrays in place of the grid data structure in gm. When i figure out how to set up a project in code:blocks anyway, hehe.