Jump to content

Flexman

Members
  • Posts

    916
  • Joined

  • Last visited

Posts posted by Flexman

  1. If anything, it highlights that you might need to de-couple your game logic from renderable entities. Split them into two states; renderables and logical entities. Not saying you should do that Rick, just something to consider in general.

     

    As always it depends on the scale of the game, small games/demos can get away with it.

  2. For the benefit of others who might overlook this little feature. This is actually pretty good for doing basic stuff in 3D games.

     

    A common example, when you have a player vehicle or an animated character viewed from first person.

     

    In these situations you don't want the mesh intruding into the camera view (the inside of someone's head can be disturbing) but you want all the benefits of collision detection and shadows. If you simply Hide() the model you loose those.

     

    Another scenario; when you have a detailed vehicle interior, but when viewed from the drivers position you might still see parts of the exterior model (it may be a different scale or the mesh doesn't quite match up etc). You can make different meshes visible/invisible depending on the viewpoint. In some situations you can simply use Hide() and Show()

     

    We've found this really useful in LE2.

  3. Just to chime in, had my first Win 8 experience last night trying to fix a router problem. Within 5 mins I wanted to put my fist through the screen. As user experiences go, that's a first for me. You must have incredible patience. Maybe 8.1 is better. Steam OS, bring it on.

  4. 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?

     

     

    screenshot_295.jpg

  5. 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.

  6. 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.

  7. 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.

     

    post-52-0-13764500-1378246490_thumb.png

     

    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).

     

    post-52-0-49319100-1378246914_thumb.png

     

    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.

    • Upvote 1
  8. 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.

  9. 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.

    • Upvote 3
  10. 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 smile.png

     

    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.

  11. 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.

  12. Speaking generically, performance testing comes a bit later after a code base has settled down. Then optimization. It's harder to justify time spent on optimizing code when you're still working on it.

     

    I wish I had access to a decent performance HUD.

     

    Anyone got suggestions?

  13. To be fair, it runs OK on this Intel graphics machine I've been using it on. But I'm having difficulty with the usability. Couple of bugs found already but trivial.

     

    First impression is that it's a huge step up from Leadwerks 2.0 editor (apart from the lighting and terrain etc). LUA debugging is great and could use few little extras to aid work on non-trivial projects (real games, not short demos).

     

    Script Editor is always on top, toggle please or little widget. It's clunky.

     

    LE2.5 animation blending by code is clunky. There's a disconnect here between art asset and what's required to work with it. If you don't have information about frames or bones, this is a total pita still. Coders don't make animations, yet required to implement them, disconnect = arse to work with. There's still a lot of boilerplate code when you add objects, however I am sure this is just down to unfamiliarity and lack of examples of various types of objects.

     

    On the whole, not bad. It still feels like a $200 engine for what you get. And I want to see the same game project running at the same time on different platforms.

     

    I appreciate the opportunity to try it out and it does look quite promising as a mobile game development platform.

×
×
  • Create New...