Jump to content

Flexman

Members
  • Posts

    916
  • Joined

  • Last visited

Blog Entries posted by Flexman

  1. Flexman
    These are placement tests for the Apache model in the editor, getting a feel for colour, levels, position, range and angle. The left nav light (red) on the Apache model needs to have the fullbright material applied to be visible in dark conditions. One pilot was telling me that the ground on the left side on the helicopter appears brighter than the right with night vision. Interestingly our night vision shader amplifies lighting levels based on final pixel colour and gives a boost to red values so you should also experience the same effect.
     

     
    Same again but with the nav strobe blinking, ever so short flash that should be visible 2km away in game terms. It uses a corona and not a real light source for performance reasons. It's highly visible and does it's job. Although it will probably flare-out or clip in NV mode. I experimented adding two point lights in the cockpit area, these lights currently exist in the internal cockpit mode but I'll see about adding them to the external model if it can be easily done. On the whole, performance would be better just baking that light onto the texture but the exterior cockpit is really simple, the canopy doesn't cast shadows and the light range is short.
     

    Final shot is the retractable spot-light, which we were going to model, maybe we did already but can't remember...(check notes). It's supposed to be steerable and there's a toggle switch for it somewhere. I think using a 3D cone mesh to add a bit of fake 'haze' around it might be an idea.
     

    I shall get these coded up into the game model now. Pretty pleased with the overall layout.
     

     
    Source
  2. Flexman
    Fingers crossed the weather is not too bad tomorrow at Gilze-Rijen air force base. Our man in the Netherlands is prepared for a day of audio recording for the Apache and Chinook.
     
    Good luck Reck. Weather is pretty lousy here, high winds, low temps and rain, sat images and forecast is so-so. Expect wet weather and don't forget the 'dead cat'
     
    Source
  3. Flexman
    Congratulations to ArtDave (AD, geddit) for scaring the poo out of me.
     
    He tells me he's been scripting the flare pen (Gyrojet), I'm so busy heads-down in game code I'm often grunting and throwing back idle comments and ideas to get his flare launching LUA code to work.
     
    Then he sends me his completed files. I'm taking a late afternoon break and thought I'd drop his new files into the project to have a look. So I pull over the gyrojet flare pen into the scene editor, I had no idea my speakers were on so loud. I thought a bomb had gone off, the almighty flash and bang/wheeeeeeeeeeee of the flare scared the **** out of me.
     

    This is just too much fun to play with. Animation, sound, lighting. Nicely scripted. Great work Dave, I suppose we're even for farmyard animal noises I put into your cockpit.
     
    Source
  4. Flexman
    At no point before have I felt so much under pressure as I do now. Hence the lack of blog updates. The new physics engine is still being problematic but these are issues relating to -ff-math and tracking down typos, the odd logic error and other errors that occur when programming.
     
    In a flight model, such errors result in numbers quickly blowing up, which they do. So I'm currently tracking down each issue, one at a time until, eventually, it should just all click into place.
     
    I finally configured my Combat-Helo input map for my Saitek X52 and apart from my shocking oversight of an inverse axis option it was a nice experience using the old mk1 flight model. It's frustratingly hard to get up to speed and it still flies in a nose down attitude. I may fix those points and retain it as a 'rookie' flight model.
     
    All this debugging and testing is taking up all my time, the goal is to have it in place for the show on the 28th. It's looking hit-and-miss atm. We're supposed to be working on some FSX stuff as well but that's had to take a back seat due to holidays and other things. Hopefully will be able to spend some time looking at that in two weeks time.
     
    AD did well finding an OK solution to paved roads. They work, efficient but they require a lot of work.
     
    To quote...


    Just to elaborate a bit. The key component is a vertex shader that takes the Z value (height) from the terrain and applies that to the Z value of the road vertices. The road itself is built in 3dsmax as a primitive mesh, a meter high and 20 meters wide. It's flat and the vertex shader sets the height at the end of each section of road.
     
    40960M's of road can be bought at the cost of about 2500 polys which is outstanding in comparison to the native road system which costs tens of thousands of polys for short distances, doesn't work most the time, creates massive slow-downs, and flickers like a 1950's TV in a washing machine.
     
    The only real down-side is the amount of work it takes creating the road mesh itself. It took me about an hour to lay down 10KM's, debug the path and smooth-out the ground underneath it. Therefore it probably won't be a suitable method for the dirt roads. I would add that the native road system is fine for small areas, it's perfect for small FPS style levels but non-instanced geometry will always have a huge performance hit if there's a lot of it.
     
    Using static meshes for the road system makes it easy for collision testing to flag "onRoad=True" and the model can use this value to adjust sound and emitter properties. For example, running across sand will sound different to running across a road surface. More dust will be kicked up. Those things are more complicated to do using texture splatting or a giant texture overlay to represent these kinds of features.
     
    Here are some pics of the roadworks.
     



     
    Source
  5. Flexman
    I can't talk about the details much as it's proprietary code. Helicopters have been (inaccurately) described as thousands of moving parts flying in lose formation. Mathematically a helicopter is thousands of interactions flying in loose formation. For Combat-Helo and future simulations we're assembling a modular version of what we call FFD (FreeFlight Dynamics), a library based on definitive engineering texts on how helicopters fly through air. Texts such as Bramwell's Helicopter Dynamics and Wayne's Helicopter Theory are the staple of many an engineer.
     
    FFD is the physics part of HTR, a freely available module for Flight Simulator X. HTR stands for Helicopter Total Realism, conceived and developed over a period of two years by Fred Naar and fine tuned by input from real helicopter pilots.
     
    At the core of FFD library is an ingenious and elegant approach that is easy to expand and simplify. Potentially capable of handling different types of power-plant, flight control systems and rotor configurations without straying from the principles of rotor-dynamics. It has a big future as middle-ware, not being tied to any particular 3D engine and totally independent makes it portable, I can compile this on the Mac. Future versions will handle fixed wing dynamics and possibly other vehicle types.
     
    I'm still on the conversion stage but progress on FFD for Combat-Helo is going smoothly.
     
    In other news, just ordered another 1TB of NAS. every backup is close to 0.3Gb. And a Corsair CPU Watercooler is on it's way to protect my CPU from heat-exhaustion.
     
    Did another job search today, bit pathetic that nobody seems interested in hiring, even for fairly trivial IT support work I don't seem able to get a bite. Can't complain though, the weather is good.
     
    Source
  6. Flexman
    Quite a scrappy day. Installed Microsoft Flight Simulator X and the SDK, there's an interface I want to try and build as a gauge in FSX. I've used the Simconnect API to interface to my own radio panel, now I need to build a gauge to talk to the Simconnect DLL.
     
    I re-worked the avionics menu page using the new vector glyphs, adding some commands to toggle the chat console, about page for version information. The UTIL page sets the FMS channels (Flight Management System or FLCS FLight Control System) in the Helicopter State.
     
     
    FMS_AXIS_PITCH:Int = 1;
    FMS_AXIS_ROLL:Int = 2;
    FMS_AXIS_YAW:Int = 4;
    FMS_AXIS_COLL:Int = 8;
    FMS_AXIS_TRIM:Int = 16;
    FMS_AXIS_ALT:Int = 32;
    FMS_AXIS_HEADING:Int = 64;
    FMS_AXIS_HOVER:Int = 128;
     
     
    These are bitwise settings as we need to be efficient sending helicopter stability settings over the network, seems sensible to use a single byte to do this. There's a lot of data needed to set up a complete helicopter if you're coming in over a network and jump into one ready to take-off. Console states won't be updated that often but when we do, we don't want a bottleneck.
     
    Time to sit back and examine the feature list, clear up where are priorities are and how far away are we from the major milestones. It's important to get this bird ready for some serious flight testing, there's the terrain LOD system to work out as we don't want ugly popping, Raleigh Scattering for the sky dome, additional fog and integrating FFD (FreeFlight dynamics tm) flight model.
     
    We might strip down the FCR a bit, the TSD we'll keep on a par with Longbow 2. There are lots of things it can do for designating fire zones and splitting them into groups which we just don't need for this version of the game. Even considering dropping the MPD cursors as they won't do much except mark areas on the TSD.
     

     

     

    I learned something interesting today, In 1980 Ken Perlin of Perlin Noise fame worked at Magi, the company that worked on Disney's film "TRON". His paper on a function to generate non-random "noise" was publish in 1985 and is often the basis of many shader techniques today. I read this today when looking at how we might introduce more ground detail into surface textures. That's the problem with shader programming, once you start, it's difficult to stop. Good job Dave knows when to stamp on my toes.
     
    Source
  7. Flexman
    Dull day, so lets post about something most normal people find dull. Fuel flow controls. In the Apache D model this is administered on the FUEL MPD page.
     
    Not much to say about it, I'm bored already. It does what it does. Our Apache has two internal ballistically shielded self-sealing fuel tanks. Fuel can be drawn or transferred from one or the other to adjust weight distribution. Activating fuel boost engages the rear tank cross-feed valves as seen here. Fuel transfer between tanks should normally be left to auto unless you feel the need to play with it. HTR flight model should take account of the weight distribution.
     
    Marching antsFuel flow takes about 4 seconds to change, while changing, indicated fuel lines are drawn in high intensity white before returning to green.
     
    The most important button on this page is bottom right [CHECK]. This brings up the a sub version of the page where you set your bingo fuel status if you get an alert reminder in the UFD.
     
    Bingo TimeAward for dullest sim video goes to...."Fuel Crossfeed"..yeah. There it is. It's Friday.
     
     

     
    Source
  8. Flexman
    Thanks to "GrViper", bit of Russian press coverage courtesy of "Game Navigator". I think I like the intro about raining fire and brimestone? I had to have a Russian friend in Siberia read it out to me over Teamspeak after which he asked, "so you're interested in flight simulation then?"

    Work update
    Last night I added the waypoint/navigation system which is rudimentary but has the needed functions for other bits of code to insert them into an aircrafts avionics. It's a linked list with some methods for management and selection. Once the HMD and MFD gets the steering cues for the current waypoint it should make it easier to navigate around our game theater.
    Also I worked on the flight path vector which is a little confusing since it's 'virtualised' in the helmet sight (adopts real world position regardless of your head rotation), but the artifical horizon is not.
    How *I* currently made it work (which is slightly different from how it will finish) is a magnitude of vertical speed and horizontal displacement (sideslip) which is how I think it works in a 2D format for MPDs (the little square screens in the cockpit). For the HMD virtualised mode it's a matter of using angular velocities (HeloBodyOmega) to estimate where the nose is going to be in 3D space and add the pilots view position and rotation.
    Fred put it more simply, offset from nose = angular velocity * coefficient etc. Well the devil is in the detail working out what the etc. is and doing it in the right order.
    Flight path vector - circled
    Nav symbology will be done today. I'd like to thank Toshiba for the Qosmio X300, the most ugly laptop ever made but certainly a powerful machine.
     
    Source
  9. Flexman
    Airbase preview at our SimHQ forum.
     
    Gluing the airfield into place has been an interesting job, using terrain 'visibility' to cut out terrain chunks and fit it into place. Shindand airfield is used for medical and humanitarian flights, it's currently VFR only and no lighting system. We might modernise it a little for our scenario.
     
    Most NATO flights will come and go from here. A node system for AI aircraft to follow the taxiways and tank-off/land will be added.
     
    Multiplayer options starting to appear. The base sat-dish serving as network startup/shutdown. I'm using a red light on the dish to indicate offline and blueish-green to indicate connected status. We're using the tried and tested Raknet library, it's the only one I have experience with and quite reliable.
     
    These screens are from my forest test area and for testing purposes only.
     
    Command tent (that hanging light, I stole from an underground bunker). This is a spacious area where you'll find the mission terminal, chalkboard (scores/stats) and overhead projector display.
     
    Reality check. These command and briefing tents are normally enclosed/air conditioned and inflated. But in homage to older 90s sims we're using this. It's roomy and allows quick access. MMOs typically have overscale interiors/doorways to ease player mobility.
    This week allowed me to finish off the missing elements of the arming procedure. Loading rockets into zones and building the weapons page inventory. I did run into a slight discrepancy. As I allow each pod to be loaded with 3 different kinds of ammo, in the Apache you can only select 5 zones. I was torn between giving more flexibility to the player and keeping it simple or hardwiring 5 zones and cross-linking zones. For now I'm going to let the players have the extra zone and bump the additional level of realism to a post release update.
     
    Source
  10. Flexman
    Quadtree software has released the 3.1 update to Grome.
     
    Grome is a fantastic terrain editor I've been playing with for future enhancements and rolling out a larger terrain systems in the future. If you play flying games and RPGs on consoles chances are you've probably already seen a Grome edited terrain. It's used by nearly every major player in the simulation industry. Incorporating a plug-in system, OpenSceneGraph and now new improved Unity integration.
     
    What's new in 3.1
     
     
     



     
     



    I'm quite keen to see how it works in the up and coming Leadwerks 3(D) engine which is looking to sport threaded streaming of assets. If this could be incorporated alongside the vegetation system it would be perhaps the most powerful and complete 3D engine for less than 1,000 USD.

     
    Source
  11. Flexman
    This is months of painstaking trial-and-error, optimisation and experimentation. I said months ago, "We don't have the resources or time to build a whole city, just a close approximation". Well it's an approximation but it's more than what we anticipated was possible. Given that the old girl Longbow 2 had a small village, a dozen or so muddy cubes, this is 2010 and we can afford to push it a little.
     

    Putting the demo together for Summer Sim 2010 next weekend, the updated map includes Herat city which is not a center for our first campaign map, geographically or strategically as it's close to the north-west corner of the map. But it is a regional feature, the city is the gateway to Iran. One of the campaign scenarios involve a armoured invasion by Iranian forces in an attempt to do something about a deteriorating security situation in which NATO led US forces are caught in the middle and ultimately you decide which way that goes. The city will present a real challenge for pilots, not only is it a maze of structures and narrow streets, there are not many open areas to perform an emergency landing should the need arise.
     




    I don't think we want to build another city like this. Hopefully you'll be able to appreciate the amount of work that's gone into the environment. Flying over the rooftops and sat dishes in the pilot seat with a full HOTAS is a dream come true, I certainly never expected anything like this when we started last September. It has the feel of an old familiar sim mixed with the new and we're not finished yet. AD has done an outstanding job in realising the setting. If there's one criticism I can level, there's not enough of it. I'd happily fly for longer than I perhaps normally would in other sims as the detail is better. There's always something interesting over in the next valley, or a nice low level route to challenge your flying skills.
    We chose from the outset not to put the player in Helmand which is where the worst of the troubles are. It's a question that's been asked, why not?
    It limits what you can do with scenarios and we wanted the Apache to do what it does best, spank heavy armour. Italy is currently the occupying security force in this region which is set to pass on to the US in the near future. Here we get to play out two different kinds of warfare. And what starts as one kind, if you do really badly in one campaign, may step things up and move you into the second. And if that happens you'll be flying over Herat, weapons hot.
     
     

     
    Source
  12. Flexman
    More flight symbology added today. Raining almost non-stop and my cars wiper motor has failed, so wasn't going anywhere.
     

    We added a couple of items that make it possible to do some precise flying.
     

    Velocity Vector Acceleration Cue The Velocity Vector is the blob on the stick that originates from the cross in the centre of the HMD. This is a representation of the direction and speed of your aircraft. Think of these as "top down" views with your aircraft in the middle, forwards movement is up, sideslip left and right. It's scaled so that the top of the HMD (below the heading tape) represents 60 knots. This scale changes depending on the mode but for now I'll stick to the TRANS (transition) which is the most used.
     
     
    Floating around the end of the "stick" is a circle, that's the Acceleration Cue which shows your helicopters acceleration. Generally the blob on the stick will steer towards the Acceleration Cue as you manoeuvre the aircraft.
     
    Using these cues it's possible to perform some precision flying and arrest unintended movement before it becomes a problem. Learning how to read these will improve slow speed manoeuvres approaches and landings.
     
    I also changed the rate of climb indicator to a solid pointer, slip ball is currently being added. And basic waypoints and steering cues will probably be done this weekend. Especially if the weather is still lousy.
     
    Source
  13. Flexman
    HMD = Helmet Mounted Display
     
    Remember when Virtual Reality was going to be the next big thing? Seems odd having to re-create something virtual in a game that is virtual, the modern Apache has evolved a bit since the late 1990s. Being able to display in the pilots 3D monocle (yes that's a joke) a lot of data to the crew about targets hidden behind objects, terrain contours. These 'virtual' items are matched 1:1 with the crews head movement unlike a lot of the symbology that is static.
     
    The first one we're going to look at is the "head-tracker". This is a broken diamond that represent the nose of your aircraft. As you look left you should see the diamond maintain a relative position to the nose of the helicopter. For give my "Novalogic" terrain map.
     


    I had a bugger of a time getting the function to match up to the outside world until I worked out I was missing the aspect ratio of the window (the HUD has a scale factor too in case it's too big or small for your resolution). We're ready to add the waypoint indicators and LOAL/LOBL missile constraint boxes. The flight path indicator is another one, that represents the position of the aircraft in (I think) one second? Have to check my notes on that.
     
    You might see some alerts on the UFD that shouldn't be there, as always it's not final and I know about them.
     
    The cockpit seems slightly offset from the absolute outside world position, now the crew does seem to sit off axis but I'm checking this out. The camera positions are absolute and bang on the X axis zero line of the aircraft and not directly centred on the crew seats. It looks a bit odd otherwise. Looking into that anyway.
     
    Source
  14. Flexman
    Time for another dull dev blog. This time, the exciting world of Hydraulics which I didn't know much about except what I can gather from various books I have laying around.
     
    Hydraulics are a game component as it effects how long you can maintain control in event of damage to your controls or hydraulic lines and it also powers gun turret control. Controls are not direct in modern aircraft, due to the amount of force required to move a large surface area on an aircraft weighing tons, human muscle has been replaced by a system of wires, pipes, pumps and actuators.
     
    Pressure within this system is vital as it translates a pilots control movement into control surface movement, on a helicopter the cyclic (joystick) operates hydraulic servos that move a large ring under the main rotor called the "swashplate". Wikipedia (swashplate)
     
    I digress.
     
    To simulate damage to this system, we need a basic simulation that isn't too complex as it needs to work for all AI helicopters in our main update loop. If the hydraulic pressure drops then control response has to become "mushy", you should feel this if you're flying a damaged bird. Additionally this should give the AI flying as it's virtual control inputs lag potentially inducing poor looking oscillation. More experience AI crew having faster input response times should be able to handle emergency situations better.
     
    From time of loosing pressure, we're going to give you around 20 minutes to land, your mileage will definitely vary. The ACCumulator stores around 3000psi and is a buffer that maintains the pressure of the primary (PRI) and utility (UTIL) system pressure. These two systems, PRI and UTIL are pressurised from the APU and used to start the engines.
     
    This is reflected in the ENG page during startup. Start the APU, watch the pressures (there's a bleed metric for damage to the system and a fluid level as a percentage). As soon as the primary system reaches around 3000psi (there's a bit of fluctuation added for authenticity) you're good for engine start.
     
    I think this is where the LOCK position of the rotor brake gets it's pressure from.
     
    Almost everything in the Apache is automatic here, operation of this system is handled for you with some exceptions. We have a big Emergency Hydraulics button in the cockpit, pictured below. This allows fluid from the accumulator circuit to flow into the utility circuit. After that, you're on your own.
     

     
    The things we have to do just to get three numbers up. Oh, and don't get me started on oil pressure ;-)
     
    Source
  15. Flexman
    My chair's really bad and falling apart. Went looking online, some nice ones that might be good for my back but I saw this one,from Amazon.co.uk oh boy, to bad it doesn't come with Kevlar plates and a cup-holder.
     

    This one is quite nice too...bloody expensive though...

     
    Guess I'll end up with this one...

     
    Source
  16. Flexman
    Most of the IHADSS modes are complete except for a couple of elements in hover and bobup, and the flight-path indicator in TRANS mode.
     
    Also added for Dave's benefit a small map which I'll use later as a background underlay for a tactical situation display (TSD) and easy nav mode.
     
    RichP has supplied an authentic start-up sequence complete with appropriate caution and warning signalling that fits our bird nicely. Once we're done with the arming set-up I'll get back on the cockpit sequencing.
     


    There will be an easy start option but you'll like the complexity of starting your own chopper. Modern helicopters with computers are pretty easy to start though.
     
    A new version of the 3D engine is in the works which has a new improved Octree, vegetation culling and I think lets us do a little more with terrain texture blending. Might lets us squeeze out higher detailed areas.
     
    So there's a lot of stuff being worked on at the same time. Not much time for big blog updates or making new videos. I suspect the next video will be the cockpit startup when it's ready followed by a short test flight



    *edit* I also made some improvements over the past day or so to lift calculations, by no means complete but much better handling during turns. Managed a roll and a loop (unloaded helo, only hit the ground once). Blade stress isn't calculated yet. But you can get sucked out of the sky if you descend too quickly.

     
    Source
  17. Flexman
    HUDs often used in simulators adopt a green hue and use an additive or alpha blend. It can be hard to read them in some conditions and this is something I was thinking about so I tried a few experiments, non of which I like fully.
     
    First: To improving readability of heads up displays by down-sampling the HUD buffer to a smaller buffer (I called the hud_fx_buffer) with a texture filter, a poor-mans blur. Using the resulting 'fuzzy' version to reduce the intensity level of the background image.
     
    Has potential, reduce the resolution of the hud_fx_buffer too much and you get a darkend 'strobe' effect around the symbology which is akin to what you see on video tapes. It think with a Gaussian blur effect and a higher res buffer it might be a winner.
     

    Second experiment, the ubiquitous drop-shadow.
     

    Yuck. Looks like a drop-shadow. It's the same down-sampled hud buffer with a small offset. It works though, can clearly see the symbology against the lighter parts of the horizon without resorting to 'orange' or black.
     
    The hud 'clarity' will remain a user option, off by default.
     
    *update*
     
    One last toy, a twinkly hud glow. This is actually quite pretty in motion and again reminded me of some old HUD tape footage shot in old Jaguar aircraft.
     

    Good for simulating what it's like to have certain eye-conditions. Another one for the cutting-room floor.
     
    Finally, below we have hud glow mk2, a more subtle variation which is just a glow applied, mipmaps help soften out the hud image.
     




     
    Source
  18. Flexman
    Added some fixed internal views for 'quick' look downs and drama shots.
     
    Wiper dash...this has a little vibration.

     
    Pilot displays...

     
    Over shoulder...

     
    Pilot engine controls (startup and lighting)...CP/G similar (not pictured)

     
    Co-pilot target panel (TEDAC)...

     
    I think a 'foot-well' cam will come when we get a pilot model in game so we can see the crew looking around. And I think we could use an ADI/Comms panel view. Feel free to suggest a few more.
     
    Source
  19. Flexman
    No work will be done tomorrow. Just Cause 2 PS3 is released. The acting sucks, the actual game doesn't seem all that hot from the demo either, but the stunt playground aspect is brilliant.
     
    Source
  20. Flexman
    I had a couple of hours with Just Cause 2 which I hesitate to recommend, it a really fun game but you're stuck playing an unlikeable character. Cheesy dialogue abounds and that's no bad thing in games, I scripted plenty of cheese for Longbow Combat Helo. Think about the lines of dialogue from old games you might remember.
     
    The Playstation 3 was needed by the children for Final Fanstasy n so Rico, Scorpio (whatever the slab of MDF you play is called) was parked for the evening.
     
    So back to doing some little things on the project. There's an expectation of standards, a language of gaming to follow. To guide players through the work-flow by implementing cues and guides, can something be too obvious? I think so. I might expect to see the following (see picture below) on an XBOX or PS3 title but not a Combat Sim. Maybe some funky looking icon suggesting "mount".
     



    The advantage of icons over text is that they don't need to be localised. English, French, German, one icon says it all, even if you don't understand apparent meaning the first time, you associate the action with the icon afterwards. So I think we'll go down that route.
     
    So what is the internationally recognised symbol for "Board Helicopter"? Agghh, just stick any old **** in there, people are smart, they'll work it out.
     
    Source
  21. Flexman
    First screen-shot of a quickly put together KBU (keyboard unit). This is a flat 2D image you click on, taken from the texture used in the cockpit. I wanted to see how good/bad it looked since we don't have time to develop a 3D one.
     
     



     
    Clicking on Air Surv will abort current FCR operation
    and switch to an active air scan (air surv mode)
    The keyboard command list is looking horrible if you want full control over this. The shot cut keys work fine however. I made some tweaks to the heading tape symbols and the Air Surveillance Mode has been adjusted according to recent feedback posted. No sweep indicator is displayed (? is that correct) but the radar is still active. And not NTS or targeting is available. This mode is not available if either crew station has FCR as the selected sight. Either crewman selecting FCR or cycling through HMD/TADS/FCR will cancel this mode.
     
    I made attempts to smooth out the logic for simple joystick control so you can hot key from mode to mode.
     
     
     



    FCR Scan and FCR Scan burst will cancel each other out with immediate effect, no waiting for a scan cycle to complete (which is what it did before).
     
    I'll adjust the scale of the FOR box shortly. The dot isn't active yet, will fix that shortly and then I'll correct the cue dots in the HMD,
     
    That will be as much time as I want to spend on the FCR. I think it's not too shabby and does nearly everything it needs to do for now. Completing the command list for the sensors now means I can finish the default control setup for new installations.
     
    For full control on a joystick you need 3 hats minimum.
     

    4 Way Sight Select (HMD, TADS, FCR)
    4 Way FCR Mode Select (GTM, ATM, other to come)
    4 Way FCR Footprint Set (Zoom, Wide, Medium, Narrow)
    There are also keys assigned to FCR Mode Cycle Up/Down to keep the control count down on smaller sticks.
     
    As always if I've got it wrong then please leave some feedback however I'm unlikely to embark on any more major changes for now. Quite pleased with the detail and how it works.

     
    Source
  22. Flexman
    About: This is a short series for the Leadwerks community on the process of creating a simple game using procedural content.
     
    A short while ago I was approached to write a book on terrain generation using dedicated tools for a variety of game engines. There's a lot more to game content than just terrains. Josh's recent blogs on CSG got me thinking about one of my favourite games and had me itching to re-visit the genre.
     
     
     
    This series is an exploration of topics I don't normally exercise but are fun to do. Leadwerks is a fun engine that's ideal for prototyping ideas. So throw out your terrain system, we're going to make a game all about claustrophobia. We're going DOWN into the tunnels to blow stuff up Leadwerks style using a mix of old-school gaming know how and modern day 3D.
     
    Our goal: create a simple six degrees of freedom shooter set in a procedurally generated network of rooms and corridors. You can use this as the basis for a number of different games but as I'm a fan of the old classic shooter "Descent" and it's easy to create a physics controller to fly around in Leadwerks. Also it can be re-worked using Leadwerks3Ds CSG functions when it's available.
     
     
    Procedural Map Generation
     
    Dungeoneering is back in gaming news with Legend of Grimrock, a take on Dungeon Master grid based geometry. Many games are based on grids, they are easy to work with and often form the basis of AI routines. They are also easy to generate geometry for. There have already been numerous articles and blogs on creating such levels, you'll find links at the bottom of this article.
     

    True Story: The Survival horror Amiga game Xenomorph copied the same gridded dungeon mechanics in a blatant rip-off of the Alien universe where stone walls were replaced by ship corridors. Coded by an ex-Microprose employee I visited his house somewhere in Devon many years ago. He revealed that many of the game objects I clung onto for dear life had no function whatsoever. Lesson learned: Don't explain everything, keep the mystery, it's dishonest but more fun for the player.  
    But before we look at some LUA code to create geometry we'll first have a taster of different techniques used in creating random level geometry. After that we'll kick things up by adding more vertical elements for our demo game. I warn you in advance, I'm not a LUA expert and nor am I a big fan but I'm sure you good folks can make it better and LUA brings the examples to the widest possible audience.
     
     
     
    Node based grid
     
    Our goal is to create a collection of rooms connected by corridors through which we can explore. A simple approach is to seed a random number of nodes (rooms) and connect them up. There are other methods, such as a corridor based approach which adds rooms in a second pass, such a method is used in the classic DOS game HACK (aka NETHACK).
     
    For our examples we'll stick to a 40 x 40 grid to keep it simple. Each grid square could equate 100 world units or 10 in Leadwerks, it doesn't matter as long as we use a consistent scale. We'll stick to 100 units (1 unit = 1 meter) per grid square for this example meaning our potential map is 400x400 units.
     

     
    Here each node represents a room of random size. We can restrict the size of the room to fit within its parent grid to make it easier to deal with problem of overlapping rooms as illustrated in the figure below. Eventually we'll construct the geometry to build these irregular shaped rooms so they merge as a single entity.
     
    You can see that choosing the size of rooms will impact on how much corridor space you're going to end up with per map. This is something you can set in code easily giving control over how open or closed your level will feel.
     

     
    If we stick to the grid arrangement connecting them by corridors becomes an easy process. The difficult part is constructing the vertices and triangles to fit together nicely but we'll get to that. By far the easiest way of joining rooms together is by joining them at the cardinal points of the room. While this makes logic easy it also makes for a pretty boring layout. What's more, there's no reason why a corridor has to be of fixed width...or height.
     
    A room typically connects to a room in a neighbouring grid using the straightest link possible and we'll dog leg corridors as required. To add some interest we'll create a 'route' through the grid and randomly connect to neighbours.
     
    Again there are many ways you can do this and I encourage you to try your own variations. Our rule-set will have a random chance of connecting to a neighbour if that room. That chance will degrade if that room overlaps and on the number of existing corridor links. Hopefully our final 2D layout will approximate the figure below.
     

     
    Then each room can add its own flavour by adding columns, point lights, props, whatever fits your game.
     
    Once we've got a class to generate the map we can then move on to generating the required geometry (surfaces) so we end up with something looking like...

     
    Things get even more exciting when we'll extend these maps into 3D, with vertically offset rooms and corridors. Eventually we'll have a complete base generated by a single random seed you can fly, shoot, leap, run through with a basic controller.
     
    Once we make the logic for generating rooms 'furniture' props can be parented to the room mesh to take advantage of culling. I'm not going to add much in the way of occlusion, instead Leadwerks can take the stain and should do a good job with no effort on our part.
     
    In part 2 we'll start with some code to generate the above with geometry directly in the Leadwerks editor and we'll be using Vertex and Surface commands to create rooms which look like the screen-shot below.

     
    Random room generation in LUA, corridors coming shortly for part 2

     
     
    Everyone is welcome to contribute.
     
     
    External Links
     

    Procedural Content Wiki http://pcg.wikidot.c...geon-generation
    Generating Random Dungeons http://dirkkok.wordp...article-series/
×
×
  • Create New...