Editorial - August 2007

Maybe it's the rain, but it would appear that there have been some very active coders in recent months. Again we bring you a collection of commercial projects, including the NASA Lunar Lander simulator, a navigation and guidance control training system for the US Navy, and of course some down-to-earth games titles. We also have Model Pack 8 to unveil, two tutorials, updates on FPSC X10, and some interesting developments on the horizon to report from the user base.

Inside TGC HQ

This month I was more than happy to accept the invitation from Rick Vanner to visit both himself and Lee Bamber to see what TGC are busy with. So after Googling their Wigan-based location in the UK, I made my way to what became a very long and extremely fascinating day in the depths of the development centre that is Lee's office.

Naturally, FPSC X10 is the focal point right now. Having seen the real thing in glorious widescreen, I can say that the YouTube videos, as impressive as they are, do not do the product justice. You cannot appreciate the level of detail in every frame of gameplay until you have seen, up close, every ripple of water, glisten of alien skin and glare of radiation. To see the interactive development environment is also a sight to behold. Dragging the water level up and down, changing it's hue and turbulence whilst watching the changes onscreen is a perfect demonstration of the power.

More intriguing than this is getting to know the people behind the product. As I sat watching my preview of FPSC X10, I witnessed the ongoing refinement of the application. "Those boxes look wrong when the water rises", Rick mentioned in passing. "They need to wobble as they rise to give them a more natural look". In response, Lee not only agreed that it should be implemented, but it would also be tied to the user-definable turbulence of the water, and so it was added to the to-do list. It's one example of the numerous enhancements that just happened as the day progressed.

It's also enlightening to see that Lee and Rick are very open about the challenges they face. I was given a highly amusing demonstration of just what happens when the enemy tries to climb a pile of bodies and gets his head stuck in the roof, and some very talented dancing thugs who want to run but have nowhere to go. Thankfully, I also saw the solutions to the issues that will make their way into the finished article long before we see it on the shelves.

To summarise my day, I was given an insight into what makes The Game Creators a successful team. I was the preverbial fly on the wall, watching Lee and Rick bounce ideas, challenges and solutions back and forth throughout the entire day. It's a successful partnership that we as consumers see in every product they produce.

contents

(1) FPSC X10 (2) Convention (3) Updates (4) DBPro (5) Tutorial - 7 Ps (6) FPSC News (7) DGDK (9) Lee's Tip of the Month (10) DBPro Fundamentals (11) Crytek Interview (12) Competition (13) PlayBasic (14) From the Forums (15) Winner (16) Outro

FPS Creator X10 Update

Update by Lee Bamber

There comes a time in any development, where the influx of features outweighs the tasks required to bed those features down and keep everything stable and safe. In last month's pursuit for speed, and from various feature ideas we threw in, we had no time to consider the smaller, more secondary tweaks that are also required for a successful development.

This past month has seen much attention to these areas, which amongst other things ensures we can catch a glimpse of what the finished product may look and play like. Unlike monster features such as AI and PHYSICS, these smaller tasks number in the hundreds and a comprehensive list would probably send you to sleep. There are some minor improvements, though, that you might find interesting.

We have added new property fields to the entities to cover some of the requests we have received such as a SCORE property. The engine now supports a score to be displayed on the screen, each entity can have its own score value and the player has a new objective type called SCORE GOAL which wins the level when the player reaches the desired value. The inspiration for this has come from the more creative community of game makers who recognise FPSC can create great games without the need to add a single gun. By using challenging room designs, obstacles, puzzles and now scoring, the player can have a great deal of fun without having to shoot anything. We hope to extend this in the future to include more non-shooting elements, and start creeping into more genres such as adventure, rpg and more sophisticated puzzle solving.

Some other cool properties are flags to switch off the health bar and ally display on characters, a value which controls how much health is added or deducted when the player stands inside a heal or hurt zone, and a value to control the amount of physical force a weapon can deliver to ragdolls. This ragdoll impact force value when set low will treat a bullet hit similar to a throw, whereas a high value will be like hitting the character with a cannon ball. It's quite fun to set the wimpy pistol deliver an impact which sends a character flying across the room!

A new value has been added to control the decay time of fallen characters. This way you can create your levels so the characters stay on the floor throughout the game, or instruct them to disappear after so many seconds.

One of our favourite values is in the Player Start marker, which controls the players jump height. Rather than rely on a default, you can change the jump value to zero, which effectively robs the player of his ability to jump. You can also set this value high, allowing the player to literally jump on top of buildings with a single bound.

We continue to work on these smaller task issues, as collectively they represent the majority of the work left to do on X10. Most of the major issues have been dealt with, and our technology is getting stronger by the day. We have recently integrated PerfHUD opt-in code to the latest beta so we can analyse what the GPU is actually doing, and our early tests show that our engine produces no GPU stalls. This means if a graphics card could melt, X10 would do its best to try. If you are thinking about buying a DX10 card, my advice would be to buy the biggest one you can afford. X10 will extract as much GPU horsepower as you have, and won't be afraid to ask for seconds!

'07 - The Official Game Creators Convention

The Time: October 27 & 28, 2007
The Place: Hinsley Hall conference centre, Leeds, UK 

2007 sees the first Official Convention of The Games Creators, to be held in the UK later this year. We can now give you a sneak preview of some of the presentations.

Rick Vanner, Financial Director, The Game Creators
Rick will be giving an insight into the world of TGC. You'll get a chance to find out how the company ticks, what the future holds, and as the market in independent games creation rapidly progresses, how you could potentially be a part of that future.

Lee Bamber, Head Developer, The Game Creators
FPS Creator X10 is naturally the focus of Lee's attention and has been for some time. He will be taking you behind the scenes of it's development, and reveal some of the tricks of the trade. The FPSC engine is written using the next generation of the DarkBASIC language, so this will prove to be a valuable resource for the future.

Mike Johnson, TGC Programmer
Mike will be showing the benefits of using DarkGDK and how easy and flexible it is. He will also outline plans for the future of the technology. Mike is also responsible for Dark Physics which he'll present to you and advise how to get the best out of it.

Dave Milton, TGC Programmer
For the past two years Dave has been working on a commercial product using the GDK. In his session he'll present a post mortem of that project. You'll hear what worked and what didn't. How GDK had to be shaped and tweaked to make this complex project a reality. A huge issue was the physics system which delayed the project a number of times - Dave will outline the problems he encountered and how he was able to overcome them.

Paul Johnston, TGC Programmer
The world of sequencial programming is coming to an end, developers now have to adapt and start to take advantge of the latest multi-core systems. Today we have dual and quad core PCs,and with eight core on the horizon it's now time to learn how your code can take advantage of this extra processing power. With the help of Intel. Paul has developed routines that we have used in FPSC X10 to speed up the lightmapping and AI systems, he'll be able to share his knowledge with you during his talk.

Most of the accommodation is en-suite, but it is advisable to book as soon as possible to guarantee your room. Other parties will also be using the facilities, but we have announced the convention early to give you the best opportunity possible.

You can download the booking form here, and return it with a small deposit to reserve your place. You can pay online, simply email michelle@devink.co.uk for the details. We are very excited about this event, and hope that you will take advantage of this unique opportunity. Find more details and join in the discussions on the forums.

Product Updates

Styx in now at release 2.00. This is more than minor amendments and enhancements, it includes some significant new functionality:

• revamped "Interval" system, allowing thread based calls
• create callback functions in DarkBasic Pro
• basic runtime error handling
• anisotropic filtering and anti-aliasing in DBPro
• powerful tokenizer
• run-time expression evaluator
• more new commands!

If you are unfamiliar with the original version, it contains over 200 new commands allowing you to integrate your DarkBASIC Professional game and applications with common Microsoft technologies - .NET, ActiveX and COM. Not only this but it also provides for extra handling of Strings, Number operations, Windows (and Window shaping), Splash screens, MIDI support, XML support, Direct Memory Access, integration of Flash movies, INI file handling and Intervals (code running on interrupts).

You can purchase Styx from the product page on the TGC site. Existing owners of Styx will find the upgrade in their account orders page.

eXtends has been upgraded to version 1.3. In this release you will find various enhancements and resources:

• 2 new RTSkyboxes
• Improved dynamic media handler and string handling
• Fixes to B3D, E3D and RTS commands
• Fixed the problem with ZBuffer that cause some objects of the sky to disappear under some circumstances
• Six new Vector commands
• Two new memblock commands for copying images

These updates complement the original product, which encompasses dynamic media handling, GUI system, fonts, 2D effects, sprite collision, billboarding, virtual lighting system, particles and real-time skies.

You can purchase eXtends from the product page on the TGC site. Existing owners of eXtends will find the upgrade in their account orders page.

DarkBASIC Professional Round-up

The Little Book of Source Code 

We start this month's collection with a contribution from Daniel Foreman. To help new users understand data management more effectively, he's released a preview volume of his upcoming publication, The Little Book of Source Code. This volume features 15 pages of example source code and explanations covering variables, arrays and datatypes. These are the areas that form the backbone of DarkBASIC Professional (and all other languages for that matter). Daniel hopes you enjoy this preview volume, and we look forward to future news on the full version.

http://files.thegamecreators.com/darkbasicprofessional/darkbasic_help_variables.pdf

You may recall, back in March 2005, the newsletter cover artwork was taken from a game called Easy Lander. Written by Stephan Guenther of Space Dream Studios, it was a simulation of the landing of the lunar module by Apollo 15. Stephan did not realise at the time just what this would lead to.

NASA's Johnson Space Center has recently acquired four new simulators that offer a chance to fly NASA's planned Lunar Surface Access Module (LSAM), finishing with touchdown on the Moon. These simulators are running software developed by Space Dream Studios in Germany, coded in DarkBASIC Professional. The call was made after the original game received interest from Amusitronix, commisioned to build the new simulators. It was Stephan's suggestion to base the project on the forthcoming lunar landing.

The modelling of the Lunar Surface Access Module (LSAM) took around a week, and is the heart of an application which was developed over 2 months. Because the LSAM itself forms such an essential part of the project it was modelled first, and the application had to conform to it's requirements. Included in the development process is Dark Physics and realtime shadow implementation.

Lunar Lander 2020, the application within the simulators, is designed to work in two modes. Within the official simulator it works on multiple screens to provide the full experience. Outside of the intended environment, it can also be run on a single screen, allowing the program to be used on a standard PC.  

With a choice of three levels, anyone can pit their wits against technology that has not yet been realised, over 12 years before it is due to land on the moon. The highest level is appropriately entitled realistic, and only the most steady and skilled operatives will succeed!

The physical installation took three days, with Stephan modifying the code as necessary, on-site. Increasing the realism are integrated Bass-boost speakers, which amplify the noise of the LSAM boosters to a point that rumbles through the entire exhibition hall at the centre!

Stephan is truly dedicated to his passion in life. "I have been a space enthusiast since I watched the first lunar landing when I was one year old, standing on the couch in my parents' house...and nobody was able to pull me away from the black and white pictures on our old TV.

"I'm working towards being on the surface of the moon some day in the near future and looking up to mother earth".

Details of the Lunar Lander simulation can be found at http://www.spacedreamstudios.com/

Vector Animado featured in last month's newsletter, with their games-based approach to different markets. Onae is their offering to visually impaired people, giving them the opportunity to experience the world of video games. Piopa is a tool that assists in identifying children affected by anti-social behaviour. This month we feature Lumæ, which is a game of normal standing, but with another socially motivated background.

The World of Lumæ

Lumæ is the smaller daughter of the king of the Taiños, the latest in a line of men of good heart and at one with nature, that have lived in Galicia for many, many years. Lumæ is a fictitious being, in the form of a half-nymph. The scene is set in the mythological world of Galicia. The style is cartoonesque, with vivid colors in the portrayal of a world of castles and forests, in which many puzzles must be solved to win.

What makes this game different is it's messages of socially and humanely acceptable behaviour. To complete each level, the puzzles must be resolved in line with the messages of the game. Level one reinforces the importance of realising the dangers of drugs. Level two bases the message on respect for one another, and the third focuses on care for the environment.

This game is presented for the Spanish market. As a developer, it is worth visiting the site for the in-depth information regarding the development of their suite of games, and how the design is centred around the requirements of the audience. You can click on the Babelfish link to get the detail in (almost) English.

http://www.vectoranimado.com/

Weed Works is a fast-developing work in progress by Ethan D. Keiley, aka Alquerian. This freeware application is designed for rapid development of groundcover such as grass, weeds and other foliage. It has a multitude of options to create everything from a single blade to a landscape of extra-terrestrial, multi-coloured fields.

As well as developing the application, Ethan has collated and made available a huge collection of images including flowers, stones and of course weeds. You can find these in the forum thread, the link is at the end of this article.

The first version has been made publically available, and can be used freely in any project, private or commercial. Feedback is always appreciated, and will shape future developments.

The forum thread with full details can be found here.
There is a Youtube video showing the features here.
The alpha version is currently downloadable here.

devhat.net have produced a podcast centred around the world of DarkBASIC. Produced by forum names we all know (Zenassem, DanielTGC, Raven, Kentaree), it takes a look at various topical subjects including upcoming products, publications, websites and other resources. Look out for further podcasts in the future.

http://forum.thegamecreators.com/?m=forum_view&t=110734&b=2

Lukas Wadenhof has released his free Game manager. Users get instant notification of new games and updates delivered by the application in a similar fashion to other commercial systems. Developers can also share their own productions and either link via the system to their own download site or upload the package to the central server. It supports DarkBASIC, DarkBASIC Professional and FPS Creator.

You can download the Game Manager from Lukas' site - http://lukasw.com/GameManager/

The forum thread discussing the features is here - http://forum.thegamecreators.com/?m=forum_view&t=108800&b=5

Tutorial - The Seven Ps

This month sees the start of a series of tutorials by Craig McFarlane. This month, Craig sets down the guidelines by which future projects will be governed. As any seasoned programmer will tell you, this is the key to success.

Prior Preparation and Planning, Prevents a Particularly Poor Performance.

If you've been following the tutorials for a while, you will already have come across the October 2006 newsletter which taught you all about designing your game and how best to organise everything long before you write your first line of code. So, we don't need to go over that again. Instead, let's have a show of hands....

How many of you have started writing a game without any real planning, only to find you've coded yourself into a hole? You've got too many bugs and your code is too scrambled to unravel. You've got so many ideas that you want to implement but your code is such a mess that you've got no idea whereabouts your new idea should be placed. Sound familiar? You're not alone, there are a lot of hands raised out there ... mine too!

I used to be just like that. I had grand ideas and I would set about laying down my code line after line with no organisation. It wouldn't be long before the code was a jumbled mess that I simply couldn't follow. Debugging was near impossible, I couldn't remember what numbers had been assigned to objects and images and it wasn't long before the project would grind to a halt, never to see the light of day.

As we've already said, planning is essential but so is keeping control of your code and keeping track of the numbers that you have assigned to objects and images.

So, what can we do about it? We will tackle the code in a moment; firstly let's consider the object numbers. How can we remember what numbers have already been assigned and what numbers are still available? Well, there are several methods:

Firstly, you could write down all of the object numbers on a piece of paper that you can keep next to your PC. That way a quick glance to the side will let you know what each number represents.

That would certainly work but it isn't very practical.

The next method to look at involves writing a small function which assigns a name to each object, image etc. and another function to ascertain what number the name represents. Something like this:

function NewObject(Name as string)
   i = 1
   repeat
      inc i
      if object exist(i)=0 then found=1
   until found
   ObjectName(i) = Name
endfunction i 

function ObjectNo(Name as string)
   i = 1
   repeat
      inc i
      if ObjectName(i) = Name then found = 1
   until found
endfunction i 

With those two functions at the bottom of our code somewhere and a dimensioned array at the top, we can then create objects with names. Like this:

Load Object "Player.dbo", NewObject("Player")
Load Object "Monster.dbo", NewObject("Monster")
Load Object "Level.dbo", NewObject("Level") 

... and when we want to access them:

X = Object Position X(ObjectNo("Monster")) 

On the surface, that looks great because now we have a name for our objects. So, we don't need to remember what number our Monster object is. Instead we can just call it by name. This is actually quite a popular method but it has a major drawback. Each time we want to reference an object, we have to go through a loop and compare the name with every other object's name until we find the correct one and that takes time. In a large project it will cause a very noticeable drop in frame rate.

So, on to the third method: This is a combination of both of the methods above. What we do is assign a variable to each object, image, sound or whatever media we are using and set that variable as global so that it can be accessed from anywhere in our code. Like this:

Global oPlayer as integer = 1
Global oMonster as integer = 2
Global oLevel as integer = 3 

Tip: Setting the variables as integer is actually the default and is therefore largely superfluous but it is a good idea to keep it in there for ease of reference at a later date.

And to load the objects:

Load Object "Player.dbo", oPlayer
Load Object "Monster.dbo", oMonster
Load Object "Level.dbo", oLevel 

As you can see, we are still using a name instead of a number but now we don't have to go through a loop to look it up, saving valuable frames per second. Another advantage of this method is we now have a list of all assigned object numbers at the start of the code, similar to having it all on a piece of paper but much handier.

The astute amongst you will have noticed that there is a letter ‘o' before each name. That is a form of what is known as Hungarian notation and it allows us to see what each variable represents. In this case an ‘o' represents an object. Using this method we could have a very similar name for the texture as we do for the object but we would still know which was which. For example:

Global oPlayer as integer = 1
Global iPlayer as integer = 1
Load Object "Player.dbo", oPlayer
Load Image "Player.jpg", iPlayer
Texture Object oPlayer, iPlayer 

Which letters you choose to represent each format is up to you. Standard Hungarian notation uses ‘i' to mean integer but I prefer it to be image and leave integer variables unsigned.

Here is my preferred list:

• iImage
• oObject
• spSprite
• sSound
• mMusic
• mbMemblock
• bBitmap
• fxShaderEffect
• vVector

Obviously you can change this to whatever suits you best but I think these are very intuitive and provide a good way to remember them.

Ok, that is the numbers taken care of, now let's consider the code. We have done all the planning. We know what our game is going to be like. Now we want to get stuck in and write the code. The trouble is, if you do just get ‘stuck in' then you will probably get yourself well and truly stuck. What you need is some kind of layout or template which you can load up at the start of any project and adapt as necessary.  Try this project template for size:

`Project :
`=========================
`Author :
`=========================
`Started : 

set display mode 800, 600, 32, 1
autocam off
hide mouse
Disable EscapeKey 

`Define Types
`
`Assign Types
`
`Arrays
`
`Constants
`
`Booleans
`
`Floats
`
`Integers
`
`Objects
`
`Images
`
`Sprites
`
`Sounds
`
`Bitmaps
`
`Memblocks
`
`Dwords
`
`Vectors 

`-------------------
` LOAD IMAGES
`-------------------
`
`-------------------
` LOAD OBJECTS
`-------------------
`
`-------------------
` MAKE OBJECTS
`-------------------
`
`-------------------
` LOAD SOUNDS
`-------------------
`
`-------------------
` LOAD MUSIC
`-------------------
`
`-------------------
` LOAD SHADERS
`-------------------
`
`-------------------
` SET UP WORLD
`------------------- 

sync on
sync rate 0 

`************************************************************************************
`* *
`* S T A R T O F M A I N L O O P *
`* *
`************************************************************************************
`
do
   GetUserInput()
   UpDateDisplay()
   _DeBug()
   sync
loop
`
`***********************************************************************************
`* *
`* E N D O F M A I N L O O P *
`* *
`*********************************************************************************** 

`-------------------
` DEBUG
`-------------------
`
function _DeBug()
   text 0,0,"FPS : "+str$(Screen fps())
endfunction 

`-------------------
` GET USER INPUT
`-------------------
`
function GetUserInput()
   if keystate(1) then EndGame()
endfunction 

`-------------------
` UPDATE DISPLAY
`-------------------
`
function UpDateDisplay()
`
endfunction 

`-------------------
` END GAME
`-------------------
`
function EndGame()
   `Perform Garbage Collection
   End
endfunction 

Ok, let's break that down. Firstly, there are three comments to record the project name, your name and the date you started the project. Not essential by any means but handy stuff to have at the start of any project. Next there are a few set ups:

• The display mode, which you can change to suit your project. Note the additional flag at the end. That will ensure your game runs at the screen refresh rate. I've turned off the Autocam and hidden the mouse. That's personal preference but there aren't many projects where they are needed. Then I have disabled the Escape key. I still want to use Escape to exit the program, so in the GetUserInput() function I have put in a check to see if it is pressed. The reason for that is so that we can ‘clean up' (remove media from memory) before ending the program.
• After the set up stage there are lots of Rem statements. They are there to provide a place for assigning variable names to media as we discussed earlier.
• Then comes a place to load the media, followed by the main loop and finally three functions that each project will need. Of course you will need more functions as your game progresses but using a template like this everything is nice and tidy and it is easy to see what is happening and where to put new code.

Hopefully, you can now take this template and build on it. Whilst it doesn't make game creation easier it does make game completion a much more accessible goal. Don't worry if you still need help, because next month we will take this template and demonstrate how to use it to make a simple game. Until then ... remember the 7 Ps.

News from the World of FPS Creator

It's time to get all Indiana Jones as you take your FPS Creator games into the Egyptian world. With 17 complete full room designs and over 280 new scenery entities there is plenty here to create a convincing and enticing environment.

17 Room Designs consisting of 257 Individual Room Segments

• 4 x Basic Room Styles (with inside and outside variations)
• 6 x Temple Room Styles (with inside and outside variations)
• 1 x Tomb Style System (with many variations)
• 4 x Village Hut Styles (with inside and outside variations)
• 1 x Cellar Style Room System
• 1 x Pit Style Room System

All rooms are constructed with floors and ceilings. Also included are:

• 70 x Corner segments (for use inside & outside of rooms)
• 101 x Inner Wall segments (for Inner room construction)
• 13 x Ceiling / Roof segments (for creating 'flat' roof areas on rooms)
• 2 x Floor Systems (for outside use (light sand & dark sand)
• 8 x Extra Floors (for various uses - found in various room folders)
• 2 x Pit Shaft (Trap Shaft) segments (all in one unit size for 'vertical' use)
• 2 x Pits (Traps) segments (all in one unit size, Snake Pit & Scorpion Pit)
• 3 x Platform Systems (Grid, Wicker & Wood)
• 2 x Shaft Systems (for 'horizontal' use)
• 8 x Steps (Stone & Wood, various types)
• 11 x Stairwell Units (all in one unit size in various styles)

285 Scenery Entities including:

• 38 x Arches (for entrances and inside use)
• 18 x Maps (that show secret area clues)
• 29 x Items (including a plinth system & ramps of various sizes)
• 29 x Floor Traps (can be 'reversed' to become solid)
• 20 x Floor Grids (can be looked through & 'reversed' to become 'Traps')
• 21 x Floor Hatchs, Open & Closed (use as entrances to steps or stairwell segments, can be 'reversed')
• 33 x Ceilings, Sky view (can look through, can be 'reversed' to turn into 'Roof Traps')
• 30 x False Corners (inside & outside use, can be walked through to secret areas, can be 'reversed')
• 39 x False Walls (inside, outside & inner use, can be walked through, can be 'reversed')
• 19 x Doorways (no doors) (for use as entrances to rooms and inner room construction, can be 'reversed')

Plus the following nice extras:

• Ceiling beams for corridors
• A Spiderweb
• Floor Holes
• 2 x Shaft Exits

All of these can be 'reversed'. Reversed means changing the state from 'Static to Dynamic' or 'Dynamic to Static', creating different uses in the process.

More details, and the purchasing link can be found here - //www.thegamecreators.com/?m=view_product&id=2036

Featured back in issue 50, Extinction Level Event is an FPS game which has a publisher and will shortly be brought to the Spanish market. It's a series of 3 games, and aside from the highly polished game playing, it is supported by a wealth of cinematic cut-scenes to tell the story behind your mission. You can now view a video of the finished product on the Alia 3D website - http://www.alia3d.com/ele/trailer2.htm

As great as this product looks, we have another motive for featuring this site. Take a look on the site at the promotional video for the Trimersion headset. It's a great gadget for viewing and controlling your games using the wireless technology. In this case, the game that's being controlled is made using FPS Creator!

Trimersion promotional video - http://www.trimersion.com/pro_info.html

DGDK Highlights

Last month Thiago presented a great insight into DGDK.net with his tutorial for beginners. He's working hard on the next installment alonside Paul Millard, the developer of this product. Watch out next month for the fruits of this labour. In the meantime, take a look at how others are using the language.

It's always intriguing to see the uses that the TGC programming languages have been put to outside of the gaming world. Vehicle Control Technologies have taken DarkGDK to what is probably one of the most exciting and intensive environments we have seen to date. Ken Kueny, Vice President of VCT took time out to explain to me just what they do and how DarkGDK has enhanced their development.

In Autumn 2005 Vehicle Control Technologies (VCT) developed a suite of Guidance, Navigation, & Control (GNC) flight software for Raytheon Integrated Defense Systems. Raytheon was integrating the BAE Archerfish mine neutralization vehicle into the MH-60S helicopter for the US Navy under the Airborne Mine Neutralization System (AMNS) project. At the time, the Archerfish vehicle was manually piloted. But, the US Navy wanted a partially automated system to minimize workload for the operators. Once VCT got to work, their engineers quickly realized that our GNC system would have to have both manual and automatic flight modes.

To test the manual flight mode, a visual display was added (including joystick) to the existing batch mode simulator using shared memory (aka "file mapping" in Windows speak). The simulation was used to help "fly" the vehicle using the GNC software prior to delivery. After delivery, a BAE test pilot was able to use the same simulator to help refine the manual control system design.

The net result was a rapid engineering development cycle. The team went from their first code delivery and first flight (in Waterlooville, UK) in October, 2005 to high water current engineering tests at the NAVSEA Carderock facility (near Washington, DC) in November, 2005 to successful in-water trials (near Panama City, Florida) in December, 2005.

Given that VCT are not in the market of game development, having the ability to quickly employ an off-the-shelf game engine with a higher level interface than DirectX or OpenGL was absolutely critical. Ken Kueny had used DarkBasic for some standalone visual demos. But, being able to integrate DarkGDK graphics directly with their existing C++ simulator resulted in a much more powerful application.

Ken and his team are currently in the process of delivering additional copies of the AMNS Archerfish simulator to engineers at Raytheon, Lockheed-Martin, and the US Navy to help them train operators and develop more complex system simulators.

This project has generated huge interest in terms of technology and development. You can read about the impact and all of the facts and figures in the BAE news release, Raytheon site and newspaper coverage.

Lee's Tip of the Month - Which DX10 Card Should I Buy?

I recently took possession of a quad core PC from Intel, which I immediately recruited into my test farm. I was fortunate to have one of the cheapest DX10 cards available sitting on my desk at the time, and so installed the system with Vista, a GeForce 8500 and the latest drivers.

I then ran our new FPS Creator X10 beta version on the machine. Although we have a lot of beta testers with various Vista systems, I had not attempted to run X10 on a low end DX10 GPU and was curious as to the results.

To my delight, the beta worked first time. Installing X10 on a fresh install of Vista, and running the application was straight forward and painless. The good news was that X10 would run on practically any Vista machine with a DX10 card. The four CPUs and a gigabyte of memory helped the test machine along, but I felt any motherboard that can take a PCI-Express card will provide plenty of power.

The bad news was the performance of the GeForce 8500 in X10. We regularly measure how long it takes various parts of the engine to complete a task. For a single room in the game, using the GPU usually takes around 20,000 ticks and 416fps on a GeForce 8800 right now. The X10 beta version running on the test machine clocked 175,000 ticks and ran at 42fps. Now this was a single prefab room with no guns, no enemies, no objects, no lights, no nothing - just a basic room with a door. When I created a small level on the test machine, the GPU workload killed off the frame rate almost right away.

The conclusion is that we have some optimization work to do for lower end DX10 cards, switching off certain features that impact heavily on the GPU. It is also evident that X10 does a lot of GPU intensive work, and if you want those 50 characters running around in a smoke filled battle arena, you probably won't be getting it with a GeForce 8500. The card is great to experiment with DirectX10, and running well designed and optimized 3D content, but for the kind of raw power you want to glimpse at the next generation of gaming, you really need the high end card.

My advice, for those who are thinking of switching to Vista, and only have one shot at it; save a little more and buy the best DX10 card you can afford. It could mean the difference between fun and frustration.

DarkBASIC Professional Fundamentals

You can find previous fundamentals tutorials in the back issues of The Game Creators newsletter.

Fundamentals Tutorial 8 - Loading Multiple Objects

At some point you will want to load more than one object model, or primitive object. This has already been achieved in prior tutorials, but this section will explain the details and requirements.

All objects require a unique number in your program. Primitives of all kinds and loaded models share the same numbering system. This code shows the correct enumeration of objects, where each object has a unique id:

MAKE OBJECT CUBE 1, 10
LOAD OBJECT "MyModel.x", 2
MAKE OBJECT PLAIN 3, 12, 15 

Here are some examples of incorrect enumeration. Different types of object, whether it be different primitives or loaded objects, all share the same indexing system:

MAKE OBJECT CUBE 1, 10
MAKE OBJECT SPHERE 1, 12
MAKE OBJECT CYLINDER 1, 8.5
LOAD OBJECT "MyModel.x", 2
MAKE OBJECT PLAIN 2, 3, 2 

Just like you can make multiple cubes or spheres, so too can you load the same model file multiple times. If you want 6 vehicles, then this is acceptable:

LOAD OBJECT "MyCar.x", 1
LOAD OBJECT "MyCar.x", 2
LOAD OBJECT "MyCar.x", 3
LOAD OBJECT "MyCar.x", 4
LOAD OBJECT "MyCar.x", 5
LOAD OBJECT "MyCar.x", 6 

Alternatively, you may want to use 6 different models of car, and this is equally acceptable:

LOAD OBJECT "MyCar_1.x", 1
LOAD OBJECT "MyCar_3.x", 2
LOAD OBJECT "MyCar_8.x", 3
LOAD OBJECT "MyCar_4.x", 4
LOAD OBJECT "MyCar_9.x", 5
LOAD OBJECT "MyCar_2.x", 6 

Object Positioning

All newly created objects are positioned in your world at coordinates 0,0,0. For primitive objects, this will represent the centre of your object. For loaded models, the centre will be determined by the modeller, and may not necessarily be central. The main point of this behaviour is that all new objects will be placed in the same space in your game world. Until you move the objects, the appearance of multiple newly loaded objects may be somewhat confusing.

 Run the code! (Download the Project Files)

Run the example for this section, which will demonstrate the positioning of new objects. The first item is a primitive cube, and is visibly centred squarely around position 0,0,0. The matrix in this example represents floor height, and it is apparent from this that a primitive cube is as far below floor level as it is above. The second object is a loaded model cube. The model has been constructed is such a way that it's centre is actually at the base of the shape. As a consequence, the cube is placed at floor level by default. Finally, a third model cube is loaded, but in the modelling phase the cube was offset from the central point.

Cloning and Instancing

Cloning

When initialising a game, one of the more intensive operations is loading the resources from disk. Where a particular item is a duplication of existing resources, we can remove the need to keep taking from disk, and clone from the existing data already in memory. Copying memory is many times faster than reading from Disk. Here are 2 lines of code, loading the same model twice:

LOAD OBJECT "MyModel.x", 1
LOAD OBJECT "MyModel.x", 2 

Now, here is the same result, using the cloning technique.

LOAD OBJECT "MyModel.x", 1
CLONE OBJECT 2, 1 

The first line loads the model in the standard way. The second line creates a further copy of the same model, but using the more efficient cloning method. There has been no saving in the amount of code used, but at runtime the benefits are far greater.

 Run the code! (Download the Project Files)

Run the example to see cloning in action. You can see that a cloned object inherits texture, size and position from it's parent. The example takes the concept a stage further by demonstrating that the second model can then be retextured, and is indeed an entity in it's own right. The original model is also retextured to highlight that there is no link between the original model and it's child clones.

Instancing

This method is very similar in it's application to cloning, but has some significant and very important differences:

• An instanced object can have it's own scale, position and rotation
• An instanced object shares it's other properties throughout it's life. An instanced object cannot be retextured, for example.
• Retexturing an object that has been instanced will change the texture of all it's child instances.
• You cannot instance an instanced object

 Run the code! (Download the Project Files)

Run the second example in this section to see instancing in action. Look at the differences in the code, in respect of instancing a second object, and retexturing and the visible results.

In summary, Cloning allows faster loading and setup of multiple objects, providing a simple template system. Where multiple, identical objects are required, Instancing can provide a more streamlined method than Cloning, but with restrictions.

Until next time,
Happy Coding!

An Interview with Tony Davis of Crytek

Farcry, released in 2004, has been one of the most successful games in recent times. Acclaimed for it's graphical excellence, fantastic open-ended gameplay and vast seamless landscapes, Crysis is soon to follow in it's footsteps and is already causing a similar stir. Tony Davis, Lead Level Designer at Crytek, has taken time out of his busy schedule to give you an insight into the world of Triple A titles. Tony lives and works in Germany, and is currently involved in the final stages of Crysis development.

Tony uses DarkBASIC Professional as part of his toolset. "I started with DarkBASIC at the beginning of 2006, after a suggestion from one of our programmers. I was looking for something that could do 3D ‘easily', and have an acceptable learning curve - I am not, nor have any desire to be a ‘real' programmer. I had used a visual scripting application for a few years that was mainly designed to do Multi-Media presentations, but had a built in programming language of sorts so I used it to mock up ideas. Going from an icon based sequential editor to an actual procedural language was daunting at first, until I realised they both followed a logical structure."

Like me, you're probably asking why an application that is affordable by the casual hobbyist is being used in a professional environment. "I use it as a tool to help me relate to the programmers here at Crytek and learn more about programming.", explains Tony, "I have found that as a non-programmer, being able to talk to programmers in technical terms and using conventions familiar to them, I've earned a bit more respect and we are able to achieve more as a team. The less time a programmer has to spend explaining basic concepts, the more time he has to implement features"

Working in a team that covers all aspects of design has it's challenges and advantages. I asked how this presents itself at Crytek. "I have enough say in my area of expertise - everybody's ideas are listened to, so everybody feels involved. We throw ideas around, the Project Lead then writes up very detailed documents that we refer to later. I often write documents on items specific to my part of the project - level design and game play."

On the subject of the secret of their success, Tony is quite clear. "There is no formula as such, other than ‘prototype and iterate on ideas' - this means never being happy with a game idea until we've seen it prove itself on screen. Ultimately the game must be fun . We plan our games out thoroughly and ensure they stick to a schedule that we can realistically achieve. When we get close to releasing a game and the schedule is tight, we cut over ambitious features if they don't add to the overall quality of the project.

"Rework of game-assets happens when it becomes obvious that the games potential can be greater, or the quality bar can be pushed higher. Although it can be painful at the time, the results are always clear to see. Refactoring of game-code happens all the time as new features are added and the game's scope increases."

So what can the hobbyist coder, or would-be professional learn from Tony's experiences? "Keep playing your project and try to approach it from an end-user perspective; I'm always over-complicating my GUI's, then dumb them down for other people to understand. Less is more! "

As always, the final word goes to the man in the spotlight. "I'd like to thank the DB Pro community for providing so much help via the forums, and the DLL/plug-in guys who provide so many cool toys for me to play with!"

Hands On DarkBASIC Pro Competition

Issue 53 saw the announcement of a competition to design a cover for the Hands On publication. As the competition deadline draws near, we've provided you with a small reminder of how you can have your artwork adorning the cover of this popular book. 

Digital Skills has decided to change the cover of their best-selling book - Hands On DarkBASIC Pro Volume 1. And, since they know our dedicated readers have more than a little talent when it comes to graphics, they've decided to give you a chance of seeing your own artwork sitting on the shelves of a bookshop near you.

They are running a competition for a new cover with a prize of £250 (that's almost $500 USD at current exchange rates) and of course, a copy of the book displaying YOUR cover design.

The full details are available on the Digital Skills website.

The website contains several chapters from the Hands On DarkBASIC Pro books as well as almost 70 pages of supplementary material all in PDF format. Don't forget there is also a follow-up to this popular title, namely Hands On DarkBASIC Pro Volume 2.

The Digital Skills website and full comptition details can be found at http://www.digital-skills.co.uk/

PlayBasic News

PlayBasic - Round Up

by Kevin Picone

Ballistic Blasters Closes

By the time you've read this, the submission deadline will have passed. So make sure you check out the Ballistic Blasters forums for the entry submissions and the final results. Here's a couple of WIP shots from two of the entries.

Team Calypson

Aquarius

Development update

This month we've been updating some of the PlayBasic example materials to bring them in line with the current release. While the majority of the older demos still work fine, many were hastily written and therefore needlessly messy - not ideal for new users to pick through and expand. To be honest, it's been fun going back through and updating them. It really gives me a sense of just how far PB has come in such a short time, particularly in terms of performance, which is really evident in the updated software 3D engine demo. We've also released two more updates to 1.62c (Demo) and 1.63h (Retail). The latter includes a few more toys for registered users to exploit in their application in the form of optimisations, bug fixes and a few retro-fitted features.

PlayBasic V1.63h Retail Update

This revision started out as a feature addition and simple bug fix which soon turned into an optimisation-fest, with various rendering improvements and even some core modifications to functionality such as For/Loops, of all things.

Looking at rendering, I had been wanting to exploit some parallel pixel processing opportunities in Alpha Blending. This can be a double-edged sword; the advantage of pipelining instructions can be easily lost in the setup code (slower for small runs, faster for longer runs). But with a little persistence (ie. a number of failures) I've been able to improve the throughput of variable-alpha blending. This is used in things like boxes, circles, filling shapes and polygons. Performance-wise the new approach suits 16-bit modes better than 32-bit. While both are faster, the 16-bit version is around 40% faster whilst the 32-bit version is about 15% faster.

The other main improvement has been in the performance of For/Next loops, in particular in the For/Next/Step variation. This has seen a 36% improvement over a 120 million iteration test. So it's nothing to be sneezed at!

Show Case

Probably one of the most common questions we're asked is: what type of games/programs can PlayBasic create? So frequently in fact, that we've added a simple FAQ on the subject. While it doesn't cover everything, there's enough to give users some idea of what type of games each edition of PlayBasic is suited to.

Just take a look at some of the projects that have been developed in PlayBasic recently:

Nascent Online Quiz	Forest Blast
Software 3D Engine	Axis

From the PlayBasic team...Over & Out! 
 

From the Forums

In the forums there are some highly creative people doing highly creative things...

.

.

This months Winner

Each month we pluck one lucky subscriber from the newsletter mailing list and award them a free copy of DarkBASIC Professional. The email address of this months winner is: ????@neogen2.com  If this is you then send us an email to claim your prize.

Outro

Share your news with over 14,000 active games developers!

If you have something you'd like featured in a future issue then please get in touch and include as much information as possible (including where applicable: screen shots, URLs and zip files).
Issue 56 deadline - August 28th.

Famous Programming Quote: "If you lie to the compiler, it will get its revenge." (Henry Spencer)

The Game Creators in no way endorse or support products mentioned in this newsletter that are not specifically published by them. Always check first before parting with your money. © The Game Creators Limited 2007.