"Gorgeous tech demo trailer showcasing the features of Unreal Engine 3 and its free counterpart, the Unreal Development Kit, that help make lush environments."
Working on two principles K.I.S.S. (keep it simple stupid!) and more for less.
I spent a lot of time researching (read playing) certain games that have what I call an ambient NPC population. This is specifically those NPC's that reside in the background and generally have no real or very limited interaction with the player. Two such areas of research included Assassins Creed and Fable 2. Although both of these games have a far more complex general NPC population than what I am setting out to create, but the "research" was most enjoyable.
First Step:
Machine Intelligence "Kinda Almost":
Machine Intelligence "Kinda Almost", simply gives an illusion that there is intelligence at work but there is not, sort of like, the lights are on but no ones home. There are several subsets to this group but the obvious one is simple animation. Also this can include proximity reaction behaviour, a posh and complicated way of saying when the player is near, stop what you are doing, and do this instead. But that's as far as interaction goes for those NPC's in this group. This simple ambient NPC type could also use lua scripts, loaded with the level and be left to attend to themselves.
For example, just two chaps having a chat:
Having a chat is basically all they do, its simple per character animation's controlled by lua scripts. The purple block volume is the walkable area that would be utilised by more "advanced" ambient NPC's, typically those that move about, particularly those that would use Pre-Loaded and Pre Calculated path routes for this particular level. The purple block volumes are simply required by the application I wrote to generate the route node data for the pathfinding tools I created and have demonstrated here. Not that this is a level just something thrown together for testing but I think I should unarchive some of my GMF format models and put together a small town/Village for testing this, rather than another simple "BlocksVille".
There are obvious limitations to consider with this approach to the first tier of the Ambient NPC population for a "busy" town/village. The NPC's need animation's, most come with maybe 15 animation's (if you're lucky). My intention is to surmount this by adding animation's to them, primarily Mo-Caps. This will require a little work but will be the bedrock for the construction of this "tier". There are some very good applications on the market for achieving this. For me I prefer Fragmotion, there is also a free alternative that I also use on occasion called Pacemaker. But don't be fooled though, none of these applications will do it all "for you", you will need to skin the mesh to the correct rig for the plethora of free to use Mo-Caps, or indeed ones that can be purchased. It will all depend on budget and or requirement.
This is still only a very basic outline for this "packing" stage, it will still require a lot of work but my goal is to get the impact of it at runtime to an almost negligible effect even when including proximity reaction behaviour.
I decided to give the testing a few more hours. First off I wanted to create a new NPC Type which would have its own control flags and most importantly its own path storage buffer.
After a little thinking (a little thinking is what I excel at lol) and a few hours of coding and tweaking, I managed to get 32 new NPC Types all pathfinding their individual way around "BlocksVille".
For those interested I will try and get a demo.exe up later onto the showcase thread:
Following on from "On The Right Path, A* Pathfinding In Leadwerks" I thought before I archive the code, I'd have a little "dabble" with a basic function to get an NPC reading the path data and then following it to the "target" I had a couple of ideas on how to do this but as time for playing in leadwerks was running out I opted for a basic idea.
1. Target Position Selected
2. Path from NPC to selection calculated.
3. Path transfered to a temp storage array for that particular NPC
4. An NPC Pilot reads that data.
5. NPC follows the pilot.
Think of the "pilot" as the plastic stick thing on the underside of a scaletrix car .. it follows the groove in the track and the car follows right along. This was the quickest and dirtiest method but solved a variety of issues in one. Plus I just wanted to get the NPC moving and the sands of time were running out.
So an hour later and I have not only the NPC following the generated path but the path is updated with a repositioning of the target and the pilot takes the NPC off onto the new track.
This is all still quick and dirty, when I can remember what the code does and does not need, I will up a small demo.exe to the thread Pathfinding With A*
Well, it has been a while since I made a blog entry, let alone done any work in LE. But I do keep an eye on the forum and Leadwerks in between Daily life and working on my project(s).
I have also been going through my Blitzmax code archive, where I stored all my Blitmax/LE projects and code snippets (finished and not completed). One idea I had been playing with before, was basic NPC AI. I had some small success with some Bugs using autonomous logic.
In my "treasure trove" of unfinished and messy development code I found what was going to be the next step (for me) with AI functionality. The dreaded "pathfinding". I have read that Naughty Alien said he will be doing a two part tutorial on this and I am looking forward to that, having followed his work with Hidden Dawn I expect the tutorial to be top notch. But I wanted to get to grips with the in's and out's myself. So I started with the basics. I spent some time looking for code snippets and A* lib's in any language that had them to see of I could follow along what was being done ... Not a good place to start, in the end I spent some time reading "A* Pathfinding for Beginners", very helpful.I decided it would be best to start with a "2D" approach and maybe use nodes. Most 2D implementations use a grid based on the X and Y co-ordinates of the screen and tiles to represent an "unwalkable" tile. So I thought I would translate this approach to a 128 x 128 flat terrain with some primitive models to define the "unwalkable tiles". As this was a time limited "side-track" in LE from my other projects, it was all going to have to be quick and dirty. I wrote an app to calculate which "tiles" of the 128 x 128 terrain did not have an obstruction and then squirted this data out to a text file to be read into another app as a 2D array. The map data loads in a few milliseconds so this eliminated having to wait for the same data to be generated by the application I wanted to use to try and get the pathfinding working. One problem I did encounter was that I ended up trying to reconcile three different centre of origins for the co-ordinates. The map data had 0,0 at the top left, the terrain of course has 0,0,0 in the centre and my maths managed to get the A* to read 0,0 at the bottom left, after some profanity meditation I used some quick and dirty and hastily constructed math functions to bring them all into focus, thus as per usual the dev. code was a complete mess, atleast on that score I am consistent lol
This version of pathfinding is very limited, mainly due to the way I created the node info. But for a first attempt I was quite happy.
I have uploaded a demo App to the Leadwerks Forum showcase , the picking can be a little temperamental and sometimes the quickest path is not always found and some "sightseeing" seems to find its way into the route. But on the whole I think it is definitely a platform on which to build.
Currently I am taking a small break from actual coding right now, give or take the odd few hours now and then I thought it best to start construction of my testing level, or at least get the main parts of it built as the testing scene/areas are blueprints for a project I have had in mind for a while, basically some nasty persons do some nasty things which in turn brings about a whole lot of nasty and the player is the antidote to nasty in general. Yeah, not much of "game description" but radically indepth compared to one by our very own Gordon ... but as usual, I start on one thing and somehow get sidetracked .. not my fault though, honest, it was Epson's! They made my printer, and it got clogged, and if I had not spent 15 mins cleaning it out with A4 paper I'd have never have thought, hey look .. grunge textures. Well, I am no artist that's for sure, and I hate texturing, but I thought might as well make a start. So after the ink had dried I scanned them in and spent a few hours working on a connecting corridor section, heres a few screenshots of how it has progressed so far. Still very much a WIP, but slowly coming together.
I started out this morning looking to update a test scene that I used for some first person tests I did in C++ after only having the engine for a few weeks and coding in C++ for even less time. Well, that was the plan. I managed to redesign the layout using 3DWS, and threw a few Dexsoft crates and Barrels in. The plan was then to work on textures but as usual after about an hour I had set sail on the good ship "unrelated" for a voyage across the bay of tangents. Don't you just hate it when that happens?
The scene under modification was for my FPS prototype code in Blitzmax, whilst sorting through my code "archives" I came across my basic code for NPC creation with basic Seek : Pursue : Attack Behaviour (an NPC Type using methods which I wrote about here). Integrating it into my FPS prototype was easy enough and an hour and a few more dozen tweaking "tangents" later I had it all working quite well. The video basically shows 3 "settings" for NPC toughness.
Best viewed in HD
Player Control was a bit "twitchy" as I have yet to tweak the Xbox 360 gamepad functions for smoother action, also the screen capture lag did not help.
It all still needs a lot of work but I was happy with the results thus far.
I guess tomorrow I will do what I was intending to do today ... or maybe not.
It seems Crytek maybe planning a free CryEngine release.
"The developer behind Crysis 2 and the engine behind it, CryEngine 3, has plans to release a free version of their game engine that will be "up to speed" with CryEngine 3. This should help Crytek to further compete with Epic Games and Unity, both of which offer free versions of their respective game engines, Unreal Engine 3 and Unity. "
I started out yesterday morning looking to improve my understanding of types and methods in Blitzmax, and figure out how to use object-oriented programming (OOP) with it. I have only been programming in Blitzmax since the beginning of December last year, and only programming with C++ since the middle of October last year and The Leadwerks Engine since the beginning of October last year. So I am still on a very high learning curve in this regard.
As usual, for me, I started out on one thing and ended up on another. I found a link on the old forum for a small tutorial on Object-Oriented Programming in BlitzMax By John Judnich. But by the time I had got to page 6 of 21, I was already off on a tangent and found myself working on a simple NPC type containing a creation method and simple seek behaviour method, after all I was now an expert after only 6 pages lol.
I had already been "playing" around with some simple AI which showed vague promise, for an Idea for a small project.
An hour and a few more "tangents" later I had managed to restructure the basic code for NPC creation and basic seek behaviour into an NPC Type using methods. This now allowed the easy creation of an NPC, in this case a rather nifty bug, created by ‘Psionic’, with its walking animation handled by its Lua script on load.
The test scenes buildings are by GIMPY73 and the Freebeast model is by ‘Psionic’.
Updated: Test of Basic NPC creation : Seek : Pursue : Attack Behaviour using OOP in Blitzmax running the Leadwerks Engine. Extra flags added for behaviour to the NPC Type with extra methods to communicate with the NPC model's Lua scripts for animation control. Although I did manage to hardcode a typo in the "Pursuit" flag.
Of course this basic AI is nothing like the calibre of AI work being done by Chris Paulson or Pixel Perfect, but I had to start somewhere and this seemed the best place, so far I am pleased with my meagre results.
I recall Josh showing interest in integrating Recast into the editor, this would truly be a useful addition. Leadwerks could really use an integrated AI starting point. Thats not a complaint just an observation. Recast integrated into the engine and editor could be that starting point.
I have not entirely made my mind up on the new SSDO (screen-space directional occlusion). I liked, in some circumstances, the effect SSAO gave, especially on bump mapped brick textures. But I find SSDO to be quite "fizzy" possibly from the curve on the camera look values. This may well be down to settings but so far try as I might I still get this. Not sure it will be useful in an FPS situation as the HUD model seems to interact.
It does however have a very pleasing effect on "organic" assets.
I think I will "play" some more with it, see if I can reduce the "fizzing".
The new Indoor Lighting Optimization is truly a fine addition to the Engine. It has taken a little while to get into the habit of automatically setting the lights to Dynamic, Dynamic + Static, Static or Dynamic + Static + Buffered, as well as the needed setting for the objects in the scene. Objects that would normally always be static I have, for the time being, simply added an ini file to set them to static automatically. This will later be set via their scripts but for now it suffices.
Well, after much testing I have decided on an actual 3D modelling app to use in my workflow. I already have Blender, and while there are some very skilled users of this on the forum (Niosop and afecelis spring to mind and their tutorials are definitely worth checking out), I still find its user interface awkward and clumsy. So I demo'd a few different ones that would not break the bank. In the end I decided on AC3D. I find it simple to use and has enough features for what I wanted it for. 3DWS is still my main application for creating architecture, but I needed something for what I call redundant decoration, and so far AC3D has proved to be just what I was looking for.
Redundant Decoration is simply my term for low poly non functional assets, like in the picture below, filing cabinets, desks, fake PC's ect.
Filing Cabinet: 12 Polys
Desk: 192 Polys (currently, still room for "pruning")
PC Screen & Keyboard: 70 Polys
The textures still need some work, but using a combination of ShaderMap Pro and manual editing on the normal maps has produced some promising results.
So far I am impressed with AC3D, and would recommend to those who were looking for a low priced 3D Modeller to check out its 14 day demo. Combined with 3DWS, Blender and UU3D I think I have this side of development sewn up application wise.
Well nothing much to report, that does not mean nothing much has been going on though.
I have decided that as and when I make an emitter for a specific purpose, I will now create its own editor entity to save time by not having to create the exact same settings over and over. Also not every setting available needs to be adjusted so I will now re-write the properties to reflect what they effect and remove the ones not requiring adjusting for a particular effect and simply hard code them into the script.
This sort of came about when thinking about trying to get weather effects into the editor and eventually into an app. This is one I did for snow. It's a simple emitter used to create a localised snow effect in the Leadwerks Editor, using a custom .dds file for the snow flake created in Paint.NET