GDL - Frontier: Elite II

As its title suggests, Frontier: Elite II is the sequel to the hugely popular "Elite", a game first released in 1984 for the BBC Micro. Elite was a space game that blended several genres together to create a unique and compelling experience, and Frontier built upon this solid foundation. Several new features were added, and although the game received its fair share of criticism, overall it enjoyed plenty of success.

With rumours of another sequel to Frontier floating around the Internet, now seems like a great time to look back at a true classic from the 16-bit computer era.

What works

It's a Space Sandbox

frontier-screen-1.png

You can choose to start the game from several locations, but once you've started you're left to your own devices. There are no commanders briefing you, no tutorials to wade through. Once you're in, the choice is yours. You can destroy ships and steal their cargo, mine planets and asteroids for precious metals, take up assassination contracts, ferry passengers around or just trade regular cargo.

Frontier's main strength was the complete freedom given to the player. Although there was no story, there were many missions that could be carried out, and it took a considerable amount of time and skill to obtain the largest ship.

Easy to Change Your Style

This might seem like a strange point, but some games with different career paths make it difficult or impossible for you to change once you've started. In Frontier you can change whenever you want with very little difficulty. For example, if you're tired of ferrying around passengers, you can sell your ship and buy something lighter for courier delivery, or perhaps something larger and more suited for dishing out death. Having freedom to choose your path is always good, and adding the extra freedom to choose when you wish to change is even better.

Semi-Random People

frontier-screen-2.png

There are really two important points here:

  1. All of the faces are dynamically generated using an "identikit" process. This kind of content generation can save a lot of time in the long run, and also helps to prevent the various people becoming too alike in appearance.
  2. Even though space is big, some people keep cropping up. Sometimes you'll run across the same person in different systems, usually when they're on the run. It's a very subtle touch, and perhaps it's not even meant to be that way, but it helps to shrink the game world a little. It's great to have a huge world to explore, but a little familiarity prevents the player from becoming too disconnected from the game world.

What doesn't work

It's a Space Sandbox

Space is big. Really big. Traveling through the galaxy is fun, but most of the "outer" systems contain no planets so there's very little to do. For the most part, the outer reaches can be avoided, but you may be unlucky enough to suffer a hyperspace "mis-jump". It may throw you a few light years off course, or you might end up 400 light years from where you want to be.

It's great having so much to explore, and technically it's impressive, but in the end it means a huge amount of the game's content is just barren star systems with nothing to do.

Realistic Physics

In space travel, half the time of travel is spent speeding up, and the rest is spent slowing down. Frontier replicates this feature, and it's not particularly fun. Because everything works in real-time (though thankfully you can speed time using the "star dreamer"), all of the planetary bodies move including space stations. Traveling to a station often takes several days, so the station and the planet it orbits will be in different places. Keeping up with all these changes can be quite difficult, and it's not particularly fun either. If you don't have an autopilot, you're on your own.

Again, this feature is technically impressive, but it makes the game more like a space simulator than a space game.

Essential Items Aren't Included by Default

The autopilot is not included by default in any ship you buy and it's only included on one of the starting points. This means you end up selling other packaged equipment to raise funds for it.

Using the autopilot is not mandatory, so players can switch between manual and automatic controls without any problems which makes the decision not to include it even more baffling. Whilst it's more than possible that someone could learn to pilot the ships and land manually, it is incredibly difficult. Landing on a planet is one of the hardest things in the game, and nine times out of 10 you'll end up plummeting into the ground before you even realise it.

Intrusive Anti-Piracy Measures

frontier-screen-3.png

One of the classic methods of preventing software piracy was to require text from the manual to be entered during run-time to prove it had been purchased. This is the method Frontier uses, but instead of a single check at the start they appear randomly throughout gameplay. They're integrated quite nicely, with police officers asking you to take a "starship ownership test", but there's no immediate feedback if you got it right or wrong. If you type the wrong letter, you can end up continuing only to find out later in the game that you failed the test (which ends the game). Hurrah.

No Aliens

Elite had some of the coolest randomly generated aliens, complete with bug eyes and purple skin. Sadly Frontier stuck entirely to the human race, which is a shame.

What Can Be Learned

Make Physics Fun

If you're adding a feature to a game, make sure it's fun. A well implemented physics engine can add a lot to a game, as it lets the player use their imagination to create new ways of doing things. A recent example of this is "Crackdown", in which some resourceful players place a rubbish skip over a vehicle to create an armoured tank.

By giving players a few rules to use, they can create far more content with their imaginations.

Bigger Isn't Always Better

There comes a point in a game's size where it is too large for the majority of players to fully explore. If the game is large, make sure there is some form of reward for reaching far off or difficult to reach places. There's nothing quite as frustrating as defying insurmountable odds and reaching a hidden area to find it's completely empty.

Don't Punish Legitimate Players

Having your software cracked is one of the most heartbreaking and frustrating things that can happen to a software developer. However, being treated like a thief is one of the most annoying things that can happen to a player. The topic of countering software piracy is far too complex to cover in this article, but always be looking to strike a balance between protecting your software and keeping your customers happy.


Issue 2 - Build Stuff

It's been a while since the last issue, but there's been plenty going on behind the scenes. This issue sees the release of a new developer tool, some improvements to the website and glimpse of what's in store next issue.

Featured Article

Automating the Build Process

Building software can be a difficult and tedious process, with many different elements going together to create the finished package. This article looks at…

Read the full article

Also Featured

Also featured in this issue:

  • New Resource - BlitzBuild – The very first release of BlitzBuild, a command line build tool developed especially for the Blitz series of languages.
  • GDL – Frontier: Elite II – Rumours of another Elite game are surfacing again, so it seems like a great time to take a look at one of the classic games of the 16-bit computer era – Frontier: Elite II.
  • Shrink Your Software – Tips and utilities for shrinking your finished software, which leads to lower bandwidth bills and increased downloads.
  • The Fizz – The regular column that details all of the exciting things happening at Sodaware.
  • Quick Tip: Adding Apps to the Windows PATH – A really simple tip that can speed up your work if you use the Windows command line.

Finished reading all of that already? Issue 3 is due out on April 23rd.


New Resource - BlitzBuild

What is BlitzBuild?

BlitzBuild is a command line tool for compiling BlitzPlus and Blitz3D applications, although it can be used to automate other tasks in a similar fashion to Windows batch files. BlitzBuild's primary aim is to make it easier to build software with the Blitz series of languages, to remove the IDE from the build process and to combine several key build steps (such as documentation creation and testing) into a single step. This saves time and can also improve the quality of the finished article.

For the latest updates to this project, see the BlitzBuild project homepage.

Important Note: This release is very much a "preview", and as such isn't really recommended for a production environment.

License

BlitzBuild is freeware and may be used without restrictions.

Quick Links

Donations & Support

If you find this library helpful in your projects, please consider donating. Donations of any size are always welcome!

If you have any comments, please feel free to leave them here. You can also send an email or leave them as a feature request on the bug tracker.

Download


Adding Apps to the Windows PATH

This is a simple change that can make using the Windows command line much easier. Adding a directory to the Windows PATH will mean Windows will search the directory when a command is entered. The main reason for doing this is that it acts as a shortcut for common applications you may run.

For example, instead of typing the pull path to launch an application (as in example 1), you can type a much shorter version:

"C:\Program Files\SomeProgram\Bin\MyProg.exe" --some-arg
MyProg.exe --some-arg

This has three main advantages:

  1. Looks Neater – This can be important if you're using batch files. Long lines are hard to read, so shortening things is a good idea.
  2. Less Typing – Speaks for itself. If you use the command line or batch files for any amount of time, you'll appreciate how much easier it is to use if you're not typing full paths for your tools.
  3. Portable – Perhaps the most important detail. Not using hard-coded paths makes it easier to port your batch files to other machines.

Note: Be careful when editing your path variable, as you could render some programs unusable if you make a mistake. Also remember that changes won't take effect until you restart the console.

Editing the Windows Path Variable

1 – Right click "My Computer" and select "Properties" OR goto Control Panel and select "System". This will open the "System Properties" window.

2 – Switch to the “Advanced” tab, and select "Environment Variables".

environment-variables-1.png

3 – There are now two options. You can modify the global path variable, or add your own to your personal profile. If you want all users on the machine to have the same shortcut, add it to the global path, otherwise use the local one.

a. To modify the global path variable – Find "Path" or "PATH" in the lower window (marked Global variables). Select Edit. Add the path to your application. Separate paths with a semi-colon (;). Add trailing slashes if you wish.

b. Either modify an existing one using the tutorial above, or select "new", then enter "PATH" as the name of the variable and enter the path value in the environment value section.

environment-variables-2.png

Modifying the Path Using the Command Line

If you'd like to do this using the command line, you can use the "setx" command included with Windows XP service pack two. To add the directory "c:\program files\SomeProgram\Bin" to your path, use the following:

setx path "%PATH%;C:\Program Files\SomeProgram\Bin"

Remember to include the %PATH% variable at the start of your setx command so that you'll keep existing path names.


Automating the Build Process

Creating software is a time consuming business, and it's important to always be on the lookout for ways to reduce the amount of time spent on less important tasks. The process of actually building software (creating the finished distributable binary) is one such area that can be optimised. Opening up your IDE and hitting "compile" might not seem particularly time consuming, but it's only one part of the build process.

To get you started, here's a short list of tasks that can be automated:

  • Compiling the executables and dependent libraries
  • Packing media
  • Creating an installer
  • Uploading files to an FTP site
  • Checking out files from a repository to be built
  • Sending an email about a finished build to other developers
  • Creating the application documentation / Converting it to HTML
  • Testing the software

The benefits of using an automated build system include:

  • Saves time – Run a build and leave the computer to do the work whilst you take care of other tasks.
  • Documents the build process – If a build requires several steps before being completed, a build file will document this process for you. This is useful if templates need to be generated or options need to be set before a build is ready.
  • Improves quality – As well as automating the creation of a binary package, tests can be automated. This saves a lot of time on the development end, as tests can be constantly run so you'll quickly find out if the software's behaviour has changed.

Simple Automation – Batch Files

The simplest way to automate many of these tasks is to use batch files. A batch file is a list of tasks to be run, usually in the form of a list of applications with some command line parameters. Using a few simple commands it's possible to run many tasks in succession without any user input, leaving you to do more important things. Microsoft.com has a is a simple guide to batch files which is a good place to start.

As useful as batch files are, there is only so much they can accomplish, and there may come a time when something more complex is required for your project. Thankfully there are many build systems available

Build Tools

There are plenty of build systems available, and several of them are targeted at certain platforms or languages. It may take a while to become comfortable with a platform, but the savings are worth it.

  • GNU make – A standard system used by many Linux projects. It consists of a plain text file that lists targets and dependencies, and features many advanced features such as automatically determining which files require rebuilding.
  • Apache Ant – Ant is designed as a replacement for make, and uses XML files to describe the build process instead of text files. It's written in JAVA, and is completely portable.
  • nAnt – nAnt is a .NET based version of Ant, and although it is not exclusively for .NET developers it has many features that make it useful for building .NET apps.
  • A-A-P – A-A-P is a portable build tool that uses text-based "recipes" to compile and distribute software, but it can also be used for other tasks such as publishing websites and generating files from templates.
  • Visual Build Professional – VBP is a commercial build tool that takes a more visual approach to creating build scripts. It integrates well into many Microsoft IDEs, but also supports other languages such as Delphi and Java.
  • BlitzBuild – A free build tool aimed at BlitzPlus and Blitz3D developers.

Breaking the Task Down

Most build scripts will contain more than a single command, so it is useful to break the build script into different groups or "targets" that can be executed individually. This is particularly useful if building of data files is included, as it can be used for art or music to be built independently of the main application. Many build platforms also allow targets to be called from other targets, which effectively breaks a build script into a set of functions that can be executed in any order.

Common targets include compilation, installation and cleanup, but the choice is entirely up to the developer. It may also prove beneficial to include a separate target for generating debug versions of the application which can be distributed as a troubleshooting option.