Laurens

Yes, I want it!

Getting hit by a bullet could easily be solved with a raycast. Whenever someone hits the trigger button, do a raycast and see if it hits the player. If so, kill him off. http://www.leadwerks.com/wiki/index.php?title=Raycasting#LinePick

In its most basic form I would simply start running a counter the second the player's altitude is less than 0 (this may ofcourse not always mean the player is submerged, you probably need some more complicated algorithm to determine whether or not the player is under water). Whenever that counter hits 30, start decreasing the health of the player each update. Game Coding Complete (Third Edition) defines a useful Process/ProcessManager for these sort of long running processes (i.e. spanning more than one Update call). I can highly recommend the book. As far as the user interface is concerned you could simply make some health bar in Paint and do DrawImage (or whatever it is called) with varying width to represent the player's current health.

This is what callbacks achieve without hardcoding a specific method that all entities must then implement.

Do you mean from a user interface perspective or from a programming perspective (as in the domain model)?

I don't think Aggror is still around, I'm not sure if this would even run anymore.

Wow, that C4 code made me cry even worse. It's a prime example of why I think Leadwerk's has a giant edge over the competition. Josh does not enforce some paradigm on us like C4 does.

I sometimes have to cry compiling open source libraries. True story.

As Metatron suggested, you need to write two class scripts, one on the wolf and one on the bird. Then, initialize its properties from the editor. Open up the atmosphere script as an example. Then there is also no need to maintain a separate table for entities, you can simply find any entity by doing FindChild on the scene. As far as your common methods go, Leadwerks defines several callbacks you can use to run update logic. Take a look here: http://leadwerks.com/wiki/index.php?title=Entities#Callback_Functions Then you don't need to go about defining your own methods. I am not sure they are implemented in Lua though. You can most certainly use them in C/C++. Before you start re-inventing the wheel, I would suggest you write some small (think Pong, Asteroids, Gorillas) clones to get a feel of what Leadwerks can and can't do. It will save you time later.

I was not saying that. I was saying that **** art will look **** on any platform. Something that looks inconsistent on a PC will look inconsistent on a mobile platform as well.

I'd also like to argue that **** and inconsistent art will still look **** and inconsistent on a mobile platform, not negating the need to have both programming and art disciplines on your team unless you are some kind of prodigy.

I have spend the last two evenings trying to get CEGUI to compile, even without replacing the Lua implementations but slew of dependencies is hellish and I think I am going to give up on this one. I vaguely remember you having similar problems when you were trying to create a single DLL that contained all the dependencies for Leadwerks. In the spirit of moving forward I think am I going to hardcode the event handlers, which allows me to still define layouts in XML, just not the interactions.

I do not want total control, if I wanted total control I would be programming Assembly. I want a certain degree of control. And Leadwerks' offers me that control. I indeed can't and don't want to. But that still does not warrant a move to Unity, Because this is a programmer-centric engine and the main reason why a lot of programmers got this engine instead of Unity. But there is obviously no right or wrong. There is vanilla and strawberry. I do think, without trying to offend you, you bought the wrong engine and you should get Unity. It appearantly is everything you want. There is a free version you know.

Interaction between "players" and "characters" is such a specific feature I would find it highly undesirable to be forced into Josh' paradigm as far as the implementation would go (I'm starting to feel like and old record player). You keep iterating you want everything to be "simple". Let's take that to the extreme so I can illustrate my point. In the most simple possible case whe have a button that creates a game for you. Slightly more complicated you can define a genre. Even slightly more complicated you can specify additional parameters such as number of units or available weapons. You can see where this is going. Then there is Unity. Allows you a fair amount of control. More complex is Leadwerks. Allows even more control. And that is why I bought Leadwerks and not Unity. Because it allows me control to the degree I want.

Hi Rick, CEGUI can indeed call Lua functions but it does so in its own state. It has Lua 5.0.1 compiled into it and passing Leadwerks' Lua state as a parameter to the construction of the scripting module fails. Communication between CEGUI and Leadwerks is therefore not possible (so you can't call engine methods from the CEGUI state and vice versa) so next order of business is trying to recompile CEGUI and roll in LuaJIT as a replacement to "vanilla" Lua.