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.
Sunday, 30 May 2010
Saturday, 29 May 2010
Time is an illusion, game-time doubly so.
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.
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.
Labels:
game time
Friday, 28 May 2010
Little update, Chinooks are round.
Spac3Rat sent in a nice new game icon as well as two editions of his Rotorwash magazine from 2006 to read. Fascinating look at building helos for FSX, one thing we learned about FSX models, they don't work too well for our kind of real-time work. But fascinating all the same.
Dave is busy in 3DMAX building something that looks very much like a Chinook. I'm making incremental improvements to the GUI system, panels can now be roughly dragged around without risk of "mouse droppings" (the window/item being dropped off the mouse during aggressive mousing). Buttons and input fields are getting focus and their classes respond to events OK. Running two Combat-Helo instances side by side isn't recommended but doable, solves the logistics problem for network testing until I can persuade my wife to maybe set-up a virtual machine with 3D acceleration like she has on her desktop.
The gui system is linked list of active TGUIPanels (base type) which maintain their own linked list of user controls (TGUIItem), each control having a simple drawing function. They keep track of what's got focus, what's been clicked on and dragged around. It's only going to be used for a few things but it makes it easier to add checklists if needed. And they just make use of a couple of base textures and existing game fonts (of which there are about 5).
The IHADSS or HMD has a problem that has been bugging for some time since the early flight tests and a recent personal message confirmed it. Look over your shoulder and how the hell can you tell which way up you are when the artificial horizon vanishes? So we're going to fix that to work as it should as soon as we can. It's also supposed to be quite low resolution but that would look really ugly when it's constantly in your face, I can't bring myself to reduce it to VGA res.
Dave has learned that Chinooks are round, very round. I learned how to pronounce it correctly (Shin-uk) thanks to my Canadian wife who repeatedly laughed at my attempts.
Finally, Red Dead Redpemtion has been a fantastic game, the open-world and amoral nature of Grand Theft Auto games applied to the old West (USA, 1903 era) fits perfectly. And you get to play a protagonist you can like. Amazing inverse kinematic system meaning character movement seems quite natural compared to traditional baked animations. A world that is just fun to roam around in, a magnificent achievement. I spent an hour in a saloon just playing Blackjack. Which reminds me, I'm out of Whiskey.
Dave is busy in 3DMAX building something that looks very much like a Chinook. I'm making incremental improvements to the GUI system, panels can now be roughly dragged around without risk of "mouse droppings" (the window/item being dropped off the mouse during aggressive mousing). Buttons and input fields are getting focus and their classes respond to events OK. Running two Combat-Helo instances side by side isn't recommended but doable, solves the logistics problem for network testing until I can persuade my wife to maybe set-up a virtual machine with 3D acceleration like she has on her desktop.
The gui system is linked list of active TGUIPanels (base type) which maintain their own linked list of user controls (TGUIItem), each control having a simple drawing function. They keep track of what's got focus, what's been clicked on and dragged around. It's only going to be used for a few things but it makes it easier to add checklists if needed. And they just make use of a couple of base textures and existing game fonts (of which there are about 5).
The IHADSS or HMD has a problem that has been bugging for some time since the early flight tests and a recent personal message confirmed it. Look over your shoulder and how the hell can you tell which way up you are when the artificial horizon vanishes? So we're going to fix that to work as it should as soon as we can. It's also supposed to be quite low resolution but that would look really ugly when it's constantly in your face, I can't bring myself to reduce it to VGA res.
Dave has learned that Chinooks are round, very round. I learned how to pronounce it correctly (Shin-uk) thanks to my Canadian wife who repeatedly laughed at my attempts.
Finally, Red Dead Redpemtion has been a fantastic game, the open-world and amoral nature of Grand Theft Auto games applied to the old West (USA, 1903 era) fits perfectly. And you get to play a protagonist you can like. Amazing inverse kinematic system meaning character movement seems quite natural compared to traditional baked animations. A world that is just fun to roam around in, a magnificent achievement. I spent an hour in a saloon just playing Blackjack. Which reminds me, I'm out of Whiskey.
Wednesday, 26 May 2010
YAG - yet another gui
I wasn't going to add a complete gui system, we don't need anything complex. The address book needs to accept input from mouse and keyboard and when I thought about it, the planned map viewer/editor will require it too.
It had to be a simple gui system with input focus and keyboard entry. Since the chat console had functions for filtering keys and the input mapper directed keyboard input into it when active it was simple enough to change it to send to a gui class and whatever control input had focus.
GUI drawing and input handling is as far as I got this evening. Should be functional by late evening tomorrow. Address book will store entries as XML, not sure if passwords should be stored or not. My professional hat says no, my lazy hat says yes. It's non-critical so it seems reasonable to store the last used password no?
It had to be a simple gui system with input focus and keyboard entry. Since the chat console had functions for filtering keys and the input mapper directed keyboard input into it when active it was simple enough to change it to send to a gui class and whatever control input had focus.
GUI drawing and input handling is as far as I got this evening. Should be functional by late evening tomorrow. Address book will store entries as XML, not sure if passwords should be stored or not. My professional hat says no, my lazy hat says yes. It's non-critical so it seems reasonable to store the last used password no?
Tuesday, 25 May 2010
Splash one load screen
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.
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.
Monday, 24 May 2010
Monday update
Today was spent working on reliable user interface for network client/server connections. There are lots of possible states, more so that other game elements. At the least it became apparent I need to add some additional items to the top of the screen:
These to sit alongside the current game mode, camera mode and have a suitable background image.
Testing is proving difficult logistically. I would like a fairly inexpensive second PC with small form factor capable of running the Leadwerks engine at a reasonable speed. Something that can sit on top of/or next to my main PC.
Password protection seems to work with servers rejecting connections appropriately.
Facebook
I'm told everyone and their app has a Facebook page so here is the Combat-Helo Facebook entry. There is something of a virtual Apache walk-around with an internal one coming later, a collection of screen-shots in the galleries so you don't have to hunt around for them.
- Current world time
- Mission Time (as offset of world time)
- Connection status indicators (connecting/connected/ping status)
These to sit alongside the current game mode, camera mode and have a suitable background image.
Testing is proving difficult logistically. I would like a fairly inexpensive second PC with small form factor capable of running the Leadwerks engine at a reasonable speed. Something that can sit on top of/or next to my main PC.
Password protection seems to work with servers rejecting connections appropriately.
I'm told everyone and their app has a Facebook page so here is the Combat-Helo Facebook entry. There is something of a virtual Apache walk-around with an internal one coming later, a collection of screen-shots in the galleries so you don't have to hunt around for them.
Labels:
facebook,
Networking
Sunday, 23 May 2010
Low poly infantry en mass
We finally sourced a a reasonably good infantry soldier, low poly model, rigged, animated and exported. We can fill the screen with dozens of these guys, falling, shooting prone, grenade tossing. We'll give them a couple of weapons they can swap between and a range of helmets swapped in by setting an entity key.
To initially test animation sequences I populated a drop-down control for the editor dialog with the following LUA, chopped up for readability. But lets you pick which frames to loop by name (or number). This is quite compact for AI troops which need to be lightweight in processing terms, this means non-use of character controllers.
class.anim = {
{"Idle",0,49},
{"Stand and Fire",50,89},
{"Running",90,111},
{"Walking",112,147},
{"Grenade Throw",148,187},
{"Take Cover",188,213},
{"Stand to Squat",214,241},
{"Fire from Squat",242,291},
{"Squat to Stand",292,313},
{"Go Prone",314,359},
{"Fire from Prone",360,379},
{"Stand Up",380,425},
{"Death Forwards",426,532},
{"Death Backwards",533,568},
{"Jump",569,614}
}
function class:InitDialog(grid)
local choices = ""
local total = table.getn(class.anim)
for i=1,total do
choices = choices .. class.anim[i][1]
if (i < total) then
choices = choices ..","
end
end
self.super:InitDialog(grid)
group=grid:AddGroup("Animation")
group:AddProperty("sequence",PROPERTY_CHOICE, choices , "Animation")
group:Expand(1)
end
function object:SetKey(key,value)
if key=="sequence" then
object.framestart = class.anim[value+1][2]
object.frameend = class.anim[value+1][3]
end
return self.super:SetKey(key,value)
end
To initially test animation sequences I populated a drop-down control for the editor dialog with the following LUA, chopped up for readability. But lets you pick which frames to loop by name (or number). This is quite compact for AI troops which need to be lightweight in processing terms, this means non-use of character controllers.
class.anim = {
{"Idle",0,49},
{"Stand and Fire",50,89},
{"Running",90,111},
{"Walking",112,147},
{"Grenade Throw",148,187},
{"Take Cover",188,213},
{"Stand to Squat",214,241},
{"Fire from Squat",242,291},
{"Squat to Stand",292,313},
{"Go Prone",314,359},
{"Fire from Prone",360,379},
{"Stand Up",380,425},
{"Death Forwards",426,532},
{"Death Backwards",533,568},
{"Jump",569,614}
}
function class:InitDialog(grid)
local choices = ""
local total = table.getn(class.anim)
for i=1,total do
choices = choices .. class.anim[i][1]
if (i < total) then
choices = choices ..","
end
end
self.super:InitDialog(grid)
group=grid:AddGroup("Animation")
group:AddProperty("sequence",PROPERTY_CHOICE, choices , "Animation")
group:Expand(1)
end
function object:SetKey(key,value)
if key=="sequence" then
object.framestart = class.anim[value+1][2]
object.frameend = class.anim[value+1][3]
end
return self.super:SetKey(key,value)
end
Thursday, 20 May 2010
Building a city, Herat
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.
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.
Wednesday, 19 May 2010
Multi-player address book
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.
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.
Tuesday, 18 May 2010
Middle East city block
Dexsoft's Middle East City pack has been tweaked by the Dave-9000 supercomputer and has produced a low poly high density city block of 1038 polys. Requiring heavy edits of UV co-ordinates and placing all the textures onto a single surface for blinding performance.
Perfect for iPhone and as a building block of the high-density city of Herat.
Perfect for iPhone and as a building block of the high-density city of Herat.
Monday, 17 May 2010
Comms console
Today I added the ubiquitous chat console complete with 4 colour coded channel presets, Global, Side, Group, Vehicle. Complete with command parsing (/setkey lets you send keys to any object you're standing before which is handy). The console also has a command history using the UP/DOWN cursor keys.
Chat entry toggled by hitting the ENTER key ala Warcraft. Be aware that the primary action key has moved from the ENTER key to the "P" key (P for primary and also handily close to the square brackets used for menu navigation.
Clipboard paste is supported via..
Extern "Win32"
{
Function OpenClipboard(hwnd%)
Function CloseClipboard()
Function GetClipboardData:Byte Ptr(Format:Int)
}
if(OpenClipboard(0)) String.FromCString(GetClipboardData(1));
Console text entry mode also disables all input mapper KEY_DEVICE inputs to avoid conflict. It was important to Flush the keybuffer on exit otherwise all those spaces translated into SUPER JUMPS after entering text. Besides, you should always flush before you leave.
Network comms chat is working fine except an occasional (Not Responding) display "freeze" only when the server was active. I thought was a problem with my Raknet interface but logs show packets still being processed by the game. The problem seems related to not wearing the TrackIR pro-clip device when the network is active. As soon as I put on the head tracker device the display responded normally as if nothing had happened, even chat catches up. Most odd as I've not experienced this with TrackIR before.
Commands for server control are working including IP ban/unban. I do need to harden the user interface for network connections, the menus need to change to show the connection is already active and offer a disconnect. And the client needs a suitable connect-time period before giving up and allowing a re-try. We will begin NAT testing when I've got that sorted.
Last night I made a DLL into which I was able to pass a structure containing flight data. It did nothing beyond reading it back but will be handy for exporting game data to third party programs.
My TrackClip Pro has fallen apart. Only glue is holding it together.
Saturday, 15 May 2010
GEOWEPS - Gratuitous end-of-week post of screen-shots
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.
I think the helipads will benefit from being 'baked' into the rest of the taxiway geometry to prevent problems with taxiing. This is the general layout of arming and take-off areas.
They need to be big enough to comfortably take a Chinook.
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.
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.
I think the helipads will benefit from being 'baked' into the rest of the taxiway geometry to prevent problems with taxiing. This is the general layout of arming and take-off areas.
They need to be big enough to comfortably take a Chinook.
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.
Friday, 14 May 2010
Upgrade 2.32 - let the fun begin
My wife reminds me that it takes typically two weeks after each engine upgrade to get things working as intended.
There's the odd "caps sensitive" issue in some of the LUA source. And a quick change of fw.Main to fw.main in Renderer to get ll the helo/sky scripts working. Rebuilding the lua-gluefunctions and making sure not residue from the previous version was causing problems.
All that's left is handling changes of appearance and shaders....and re-serialising all of the 3D work.
Performance is fantastic almost doubling frame-rates in our vegetation heavy scenes. The vegetation rewrite has been well worth the effort, with collisions and lighting changes. More varied lighting does a lot to reduce the uniform appearance at range. At least I hope the lighting variations are intentional and not some shader problem. The evening skies came out purple in the new version for some reason, now I really like this colour. It reminded me right away of the Longbow 2 opening movie. Nailed the colour palette.
The downside is the need to re-export all the 3D work. The cockpit simply doesn't work anymore except for a couple of buttons. Interestingly the weapon arming only 50% works too, that uses linepicks also. And the upfront controller material has a normal map smeared over it. I'll have to look at the materials for these, make sure it's not using one.
And the occlusion culling is a little problematic. Half of the cockpit vanishes at certain angles and the helipad and radio towers vanish, and when they do other objects tend to go with them. Those are typically large objects, the helipad is often positioned so it intersects the terrain. It's all very strange and interesting doing these updates :)
I'm hoping a lot of problems are just down to the need to fix up the 3D assets. Some behaviours have changed, Coronas, I used as hazard lights are so dim they are hard to see. Also the sun as represented by a Corona, now seems to have been flung from the heavens and lets you 'walk' around it. But is still rendered in the background world.
In the mean-time while I go through those assets I'll continue work on the current 'stable' build. I've added config options to set the server and port address with an 'auto join' flag to start the client mode after game load. The 'radar' dish (pictured above) is another interactive object that gives access to multiplayer options. Start Server / Client Connect and an as yet unimplemented address-book.
I'd like to thank AndyGFX for his posts on migration issues past and present that helped enormously, and also Macklebee, Red Ocktober and others that have also been posting their issues and solutions.
There's the odd "caps sensitive" issue in some of the LUA source. And a quick change of fw.Main to fw.main in Renderer to get ll the helo/sky scripts working. Rebuilding the lua-gluefunctions and making sure not residue from the previous version was causing problems.
All that's left is handling changes of appearance and shaders....and re-serialising all of the 3D work.
Performance is fantastic almost doubling frame-rates in our vegetation heavy scenes. The vegetation rewrite has been well worth the effort, with collisions and lighting changes. More varied lighting does a lot to reduce the uniform appearance at range. At least I hope the lighting variations are intentional and not some shader problem. The evening skies came out purple in the new version for some reason, now I really like this colour. It reminded me right away of the Longbow 2 opening movie. Nailed the colour palette.
The downside is the need to re-export all the 3D work. The cockpit simply doesn't work anymore except for a couple of buttons. Interestingly the weapon arming only 50% works too, that uses linepicks also. And the upfront controller material has a normal map smeared over it. I'll have to look at the materials for these, make sure it's not using one.
And the occlusion culling is a little problematic. Half of the cockpit vanishes at certain angles and the helipad and radio towers vanish, and when they do other objects tend to go with them. Those are typically large objects, the helipad is often positioned so it intersects the terrain. It's all very strange and interesting doing these updates :)
I'm hoping a lot of problems are just down to the need to fix up the 3D assets. Some behaviours have changed, Coronas, I used as hazard lights are so dim they are hard to see. Also the sun as represented by a Corona, now seems to have been flung from the heavens and lets you 'walk' around it. But is still rendered in the background world.
In the mean-time while I go through those assets I'll continue work on the current 'stable' build. I've added config options to set the server and port address with an 'auto join' flag to start the client mode after game load. The 'radar' dish (pictured above) is another interactive object that gives access to multiplayer options. Start Server / Client Connect and an as yet unimplemented address-book.
I'd like to thank AndyGFX for his posts on migration issues past and present that helped enormously, and also Macklebee, Red Ocktober and others that have also been posting their issues and solutions.
Thursday, 13 May 2010
Tricubic Studios Ltd.
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.
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.
Monday, 10 May 2010
Environment, weather, day cycles, iPhones, everything.
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.
Thursday, 6 May 2010
Building bridges and instrument lights
Dave sent me his first bridge work for crossing the Death Star(tm) 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.
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.
The bridge is based on this one.
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.
Monday, 3 May 2010
Multi-Page Displays - WEP Gun Submode *update*
All actions relating to the AH64D go though a message receiver. Player mount, dismount, ground crew arming, lights, AI commanding and (getting to the point) virtual cockpit interactions.
The MPD button naming convention of "MPD_1_17" refering to MPD 1 (pilot left) and key 17 (counting from top left) that gets sent to the input handler for that MPD.
Key messages can originate from the client or network. I had to add a source ID to account for situations where one person in the same vehicle has authority over some function.
The keys and knobs are all working well, interacting with the avionics. I've removed some of the more obscure items and checking authenticity of some elements. Had to simplify a few things just because it's not intuitive. CTRL-G (default mapping) will switch to guns. ALT-G cycles gun round burst mode between 10, 20, 50, 100 and full. Burst is the number of chain gun rounds fired with each trigger pull.
*edit* I made some changes, MODE has now reverted to ACQ (acquisition) as MODE is used for switching AGM launch modes between LOAL and LOBL.
ACQ is the method of gun tracking. It cycles between
This is a fairly important mode distinction, particually in co-op play as the pilot controls gun/rockets and the the co-pilot/gunner operates TADS and other weapons such as the AGMs (air to ground missiles).
This I think neatly simplifies operation and easy to understand. For most situations you will want to leave it in TADS mode so you can quickly deploy cannon or AGMs against ground targets.
MAN RNG adjusts the ballistics trajectory. Cycles between fixed ranges given in meters. It's there for completeness without adding complexity. It's a candidate for removal.
Night Lighting
As I was pondering what to do next (never a shortage of things) I added the pointligts to the cockpit for the night lighting. The instrument panel could benefit maybe from a specular map here, so the pit lighting picks out highlights. But that might be going a bit too far.
The MPD button naming convention of "MPD_1_17" refering to MPD 1 (pilot left) and key 17 (counting from top left) that gets sent to the input handler for that MPD.
Key messages can originate from the client or network. I had to add a source ID to account for situations where one person in the same vehicle has authority over some function.
The keys and knobs are all working well, interacting with the avionics. I've removed some of the more obscure items and checking authenticity of some elements. Had to simplify a few things just because it's not intuitive. CTRL-G (default mapping) will switch to guns. ALT-G cycles gun round burst mode between 10, 20, 50, 100 and full. Burst is the number of chain gun rounds fired with each trigger pull.
*edit* I made some changes, MODE has now reverted to ACQ (acquisition) as MODE is used for switching AGM launch modes between LOAL and LOBL.
ACQ is the method of gun tracking. It cycles between
- HMD (helmet mounted display, this is TrackIR or mouselook, where you are looking)
- FXD is fixed forward
- TADS is the current TADS position.
This is a fairly important mode distinction, particually in co-op play as the pilot controls gun/rockets and the the co-pilot/gunner operates TADS and other weapons such as the AGMs (air to ground missiles).
This I think neatly simplifies operation and easy to understand. For most situations you will want to leave it in TADS mode so you can quickly deploy cannon or AGMs against ground targets.
MAN RNG adjusts the ballistics trajectory. Cycles between fixed ranges given in meters. It's there for completeness without adding complexity. It's a candidate for removal.
Night Lighting
As I was pondering what to do next (never a shortage of things) I added the pointligts to the cockpit for the night lighting. The instrument panel could benefit maybe from a specular map here, so the pit lighting picks out highlights. But that might be going a bit too far.
Saturday, 1 May 2010
What we've been up to this week
It's the weekend and a round-up of goings on here at Camp Zero of the Combat-Helo indie group.
Elements we've been working on over the past few weeks are converging. The first helicopter for Combat-Helo (that's the Apache Longbow if you haven't spotted it by now *wink*) is coming alive. Systems are now beginning to interact, virtual cockpit control, avionics, external state sources, little improvements here and there. Dave added prima-cord around the canopy glass which is a different look to the 'shades' she's been wearing for the last few weeks. See pic. If you have the Playstation 3 Apache theme it's pretty obvious from the stills; if you have a Playstation 3 you should get this theme, amazing photography and lighting.
Behind the scenes we've started planning some some iPhone programs, my role is more supervision than active development. We have some interesting ideas that are worth exploring, to aim is to leverage assets and untapped skills to being in a little income and gain experience in new platforms. Also it gives me a chance to work on some of the cross platform stuff for the Mac.
We've also been looking at some exciting plug-in flight model technology for the real-hardcore crowd. I'm very excited by this and hope we can move this along as soon as we can, just a matter of finding a good time to work on it.
And finally some interesting software technology came to my attention courtesy of Drew Benton's Blog in turn inspired by a Gamedev article on real time application analysis. This is using a web browser to query your game or application as it's running, and it does this by embedding a small web server that you program to respond to queries. Even supplying the current frame buffer as a web image. This means it would be possible to record games in progress, pull out campaign information and do performance analysis; as easy as using http://locahost:blahblah in a web browser. Drew's demonstration was simple but opens the way for some interesting applications. It will certainly make it easier for me to debug and tweak the campaign module.
Looking to the long term future I had a chance to look at Unigine a cutting edge cross-platform engine and assess it's suitability for "bigger" games. It's certainly impressive.
On the whole we managed to pack a lot in this week and I'm still hammering out fixes, updates and new stuff to the game. For example the PNVS pie tracks the pilots head position.That's going to look pretty cool with AI wingmen looking around.
Till later.
Elements we've been working on over the past few weeks are converging. The first helicopter for Combat-Helo (that's the Apache Longbow if you haven't spotted it by now *wink*) is coming alive. Systems are now beginning to interact, virtual cockpit control, avionics, external state sources, little improvements here and there. Dave added prima-cord around the canopy glass which is a different look to the 'shades' she's been wearing for the last few weeks. See pic. If you have the Playstation 3 Apache theme it's pretty obvious from the stills; if you have a Playstation 3 you should get this theme, amazing photography and lighting.
Behind the scenes we've started planning some some iPhone programs, my role is more supervision than active development. We have some interesting ideas that are worth exploring, to aim is to leverage assets and untapped skills to being in a little income and gain experience in new platforms. Also it gives me a chance to work on some of the cross platform stuff for the Mac.
We've also been looking at some exciting plug-in flight model technology for the real-hardcore crowd. I'm very excited by this and hope we can move this along as soon as we can, just a matter of finding a good time to work on it.
And finally some interesting software technology came to my attention courtesy of Drew Benton's Blog in turn inspired by a Gamedev article on real time application analysis. This is using a web browser to query your game or application as it's running, and it does this by embedding a small web server that you program to respond to queries. Even supplying the current frame buffer as a web image. This means it would be possible to record games in progress, pull out campaign information and do performance analysis; as easy as using http://locahost:blahblah in a web browser. Drew's demonstration was simple but opens the way for some interesting applications. It will certainly make it easier for me to debug and tweak the campaign module.
Looking to the long term future I had a chance to look at Unigine a cutting edge cross-platform engine and assess it's suitability for "bigger" games. It's certainly impressive.
On the whole we managed to pack a lot in this week and I'm still hammering out fixes, updates and new stuff to the game. For example the PNVS pie tracks the pilots head position.That's going to look pretty cool with AI wingmen looking around.
Till later.
Subscribe to:
Posts (Atom)