Progress Update

THINGS ARE NOT GOING GOOD

via GIPHY

Stay tuned for more, soon.

Limitations of the BGE

After a few months of prototyping different things Ive come to realize that the BGE has a few crucial limitations for games of this size.



The main issue I'm facing at the moment is the lack of physical distance in the game engine. The BGE is limited to a 5km view in realtime (with 1-1 unit sizes for physics calculations), or 500,000km when edited as Campbell described to me on the BA forum (quoted below)

"as for floating point limits - if you have a 20m ship best scale by 0.1 and make it 2m. Real camera limit is 500,000 (set the grid size in the 3D view to 100.0). But these are not ideal solutions I think a proper solution could store a much bigger world in a database and load in parts to an area closer to 0,0,0"

500,000 is quite a distance, maybe enough to fit in a decent sized planet or a star, but to fit in a visible 360 degree sky of stars, stretching out into the reaches of space? Not a realistic goal currently.

So to get around this I need to come up with an efficient and fast system for displaying the far reaches of space, but in a smaller local area. Heres my first idea (drawn and described below) which I will code in python sometime soon to test.


The basics behind this, is that you have the ships position as point 'O' marked on the image. This is basically the 'origin' of the game universe. Point 'S' is the position of the star, which is at point (Sx,Sy,Sz) in the universe, in relation to the origin ship. The sphere around the point 'O' is the extent of the visible universe in the game. This is the sphere which the background star map is mapped onto, and its vertex parented to the ship (this means that it will always remain the same distance from the ship, but wont rotate with the ship as it tumbles through space) The most important part of this idea is point 'I' which is the intersection of the line from 'O' to 'S' through the edge of the sphere. At this point 'I' the image for the star will be displayed, its scale relative to its distance from point 'O', and this will/should update when the ship moves to a different location relative to the star.
Then, as a star or planet gets closer its image will increase in size, giving the appearance that it is getting closer, until it is inside the visible area of the sphere, where (with a basic LOD system thrown in) the star image will change into a physical object which the player can then 'interact with'.

The only issue is making this system efficient for thousands of stars, not to mention planets and other space objects (most of which can be ignored at appropriate distances anyway)




Along with this, there has been a lot of interest in finding the 'edge' of the BGE, which has been discussed here (http://blenderartists.org/forum/showthread.php?t=156488) I ran my own test on this, leaving a 'ship' object flying at max speed for several hours, sending its position information to the blender consol (I quit the simulation when it got to 10,000,000km), I didnt reach an 'edge' (I actually didnt come anywhere near reaching an 'edge') and the BGE also didnt slow down at all (as there are roumors that the BGE becomes laggy when you move a large distance from the centre)
So in conclusion, the 'edge' of the BGE will not be an issue for this Protostar game.



Ive also contacted MatrixNAN (one of the guys currently developing the BGE into a Pro engine) about these issues and he replied to my comment:

"I have a couple of questions.

For the BGE the view distances are very low, limited to 10,000 units, 10km for the 3D window, half that (5km) for cameras in-game. For most games this is fine, but for a big space scene or game with large scale objects (like ships of several hundred meters long) its hard to think of how to get it to work. Especially when you have hundreds of stars and planets in the background, ranging from several hundred km away to thousands and thousands of km away. Do you guys have any plans on making the BGE work better for huge scenes?

For a space scene there's usually not that much in between stars, so its not like it would be that intensive object-wise, its just viewing the large distances involved which seems to be a problem. "

With this:

"AD Edge:
Yes our game uses very large scenes so BGE should be able to handle much larger scenes than it has in the past. DXT is next month Campbell will be doing it. "

So that is at least something, they might be working on this issue and it might make my life easier in the future. But for now, time to start prototyping Protostar. ;)

The Story So Far

So I thought I'd post a little about the storyline the game will follow, as I haven’t got much work on the game done lately. I was hoping to have the main character underway by now, but studying full time at Uni and working every night has slowed progress to nearly zero. (I guess a lot of the work will have to wait until holidays)

Anyway I've spent 6 or so months prototyping the storyline for Protostar (The plot is crucial). Its been something I've had in mind for many years, so its good to get it down on paper - many, many pages written so far, I'm slowly transferring them onto my laptop for easier editing.

You take the role of a deep space engineer (no name or gender yet, might be optional). You’re returning from a 'business trip' several thousand light years from Earth (more on the methods of space travel, business and game location later).
Throughout space there have been several 'midway' stations built, which are smallish space stations for long distance travellers to dock at every few weeks as they journey hundreds of light years though deep space. The midway stations provide a temporary place to rest, refuel, repair and possibly meet up with other crews.

The game will start out with our main character docking at a midway station, which is currently unoccupied, landing in the landing bay. Our characters ship is tended to by automatic machines, while our main character heads to a 'lounge' area for food and relaxation.

Shortly after arriving our character is interrupted by an urgent incoming transmission. Its an Admiral from a certain division of the military, requesting assistance with a situation. He explains to the character that one of his large research vessels has gone missing in the area, and he needs someone in the area to find the ship, scan the ship to determine its status and transmit the data for analysis. He explains that our character is the only one in the system, he has dispatched a crew of his own but they won’t arrive for a week or so, he fears for the immediate safety of the invaluable ship.

So our characters initial order is to find the ship, by searching a series of nearby star systems (pointed out by the Admiral as the star systems being examined by the research ship) until the it is located. Then the ship must be scanned, and our character must return to the midway station to relay the data back to the Admiral.

Its a pretty simple mission, with a large pay check if completed. Unfortunately for our character the ship is discovered near a massive Protostar, the crew is unresponsive, the data uncovered points out some even more alarming facts. The research vessel is a ghost ship, no signs of life or power. Its dead and drifting though space like an enormous lump of metal. The most alarming fact however is its decaying orbit, the nearby Protostar has caught it, in its gravitational pull, and slowly the large ship is being pulled towards its fiery centre.


Your new orders: Board the ship, activate its Nuclear power core, its main systems, its engines and pilot it away from the Protostar.


That’s about as much of the story as I'll be giving away. Clearly nothing is as it seems, there’s a detailed mystery to uncover, one that turns a simple mission into a horrific grasp for survival.

Star Maps

Because this game will be based in space I'll need a lot of starry backgrounds. I found some nice tutorials for making realistic looking star fields using GIMP and gave it a go. My first attempt came out with this:

The title picture for this blog currently, not to bad for a first go!

After that one I made a much larger black and while one to test some resolution settings:


And then I made a very simple star map filled with basic stars (good for deep space scenes):


So there some good initial tests. GIMP will certainly be able to make decent star fields for this game, I could of course use Blender for this as well, so I might give that a try sometime. These textures are going to be tilled onto background objects in the game, to give a nice background of stars, nebula and other spacey stuff.

The Beginning - Protostar

'Protostar' is the current title of the game and every day it seems to sound better, so its probubly what ill stick to.
So what is a Protostar? The title certainly sounds space-like and somewhat mysterious (at least I hope so)

Putting it simply a Protostar is a star in its very early stages of development. It forms from a large interstellar cloud as the gases collapse inwards from strong gravitational forces. As the cloud gathers into a central point it begins to form a spinning sphere, the soon to be new star. The interstellar clouds swirls around this central sphere, until they are consumed by the new star or collected into orbiting lumps of rocks and gas (soon to become planets)

What does this have to do with my game?
Well the majority of the game will place aboard a large ship (named IcarusIV, of course), which is disabled and caught in the gravitational pull of the Protostar, with a strangely unresponsive crew. The scene would be spectacular, and a race against time to reach the ship, fire up its systems and propulsion drive, saving it from a fiery death. Easy right..?

But regardless, I find a huge developing star to be a unique and very interesting environment for a game like this, I originally thought to have a normal star, but that seemed far too cliche (and somewhat boring compared to a Protostar).

The final image below is an artists impression of a Protostar, certainly something you don't see every day. There's more information about Protostars on the Wiki.
So that's where the title of the game comes from, ill post some initial concept work and more plot details soon.

Weapons of Choice

So I'm going to make a game, which programs will I use?

That's always an important initial question for any game designer. Personally I've been getting into the open source software quite a bit, open source programs are free to download and usually have good support. Perfect for a hobbyist not wanting to spend thousands on industry software.



My first and favorite opensource (or otherwise) program is 'Blender3D'. Ive been using it for over 4 years now and have become reasonably experienced. Its great for all 3D work, ie modeling, texturing, rigging, animations and making games with the inbuilt BGE (Blender Game Engine). Its really a very flexible program, doing nearly everything you would ever want. There's also updates all the time, anywhere from 3-6 new versions come out every year, each with heaps of bug fixes and new features usually requested by the Blender community, along with great tutorial support so its nice and easy to learn.

Ive been part of the Blender community for as long as I've been using Blender. The main forum is at Blenderartists.org which features a great community of over 40,000 members. There's also a more game orientated forum at GameBlender.org.
I've also been working as a writer/editor at Blendernation for over a year now, which is great fun.

(Blender can be freely downloaded from www.Blender.org)



For 2D work the opensource program 'GIMP' is the way to go. Its just like Photoshop, except lacking a few features. But hey, it does everything I need it to, and saves me buying photoshop. Plus its regulary getting new features, much like Blender.

(Download from www.GIMP.org)



And for scripting, 'Python' is my program of choice. Mainly because its the native langue of the Blender Game Engine, and of course is free to download. Its even packed into Blender, so you dont really have to download it at all. Probubly one of the easyest scripting languages to learn.

(Download from www.python.org)


I'm also considering the OGRE or CrystalSpace game engines for the game, if the BGE cant handle it (the Blender game engine is lacking in some areas currently, but has improved a lot since a year or so ago)
We'll see how the BGE goes first though, I'd love to be able to promote the BGE and show what its really capable of when in the right hands.

'Breif' Introduction

My name is Alex Delderfield, I go by the online name of AD-Edge and I'm currently 19 and studying Engineering at University in Australia (South Australia).



This is the first of hopefully many posts on this Blog about a game I'm just beginning to get serious about making (Its been in preproduction now since mid 2008), this post should prove to be mainly an introduction of myself, my past and what plans I have for this game (snore, I know). I don't really get into the whole Blogging thing, seems like a waste of time usually, but I've wanted to start this blog as a place to record the history of this game as it develops. If no one reads it, that's fine, it doesn't bother me :) Sometime when this game really gets underway I'll probubly move to a dedicated site, but currently I don't know how long this game will take, and don't like the idea of paying for a website which potentially wont be worth anything for years to come (yes, this will be a long project *ehhh..*)


Anyways, onwards:


Ive had the idea for this particular game for quite some time, and have had a strong craving to make a very impressive game for many years. I grew up playing games (starting on an old Commodore 64) and moved onto a proper computer many years later. I also liked to make picture books when I was very young, moving onto written stories, then 2D animations and games, followed finally by 3D animations and games which is where I'm currently at.

No matter what the medium, there's always plenty of interesting stories to be told.


3 Facts:

1. My favorite medium is the realm of gaming. Nothing else gives the viewer/player as much immersion as games are capable of. Your directly involved with the events, and for me that's a very powerful thing, you have complete control over your audience, and thus you can have a very strong control over how the story is told.
2. My favorite genre is Science Fiction. Space stuff mostly, things like Star Wars, Star Gate, Star Trek etc etc. (See a pattern there??)
3. My favorite genre of game is Survival Horror (focusing more on Psychological horror, opposed to blood and guts 'shock' style) Of course there's a time and a place for shock horror, so don't worry, that definitely wont be ignored *evil grin*
   I'll admit straight away that a lot of inspiration has come from a horror game called 'Penumbra', which was made by a very dedicated team of 2 or so people and in my opinion is the greatest horror game created. It proves you don't need hundreds of game developers to make a professional and successful game. Personally I like working alone, its the best way to learn. Plus I'm a control freak, I like to have 100% control on the outcome.

So in summary I'm going to bring the three together and create:

A Science Fiction Survival Horror Game


Well that's the intro out of the way, more soon.