Pixel Perfect

Cover points now enabled accross the entire level. The type of scenario shown in the video can be played out anywhere in the level. Just need to code the partial cover points now where NPCs will crouch behind smaller objects for cover and randomly stand up to fire; to add some more variety and realism

Haha ... cool game. Simple idea but really quite addictive. Man do those barrels move at times !!!! Only just started playing it but my high score so far is a pathetic 68 I can do better

Thanks Aily. It does require a lot of code and functionality to be in place before you can start to put this sort of behaviour together but once it's there it's fairly easy to construct the AI. But to increase the complexity I really do need the better tools to make it easier to manage; which is where EKIOne will come in. I've posted a copy to the video gallery, thanks Josh!

Thanks Roland. Yes, just LE2 and C++. I have never needed to use Lua yet.

Most of you know me; I have been a member of the forums and user of Leadwerks technology from the beginning of Leadwerks 2 and have been slowly developing a game engine and toolset based on Leadwerks 2 in my spare time. I have two potential games in progress, an FPS/RPG called 'STRANDED - The Game' and an Adventure/RPG game called 'The Kingdom Of Soul'. Both of these have had the underlying game engine functionality built, to a certain extent, in preparation for the construction of the games themselves and my engine is designed to support both genres seamlessly. Previously I have maintained separate threads for each but as the two games now share a common engine I'm starting this thread to consolidate all output based on my Neutrino game engine development. Early trial space scene from my STRANDED game: As some of you will already know I developed my own game editor for the purposes of facilitating the design of my path finding solution and AI and to act as a test bed for the engines functionality. The game engine is embedded into the editor and runs in real time within in it. I added FSM (Finite state machine) support to allow AI development and animation driven motion and blending support. I have been working more recently on integrating the EKIOne path finding/AI product from Artificial Technology in Germany as it offers far better tools than I could hope to develop. I believe once I have EKIOne on board I will be able to expand the AI design far beyond what I can currently manage with my simple implementation of FSMs. However, whilst I've been waiting for an updated SDK from Artificial Technology (which I have now received) I went back to playing with my Cover Point functionality in my game engine and now have that working to a point where I can demo some of it. It’s still pretty basic and needs further refinement but the foundations are there and I hope to export this functionality for use with EKIOne once I have that fully embedded. The input to this thread is likely to remain sporadic for the meantime as I develop further elements of the engine and toolsets but I'll try and update it with progress as and when I complete further goals or have anything interesting to show. So, simple cover point functionality running in my game editor (Note: the NPCs do not have the ability to kill the player yet so it's a little one sided, even if this was coded it would be switched off for testing purposes). Again ... best watched in 720p in full screen:

We have no real issues with the game play or the controls, works well enough for us. The only issue we have seen, but have been unable to reproduce again, was one occasion where my son managed to get stuck inside one of the platform blocks and was unable to get out (a collision failure of some sort). Seeing hows he's played it every day since you released it I don't really think it's much of a problem though. We will definitely buy the finished game B)

Chris's method above is certainly widely used in games these days although walking into a room where objects are highlighted or glow at you I've personally found annoying as it takes any skill out of the game (a bit like playing a game with a walk through guide in your hand). An alternative is to either highlight the object only when your cursor is over it, as you suggested, or in my pick/inventory interface I simply enable inspect and pick icons when the cursor (a hand in my case) is over a pickable/inspectable item as show below:

That really looks very impressive deniz ... nice work!

I couldn't agree more. We all tend to start off thinking if only we had tools to simplify this and tools to simplify that so we don't have to put loads of work and often experiment with generic tools that are available and dream of ones which have yet to be invented. However, we quickly start to see the limitations and the price we have to pay for using such shortcuts and those with the stamina for it move on to just doing the hard work. That's what gets the games made in the end and stamps your individual style on them. Sure some things can be aided by good toolsets but having good artists and programmers on the team is not something you are going to be able to compromise on without severely compromising your game. A good programmer will build toolsets customized to your game and tweak and expand on the engine in order to get that extra mileage out of it to add that essential polish and make your game stand out from the crowd. Sure you can produce simple games on your own and with minimal programming and artistic skills but that's as far as you'll get without adding specialists to your team. In my humble experience the people that succeed in making games are not those who say 'if only I had this I could make my game' but those who say 'I will make this in order to complete my game'. It is this difference that separates the dreamers from the achievers. I am still walking the path from dreamer to achiever and hoping I manage to get there but have the utmost admiration for those who do.

I have no need for Networking atm but when I do I know where to come. Thanks for posting this Ken

Aily ... you're a genious mate! Best Leadwerks game so far ... by a long way! The overall design and attention to detail is superb. I'd love to be able to give you a time, but my 7 year old son won't let me near it, he won't stop playing it. Once the novelty's worn off I might get to play it all the way through Just needs some sound to really bring it to life.

Can't wait to try this tonight ... looks great Aily

Its not specifically a 64 bit issue as far as I'm aware as 3DWS runs fine on my Win7 64 bit OS

I actually found a XNA thread associated with this that Josh was contributing to here so maybe he knows more about this than I at first thought. Guess Josh might be able to shed some light on this! The last references and comments to this I was able to find was it was all working bar some issues with terrain. Does it not come with any example code ?

I doubt anyone here has any experience of this importer as it's been written for XNA. I have no idea what output this importer creates or how accurate it is. I'd suggest looking through the .3dw file format documentation for starters.

Now that made me laugh

Access to a simple variable ( a pointer in this case) is always going to involve less overhead than running a Leadwerks function. It wouldn't matter either way if it was a single call, but if its repeated then I'd go with the variable every time.

This is where nav meshes (or other path finding constructs) can come in useful in limiting the player motion or rather confining them to just those areas. Failing that, a simple constraint on the x and z movement to reflect the size of the traversable area such that if the player attempts to move beyond those extents they are simple ignored would do the trick. Invisible objects (geometry) would be a second suggestion where collision with such objects would halt motion beyond that point.

Yes, you will get individuals achieving great things; I have never argued that's not the case. It’s just general advice I'm trying to give. From my experience of years on game development forums, less than 0.1% of members will ever finish a game, let alone be capable of completing the entire task themselves. The people who fit the 'Lone wolf' profile you're referring to fit into the 0.01% or (1 in 10,000). A team can be as small as two people and stands a much better chance of succeeding, and believe me good art or programming is not just confined to PC AAA titles, a well designed and resourced game on a mobile phone stands out from the crowd in just the same way. I agree that the graphical demands are a lot less demanding on those platforms although that is changing rapidly too. I'm not trying to be cynical but I have seen a constant stream of people from when I first got into game development who I tend to put into the 'if only' category as they are constantly saying ''if only this engine did this, or if only this engine did that' rather than the real lone wolfs who just get on with the tools at hand and make it happen! I have a huge respect for the lone wolfs of this world but wouldn't recommend that approach to the majority of people LE3 is coming and we all hope it will be improve greatly on LE2, especially the workflow elements as you correctly point out and the inclusion of path finding and simple AI. However, a stable LE3 will be at least a year away if past experience is anything to go on so why not use your time constructively and have a go with LE2. It may not be as user friendly but it's quite capable.

Wolves are pack animals, and are so as it’s been proven to be more successful in keeping the individuals alive by behaving in that way. Sure, you have individuals who are capable of both art and programming and excel at both but anyone like that would already have demonstrated that with LE2. Anyone who hasn't really isn't one of these people and therefore would be better adopting the pack mentality and teaming up with others. I don't understand this insistence of having to do everything oneself ... for the majority of us it’s so limiting in a marketplace that requires such a diverse set of skills. We make these comments because we believe them to be true, not because we feel attacked. I'm a programmer and quite comfortable with that and use artists to provide the artwork/models I need and it’s not because I don't have any artistic talent, I do, but time is short. In truth, I have no need of LE3 and it’s debatable if I'll even buy it as there is more than enough I can do presently with LE2.

Yeah, fair point Rick. I have Minecraft and my son loves it and it certainly shows what a very talented programmer can do. There are always exceptions to the rule, but most of us are not that exceptional so I believe my basic premise still stands. Show me any game house that is not comprised of mixtures of programmers and artists ... and that's not by coincidence!

All engines are in my opinion 'engines for programmers', it’s just some like Leadwerks do it a little more elegantly than others. This idea that programmers can produce games without artists or artists can do so without programmers is really just a pipedream, artists and programmers need to team up to produce games and use their strengths to the full. Sure, features like the ones Josh is adding to LE3 help with the production of really simple games or prototypes; and you will be able to produce more without real programming skills than the current engine is capable of. But let’s not fool ourselves, real programming skills will always be required for a good commercial game just as real modeling/artistic skills are. Scripting does not negate the need for programming skills, good programmers will produce far better output and achieve much more than poor programmers. Unity and UDK are examples of game engines rather than game engine APIs. They have established game engine frameworks which from the onset limit you to a certain degree by demanding conformance to that framework. Leadwerks has a lot more freedom to express your creative design and allows for frameworks to be built and customized to your particular game. That is a huge advantage if you accept from the beginning that this needs to be resourced and you need good solid programming skills in your team. That's how I see it anyway.

I don't see any of this behaviour in EKI One which is using Recast, so I'm guessing its just an issue with understanding at this point. You'll get there! Interestingly, why is the nav mesh seemingly being generated as a uniform grid type system of tiles and not optimized. There are huge area there where tiles could be represented by a much larger polygonal area. This is the type of optimized nav mesh generation I am used to seeing with Recast, also shows off the dynamic regeneration quite nicely (you might want to take a look at this Naughty Alien):

Great news. Having recast embedded into LE3 is a huge plus. All nav mesh systems should handle that route easily Wchris so long as there is a viable route between the two points, the fact that there is a vertical displacement between the two points doesn't matter so long as no part of the path exceeds the maximum step height. It would be a single nav mesh as a nav mesh should reflect all walkable areas of a level regardless of where they are placed. You should, as an example, be able to fall or jump off one area onto another previously inaccessible area and still be able to navigate that new area.

It's the 3D Game Studio map format and as far as I know it is supported as a export file format from 3DWS; although I have never used it.