ArmA II and an Upcoming Tutorial

For those few who haven't got the time to keep an eye on ArmA II, here's a quick update. There's been substantial activity at ArmA2.com with posting of new media over the past two months. It's really worth taking a look at the tech behind the new iteration of the engine and understanding what's coming, I know that I for one will be picking up a new copy as soon as it hits store shelves (I've seen dates ranging from a May release through to late June). Along with ArmA2 we'll see the addition of new technologies graphics wise, hopefully improvements in the terrain area as well, Chernarus (the ArmA 2 campaign terrain) is 225km^2 in size. Also we're apparently going to witness the death of SQS syntax, meaning all scripting must be in SQF, which will apparently have a few changes as well. For those who haven't seen it yet, check out the embedded video below:

Click full-screen to get a better look!

Also for those of you here to learn something, I've got a tutorial on the way that some of you may be interested in, particularly the terrain guys. I will be posting a full how-to step by step guide on the methods to process Topographic maps and include them for use in the VBS2 map screen! I'll also attempt to provide some on-going support to those of you who have a bit of difficulty getting it, or at least putting you in contact with people who can help.

Watch this space!

Jamie.

The Danger of over-enthusiasm for Sim Training

Anything in the following post will largely revolve around an informed response to Pete Morrison's comments as on the VBS2 website here: click. Particularly this comment, "Before long, I am convinced that entire mission rehearsal exercises will be conducted entirely in game-based virtual simulation, prior to deployment"

Simply put, lets not get ahead of ourselves here, if anything research by people much more intelligent than me illustrates the short falls in using a single approach to deliver training. Yes, simulation is a step in the right direction for relating military training to the modern junior soldier who has grown up with his XBOX and PC. Anyone with half a brain should be able to see this is the case, relate the training to the soldier's interests, improve effectiveness of the stimulus and his retention of the key points. I don't need to say this, as it was illustrated in a paper from I/ITSEC that I linked to in a previous post (experiental learning and a blended approach).

The shortfall with purely game-based virtual training and using that solely for pre-deployment is lack of focus on some skills that will keep soldiers alive. Yes we can shoot a pixel at 300m at the WTSS and watch him fall down, and maybe one day it'll be a high definition pixel courtesy of Laser Shot. But unless we're training to fight in an air conditioned building, or purely focused on MOUT during deployment, we're coming up short. The enemy aren't stupid, they do revise their tactics and attempt to exploit weaknesses, if they find we've failed to prepare in the sticks, that's where they'll hit us.

VBS is simply a procedural model and a virtual simulation, depending on the application. It cannot possibly replicate everything involved in an attack, fighting withdrawal or ambush, it would be ok if wars were massively multiplayer battles fought online to "level up" and achieve world wide noteriety for being such an awesome geek. Unfortunately in war, people die, no desktop trainer or shoot house will have a massive effect on that, and as long as that remains a constant, our preparation must be a combination of mental as well as physical.

In addition to this we're fighting resistance in the form of the old-school, post-cold war soldiers who see efficiency in the class room as being more important. To suggest at this stage we'll replace blanks or simunition with ballistics models and also physical models in the virtual environment that they assure us are correct is nothing but a dream. Maybe if we could train with actual SOPs in the desktop environment rather than modified simulation SOPs or even "notionally" performing our task in the team in some cases, we'd have a chance.

Case in point, the M113AS4, I'm not interested in the fact the ADF may not have funded this content, it's an inaccurate representation. The reason I say this simply is, the cargo hatch on top cannot be opened, and diggers can't peek out the top, something we do on a regular basis, some unit SOPs may even dictate that the passengers provide rear security. This isn't exactly an unfair example as it has been proven possible in other physical models in VBS2. Without substantial development and intensive communication between SMEs and the modellers, VBS2 wont go much further than a part-task trainer.

Comments?

Jamie.

A Request

Anyone who may have linked to the GlobalMapper related article from last night or saved content from it, could you please see that relevant information displayed with the links shows this article is no longer available. I can't say when or if it will be made public again, I've had no control over this and apologise for the inconvenience.

Jamie.

Alternative Take on FizzBuzz

This just in, my first reader submission for my blog, courtesy of Ahren from [XDF]. It's his alternative and well refined take on the FizzBuzz solution and a good demonstration that there's more than one way to skin this cat!

_i = 1; // Start at 1

// Assuming initially _x is 1

// repeat until _x is less than or equal to 100

// incrememnt _x by 1 each iteration

// combined this will iterate 100 times.

for [{_x=1},{_x<=100},{_x=_x+1}] do

{

_iThree = (_i/3);

_iFive = (_i/5);

// Uses a switch instead of multiple if statements!

switch (true) do

{

case (((_iThree) == floor(_iThree)) and !((_iFive) == floor(_iFive))):

{

hint "Fizz";

};

case (((_iFive) == floor(_iFive))and !((_iThree) == floor(_iThree))):

{

hint "Buzz";

};

case (((_iThree) == floor(_iThree))and((_iFive) == floor(_iFive))):

{

hint "FizzBuzz";

};

default

{

// Alternative to hint str(_i)

// Additionally you could use format to concatenate (link or add) two strings together

// e.g. hint format ["%1%2",_i," is not a multiple of 3 or 5"];

// if _i == 2 the following would be the hint:

// 2 is not a multiple of 3 or 5

hint format ["%1",_i];

};

};

_i = _i + 1;

sleep 0.5;

};

It should be pretty self explanatory, I thought of this after I posted the original solution and he beat me to implementing it, so we were obviously on the same track. Cheers Azza!

Also, I've added a few comments in to better explain a few things I skipped in the first solution, like a brief explanation on what "for" is, as well as a brief run down on the most common use of the format command with strings.

Jamie.

I/ITSEC and a little bit more.

For those of you who don't know what I/ITSEC is, it's basically a military and industry meeting focusing on improving cooperation with simulation and education projects and it looks like one hell of a show. It involves a lot of exhibits from companies and academia alike on all aspects of modelling and simulation vectored toward a common goal.

In particular I'd like to point out a particular paper and presentation, Games -- Just How Serious Are They?, Roman/Brown (2008). I know I'm a little behind here, I would of liked to have posted on this paper earlier, but I unfortunately didn't have a blog in December last year. I've known how effective serious games could be in teaching all sorts of soldier skills for a very long time, and this paper/presentation to my mind presents undeniably valuable information to support that argument. So here are the links:

Games -- Just How Serious Are They?, Roman/Brown (2008) PDF

Presentation by Mr. Brown at I/ITSEC Flash Video (like YouTube)

If you're interested in finding out more about I/ITSEC you can go to the following link: click

For those of you bookmarking, following or getting RSS feeds from this blog I apologise for the high frequency of updates, however I justify this by being keen to deliver enough content to keep things interesting, all focused on VBS2, as well as modelling and simulation in general.

I'd just like to make others aware of the features of this blog, if you've got an RSS reader you can subscribe to the feed, additionally if you've got a google or other openID related account you can follow the blog. For those of you who have mates who might be interested on various social networking sites you can either use the addthis button (top right) or mention it to your friends directly. If you wish to give me some feedback as well that is more than welcome through the comments feature at the bottom of every post, or if you've got a better method of doing things, feel free to show it off here, I don't claim to have the only solutions to any given problem.

Cheers,

Jamie.

ArmA II and its effect on the future of VBS

Many people out there using VBS2 at this point would be largely aware of one key fact, behind the simulation is a game franchise. A franchise which is looking to take another step with a new iteration. The one the community is calling "the real sequel" to Operation Flashpoint. Armed Assault 2. To get an idea of what's on the way, there's this short summary of features from 505games.

SINGLE PLAYER MODE with emphasis on resource management and RPG elements, the player commands a squad through a story full of twists and surprises
Cooperative MULTIPLAYER and team-based large scale multiplayer over entire map for 50 live players
Built-in MISSION EDITOR allowing player to expand the game beyond original content
Complex weapons SIMULATION based on technologies used in military training and real-world data: ballistics, deflection, material penetration, glowing tracer rounds
AUTONOMOUS AI providing them ability to react dynamically depending on player's action: AI-controlled soldiers and vehicles maneuver, flank, take cover and surprise player in many ways.
AI where squads navigate in REALISTIC FASHION, soldiers can find proper cover with millimeter precision, lean from cover and return fire.
Advanced dynamic CONVERSATION system, integrating preset conversations and dynamic queries about the game environment.
GESTURES and combat communication of units: Soldiers shout and use same communication means as in real combat situations
Comprehensive library of over 60 fully simulated modern FIREARMS
Over 60 playable VEHICLES

Does this mean we can expect a new engine backing the VBS product line very soon? not necessarily. Unfortunately the major limiting factor here is the PC specifications most of the large customers are using. They're either out of date or likely to come up short, they may be able to run standard ArmA II for the most part, however one must consider the scope of VBS2, the addition of addons, numbering approximately 1000. The size of the average VBS2 terrain is also in some cases double the size of Sahrani. And the final factor in play is the expected number of participants in a scenario.

The issue here is we can't expect the current fleet of PCs to carry the weight of ArmA II, with VBS2 content, given the above additions and other planned features. The massive push with customer funded content is fast approaching its limit of exploitation on the current PC spec as it is, with each new minor version and even build we're seeing exponential leaps in capability. The changelog for 1.22 printed straight from notepad was 9 pages, and this was for a point version hop of 1. The next expected release of VBS2 which is scheduled for May/June is 1.3 (Although some elements of the US Army have 1.23).

In addition to the BIA created content, content creators who happen to be external like myself and possibly the major audience of this blog are likely to receive more as well in the tools. The 1.22 tools which we're still waiting on appear to be coming with an Enterprise licensed copy of GlobalMapper, and the long awaited FSM editor. And why are the tools being expanded? quite possibly because the applications of VBS2 are that far ranging, the demands of the end user so great and the control of information so tight, that it takes someone internal to the organisation to develop some things. Although this is a double edged sword as developing internally can edge the organisation closer to its own limit of exploitation with regards to the PC spec.

However with an intelligent approach this should not stop any organisation from taking up the challenge, particularly if the end-user requests a small feature, perhaps alteration to a terrain, creation of a basic model, scripted functionality, etc. Thanks to the tools such things are possible, particularly if the staff are aware of how the system works, or able to access someone who is. The ArmA community being a perfect example, where individuals in their own spare time armed with similar tools and a knowledge of the system have gone out on a mission to alter the functionality inline with their own objective.

Will the same expansion be seen in VBS2? well it's already underway, there is a massive desire among the user organisations to carry out their own improvement tasks, refining the utility of the simulation to match the local user requirements. Everything from controlled IED lanes through to massive combat team scenarios. Regardless of the uses, one thing is quite clear through all this, and that is with the current package and the current engine, VBS2 isn't likely to be going anywhere. As every day passes, every success in VBS2 is only another reason to persist with it and refine it, tirelessly pursuing perfection.

Removed.

Removed.

Getting the party started!

OK, for my first attempt at creating something meaningful for my blog, we're going to take a look at FizzBuzz in SQF, and my first attempt at it, first of all a little background on what FizzBuzz is. Simply put, it's a programming test that you may get on job applications and the like to prove your skills, demonstrating your ability to do simple programming.

FizzBuzz

1. From 1 to 100 output text adhering to the following

• Multiples of 3 echo (or hint in the VBS2/ArmA case) "Fizz"
• Multiples of 5 echo "Buzz"
• Multiples of 3 and 5 echo "FizzBuzz"
• Everything else, just echo the number.

What this demonstration is not, is it's not a perfect implementation or the only implementation, but it might help with understanding some simple concepts in SQF.

Now for the SQF:

// FizzBuzz

// VBS2 Script responding to the FizzBuzz problem

// This is an alternative take, with hints being output instead of print.

// Multiples of 3 = hint "Fizz";

// Multiples of 5 = hint "Buzz";

// Multiples of 3 and 5 = hint "FizzBuzz";

_i = 1; // Start at 1

for [{_x=1},{_x<=100},{_x=_x+1}] do

{

// Start the for loop here

// Divide the number by 3 and 5

_iThree = (_i/3);

_iFive = (_i/5);

// Round the divided numbers down (we can't check for int easily any other way)

_fThree = (floor(_i/3));

_fFive = (floor(_i/5));

// True if _i / (3 OR 5) is equal to the floored value, meaning it's an integer

_condOne = ((_iThree) == (_fThree));

_condTwo = ((_iFive) == (_fFive));

// Determine if we need to hint Fizz, Buzz, FizzBuzz or neither.

if ((_condOne) && !(_condTwo)) then {hint "Fizz";};

if (!(_condOne) && (_condTwo)) then {hint "Buzz";};

if ((_condOne) && (_condTwo)) then {hint "FizzBuzz";};

if (!(_condOne) && !(_condTwo)) then {hint str(_i);};

_i = _i+1;

sleep 0.5;

};

Hopefully this seems pretty simple to begin with, it should be largely self explanatory. If not, let me know and I'll try and cover it better in later posts!

Alternatively rather than using a separate variable _i we could of just used _x inside the for loop as this would normally incremement, however we might want to influence the loop externally, while not apart of the original design requirement, this at least demonstrates some extra utility in the flow.