Pixel Perfect

Cheers Porsche but I'm afraid it's still very much a 'work in progress' and not currently for sale. I posted the demos in response to requests from a few people to see what I was currently working on. As previously stated I'm developing this comprehensive game engine and toolset for my own game but I hope to offer this for sale, should the interest still be there, for others to develop games with. I'm no longer certain that I'll use Leadwerks for the final game, as I've previously stated, but I have developed the editor to the point where it makes no sense to abandon it now as I can develop and test my AI using it. My current intention is to still use this to at least prototype an initial game level in Leadwerks. I want to finish what I've started as it's proving an invaluable learning curve. There is however a lot of work still to do and a huge amount of functionality still to be added. I hope eventually this may offer people with minimal coding skills a working engine with the full functionality they need to make a game and tools to aid rapid game development. The ability to do simple scripting will still be required though! I've not had a chance to put the video together of the whole test level yet as promised due to lack of available time but it's coming hopefully before the weekend.

Can't argue with this suggestion ... a big +1

Yes, I had similar problems with a 7900 around that version. Did exactly the same and was practically unusable. I would not recommend using anything less than a 8800 for development work with Leadwerks. On the second question, only Josh could tell you that but I suspect it is probably too early to know!

Not really, a game engine is more than this in as much that it will have specific embedded funtionality to handle such things as Path finding, AI, game flow, sophistocated support for animation etc. In other words, designed to have all of the major functional components required to make a game. Elements of these may be handled by program calls, so I do see where you are coming from, but more often than not supported by toolsets that allow artists/level designers to interface in a more human friendly way! UDK would be an example of a Game Engine whereas Leadwerks is more of a Library or API as it currently stands. Gives you more work to do as you have to construct your own engine using the API but ultimately more versitile than an engine where a lot of decisions have already been made for you by the designer.

There is no support of IK in Leadwerks so I'd guess there would only be any point in exporting the weighted bones as your animation package should have taken care of the IK bit for you. Leadwerks supports up to 256 bones now and the skeletal animation is handled by the GPU on the graphics card so shouldn't effect the performance too much. I must admit I've not tried anything with more than about 90 bones myself. Your poly count sounds about right for lower end hardware. Look forward to seeing some of your animated work!

Absolutely right, that’s certainly my experience of this type of approach so far. It's not to say that things can't be moved on and more flexibility built in but it will require an absolute standard interface for the components (which I know Rick is working towards) which all component manufacturers (for lack of a better expression) would need to adhere too. But much more than this, and this is where it gets tricky, an incredibly flexible framework designed to work with these in a way that allows users the freedom to wire these things up any way they want to. Whole teams of experienced programmers have worked on these kinds of systems in the past and I just fear that leaving this to a user base of part time programmers with little to no co-ordination is never likely to achieve what’s required, although the intention is good. Your approach to the game object side Mike doesn't really sound too dissimilar to mine in as much as you are attempting to support embedded functionality of a wide variety of game components whilst allowing users to customise these and substitute their own models/artwork. The problem tends to arise when you no longer can rely on just autonomous functions but need to centrally co-ordinate these things, bringing us back to the framework issues I touched on above. It seems to me you can only go so far with this encapsulated functionality methodology where it's a self contained entity in its own right without it being able to somehow register with a framework its type and functionality so that a centralised AI framework and game logic module can interact with it too. Again, I welcome all the different approaches that are being taking by the various people proposing these things (and I'm sure there are also others working in the background on systems we are yet to see anything of). It's all very healthy and ultimately encouraging for the Leadwerks community who will also be benefactors of anything that subsequently gets developed. My current editor and proposed system is not designed to work with others as it is dependant on its own centralised AI framework that has knowledge and control of its component parts but is happy to allow autonomous behaviour when required. However, if people can actively demonstrate real advantages to their systems then I'd be happy to work with them to integrate my tools with theirs. Most functionality can after all be packaged up and interfaced into other systems if the desire to do so is there!

Thanks again for your positive comments and yes, in response to your question these are very much elements which I'm looking to through into the overall AI equation. I welcome any input/suggestions on AI implementation as it’s all a brave new world for me. I'm certainly not short on my own ideas but always willing to listen to others experience and suggestions. Thanks too for your continued support and interest in this. I think a little clarification is probably required here in order to explain my answer to this. The simple answer is probably no and I'll try to explain why. What I am really doing here is attempting to build a coherent and integrated game engine/tool designed from the ground up based on the Leadwerks API. The main reason is to leverage the power of C++ and my familiarity with it whilst exposing only high level functionality to LUA for the purposes of scripting game logic. At the same time my design emphasis is very much on making it as simple as possible for people to use whilst maintaining as much flexibility as I can. This will inevitably not produce the same degree of flexibility that coding your game engine directly, be it with LUA or any of the other languages, but then ... how many people are capable of doing this? What it will hopefully bring is the benefit of fast, proven and tested underlying game engine functionality all working seamlessly and with highly configurable ways of setting it up and with a tool/tools that aid doing that. It's a more traditional approach as my belief is it’s the more direct route to achieving what the majority of Leadwerks users inevitably want. A powerful but relatively easy tool based around a pre-written game engine framework which simply allows them to design and implement games. This is what has pretty much prevented anything but static scenes from appearing in Leadwerks so far; as beautiful as some of those are. The few real game demos produced so far have been from people with a coding background or capable of embracing programming and running with it. So as much as I admire Rick's and others approach to independent game object design methodologies I find it still too radical, and little evidence that the same end goal is achievable by this approach, to invest what little free time I do have in. I started this don't forget to enable myself to make games and have taken what I perceive as the best route to bring this to fruition. The lack of any visible support from Josh on what I'm doing is testament probably to him siding more on the game objects approach which is pretty much why he introduced LUA in the first place and that neither bothers or concerns me as I have a game to make and sufficient belief in my own direction to sustain that. Competition is a great thing and I wish everyone involved in these endeavours success. The Leadwerks users themselves will decide in the end on what works for them and what doesn't and that's the way it should be.

Sounds great ... hope you do still have the code. No, you are right, I don't currently attempt to optimise the navArea nodes mainly because I found that in normal dynamic game play you don’t tend to need to plot paths that far ahead and by using multiple nav areas the connecting nodes represent a much smaller sub set and can be searched first leaving you to just plot the paths through the current child area as it may be redundant by the time you reach the next. Nav meshes are by far the most efficient approach and if I was starting from scratch again would probably go down that route (and may yet!). I'd love to see a demo of yours working if you manage to dust off the code

Both will find the shortest path! A* only differs from Dijkstra in as much as it uses a heuristic which will reduce the number of nodes searched to find the shortest path. Dijkstra expands outwards in all directions and as such usually involves searching many more nodes to get the same result and as such is normally slower. However, if the number of nodes is small then you are unlikely to see any practical difference. There are some situations where Dijkstra may be preferable to A* There are plenty of articles on the net explaining the pros and cons if you search for them. Some good stuff in that link too Kevin, thanks for that. Hopefully might enable me to avoid some of those pitfalls as my AI develops; although I'm sure I'll create plenty of my own B) No one ever said AI was easy! Thanks Pancakes. A cinematic editor is a distinct possibility at some point in the future and I keep hoping someone else will write a good GUI Editor so I don't have to do that myself lol I'd love to tackle all these things but my free time is limited with having to hold down a full time job and have a family life too! We have another baby on the way (due around March) so I'm trying to cram as much as I can in before he/she arrives

Thanks guys for all the supportive comments, I wasn't sure anyone would even make it through the first video My main design strategy when doing all this was 'keep it simple' so I'm glad to see that this seems to have rung an accord with others. It's still very much a work in progress with some way to go but I'm getting a better feeling about it every day ... in as much that it feels like I am actually getting something right here! That's a fair and accurate statement Roland and one I've given some consideration to. To address this directly my intention is to either do something similar to what you describe whilst retaining the existing path finding system or eventually swap the hierarchical grid system out for a proper nav mesh system which would allow for a more sophisticated approach to this. It's been a difficult balance to strike during the development process as I have never written a complete game engine, or graphical based editor for that matter, before. The temptation as a programmer is always to stick with each element until its perfected before moving on to the next but the problem with a development of this scale is ... unless I tackle all of the major areas/components comprising a game engine first, so be it just at a fundamental level, it's not possible to know if my ideas are feasible, will work well enough and whether my existing engine framework will support what needs to be done. As it stands now, the framework has been re-written once already as the initial one proved too inflexible as I advanced the design. So the aim is to put in place all of the major elements essential for modern game play with a stable and flexible framework and then refine and fine tune those elements at that point. This is a long term development with the intention of providing a hard core of low level embedded functionality but combined with a simple but flexible interface and a scripting function using exposed high level commands to LUA. The emphasis is basically on good flexible functionality and ease of use, because at the end of the day I want to be able to build games and have a tool/tools that really aid this process rather than hinder it. The AI is barely started but I believe I now have a good enough code base and framework to really move that forward. Next to be tackeled are: Dynamic (in real time) identification of cover points. Hopefully nothing will need to be pre determined or at least that's the aim. A gradual build up of core AI functionality for defending and attacking including NPC grouping and factions. Expansion of the info Waypoint system which already supports individual waypoints carrying key information/commands to allow the activation of these when reached. So for instance, a patrolling NPC may reach a waypoint that requests it to stop and face a certain direction and pause for a period before continuing on its way. These commands can be user defined and combined with scripts to control the action. Exposure of low level C++ functionality through high level commands to a scripting language (almost undoubtedly LUA). NPCs will be autonomous as much as possible but capable of having their behaviour scripted too, especially for support of cut-scenes and scripted events within the game. The ability to script the overall flow of the game, add triggers for level events and level loads etc. A save and load facility where all dynamic object properties are saved to file along with pertinent game data. Extention of the path finding to handle dynamic objects in the game (most of the underlying code has been written to support this) and tackle the more aesthetic elements such as the one raised by Roland. Then the eye candy will follow with the introduction of day night cycles, weather systems etc and support for multiple water planes. I will also include a menu system at this stage too. It's a big endeavour but one that I feel will be well worthwhile if I can pull it off. The main aim of this is to use the tool to initially produce my first playable game level and see if there is any interest. I would also considering making the tool/engine available at that point for other licensed Leadwerks users to develop with although there will probably be a small charge for this. I have had some commercial interest in what I'm doing for some time now but have made no firm commitments on timescales. Sorry for babbling on so much but clearly you have shown interest and I thought you might appreciate a road map on this. Thanks again guys for the support! I'll post a video of path finding in the full level this weekend, plus a few little extras!

I've posted a series of video demos showing some of the key functionality of my navArea Editor in my development blog and have included them below if anyone is interested. The whole purpose of this is to allow me to develop and test AI using the navArea Editor as my test bed. Select 480p to view at the higher resolution! Seems I cannot embed more than two so the links to the first two are below: navArea Editor Demo - Part 1a navArea Editor Demo - Part 1b http://www.youtube.com/watch?v=U-csE7nbVvg Latest Video of the techniques applied to the whole test level (posted 19-07-2010) http://www.youtube.com/watch?v=L8sn5kA7eKs

Good luck with the game RVL, look forward to seeing some trailers maybe later on

It's in the Call Of Pripyat forum Dave and the thread is named: New Dave Lee Video ... The Zone using Leadwerks Engine 2

I posted a link to the Video on the STALKER Forums and the response so far from die hard Stalker fans has been positive!

They used to be in earlier versions of the engine ... perhaps Josh should expose them again!

Very nice indeed!

Seeing that he has already stated $ 200 equals the average wage how much do you think a paperboy job is going to pay! Better and less condescending advice might have been to work with free tools and engines initially! A much better and creative use of his time I'd have thought!

There is really no lack of performance that I can detect. This engines hardware requirements are higher than some but that's hardly surprising when you see what it's capable of. There is a lot of ignorance around regarding BlitzMax and a lot of ignorant people too for that matter . I am currently getting 50+ FPS with 18 active NPCs in my scene. Example of scene below (new video coming in the next week on my development blog):

The Editor and Engine inherently supports scripting using LUA not C#, you would need to add your own scripting capability to do that. Any of the existing game play functionality that exists in the Editor is by virtue of the LUA scripts so you would need to edit those to suit your own purposes. However, if you are writing your own engine in C# it begs the question of whether you'd even need to do that. Just use the editor as a level designer, load the editor file and run all the game functionality in your engine. Those who are capable of writing their own engine don't generally need to rely on the Editor for anything other than level design and object placement Leadwerks is capable of making games in practically any genre if you are prepared to do exactly as you suggested ... just use the Leadwerks API and write all your own game functionality. This route offers the most flexibility. I came down the DarkBasicPro / DarkGDK route and believe me, this engine is a quantum leap from that but you still need to put the programming work in! Hope to see you on board soon! [EDIT] oops ... missed this one Yes you can

Hi Igor, I at least appreciate that economic situations are a relative thing and although we are experiencing a downturn in the west it doesn't necessarily compare with other countries situations. All I can suggest is that you email Josh (the CEO of Leadwerks) directly at support(at)leadwerks(dot)com and explain your situation. Good luck!

If Josh does not answer this directly then I would email him at support(at)leadwerks(dot)com with proof of purchase (your existing registration key for the version you have should be enough) and asking for details of how to update to 5.52

What version do you currently have? Version 5.52 was the last officially released version

I really wish you luck with this Rick as it's an interesting approach and I will be fascinated to see where you can take it

I love pointers and have never had a problem with them ever .... just thought I'd say that in their defence

Much nicer vid Kevin. We've seen a few nice arcade style games, from FallingBrickwork and AndyGFX to mention two that stand out, but this has to be the best looking and most accomplished game I've seen in Leadwerks so far with great looking game play game and functionality. You have both the artistic talent and the programming skills needed to succeed and are onto something special here. Keep up the good work