Jump to content
Ultra Engine Community

Flexman

Members
 View Profile  See their activity

  • Posts

    916

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Flexman

  1. Flexman
    About: This is a short series for the Leadwerks community on the process of creating a simple game using procedural content.
     
    This week we implement the map creation process discussed in part 02 then add the mesh generation and a controller to fly around our level. Then we'll have the first iteration of our procedurally generated map.
     
    Part 01
    Part 02
     
     
     
    Starting with the Map class.
     
    Map:Create Function...first iteration, no corridors.
     
    Simple nested for-loop to generate a room for each cell. Each room is stored in the table Map.Room[] with dimensions, a counter for reference and a cell offset in world units.
     
    For our example a cell is a virtual 40x40 space, our example map is made of 4 x 4 cells.
     
    We call the function like this...

    Map:Create (407, 4 , 4 , 40 )
     
    And our function definition is...
     

    function Map:Create( seed , xsize , ysize , cellscale , roomscale ) self.xsize = xsize self.ysize = ysize self.seed = seed self.roomscale = roomscale math.randomseed( seed ) if roomscale == nil then roomscale = 1.0 end Map.roomscale = roomscale if cellscale == nil then cellscale = 40.0 end Map.cellscale = cellscale Map.roomheight = 2.0 Print("Creating map, dimensions " .. xsize .. " x " .. ysize) -- table to store our rooms Map.Room = {} -- room counter rcount = 1 for x=1,xsize do for y=1,ysize do if math.random() > 0.2 then self.Room[rcount] = {} local r = self.Room[rcount] r.roomID = rcount r.cellx = x r.celly = y r.x = math.random(cellscale) r.y = math.random(cellscale) r.width = math.ceil( math.random(3 , cellscale ) ) r.length = math.ceil( math.random(3 , cellscale ) ) r.info = string.format("id %.2d cellx %.2d celly %.2d x:%.3d y:%.3d w:%d h:%d", r.roomID , r.cellx , r.celly , r.x , r.y , r.width , r.length ) print(r.info) rcount = rcount+1 end end end self:MakeGeometry() end
     
    In the above code to reduce rooms arranged in a solid 'grid' there's a random chance that a cell skips room creation. The cell offset ( r.x and r.y ) serves to add more irregularity to the layout.
     
    Map.roomscale and Map.cellscale: bigger number = bigger space. One scales distance between rooms, the other scales the room mesh.
     
     
    After generating the geometry from such an arrangement we get this...

     
    I've added a head-up display to show an overhead map and annotations to the screenshot to show how the distribution of rooms work. So far so good.
     
    Perhaps worth mentioning the CELLS are ordered top to bottom then left to right. That gives you some idea that the random offset works to radically shift rooms around to avoid being too attached to the grid arrangement.
     

    Info: CELL is a term I use to describe a container in virtual space.  
    Before we generate any geometry for our rooms we have all the data we need to display a map (like the one above). Debug overlays or HUDs are handy during early development and can be migrated to a finished game HUD later. All we need right now is some way to check room volumes and positioning, some info and the players position. Later we can use a second camera to draw a top-down view if required.
     
    Another feature we want in our HUD is some flag to draw it, a position to move it about the screen and a scale so we can fit the map to the whole screen or just squeeze it into a corner. The following code does all this. X and Y is typically used as a screen-coordinate position to draw an element and s is the size in pixels to fit the map into.
     
    If you need to re-size text as well then you need to start rendering these to a buffer but we'll avoid the extra complexity. This is often made easier with OpenGL commands but they are not exposed to Leadwerks LUA scripts (as of 2.5).
     
    Drawing the HUD and overhead map
     

    function DrawHUD() if App.showhud ~= true then return end SetBlend(2) SetColorf(0.1,0.3,0.1,0.3) DrawText("ROOM DATA",22,22) local c = string.format("RoomCount %d", #Map.Room) DrawText(c,22,60) local x = 40 local y = 80 for n,r in pairs(Map.Room) do DrawText( r.info , x , y ) y = y + 16 end x = 400 y = 80 s = 512 sx = s / (Map.cellscale * Map.xsize) sy = s / (Map.cellscale * Map.ysize) DrawText("OVERHEAD MAP",x,y-20) --DrawLine(x,y,x+s,y) DrawLine(x+s,y,x+s,y+s) DrawLine(x+s,y+s,x,y+s) DrawLine(x,y+s,x,y) for n=0,Map.xsize do DrawLine(x + (n*Map.cellscale*sx) , y , x + (n*Map.cellscale*sx) , y + s) end for n=0,Map.ysize do DrawLine(x , y + (n*Map.cellscale*sy) , x + s , y + (n*Map.cellscale*sy)) end -- sorry for the fiddly math here -- its needed to match the map scale with the HUD display scale for n,r in pairs(Map.Room) do local roomx = x + (( r.x + (r.cellx-1)*Map.cellscale) *sx ) local roomy = y + (( r.y + (r.celly-1)*Map.cellscale) *sy ) DrawRect( roomx , roomy , r.width * sx, r.length * sy ) DrawText(string.format("%.2d",r.roomID), roomx + ((r.width*sx)*0.5)-8 , roomy + ((r.length*sx)*0.5)-9 ) end DrawText(string.format("view co-ords x:%d y:%d", camera.position.x , camera.position.z) , 40, GraphicsHeight() - 20 ) -- player marker cross in yellow SetColorf(0.3,0.3,0.1,0.3) DrawText("X", x + (camera.position.x * sx)-4 , y - (camera.position.z * sy) -8 ) SetBlend(0) end
     
    The map size is adjusted by changing "s = 512" to however many pixels across. Objects are scaled and drawn accordingly. Once we start merging rooms this will need some alteration, the overhead camera might be a viable alternative and one we can have some fun with.
     

    randomly flagged tile data, looks like a "BallBlazer" level.
     
     
    Tiles and Geometry
     
    Rather than write up how it works you can look through the code and tinker with it. The next and penultimate part will cover generating corridors and using "tile" data to merge overlapping rooms and add props like doors. You'll see already there are random light sources assigned to each room, random assortments of props such as columns, crates, particles etc. can be done in a similar fashion.
     
     
     
    The Code for this article
     
    I've attached the full code which creates the room data and geometry (sans no corridors and intelligent tile merging - we'll deal with that in part 04).
     
    Don't forget to execute this script using ScriptEditor.exe (or run it with ENGINE.EXE) you will need to make sure the path at the top of START.LUA (MediaDir) points to your Leadwerks SDK location and the default scripts are present (as "required" at the top of the script).
     
    You'll find a few bits of code commented out and older functions I used to create meshes. I've left them in for curiosity (learning and laughter).
     
    Until part 04, have a good weekend.
  2. Flexman
    The art-gnome at Combat-Helo has been playing with bloom and glow shader materials for the cockpit and came up with instrument night lighting. I thought it was a cool use of extra texture stages and materials with Leadwerks engine, it's an easy effect to add. With additional green point lights around the pit it should look pretty close to the real deal.
     


     
    Here's a real shot with night lighting. Panel back-lighting and small point lights.
     

     
    Source
  3. Flexman

    Some more architecture

    By Flexman,

    I think these have been on the SimHQ forums for a couple of days but I've been too busy to post any updates. Here AD has been adding some gardens to the Friday Mosque and adding it to the city.
    To overcome scale/zbuffer issues of having a large scene, AD has buried the the tiled gardens into the terrain, just like the river sections. The gardens sit on a large slab that is quite deep, this also accommodates uneven terrain.

     

     
    No paved road surface currently. While Leadwerks supports roads that are baked into terrain geometry they are not efficient for our large scale map. One of the reasons we're looking to build our own terrain streaming system after Combat-Helo is released. We might be able to squeeze in another texture layer to splat a paved surface in.
     

     

    A high altitude view of the city shows the west side is still waiting to be populated. This was the area most damaged during a previous regional conflict.
     
    Source
  4. Flexman
    Particle engines are commonly used for fire and smoke effects adding a lot of eye-candy for little effort. Every frame an emitter creates a number of billboard sprites along a vector. Normally this is not an issue when movement along this vector between frames is quite small.
     
    But what if you're talking about something that moves really fast between frames? Such as a rocket launcher or space-ship? Fellow Brit and indy developer Cliff Harris of Gratuitous Space Battles fame ran into the same problem. Here's a screenshot from his blog of a rocket.
     

     
    The rocket moves too far between frames to space out the particles in a pleasing manner. By adding a line of particles between each frame update a more pleasing effect is achieved.
     

     
     
    In Combat-Helo the hero-ship is typically loaded with several 70mm rockets that accelerate to 700 meters per second in approx 1.5 seconds. Even maintaining a short smoke trail of 10 meters can't be maintained as the rocket distance between two frames might be 50 meters or more.
     
    A linked list of billboards (TMesh CreatePlane()) is being trialled. UsingMacklebees billboard shader tweak and changing...

    ... gl_Vertex.x,gl_Vertex.y to ... gl_Vertex.x,gl_Vertex.z
    ...to work for Planes a 2D billboard function was implemented which handled colour and timing properties with a deviation (waver) offsets.
     
    This creates a ribbon of 50-150 quads (TPlanes) aligned to the camera using the billboard shader. Scale of each quad is roughly double the space between them to ensure some overlap and consistency. The smoke texture has baked lighting with a normal map however a normal map is redundant since the quad is camera aligned and rendered in the transparency layer.
     
    The spacing produces a good fill between two positions each frame. In the example image below the length of the trail is 75 meters, each particle doesn't require much updating since this was written for a specific purpose. As the shader takes care of orientation only timer tests, waver and alpha-colour needs updating although some extra instruction for management could be implemented (see footnote).
     
    Don't attempt to use ScaleMesh() as that slows the whole pipeline down. If you need to change the size of a particle you'll either have to do it in the shader or delete the particle and replace it with a larger one.
     

     
    Same again showing the AABB of each TMesh/Plane.
     

     
    That's about as fast I can can come up with using LE commands. The next stage is to replace the TPlane billboards with a single entity built using a TMesh and adding triangles as needed.
     
    Other optimisations might include changing the number of particles depending on the 2D length between the head and tail. We need more 'filler' if seen from the side than head on.
     
    Worst case would be a full salvo from 4 pods (each pod carries 9 rockets), in this event the particle manager could limit them. With the Leadwerks emitter function, once created you can't change the number of particles so having this level of control is handy for all manner of effects that need adjustment over time. This is of course slower than the LE particle system.
  5. 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/
  6. Flexman
    Another update of map progress on the SimHQ Combat Helo forums. Showing how the City of Herat as a sprawl of densely packed compounds and commerce is being built. Using blocks of prefabs and arranged on a grid. This is a selection of my favourite.
     

    Meant to be viewed from a low altitude, the prefabs do a good job of keeping the eye busy. Here is half a city already with parks and minarets to add. All built to be frame-rate friendly.
     

    And a mini-game for your base, the "Hello World" of physics engine programming, shooting hoops. Camp Stone has it's very own half-court.
     

     
    Source
  7. Flexman
    Today we looked at a neat little program called SMAK which is a neat little program for generating normal maps for low poly models by using high poly models. It also can bake ambient occlusion shadows onto your diffuse textures.
     
    This is also a feature of 3DMAX so Dave tried a little experiment.
     
    Before, no baked AO
     
    After, with baked AO
    You might want to click on those images to see the full sized renders. Certainly the cockpit area could benefit, and the buildings we have with ground proximity shading for compounds and city blocks. Best of all, no fps impact. There's still work to do to improve normal maps.
     
    We started an audit of game textures and will extend this to include QA for each texture layer, ensuring it's as good as we can make it and optimise memory usage into the bargain.
     
    There are subtle things, such as the DXT5 compression that results in acne. Using a different DDS format and reducing the resolution can result in a better image and smaller memory footprint. See pic below.
     

     
    We made some material changes to the cockpit, specular, glow maps. I'm not sure the grips should be backlit but it makes them easier to read in the dark.
     

     
    Source
  8. 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
  9. Flexman
    Finally a video showing the free flight mode we really wanted to show at Summer Sim 2010. Thanks AD for doing an amazing job of making it all look good.
     
     

    http://www.youtube.com/watch?v=Y6ILqIQDaio
     
     
    Sorry about the lack of blade-cam, LUA object reference problem. Will get it sorted.
  10. Flexman
    Another disaster strikes, PC wont boot at all. Strange thing happens on the BIOS screen, the moment any attempt to detect any drives (and I tried a few different drives that I know were fine), a bright underscore character appears under the circled comma (picture above).
     
    So apart from my laptop I'm now without a working PC and no means to fix it atm :/
     
    Source
  11. Flexman
    It's not going to win any awards for realism but we have a rudimentary ENV environment class that handles time-of-day ticking and updating scene elements accordingly. Lighting, colouring, fog, sun position. Currently it's using computed light values which renders lovely post apocalyptic scenes, the colours are terrible IMO, looks like a nuke's gone off. A lookup table will be better and an exercise I'll leave for later. Also I added some data structures for moving weather zones around the map. These are trigger zones for adjusting fog density as you penetrate. To be used for any spot environmental effects we want to add, dust-storms, rain.
     
    Not clear how best to add the gradient data, the old Combat Helo code used a tiny 64x64 bmp. Can't seem to find the graphic I used.
     
    In the remote chance I get to implement "Megaparticles" (looks around for Shader X book) the skies would benefit from 3D looking clouds. Value vs. performance. Helicopters on our battlefield won't be spending much time at altitude and we're not a fighter sim. We can manage some rudimentary clouds but I'd avoid using particles. Fill rate costs are not worth it. Which leaves billboarding and textured planes which are cheap to render.
     
    iPhone development picked up a pace. With access to my big box of assets, Dormouse (lead dev on that project) was showing me how to fly a Sophwith Camel around with nice springy 3D person camera moves and the base skybox I just made for CombatHelo. Nice little exercise to explore what we can do with Unity iPhone. Some rudimentary shaders, OpenGL and javascript. From what I've been seeing, it's not that far removed from LUA scripting in Leadwerks although I find the way Leadwerks interacts with entities more intuitive.
     
    Dave, part man-part frame-buffer, tackled craters and we had the problem of blending them with the terrain, especially when we have massive z-buffer artifacts with co-planer polys near the outer-regions of the map. Leadwerks nice built-in library of shaders proivded the answer. Using a terrain hugging vertex shader, the crater morphs to fit, and the frag shader does a reasonable job of blending in the base texture to the terrain.
     
    And we have a new concrete bridge for Herat. The region map has been a work in progress for close to three months now. All the compounds, village buildings, structures number approx 502 with the airbase and the city of Herat yet to complete.
     
    It's a massive region on foot, and takes a while to fly across. Navigation is a bit of a problem, I hope to fix that with a pop-up map if I can work out how to blend the different map layers from the terrain buffers to make something readable. Otherwise it's going to have to be another pre-loaded DDS texture with enough resolution to zoom in.
     
    Here's more of my least favourite colour in games. Brown.
     

     
    Source
  12. Flexman
    Updates to the green-zones, incremental improvements to the billboards, painting 'shadow' under vegetation.
    Dev-diary update at SimHQ
     


    It's looking great considering how much detail we can't use. Currently we can't use the 2.32 engine due to lack of LOD distance control, and loading the levels with all the vegetation takes three times as long in the new version due to the extra processing required for veg culling. The detail in our production level map shows little performance difference between versions. Upgrading to a new version of the engine is becoming less attractive from a performance viewpoint. Which seems a bit silly but there you go.
     
    In the background we have started preliminary design work on an all new rendering system, not for Combat-Helo but for a later project (again simulator related). This will incorporating object streaming and allow for very large terrains. This work isn't interfering with Combat-Helo, there will be no unnecessary delays in production.
     
    I'm currently working on aircraft data import, the part that takes a data-file (profile) of an aircraft (helicopter, fixed wing, hot-air balloon etc) and builds an instance of a class that tells it how it flies. Our FFD (Free Flight Dynamics, or Freds Fantastic DLL) class is pretty flexible, a specialist physics engine of it's own.
     
    One of the more interesting features are the virtual helicopter controls. Your control inputs are sent to "virtual controls" which then have any necessary trim by AI/AFCS or other input shaping applied. The virtual cyclic can be set to match throw of your actual joystick, you set the ratio of your joystick to that of a full size 70cm cyclic. So if you're using a 20 cm tall stick, setting the joystick length to a value of 20 will correct the input as if you have a 70cm floor standing cyclic. It uses a non-linear function to still give you 100% cyclic throw (shaped after 20% so you can still apply fine control inputs).
     
    We'll be discussing the Auto Trim feature at a later date. It's so simple most pilots will never know it's there.
     
    Source
  13. Flexman

    Camp....insert name here

    By Flexman,

    AD has been working on a new FOB which will be the "other" main camp you'll be deployed at during the course of the campaign.
     

    It's a triangle arrangement used by some forward operational bases. Here the CH47s are ready to be deployed.
     

     

    And finally..
     

    Don't have a name for the camp yet.
     
    Source
  14. Flexman
    Swimming was one.
     
    Setting up controllers in XPlane is another.
     
    Yes the things you thought were going to take a few days which turned into a week and a bit (you could almost say 'two weeks'). Josh at Leadwerks gave me a leg-up on how to put an MMO style launcher together and I've almost done wrapping up all the security for the necessary database, key code generation, CVS style updates and all the stuff we need to match individual content to clients. We'll make available downloadable content (DLC) such as new maps and the occasional helicopter (the planned CH-47D), not to mention the odd mission pack.
     
    No, this key won't work, it's a fakeSo there was a lot to do to make a simple one shot MMO style launcher. The back-end server stuff had to be built from scratch. The launch .EXE calls home, applies on-demand updates and preps game settings for launch. For simple security sakes I layered server-side scripts for handling the updates, admin and audit. Auditing is handled by triggers, SQL injection is futile since only one procedure is exposed to clients.
     
    Any DBA will tell you Auditing is an important part of any security. If you build any kind of database exposed to the internet and you don't build your own layer on top of any default transaction logging then you're kind of asking for trouble. The database engine used here is not known for keeping detailed logs so it was necessary to build one anyway. Things you might want to think about if you ever need to create systems like these are making log indexes suitable for frequency analysis (this one method Twitter uses to spot spamming), fake open doors and keys and silent alarms. My favourite trick in the past was a fake database that gives the intruder a high and makes them believe they have walked away with the crown jewels while evidence is collected. That sort of none-sense is not required here, I kept this one functional with a tiny footprint.
     
    The Pilot ID we'll be sending out is the key to your content; install once, play as you like. If you share copies around on your network you can launch 'offline' no worries, no need to be connected to the internet until you want to update. It's nice if you want to buy multiple copies for your network and support the effort put into this project but I'm poor too so I know how it is.
     
    Little bit of script consolidation and testing to do before we let this loose in the real world.

     
    Source
  15. Flexman
    I know it's a little late for Valentines Day. Excessive flapping, bumping and separation is discussed in this priceless US Army video from 1980. If only they had "RotorCam ™". The Apache has a fixed rotor, mast bumping isn't an issue but it's all part of helicopter theory.
     

     
     
    I've been forced to continue hunting for other employment to deal with a mounting debt crisis. As a result work was put on hold the past two weeks (hence the lack of updates). I apologise for letting my post slide, the project really is taking a toll. I've been ordered to get back to Combat-Helo ASAP (taxes and all that business stuff needed to be done too), I'll be updating as well as I can. There's an engine update to finish rolling into the project (I started on that earlier in the week, this fixes a problem with terrain and I hope the EntityUserData and hierarchy problem).
     
    A Twitter follower suggested I post some Gun Cam footage, I had a look at that and found vegetation range/LOD issues in the MTADS camera need dynamic adjusting (not sure what the most efficient method will be yet).
     
    I'll just round this entry off by stating that raising funds in the UK for technical entertainment projects is very difficult if not near impossible. Bank staff/accountants take one look at video of Apache cockpits and give you funny looks like you're some kind of gun nut (that actually happened).
     
    In the meantime, enjoy the technical detail of the above video.
  16. Flexman
    Quick update. Busy working on a lot of small things. We have a cockpit update coming to update MPDs, internal and external night lighting. MPDs taking to the TStores class and working towards having a number of cockpit functions up and ready for the start-up. Dave added the CP/G throttle panel too (which removes the power switch and engine startup).
     
    Experiencing a problem with fps slowdown over time again. Mostly down to repeatedly running combat-helo, stop, edit, re-run. FPS drops to single figures. I'm not seeing main memory leaks and it doesn't effect other games. I'm not clear what is happening, a reboot fixes it.
     
    I wanted to see what the TEDAC would look like later so I was cheeky and borrowed a still from another game as temp background.
     


     
    Source
  17. Flexman
    My Dennis Norden bit. Out-takes from today. Most programmers we have a few wilco tango foxtrot moments from time to time. Here's a few from today. Starting with "How not to render lights to a buffer."
     

    The canopy glass makes for an interesting effect. Next, an interesting effect you REALLY don't want to see....ARRRRGHHHH....
     

    This is me getting a transform wrong. You can almost see the join between the high detail cockpit and the Apache exterior model. Mind the gap? I did fix this by correcting the TForm and resetting the camera back to the origin. Still have the lighting to correct but it's almost ready. The cockpit is rendered after the world, the zbuffer cleared and the pit is drawn at the world origin so zbuffer and floating point error is nil. All games have hacks to make them work, didn't you know?
     
    Speaking of hacks I highly recommend "Game Coding Complete" by Mike McShaffry. Full of funny developer anecdotes and a brief history of Ultima which is fascinating. As well as many best-practice approaches to game programming.
     
     
    Moving on, Dave was back to polishing the textures and models. More AO baking, backfaces, specular tweaks. Here's a selection of views from today. (Leaving out the rude England footy twitter jokes, some of which were priceless).
     
     

     



     
    Source
  18. Flexman
    Formally announcing the foundation of the legal entity Tricubic Studios Ltd. developers of Combat Helo, associated content and iPhone/iPad games / applications.
     
    This doesn't change very much, it grants us a recognised identity for trading, taxation and investment. Plus we get a chance to develop an insipid company website. We plan to have our first mobile platform release ready for the summer. More details on that in a few weeks. Blog updates will continue at this location.
     
    Source
  19. 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
  20. Flexman
    Dave's been busy building the unsung hero of Afghanistan and other operations around the world.
     
    Rolf: Can you tell what it is yet? ;-)
     
    It's a non-flyable but will feature prominently in the game as you'll be tasked to provide armed escort for supply, insertion and extraction missions.
     
    Much time has been spent correcting smoothing errors. Brilliant work. We'll be adding the same functionality to the rotors and rear door using LUA scripts. This morning we were looking at the various flavours of cockpit, of which there are many. Never the same cockpit twice. I thought the Apache tandem cockpit was complex. The amount of work required to make this a flyable is out of the question right now. It's a level of complexity rivalling the Apache and a candidate for future expansion.
     
    Source
  21. Flexman

    ENG rebuilt

    By Flexman,

    Been pretty ill this last week, progress has been sporadic. I took time out to rebuild the engine code so it's now the same for all Apaches, AI and player alike.
     
    Pilot feedback from screen-shots and videos also allowed me to rebuild the whole engine start-up and ENG display page. Automatically switches to in-flight mode. Things blink, change colour, are boxed appropriately. Couple of bits left to do, the biggest headache was dealing with all the fiddly scale changes and adding new code to simulate power transfer which needs some attention. Here's the page with some values thrown in to show some extremes. The whole thing is worthy of a tutorial video sometime.
     

    Still have some parts to add to the engine simulation, oil, temp. Rotor speed and torque needs values from the new flight model to work properly but essentially it's just polling values from the helicopters state. Oh another thing I didn't put back in, the actual transient timers, these are counters that show how long you're flying outside of normal parameters which can shorten component life or lead to failure.
     
    The new alert system which I also had to overhaul is ready to drop the betty samples in en-mass.
     
    Will tidy this up tomorrow, look at where we are with the new flight model and see about the Leadwerks 2.40 engine upgrade. The PHY situation is not bad as I thought since we're not using LE for vehicle physics.
     
    Source
  22. Flexman
    Spent a lot of time today house cleaning. No not code, literally the house. It's amazing what teenagers can do to your treasured Monty Python DVD collection, it's not funny. Stop that, it's silly.
     
    I over-complicated the map drawing and stripped it down. Added functionality to the TSD page for controlling the map scale. I'm happy that it will work with 3rd party maps too. Oh I just noticed in the screen shots the scale index is off by one.
     

    The green colour is from the low elevation range but I blend some of the terrain colour too which I should perhaps leave out since it gives a false impression. I'll add a button on the page to cycle map modes rather than have to go through a sub page perhaps. Otherwise it might get (more?) confusing. Hey, Longbow 2 had one button to cycle through NAV/ATK and BOTH....and no map unless you flew the Kiowa (I think).
     

    So tonight I'll add the aircraft datum (the helo symbol on the map focal or point of rotation) and begin adding the glyphs for the waypoints and other symbols that we want to appear on the map. Should finish adding the waypoint data while I'm at it (ETA etc). I can't work out endurance time yet as the fuel data isn't yet present. It varies with payload and altitude, there's a table in the A model dash-10.
     
    Would like to have an elegant algorithm to approximate it.
     
    Source
  23. Flexman
    Dave sent me his first bridge work for crossing the Death Star trench across our terrain.
     
    Pictured below is an editor scene showing it in place with some of our other 3D assets rolling across it.
     
    Five brickwork textures were used to break up the surface detail with colour matching used to make it blend with the terrain textures.
     

     
    Last night I finished playing around with the cockpit night lighting thanks to Bushmaster and his reference photos and nudging to fix the colours. Three rotary controls by the pilots left side control levels of the panel lights, dome light and backlighting. Having an little issue with the backlighting levels as I'm setting the levels by sending a uniform float to adjust levels of the glow shader, with mixed results, I'm doing something wrong.
     

    Have some details on the MPDs and navigation to sort out. The direct-to menu to add on the "M" key, rocket submode and the master arm on/off. I've borrowed some nice bullet code that I plan to adapt to the chain gun when these pages start driving me crazy again.
     
    The next month will have me looking at our iPhone game which is a way of supporting longer term development by using existing 3D assets in a two-minute finger shooter. We've been experimenting with the dev kits just to get a feel for the workflow and HID considerations. Our game is not ambitious, take-it out, play, spank some bad-guys. The platform is capable of a whopping 6k-8k polys with around 30 draw calls per frame, which is a little smaller than the typical 250k-500k poly scenes in Combat-Helo.
     
    Here's a parting shot of the CP/G station with panel lights and backlighting, again with the mock TADS image from another game (image supplied by Gary Wright). Hopefully it won't be too long before we get ours in place.
     

     
    Source
  24. Flexman
    Before I code the address book, what do you think of this arrangement?
     
    I'm trying to keep interface items as simple as possible as I hate coding fiddly bits. But these things are mandatory for modern multi-player games.
     
    Source
  25. Flexman
    Just wanted to report this to the blogosphere. I'm not a Wow player (I have an account but I don't play very often) but my wife friends across several raiding guilds play from time to time.
     
     
    They've all been subjected to hacks. And I think the leak is at Blizzard.
     
     
    Over the past few weeks, everbody we know, including friends of friends have had their accounts hacked. Including mine, which was inactive, but had an "authenticator" (a hardware device that generates a new 6 digit number every minute). I presume when my account (that was inactive as it wasn't used) was hacked, they didn't take anything as I guess they didn't want to pay money to reactivate it. But they did attach one of these authenticators to it. And I'm not the only one.
     
     
    Once again, this morning a friend had his entire account hacked and cleaned out the family guild bank. In the years I've know people who play there's been a slow increase of attempts and successful account hijackings, but just in the last few months that rate is off the scale. I've never know so many, so fast. And there's no commonality in the people I questioned, everyone I've talked to knows someone who has been effected recently.
     
     
    On this scale I can only conclude that Activision Blizzard has someone working in the organisation leaking account details or a client list has been compromised in some way.
     
     
    You only have to check out YouTube about GM hacks to see how bad things are.
     
    So I'd recommend deactivating your wow accounts or use an authenticator until they decide to do something about this.
     
     
     

     
    Source
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...