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

    Internal views

    By 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
  3. Flexman
    AD made some atmospheric screen-shots when playing with lighting and environment settings. SimHQ Diary
    Starting with the only major airbase in the region. AD is responsible for some Strike Fighter mod aircraft models, one of which is a Tornado GR1 (?). Which he's used here. I don't think these will be in the game unless we get permission from the original mod maker to use it. But it does look nice.
     

     
    This is our early version of Camp Stone complete with a half-court basket. You wouldn't have a pair of M1A1s on the doorstep but they do look interesting.
     

    Poster child..."never alone"
     

    We have been hard at work on getting a simple flying demo ready for a public showing, we've had to make it playable and gave me an excuse to put some more time into the mark 1 flight model which is a much simpler easy to fly model for general consumption. This approximates the mass of the helicopter, rotor thrust from engine power and semi coordinated turns. The landing gear desperately needs some joints to make it easier to land but I don't think I'll have time for that.
     
    Following the road north our of Camp Sone you eventually approach Herat, our version is perhaps more idyllic taxi-free version, and perhaps more green to make efficient use of geometry. Enough to fill enough area to represent a small city.
     

    No orange sunset here. Looks much more natural.
     

    Freecam mode lets you move anywhere you want to take snapshots. Contemplating broadcasting a regular call to prayer from the towers at the appropriate local game time.
     

     
    Nice choice of sky. You can see what we had to do to the rivers to prevent a lot of clipping and z-buffer fighting. Hence the "Death Star Trench" name we use.

     
    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

    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
  6. Flexman
    While I'm spending hours pouring over interfacing the flight model, AD has been tinkering with billboards again, finding a blend of shadows. There's still more to do, I want a ground fog layer, multiple layers, realistic light scattering and a more dynamic LOD system which we can't do yet. AD is reducing the tree poly counts from 1,500 to 500 on the LOD1s. This should improve shadow performance a little.
     

    Looking at shadows again, I came across a GameDev.net post that I might look into. It's similar to the shadow system used in Brano's Outerra whole world engine. I'm not sure what it would do to a high bandwidth environment like a 3 monitor wide system. Probably no worse that using HDR or other post-processing effect.
     
    Source
  7. 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
  8. Flexman
    Compounds, the Herat map contains approx 500 of them. Each one consisted of a number of walls and out buildings. Turns out, these sub objects chewed through a bit of processing time. In effect there were 7500 objects getting worked through. That's a lot and it was reflected in the performance in LE 2.31 on a fully dressed map.
     
    By collapsing the compound models into a single object for the lower LODs we saw a large increase in fps in LE 2.31. Although LE 2.32 shows not much difference (it's a better performer anyway) due to it's quad-tree culling system. Even so there lots of fine tuning to do, cockpit switches to be instanced, general code trimming. Entity view ranges, material combining and a dynamic detail function to add.
     
    Today I've been working on fixing the lighting buffer for the cockpit entity but I'm having problems copying the cockpit buffer into the main view buffer. Much strangeness, it's some alpha/blending issue I can't quite get a handle on but I'll get there.
     
    I spent some time looking at Open-flight as a specification for storing lots of scene data. It's not really designed for high efficiency 3D engines. And not surprising that other engines that use it have adopted some conversion process. Initially the idea was sound but on closer inspection it's just plain awful. Maybe I'm missing something in the organisation and construction of individual objects.
     
     
    Here are some random shots from today.
     
    Cockpit interior now moved to it's own world for rendering lighting. Materials are not happy but it's steady as a rock. You can see the GPU terrain mesh with it's 10 meter resolution rendering a DEM of mountains in the NW of Afghanistan.

     
    Not much to say about this. Pre optimisation and post debug slowdown. Not happy at all. It was just this slow on my dev machine. My laptop is much happier.

     
    The saturation and contrast levels adjusted on the "fly" can change the look of the game.
     

    I like heavily saturated games which is probably due to my first colour computer, a Sinclair ZX Spectrum which was a train-crash of colours, all eight of them. I still have one of the later models hanging around my desk (see photo I just took below). This one has an Interface 1 for Microdrives. If you don't know what they were, have a bit of fun and look them up. Strange to think that that kind of technology is still used as a backup system today. In the 80's my first games didn't get very good reviews, we had a laugh looking them up on the internet last week. They would make good mobile games today I think....hey I just found my keys.
     

     
    Source
  9. 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
  10. Flexman

    Command Tent - wip

    By Flexman,

    We're not trying to re-create Armed Assault, or even build some form of Helicopter MMO. Our plan is to take the old school 2D interfaces of military bases and create 3D analogues. Mission assignment and planning is done in the command tent. This is still exploritory, we have a number of office furniture elements planned, some of which we have tried in the editor to get a feel.
     
    There's more furniture to come. A mil-spec laptop/terminal, interactive map on a board (that's a copy of your personal map - will use the same buffer).
     
    And eventually we hope to have various AI pilots sitting in on briefings that you might want to converse with Wing Commander style. Romeo 1 from the intro mission will be hanging around. Along with WO J Petersan and others from time to time.
     
    I don't have much time to decorate, just placing these objects around my test-map to check how they look and function but it should give you an idea.
     
    With a couple of AI guys and a co-op friend there should be enough room to keep it looking busy. It's possible we might make AI crewman choices ala Gunship 2000 available in this manner if it works.
     
    We need some flooring I think. Hexmesh or some other plastic matting.
     
    Using a projected texture for mission briefings on the OHP. Interacting with a screen set 5 meters away is problematic, once at the projector you'll get to interface which will allow you to view available missions and annotated map, with a "close up" option (position a 3rd person cam up close to the screen).
     
    Like with other parts of the game, such as arming, the player interfacing with the projector will have their data shown to everyone else. Allowing you to give briefings. If there's time we might add a laser pointer for mouse control.
     
    We're using a 1024x1024 buffer for the projector which is a material assigned to a special spot_light entity parented to the OHP model. Objects/avatars walking in front of the projector have the image mapped over them in a realistic manner. So you too can act like a right tit in front of the C/O making shadow puppets with your head.
     
     
    Additional objects in the command tent will operate on a private level, mission planning and editing will work on a laptop type screen and a wall map will be copy of your pop-up map. There may also be a Sierra Hotel score board, I think that's required by tradition.
     
    So this the the start of the important ground office in Combat-Helo. We tend to have about three different project elements on the go at any one time, rather like making a series like Star Trek, planning, filming and pre-production.
     
     
    Finally a recent ETADS screen-shot, taking a peek at a sign through the trees some distance away (it's way off to the left out of sight so don't bother trying to spot it). Some folks will be well pleased with the corners. This coming week I'll be working on the event system (delayed due to PC technical problems, see earlier blog posts) and more of the TADS elements.
     

     
    Source
  11. Flexman

    Drivers again

    By Flexman,

    Seem to be having performance issues with the new nVidia drivers 257.21
     
    I noticed the reported OpenGL version has done up from 3.2.0 to 3.3.0
    Repeated launching over an hour will sap the frame rate to around 1, yes one. No apparent memory leakage. But other games are fine. Also the editor will remain unaffected unless importing the Apache model where it will sometimes exhibit a black skin.
     
    So there's some combination of factors I need to understand, the current Apache model with it's recent material updates and animated wipers and the new nVidia drivers.
     
    I wouldn't mind so much except it's keeping me of adding new content right now.
     
    I also spawned an LE 2.32 build to test, which on a small map runs 50% faster, on the full sized Afghan theater it actually runs slower. I'm at the point where I'd like to take a shotgun to my PC. The laptop has almost double the performance of my desktop PC which makes no sense, same build, engine and 257.21 drivers.
     
    *sigh*
     
    Source
  12. 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
  13. 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
  14. Flexman
    Periodically I'll create a debug build to see if any OpenGL errors popup and sure enough one did. Tthe MFD buffer mip-maps are created after rendering the contents with a call to buffer.GetColorBuffer().GenMipMaps()
     
    Not much had changed except some additional meshes, animations, all the specular maps, actually quite a lot of material changes to the interior and exterior this past week. But the debug ran fine after building and running it on the laptop. My desktop wasn't having any of it.
     
    EF2000, EECH Enemy Engaged Comanche Hokum and others, not working right? Please update your drivers. So what did I fail to do on my desktop that I did recently on the laptop (due to installing a Windows 7 upgrade). Yup, update my drivers. And lo, all is now well and good.
     
    The moral is, always heed ones own advice. Check your drivers.
     
    Still a little curious as to what was wrong with mipmaps in those drivers. I wonder how well auto-generation of mipmaps are supported across cards and is there a safer way to test it?
     
    Source
  15. Flexman
    The 3 active IR-LED head-tracker clip was never made of study stuff, constantly falling apart as soon as you put it down on the desk. Now it's finally disintegrated, I might have to resort to super-gluing the tattered remains.
     
     
     
    Microsoft Kinect apparently shoots out hundreds of IR beams in a grid pattern and uses that to build a set of data points from which the software can pull out a skeleton, track body motion. It's a motion capture studio in a box. Brilliant, for indie game production I like the idea of using it for creating motion capture files.
     
    Source
  16. Flexman
    Another "gravy" feature which I wouldn't have spent time on had David (part man, part 3DSMax) hadn't made it so easy. He detached the existing low res wipers from the exterior model and created a single 100 frame animation cycle of both wipers complete with slight wobble. The two blades operate at different speed ratios too.
     

    The cockpit wiper control was set to send it's setting as a key to both the exterior and interior cockpit model. Allowing for dual speed wiper control and a park mode (turn off and wipers return to stop position at end of the next cycle).
     

    The ETADS display had it's round inner bevel reduced and is much more square, you can make that out as the bright green screen in the above image. Also the cockpit instrument normal maps were edited to remove raised lettering and other markings that were out of place.
     
    My project planner has me working on the generic event system (GEST) for the next four days. This is a new dependency for completing the start-up procedure and mob animation.
     
    Source
  17. Flexman

    More Apache work

    By Flexman,

    Our Apache received more love today, the cockpit panel textures suffered a little from DDS compression acne. But by increasing the bits-per-pixel to 24 and using DXT1, we get better quality results using a texture half the size as a larger one using 8bpp compressed. And smaller texture memory footprint too. This only works for some textures.
     
    Additionally specular maps were added to the cockpit, now it reacts to light in a much more dynamic way and the scratched glass blast shield and canopy really adds to the sense of enclosure in a cockpit space.
     
    A few major systems are not currently fitted to our Apache, the TADS (or ETADS) was initially removed due to rendering problems. I've re-instated the TADS class and rewrote the rendering function. It's still quite primitive and there's post0processing to add to the tads_buffer as well as overlaying the symbology. As expected the performance hit is around 20% when drawing at full frame-rate. I'll add a frame-skip value to adjust performance for users. The good news is that it's not worse that I thought it would be plus there's still lots I can do to improve performance.
     
    The ETADS display is using the same Fullbright shader as the other MPDs so it's a little overbright. When I'm done it should look the part.
     
    Over the test-map testing the TADS camera.
     
    Rest of the week might be a little quiet as we're rushing to complete the startup and caution/warning system to go with it (keep getting side-tracked and doing other things). The dual-seat multiplayer mode throws up some interesting logic problems with the messaging system when generated messages don't have a source. It has resulted in front-seat controls sending signals to back-seat controls which in turn trigger front-seat controls and so on. This is why messages have a source ID so remote control messages don't trigger a local message transmission thus continuing the cycle. Yes, all I need is a message filter.
     
    Little update***
     


     
    You have control.
     
    Source
  18. Flexman
    Connection time-out now resets the connection status to "disconnected" Apache canopy glass, lighting issue fixed GUI input controls that receive key-presses still occasionally hogging the keyboard. (fixed) Some speed improvements to OpenGL DrawCurve function.
     
    New GUI style as submitted by Spac3Rat in place. See Facebook image
     
     
    Next week: Back to weapons and more multiplayer functions.
     
    Source
  20. Flexman
    The game world clock is now synced across network clients, time advance and day-night cycles locked. Accuracy is down to round-trip packet times plus a few milliseconds. More than enough to keep entity spawn times and waypoint navigation in close sync.
     
    I'm as yet unsure how often to send clock updates, currently it's every half-second which is quite aggressive, it's easy enough to tweak. Clocks run on client and frame-rate independent so they don't need to be updated often. They just need the occasional time sync from the host or when the host is changing the time-of-day.
     
    Chat channels work well, need to add the player name to the prefix. We have a player profile set in the game config but this carries no player name or any other data as yet.
     
    Almost ready to test that NAT punch-through.
     
    Source
  21. 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
  22. Flexman
    Combat-Helo presents a persistent world, day-time / night-time mission capability where you can stand around your base with your thumb up your rear-end. The game's heartbeat is the day cycle clock from which all missions, AI entity start/stop times, spawn times. All operate as offsets from mission start time. This presents the issue of real-time vs game time.
     
    To offer variety of day/night operations in a real-time game could be tedious. I want to fly a night mission, but it's noon, I can't. If mission clocks are running there's two options, kill the mission and advance time, or interpolate mission outcome as if they proceeded (can you open this can of worms for me please?)
     
    The alternative is to adopt MMO time where game-time has no parity with real-time. 4 hours of real time = a full day-night cycle. In a military game, I don't think so.
     
    So faced with real-time, how do you ensure everyone gets to play some day and night missions within a reasonable time-frame? Time advance, with constraints. No mission clocks can be running. This means everyone will need to be within the base compound with no active missions before a time advance option can be used. I can't think of any other easy way around it.
     
    The time-advance could be applied to your base tent or in the command HQ tent command terminal.
     
    Source
  23. Flexman
    We've been using the black and orange diamond logo for some time, it needed to reflect the game colour palette. As a 90's homage to sims of that era, a saturated colour scheme with the GUI elements using 90'-45' angles, black and orange. Two contrasting colours that are visible against most backgrounds.
     
    It wasn't until after I had designed and coded a number of elements that I noticed other military games using the same colours.
     
    Why bother with stuff like splash screens at this stage?
     
    They set a tone and expectation when showing demos, fix the colours and facilitate feedback on identity early on when things are still fluid. In our case, we have possible issues of copyright and licensing, issues that came about through the process of establishing identity. Matters that are hardly trivial.
     
    Plus the above vignette style works much better on multi-screen monitors when centred than the old one which was stretched. This has better overall presentation. Logo is still in flux but overall colours and shape are there and reflected through the whole game in every interface element.
     
    Source
  24. 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
  25. 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
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...