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
Subscribe to:
Posts (Atom)