Want AI, Gestures, 3D, Inventory, or Menus???

IFL · by **IFL** » Mon Oct 31, 2011 9:48 pm

(Looking at the description of the other boards, none could facilitate this topic. Please ignore/excuse any pointless-narrative or side-topics that might come up.)

I like sharing what I know and some people need coding/design guidance. I'll list what I've done in regard to AndEngine and, if anyone is interested in specific topics, I'll let you know how I did it. I might share code (or pseudo-code at my discretion) so just ask if you have an interest. If requested, I can also provide my design references for everything here.

Here's what I've done:

Complete AI system... I'm proud of this project

. It has animations, emotions, beliefs, desires, intentions, and a nifty little node-editor... (screenshot is of a character deciding if he should chase the player)

: AI_NodeEditor.jpg (70.78 KiB) Viewed 2007 times

Gesture-based touch-input... Allows lasso-selecting any number of items and calling functions based on how the user draws with multiple fingers.

Orthographic 3d rendering system with physics... It's like isometric, but without the stupid cardinal-direction-locking camera. You can actually view an entire 3d scene from any heading. This is the largest project that I've done with AndEngine. It was my main focus for several months :oops:

.

Inventory... Loads from a database file. Can create/edit/delete items from the database file at run-time. The run-time inventories based on the global database take up minimal ram and allow sorting items by type, base-value, weight, or custom characteristics. Tied into the AI system.

Menus... Created from the AI system. Easy to animate. Has a scene manager that can retrieve multiple scenes by their names.

I could share my knowledge up-front without prompt, but I'm sure that no one needs to know all of it. Plus, that would take a lot of time. This way I get to explain/discuss it in small portions. I'll also give my opinion on how to do stuff not listed here. I love discussing game design. I'll be deleting this thread if it doesn't catch on after a couple of days. Cheers.

Mathew · by **Mathew** » Tue Nov 01, 2011 11:16 pm

Very interesting, but could you please post this image with higher resolution? Because I can hardly see anything even with big enlargement, thanks.

I'll also give my opinion on how to do stuff not listed here. I love discussing game design

I would be really thankful to hear from you how would you do following game "feature"

As you already know, I'm making mario style game, but much more advanced. But unfortunately there is limitation of course, because of performance issues. I'm trying to implement "monsters" into my game, nothing really advanced at beginning - simple 'monsters' which may move in right/left direction or fly or something, depends on monster type. First solution which comes on minds, is simple DynamicBody -> it would meet mostly every needed condition for this monster, such as physic handling, contact listening and so on. But dynamic body is so expensive for our devices, and obviously I need couple of monsters per every scene, so game becames quite laggy (while there is like 58FPS without those test monsters)

I have been asking about this already, and I received help from different member of this forum, but I would like to hear from different people as well - like you, maybe you will know better solution.

I had many ideas about how to do it so far, for example limit every level to have only one monster of each type and simply moving those monsters to next positions (and disabling player to go back [left direction])

Thanks for any ideas!

IFL · by **IFL** » Thu Nov 03, 2011 5:38 pm

Mathew wrote:Very interesting, but could you please post this image with higher resolution? Because I can hardly see anything even with big enlargement, thanks.

I scaled the image to hide an important part of my generic agent routine :oops:

. Is this quick example of a sub-routine good enough?

: AI_NodeEditor_Large.jpg (272.4 KiB) Viewed 1983 times

This example isn't very practical, but I think it gets the point across. It starts at "Is Player near?".

Mathew wrote:I had many ideas about how to do it so far, for example limit every level to have only one monster of each type and simply moving those monsters to next positions (and disabling player to go back [left direction])

I think you're on the right track... It really depends on how much time and work you're willing to put into it. I'd suggest using a dynamic level unloader/loader that utilizes object pools. Objects that are far off-screen can be recycled for use in the about-to-be-shown parts of the level. As for physics, the level loader can do something similar. This approach would allow the player to go backward through the level without having too much of a performance loss. I'm unsure about how much processor would be encountered by attaching/detaching several objects each frame, but I'm betting that it would be negligible.

On top of the level loader, and even if you don't use a level loader, make sure to cull off-screen objects. It's as simple as running a for-loop to check every sprite in the scene, but it makes gigantic levels possible. I had an unreleased project called SpyTower that experienced a lot of lag when it came to large levels. The previous game engines that I've used culled automatically so I didn't even think about it being a problem. The fps maxed out after I implemented simple culling.

Don't limit the monsters. If you use a pool, then it should really only matter during initial level loading, but I think the benefit of having multiple monsters in a level makes even an initial load-time worth it.

Take my advice lightly - it's far from perfect and I often overlook obvious solutions. Having said that, here's how I'd set up your game...
Have a sprite manager that creates pools of textures. The textures should be assigned an ID number.
Have filler-entities that just hold the position of where you want sprites. They would be nothing more than 4 floats (x,y,rotation,scale) and an integer (texture ID number). You can always add more variables if needed for some reason.
Use an extended-scene class that contains an update thread to handle the placement/visibility of sprites to the filler-entities.
Do something for the physics similar to the sprites. You can even use the placement/visibility portion of the scene to apply the physics bodies.

I'm sure that I missed something, but I hope you get the idea that I'm trying to convey. There's no sense in limiting the number of on-screen physics objects if that's what you need. I guess my solution is just about making the graphics perform well to make up for the physics.

If I confused you, let me know. I think I confused myself. :lol:

Mathew · by **Mathew** » Thu Nov 03, 2011 8:56 pm

Thank you, I guess I got your point.

About culling, thats right, I wasn't really sure at beginning about what this method does, but in fact without this method used for my sprites, there was LARGE FPS lost, so thanks to this method ; ) Couple days ago I realised it prevent from rendering while object is not visible in the camera.

I will try to realise your idea, its even quite similar to my previous idea which I had in my mind, so it means it may work

Thanks

Also I think about this "replacement" of the objects (their position, reusing them instead of creating plenty of them) I guess I will try to reuse only those "advanced" objects such as those using physic, coins with animation and so on.

Because even with REALLY LARGE amount of the static bodies, I can hardly see any FPS loss (~58) Problem begins while adding dynamic bodies, even kinematic are not really harmful for performance (even while I have couple of them for on my scene, used for crushing box, collapsing boxes, moving platform and so on)

IFL · by **IFL** » Fri Nov 04, 2011 6:00 pm

Mathew wrote:Because even with REALLY LARGE amount of the static bodies, I can hardly see any FPS loss (~58) Problem begins while adding dynamic bodies, even kinematic are not really harmful for performance (even while I have couple of them for on my scene, used for crushing box, collapsing boxes, moving platform and so on)

I haven't had much of a problem with dynamic bodies. I did a stress test combining my AI system with over a hundred dynamic-bodied agents, and the FPS was always over 40.

IFL · by **IFL** » Sat Nov 05, 2011 7:18 pm

Here's some code that might help someone. It's a really small version of my AI system that goes with the images above.

First, here's how to use it:
Turn every decision into a Conditional Action. Turn every action into a regular Action.

The code for setting up a Conditional Action:

Syntax: [ Download ] [ Hide ]