Archive for category XNA
Well, as you may have noticed from the lack of articles I have had a bit of a break from Britonia in the last three months. I’ve had a few things to sort out in real life, I’ve just brought a house and should be moving in in a few months, and I’ve been sorting out a few things for work. There are a few little updates though ..
I have wanted to expand on my previous post regarding ‘Cube to Sphere Projection’ for a while now, so in this article I am going to cover how I define the spherical geometry of the planets in more detail.
I decided to write this article in response to a comment by Robert on my previous ‘Ship Lists’ article. He brought up the fact that just calculating the specific physical properties of a ship doesn’t tell the whole story of space flight without first considering fuel and payload. You can read the original comment here.
Quite honestly I glossed over the fuel and payload section in the previous article because I knew it would be a problem and I hadn’t quite decided yet how to handle the issues in-game. The question is of course “how realistic will the game be in terms of fuel and fuel consumption”? and “will be by fun/entertaining for the player to fill up the cargo hold full of fuel just to be able to leave the atmosphere of a planet”?
The three approaches which are most obvious at this stage are:
1) Simulate Realistic Physics and Fuel Consumption : This is certainly an appealing approach and a lot of people would perhaps admire such a simulation for its realism, but will definately be off-putting for casual gamers. Furthermore, accurately simulating spacecraft using real physics models is extremely complex and involve many factors; all of which aren’t really feasible or a benefit to simulate. This would also introduce issues of ship design. As an example, the thrusters required for huge spacecraft to launch would themselves be huge; and would have to appear to scale on the ship. Add to this the need to place thrusters all around the ship for rotating and ‘strafing’ etc. and the ships will no longer look slick and cool (yes cool) but like big masses of ugly efficient-functionality.
A few other less-than-fun issues introduced with this system are ‘what do you do if the player runs out of fuel?’ As always there are a few ways of handling this, but short of actually waiting for someone to come and pick you up would break the realism we were striving to achive in the first place. This is a concern.
2) Forgo Fuel Consumption: This approach was adopted in the Elite series whereby conventional thrusters didn’t require fuel for acceleration; and this definiately had its merits. For one, the player only needed to concern his/herself with purchasing fuel for hyperjumps to use the jump drive and there was nothing overly complicated with taking off and leaving a planet. Just ‘launch’, rotate the ship upwards and fire! As you can read in Robert’s previous comments, this eliminates the issue of taking off within a the gravational area of a planet.
3) Use a mixture of the two above. : Now I’m all for realism and I’ve read a lot of comments which go both ways on just how real to simulate things like this, but I’m just not convinced that simulating real space flight dynamics will be fun for the player. Also, to pass up the issue of fuel will remove some of the element of ‘danger’ and planning I think has the potential to be enjoyable. So at the minute I plan on using a mixture of the above, but perhaps a little differently than tradional space sim games.
I am thinking about including three different engines types for flight, each of which will be mountable in one ship thruster slow/position. Here are the three types (not including Jump-Drives):
ION thrusters are used in real life for long distance space flight. They are typically favoured because of the relatively low fuel consumption when compared to traditional chemical engines. This improvement in fuel consumption is because electic thrusters typically offer much higher specific impulse (this represents the change in momentum per unit amount of fuel).
There are a few draw backs with ION thrusters though, which when implemented in the game will lucky add a little diversity. The first draw back is that they don’t provide as much thrust compared to chemical thrusters due to practical power source contraints. The second draw back is that they only work in environments that are void of ionized particles, so if you decide to equip just ION thrusters on your ship, you wont be able to land on planets with atmospheres.
There are three kinds of ION thruster in real life (Electromagnetic, Electrothermal/Plasma and Electrostatic). There will be diferent ION trusters available within the game but the differences will be purely cosmetic (different thruster description, different coloured beam), with all thrusters performing with the same characteristics:
Low fuel consumption (read: no-fuel consumption)
Cannot fly within atmosheres
Low thrust (force) output
A good option for beginning players as the there is no need to worry about fuel consumption and/or running out. Hopefully more experienced players will want to eventually opt for more power chemical thrusters for greater acceration.
Chemical Rocket Thrusters
Currently all spacecraft use chemical rockets for launch. Chemical thrusters require a large amount of fuel to operate, but provide consideratly more thrust than ION thrusters. In the context of the game, chemical thrusters will be required to navigate within the atmosphere of a planet, and will indeed require fuel to do so, although the fuel consumption may not be realistic:
Provides much more power compared to the ION thruster.
Functions in atmospheric conditions (i.e. planets with atmospheres).
Would be plausible that the player can run-out of fuel and thus would need rescuing.
A good choice for players who want faster ships but requires a little more journey planning and management of fuel.
Whilst perhaps not currently technically possible I would like to include some kind of hybrid technology to make the game more sympathetic to new players who perhaps don’t want the hassile of outfitting different ships and just want to ‘shoot things’. The hybrid engines will non consume fuel in outerspace, and will require significantly less fuel when within a gravatational area. This will come at the expense of having significantly lower thrust outputs then the chemical or ION/plasma thrusters.
Offers both the benefit of power provided by the chemical engine and the ease of mind of a fuel-less alternative for emergencies.
No restricts on environment conditions
Provides less acceleration than either the electric or chemical engines of the same class.
To Sum Up
So hopefully with the details mentioned above it should be a little clearer to see what I intend to do. If you decide you want to outfit one ship for space dog-fighting, then you may want to use chemical rocket engines and refuel often for the advantage of higher accelertion. If you are a trader, then perhaps ION thrusters would be beneficial considering you needn’t worry about fuel on long journeys. The last question which I haven’t address yet is the actual consumption of the chemical engines, however this will be fun-factor based so its a little too early to say.
For the last three weeks I have started modeling the first in-game content for Horizons, the ‘Locust MK I’, using Blender3D and paint.NET. This time round, I’ll go over how I am exporting model and opaque data from blender, texturing the model with UV maps and paint.NET and importing them into XNA.
A lot of developers I speak to often ask if I use a form of SVN (SVN wikipedia) and when I answer in the negative, they usually tell me of the benefits of doing so. Now I haven’t used it (much) before and I’ve never really had a reason to, being that I am working alone on Britonia and I only really use my main computer for development. But I thought, if everyone’s doing it, maybe there are unseen benefits …
So I had a look around on the weekend for project hosting sites which offered free hosting using SVN, and I found a few. Many of the project hosting sites however only offer only free hosting to open source projects, but I did manage to find one called ProjectLocker. It seems to have everything I could need for hosting my project privately and it also offers an intergrating Trac system. So I thought I’d give it a go.
For anybody who hasn’t heard of SVN, basically it offers a way to host your entire project (minus build and object files) on a server and using a tool like TortoiseSVN in windows, you can quick and easily download (checkout) or backup (commit) changes to this one central repository. It also keeps a copy of all versions of a file and logs changes made.
This makes it easy if say, you want to work on your project from several locations, or you have multiple developers working on a project.
For now, while I still haven’t setup it all up – I am hoping that the Trac system will help me focus on specific enhancements and bugs in Britonia. I’m finding that when I sit down I spend a good 1-2 hours just playing with what is already ‘working’; tweaking the heightmaps, changing scattering colours, flying around the planets etc.
If you want to try it out, here are a few links to the tools which I am using :
This can be used to quickly upload/download files in your project.
A plugin for Visual studio professional (does not work on VS Express :()
Project Locker: http://www.projectlocker.com/
There are many hosting sites, but this is the one I choose because its private and free.
Bug tracking system.
I have been thinking quite a lot recently about some of the upcoming aspects of Britonia, and some of the decisions I made at the beginning of the project. For a long time I’ve wanted to create a game with a sense of depth and emersion, somewhere you could go and play open-endedly, without a sense of the end of the game drawing nearer the more you unraveled the story or progressed through a dungeon. Obviously, this is not as easy a task as it sounds, but thanks to procedural content, it is not totally out of the question.
I set myself no time limit for finishing the development of the game, piling on the features. I knew it would take a long time, but that didn’t bother me and indeed it still doesn’t; after all what is the point of making a game if you don’t enjoy it?
I spend quite a lot of my free time working on Britonia (or at least XNA related projects), but there are still a great many things required to get a full game working which I haven’t even started, and I think it would be better ( or faster) in the long run if I change the theme of the game before I get into the actual in-game content creation.
Therefore I am considering to change the theme / genre to a Space trading simulation, just like the old classic Elite by David Braben and Ian Bell.
Luckily though, changing to a space sim wouldn’t require me to re-write reems of code, so everything I have done thus far will remain largely unchanged. Of course the ‘new’ space game will have you landing in ground ports and/or flying around the surface of the planet looking for minerals and artefacts.
So why the change?
Simply put, after comparing the content required (models / textures / environments) for both a space sim and fantasy RPG, I think I have a much better chance of creating believable content for a space sim as opposed to the likes of human NPCs and monsters. Some of the other considerations are :
|Medieval RPG||Space RPG|
|Planets||Travel at low altitudes along the surface causes the planet quadtree to update often, and subdivision for quad nodes are always x4. Furthermore, because of the detph of the quadtree, a lot of memory is needed for the heightmaps/normal maps etc.
Adding to this, trees, npcs, towns and ground clutter ….
Planet based RPG’s don’t require realistic distances or accurate planetary movements (orbits/rotations).
|NPCs / Monsters||Modeling of NPC’s and Monsters is very complex, requiring many different animations (skinning).
Creating AI to mimick human behaviour is even more difficult.
I don’t do faces – creating a good looking one would take me hell of a long time 😦
|Modelling Spaceships is conderably easier than organic lifeforms. AI is still a challenge, but that’s AI.
Animations can be done using rigid bodies, and is typically turret points and/or landing gears.
|Towns / Communities||A high level of unique geometry (models) would be required to create believable variation in different towns. Each individual building of a town in a medieval RPG would have to exist in full with all expected functions. (A tavern would need a bar, tables chairs etc. etc.)||Cities can be represented with one (or a few) larger city meshes. Which means getting away with considerly less geometry.
One central spaceport UI screen contains all the different ammenities / services, once the player has ‘entered’ the city.
|Travel / Distances||Travel between planets is achived via ‘stargates’. I do still very much like this idea.
Travel on the surface is slow and takes a long time.
|Dude – Spaceships!|
|Textures||Buildings are constructed from different materials each requiring a unique texture. Also different altitudes affect the colour of the texture (white of mountains etc.)||It’s common knowlede that all spaces are grey with yellow windows. Easy|
I just wrote these off the top of my head, and I must admit it is hard to remain impartial after convincing myself a change is needed, but even looking at the above table I think the space sim would generally be faster and easier to implement. Although I made a few less-than-serious remarks above, some of the areas such as travel / distances are obviously made easier with the concept of space flight.
Well, please let me know what you think because I still haven’t fully made up my mind yet. You have until the website theme changes to a space scene to leave me your comments 🙂
As with all games, Z-buffering plays an important part when rendering the pixels to the screen. During the development of Britonia I have often run into a problems related to the Z-Buffer, so I thought it would be nice to share what I have learned about them and how to avoid these issues.