Flexman

I'll preface by saying this is for Leadwerks 2.5x I'm adding some seasonal variation to our game (simple test map shown below) through changing the base colour of the terrain layers. I know some of you chaps have tried or done this before. Do you have any tips on how to incrementally lighten/blend snow on the tree and vegetation models?

As Shadmar says, culling is done using AABB. Workarounds might include manually adjusting the AABB values (then calling the aabb update) or adding a couple of vertices to the mesh to make it bigger. Could be a bug though, had many frustrating times with objects being culled. Are these patches parented at all?

Thanks for the link. I never get tired of seeing the creation process. Stunning results. I can glue bits together but never create anything pretty.

Cheerio Chris. I enjoyed playing with the particle system. Best of luck with your future endeavours.

Well you SAY transparency is easier with def'ren. With simple scenes and demos it isn't difficult. Just when you try and assemble something that looks like a decent model with working parts that include a mix of transparent materials it becomes a logistical exercise.

I would think a small model would be ideal for background mountains. Simple texture layer. Certainly the current terrain objects needs to be a bit more flexible. Also it would be nice if you could have more than one terrain object. At least have one active at a time.

I should finish this tutorial sometime I remember I had to break off to finish my terrain editing book. It might be more interesting to continue this with Leadwerks 3 though. The Delaney function might come into it's own for this.

What serialization libraries have you found and feel happy with?

Using height constraints gives you just that. It's a blunt instrument. You don't necessarily want the same texture at the same y band everywhere. Should (for whatever obscure reason - and this has happened on more than one occasion) should your editor map file get corrupted and you happen to have the design of your level and all it's features as separate masks (a layer for roads, land-classes, water features, civ layer features). But it's just a suggestion and it seemed like a simple one to implement for additional flexibility. Especially if you work with 3rd party tools which export individual features as masks which would make importing designs a little easier. I guess if nobody else sees the benefit it's not worth arguing for. Features like fill layers are probably more useful.

They test units of code. And give you code coverage. For large projects that may have multiple releases or rely on 3rd party libraries that might change, it's a way of confirming they still do what you expect if you need to apply an update to your source. Take RakNet for example, you might have helper functions that listen for a client message and sends back an ack message with some server information. If you have to update the source, you would just run all the Network Unit Tests and if they are crafted well enough, will tell you quickly if the update has borked anything without having to compile the whole project and test it. For Leadwerks you might want to test different raycasting and collision scenarios with each update. Checking you get expected values from a bunch of operations on hulls and vegetation. These are more functional tests than Unit Tests but you can use the same Unit Test functions built into Visual Studio to give you a nice 'at a glance' traffic light panel. You can't always make a good case for using them, or justify the effort at all when dealing with small projects. But they can help you focus on your code and what it's supposed to do. Especially with classes which ideally have singular responsibilities. It's all too easy to pile multiple things into a class and a unit test will flag that if you can't easily write a test for it. It's more like 'healthy eating', not required, but is of benefit.

All good stuff. Many of us don't have the benefit of being mentored. You learned (like many of us I'm sure) the long way round through experimentation and simply 'doing' which is fantastic. We'd all do things differently if we knew then what we know now. And to compound it all, some coding practices today haven't been around that long. Some were possibly not around when you start a project. If I were to add anything to your list it would be unit tests, especially on complex or large projects. That and recognizing basic design patterns as they tell you how to build something (at least recognize the problem and how to structure your code). I now work in professional testing and development and even though it's not related to games, all the things you mention apply. As skills go, they work across the board. Josh would have less issues with releases if there was a more solid testing system in place. Sadly testing is much neglected, it's something that not only saves money but also time and customer satisfaction. The earlier you can catch bugs the less impact it has on a project. Developers are the first line of defence when implementing automated testing using unit tests and code contracts. It's also harder to retro-fit to a project the longer it runs. To end my comment with a t-shirt quote; what doesn't kill you, gives you experience.

Edited my original post above.

Set a layer to work as a mask for creating road, river and shoreline features easily. Would work by selecting a layer, clicking checkbox (use as mask) then going back to your work layer, all terrain painting operations use that selected layer as a mask. To illustrate... Say I had some feature such as a mesa or race track I had a texture and a mask for. But I wanted to use the terrain brushes to quickly model this in the editor. I could load the mask image into one channel, set it as a mask, then the terrain drawing tools would use it to weight the drawing operations. or... Flatten an area to create a simple island. Looking at the image below. The mask on the left shows the outline of the shore. Everything in 'red' is effected by editing operations. I flatten or set the value of some procedurally created the terrain and *bing*, instant island with sloping shoreline (if you blur the mask image first). You can simply re-purpose existing layers in the editor and use it for textures as you like. Frankly hand drawing decent terrain is a pain. You could also use a mask layer to apply textures, then the applied textures will match the terrain feature. This shouldn't add much extra work and would significantly improve control over editing. For example, in the island example above, without a mask you would have to: Procedurally generate the terrain Flatten the shoreline and sea area by hand. Hand paint the textures around the sea and beach area With a mask you; remove the time spent hand-shaping the shoreline, flattening, painting the sea and beach area. It should be a matter of setting up the mask and applying some operation. Then you use hand-tools for fine-tuning and touching up, adding detail. It doesn't require much more interface work for what you have already, just a check box or drop-down. The tool drawing operations just need to be passed the correct layer and compute the co-ordinates for weighting final output.

Imagine Star Wars with realistic audio in space. The camera POV. It's more natural. Sometimes there's a case for positioning on a character but generally if you're ears are telling you different things from your eyes then it can be confusing.

Not in a position to grab this yet. I appreciate this is an early Terrain implementation. Is it possible to have more than one terrain object currently? And if not, will it be a possibility in the future?

To improve performance don't do your LOS or FOG map updates every frame, every 0.5 seconds might be good enough. If using a fog-map (a black texture on which you paint a fuzzy white blob around each player unit) you can use this fog map in a couple of ways. As suggested above; paint it to a plane in front of the camera but above the landscape (ho hum simple but topography won't match unless you use a low res mesh version of your level topography). A better method is to pass fog-map as a texture to a full screen post-processing shader. You compute the sample position of the fog-texture based on your camera position above the map and modulate the frag color ( using mix() ) output from the camera buffer with the fog-map. For mobile you'll want to modulate the vertex output color for the scene. If you only want it to mask singular entities, use a point sample from the fog texture to modulate the entities alpha color. OR simply use an array as a grid and for each unit update the value of surrounding cells and use that to set the alpha of enemy units. So many choices.

Gamers are not gamers anymore, they are walking meat wallets. That's the take-away I get from industry journals and sites. Still, you've got to earn a living. Producing middle-ware or content seems to be the safest part of the food-chain. Having said that, the one device that's had the biggest impact on how I do things today has been the pocket sized tablet. Office, mail, social awareness, gaming is something that happens on the toilet. More than you wanted to know.

Not being negative here...B U T first thing I did was was check the documentation after reading this. Please add to official documentation.

Tessellation and displacement are hard to marry with collisions. I know one unreleased engine does this, it doesn't seem trivial. Back to textures, what if I have surface imagery of Oahu Hawaii (say it was a car racing game like Test Drive Unlimited) and want texture stages 4-5 to be a raw sat image. For low altitude rendering, stages 0-3 as m-textures. What different approaches would facilitate handling this kind of game scenario? We might want to graduate between sat images with pre-computed splats based on altitude. "Gods eye" to unit view, and back again. Would the mega-textures be computed at run-time, or during map load time or a longer tool export operation? Your description implies you're having much success with small drawing operations, but how far will it scale I wonder?

One of the tools I work with pretty much lets you paint up to 32 layers across very large datasets but renders them down on export so you never have results as good as the source. One of the biggest limitations we had when building the Afghan map was the 10 meter square resolution and shortcuts made to fit everything into memory. Interesting stuff.

Brilliant.

I'm wholly impressed by your old school approach of making flyers to post around town. It's really sweet. Props to you Rick.

The rendering aspect is trivial. Enclosed VR brings a set of user-input problems to the table which is where you'll notice the testing focus is with this stuff, VR headsets do have the advantage in that they hide the disapproving look on the wife's face and embarrassed grimaces of your kids These user interface problems are down to individual developers to shake out and tend to be application specific (from the simple "how to navigate" to locking down axis of motion, body vs head tracking). It will be interesting to see how much regular usage these devices get after the honeymoon period. Working with head-tracking stuff has had me ripping the stuff off my head as it really gets to me after a while. I do look forward to trying it out though.

iTween does a lot, pretty much everything you need for easing in/out and curving values. A Curve class should be standard as you can use it in everything, movement, color, GUIs, chained animation cycles. And you need variations of it in nearly every project that has to look polished. But I think there's a LUA implementation somewhere. I'll have to rummage. In the meantime Aggror shows the way. If you modify the movespeed based on distance to target you can add accel/decel effects.

Each entity is assigned a view range (near, medium, far, infinite ). You set the view range for each of these in the environment > atmosphere object (cull range, from memory)