Ambient NPC Population

Ambient NPC Population, a continuation of an idea ...


A Free CryENGINE SDK for everyone in August 2011? ...

Adventures In Textures

Seeing just how low you can go with the poly count by offsetting a lack of geometry with normal mapping and hand painted textures ...

UDK - Hawken

Indie development at its best ...

Unreal Engine 3 - Environments Features Overview

Gorgeous tech demo trailer showcasing the features of Unreal Engine 3 and its free counterpart, the Unreal Development Kit ...

Monday, 29 August 2011

Colourful Behaviour.

Currently I am working on the second phase of the MapData generator, which is to scan the map for scene objects and then adjust the walkable/unwalkable data accordingly. The basics are working fine from a simple AABB check per collision type. Although I am only using the x and z returns at the moment, a more "honest" check would also require y0 and y1 with reference to terrain elevation to be taken into account, but for now this will do as I have another system in mind to further "refine" the AABB space check. 

I also integrated a version of my Blitzmax A* system, and have a test "AI Bot" that can path the generated data in the editor and traverse the loaded map. Debugging is currently paramount, especially with regard to the data generated and co-ordinate conversion between the different ways arrays and tables within Blitzmax and lua store data and the co-ordinate system of an .sbx file. On smaller maps I simply drew a small coloured cube at the grid position, and made use of LE's view range to "cull out" an area surrounding the cameras position. A physical pick test which did not rely on any generated data would then tell me if the system was aligned correctly. At the moment I am confident that the formulas I have derived are working fine. 

The issue with this type of debugging is it is only practical on small maps, whilst alignment will (should) remain the same regardless of map size, drawing check cubes for every grid tile is a non starter once the map goes over a certain size, as it eats up the available memory to a point when the application will simply crash whilst generating or indeed with very large maps simply crash on start. The map in the videos is "128 x 128" or more precisely 129 x 129 with an MpT of 2 this equates to 66,049 "tiles" which would require 66,049 check cubes to be created. Whereas a "1024 x 1024" with an MpT of 2 equates to 4,198,401 "tiles" which would require 4,198,401 check cubes to be created and a "4096 x 4096" with an MpT of 2 equates to 67,125,249 "tiles" which would require 67,125,249 check cubes to be created. So my solution was to write a function for both the camera and the AI Bot that would create, on the fly, a set sized area of check cubes around the respective focal points.

So, whilst "playing" around with different ways to save and retrieve the data generated for a map, I tried the Portable Network Graphics (.png) image format, mainly to see a pictorial representation of the walkable and unwalkable areas of a map, but also as another way of storing the data, where the red and green channels act as the 1's and 0's stored in the .dat .txt and .lua files. It then dawned on me that an extra "cost" per walkable tile could be embedded in the green channels value, such as the slope of the tile, the flatter the tile, the easier the route. Writing a small routine to determine the slope of a walkable tile (along the same lines used to determine walkable/unwalkable) the value written to the green channel was adjusted a set amount for a particular slope range. The result can be seen below.

I then wrote a small function to read the png's pixel data on the fly and display its ARGB values.

This set me thinking, why just store slope data and walkable and unwalkable logic. Of course, you can change the value of the map data stored as values in .dat .txt and .lua files, for instance, instead of 1 meaning unwalkable, the value 0 could be used with walkable tiles having a value ( 1,2,3,4....) which reflects extra cost. But using the .png format this can be done using only two channels of the single (co-ordinate) pixels returned ARGB value.

But channels A and B are left unused, both of which can contain a value 0-255 (00-ff). So why not use them to reference area specific AI behaviour. One scenario might be, a town crier NPC, areas where that NPC is required to "do his stuff" could be defined by a certain value stored in either the A or B channels of the single (co-ordinate) pixels returned ARGB value, this value would only be recognised by that particular NPC class, so other NPC types would simply ignore it. The AI behaviour routines would be encapsulated into the lua control scripts for that class, simply waiting to be triggered. Of course it maybe required that an "area" should have several AI behavioural aspects associated with it, currently I can think of a way to attach three behavioural aspects to a single grid tile using the colour information from a single pixel, but I have a few other ideas on a way to increase that. Those ideas will have to wait as I am trying not to do what I always do and get side-tracked, but they are on the to do list.

This approach would also fit in well with my ideas about Ambient NPC Populations, where the vast majority of control resides in the hands of the "map".

This is all still very much a WIP, but shows potential.

Tuesday, 23 August 2011

A* Pathfinding MapData Generator.

The Alpha of my MapData Generator, this is the first phase where the terrain is interrogated and using pre-defined criteria an external .dat file is created containing the walkable and unwalkable grid information for a loaded map. This information can then be fed into either my Blitzmax/Leadwerks A* solution:

A* Pathfinding Using Blitzmax And Leadwerks Engine

or my Lua/Leadwerks A* Solution:

AI, Waypoints, A* Pathfinding, Lua & Leadwerks.

Of course this is only one way to create the node graph data for A* pathfinding. But for current tests using my Lua A* Library this approach will do just fine. The editor currently has only hard coded settings which in the demo video also checks to see if a grid square is below the waterplane and mark it unwalkable.

R.A.T.S. – Rodent Army Training Simulator

A friend of mine, Paul Thomas, is a developer on the team behind  R.A.T.S. – Rodent Army Training Simulator. I have been following this closely. I will be placing permanent links to his blog and to the R.A.T.S. website.

In association with, and presented by  Plastic Piranha,  R.A.T.S. was demonstrated at E3 2011 and  reportedly, got fantastic feedback.

I know Paul is hard at work on this, and I wish him and his crew all the best, and look forward to future updates and demos. You can check out the on going development on the R.A.T.S. website or over at 3D Masons. Heres little of the work so far.

CryENGINE3 Free SDK hits 100,000 downloads

Cryteks CryENGINE®3 Free SDK, has hit 100,000 downloads in only five days of its release on August 17th. That is a massive achievment.CryENGINE®3 Free SDK is free of charge for non-commercial use, but they are offering a royalty-only license model to developers who are interested in using the SDK for commercial projects from which Crytek requires only 20% of the developer’s revenues generated from the commercial launch of their game.

The free SDK can be downloaded from here

Epic Games, announced the Unreal Development Kit (UDK) exceeded 50,000 users worldwide a week after its launch on Nov. 5 2009. In May 24 2011 Unity annouced that its registered user base had doubled to more than 500,000 users in just over 6 months with 150,000 of those users being active monthly users. Unity Indie was renamed and released for free in October 2009.

Wednesday, 17 August 2011

CryENGINE 3 Free SDK Released.

"Anyone can now download a full version of the best All-In-One Game Development Engine, for free and use it without charge for non-commercial game development. You can try out the fastest toolset for creating game worlds and use the power of CryENGINE 3 in your own games."

More to come about this, I am just too busy downloading!

AI, Waypoints, A* Pathfinding, Lua & Leadwerks.

Over the last few days I have been getting into Lua script. A few days ago, I bounced an idea off of Macklebee about path nodes and waypoints, and things kind of took off in all directions. A special thanks to Macklebee for authoring the random visible node selection routine and other scripts and Lua snippets in this joint venture. Between us over the last few days we now have a small arsenal of different waypoints, path nodes and pathing techniques including a Lua scripted A* solution, which can use pre-calculated map data or be dynamic. Mack is currently working on another interesting idea along this route, and I have more functionality to code for some other ideas I have in this venture, from NPC behavioural information exchanges to waypoint 3D A* pathing, amongst other tweaks and new AI functionality.

Anyway, here is a short video of just some of the things we have put together entirely in Lua over the last few days. The video was shot inside the Leadwerks Engine Editor with the Lua scripts running in real-time.

Previous entries for AI and A* Pathfinding:

Oh how I hate AppTime() and the randomness of it all.

Attack of the Killer pathfinding butterflies!

A* Pathfinding Using Blitzmax And Leadwerks Engine

The Way Forward ... Making Blitzmax Trax ...

On The Right Path, A* Pathfinding In Leadwerks.

Don't you just hate it when that happens?

OOP I did it again ...

Tuesday, 16 August 2011

UDK APEX Destructible asset test

Just a quick and simple test of the workflow. I created a "metal crate" in Silo 3D, textured it in Ultimate Unwrap 3D and then imported it into APEX 1.0 PhysX Lab, where it was "sliced and diced" and exported as an APEX Destructible asset, this was then imported into UDK and placed in a default scene. Took about 5 minutes start to finish.

Monday, 15 August 2011

TGC Launch AGK (App Game Kit)

Well, this product has been in the offing for a while now, but as of today it is officially released. I pre ordered my copy a week or so ago. It did how ever take nearly an hour to get a download slot to retrieve my prize, I guess the bandwidth was taking a hammering over at TGC. I only have had a short time to play with this and go through the examples but it looks fun and relatively easy. The Tier 1 basic is pretty close to Dark Basic Pro which I used to use, and the rest of the syntax is not that dissimilar to Blitzmax or Lua. Tier 2 for this game engine is C++, or what they call native.

"The App Game Kit solves many problems caused by mobile device fragmentation. With it you can code your game once and then deploy your game to multiple platforms. Different resolutions and input systems are all handled by AGK."

Current support at the time of release is for Windows, iOS, MacOS, Samsung Bada and MeeGo with support coming post release for Symbian, Android, Windows Mobile 7 and Blackberry.

I will blog about it more later when I have had a chance to "play".


Twitter Delicious Facebook Digg Stumbleupon Favorites