Development diary #3

Long time no see...

Well, the engine is moving steadily. Most of the ongoing features are complete or stable enough now to comfortably keep expanding.

Those features include the modular graphic framework, wrapped around SFML/OpenGL which can handle Sprites, Text, as well as custom "visuals" (e.g. the main planet has its own type). Although the framework act as a wrapper, it also abstracts the data, allowing the user to easily add new visuals to the scene, move the viewport around, without having to worry about optmization : culling, occlusion, depth, and so on.

The object manager I talked about in the previous diary is almost fully working, and supports two types of objects : objects and visible objects.
The idea behind that system, is that users can easily create new types of objects, which can either act as a game object (e.g a character, with a sprite and AI), or a more abstract component (a radar ) which would run in the background. Once the object has been written ( for now only in C++ ), the user just needs to insert it whenever he/she wants during the game, without having to worry about calling the appropriate update function (which is being handled by the object manager).
Some examples of the system being used are the console GUI, and the planets.

Talking about planets, I have rewritten the main planet code from scratch, in order to correspond with the current engine's structure. Initially in the prototype version, which wasn't very much optimized, the landscape was generated using RMD ( random midpoint displacement : http://www.gameprogrammer.com/fractal.html), and used a very primitive LOD ( level of detail ) system which would skip a certain amount of points based on the zoom factor and the screen position. All of this has been rewritten aswell, using a binary tree structure, and proper viewport culling, which in the end increased the performances by 10, if not more. This not only improves performance, it also means the level of complexity can be increased even further with no issues, as well as allowing easy geometry alteration.

This particular point will be the next one on my list : terraforming will be a key element in Biosphere. The terrain will be altered by your settlers when building infrastructures, meteorites colliding with the planet, and possibly volcanos and errosion.

To give you an idea, I am running the whole application at a stable 300FPS on a laptop with an Intel dual core 2.1GHz CPU, 2048MB of RAM and a Geforce 8600M GS.

Finally, an interesting (in my opinion) feature I recently implemented, which I had not planned initially : the inclusion of the Python scripting language, more precisely stackless Python : http://www.stackless.com/ ( other games such as Eve Online use it ). The idea of using the scripting language is to abstract and encapsulate the game engine, as well as making it alot faster and easier to define and alter the game code. Although it is not fully linked with the engine's component yet, it should allow the user to easily extend the game, by deriving base objects into his/her own custom objects, make menus and interfaces without requiring any knowledge of C++.
The other benefit of the scripting layer, is that it simplifies the memory management process : python has a garbage collector, and once plugged into the engine, it facilitates the whole allocation/deallocation process, making it a safe engine to use. Although some people might argue over the fact that scripting languages are slow, the interpreter is run in parallel of the C++ code, at a controlled speed, meaning no slow downs, or stalls.

In the end, I have still decided to keep the python script optional, as I found it added an extra dependency to the application ( users are required to install stackless Python in order to run the game ). So basically, users should be allowed to choose between C++, Python or even both, seemlessly, and include it or not with their application.

What's new ?

Voilà !! That's all for now, so let's have a look at what I have done so far :

• Working modular graphic framework, with a stable pipeline, and which now handles viewports (singular for now) and custom types (e.g. the planet renderer).
• Working object manager, with easy implementation of custom components.
• Implementation of the stackless Python interpreter, allowing the game to be coded both in C++ and Python.
• Main planet landscape with working dynamic LOD.

Plans for the future ?

I have quite a lot ahead of me, but here is what I'm aiming to achieve soon :

• Fully linked Python interpreter with the ability to fully script the game mechanics.
• Terraformable terrain.
• And of course the other core components, such as input and sound (already supported, but not embedded in the engine).

I have a couple of weeks work-free, so hopefully, I should be able to post some more update soon. In the meantime, here are some snap shots of the LOD system in action :

Development diary #2

A busy month...

A couple of weeks have gone by, and I haven't had as much time to spare on my project as I would have wanted to. Anyway, I have still managed to make some progress, and here is out it went :

As said in the previous entry, my aim was to implement a modular graphical renderer/handler, which could handle both SFML and OpenGL (my main renderers), but also allow the developer to seamlessly code another renderer (based on Direct3D for example, or any other rendering library), and plug it in the engine, via a DLL.

For the moment, I have set up the abstract renderer class, as well as the basic types (Sprites, Animated Sprites, and Text), and have created my own SFML/OpenGL renderer to demonstrate the principle, and fortunately it works!!

I have also worked on data abstraction of objects, visuals etc, and making the engine as modular and independant as possible, to allow myself (or someone else) to be able to use the engine for another game, without having to delete all my game-related code.

Finally, the rest of my time has been spent on solving glitches, adding more features to existing components, and improving the engine's architecture.

So what's new ?

Enough with that, here is a quick summary of my progress for this dev diary :

• Implementation of a modular graphical renderer (or should I say framework )
• Implementation of an abstract object manager, to handle all the games assets.
• Tweaks in the engine's architecture, making it easier to use, and less dependant of the various components.

What's next ?

In the near future, here is a list of what I am aiming to achieve :

• Fully working SFML/OpenGL graphical renderer, and rendering pipeline
• Fully working objects systems, allowing users to add either assets, or external modules to their game, without having to sneak into the engine's structure.
• Working input system following the same design as the renderers, meaning modular, and independant.
• Working audio system, again modular.

Unfortunately, I have no pictures to illustrate my progress, as it is mainly internal to the game's engine, and thus visible, but I did manage to find a video of the early prototype, and thought I might post it here.

Hope you enjoy it !!

Development diary #1

So here it is : my first development diary.

If you are here for the first time, and wonder what the hell that picture is about, I suggest you start reading the previous article, explaining what Biosphere is all about ;).

Preliminary work and prototype ?

For the last couple of months, I have spent my time mostly thinking about the game, and writing up various documents, be it a game design document, UML class chart, concept art, or just random ideas on a piece of paper.

The first prototype I managed to put in place featured a simplistic view of a solar system, with rotating planets, as well as a randomly generated planet with varying LODs, and a zooming feature allowing the user to look at the planet's landscape closely, as well as admiring the planets' rotations. I made this prototype in order to solve a few technical issues (notably the varying LOD), get a general feel of game ( if the sliced 2D view really worked ), and basically whether I thought the game would work.

Expanding from this small prototype, I messed around with the code, adding new features and testing out bits and bobs to see what else I could add to the game.

What about now ?

From there, following my various charts and notes, With the word "modular" in mind, I have started from scratch, programming the lower layer classes that will handle vital information, external components, and provide the game with dynamic information. These components include configuration files, to defines various engine variables, such as screen resolution, level of detail, language, keyboard mapping, etc., but also custom localization files, that enable the game to handle different languages, but also allow new languages to be added later on (I only intend to release it in english and french for now, but it is still nice to know it is possible).

Finally, the last two days, I have been linking all these handlers together, as well as other minor classes, under one main component : the game engine.

I'm not a pro (yet... ^^), I don't know what is the best way to make a game, or if my way is a good one, but here is how I went:

The game will be split into two parts, the engine, and game states. Basically, the engine is a huge controller, which handles the window, input and output, reads and write from/to external files, and plays the game state (can be a level, a menu, or just a cut scene), forwarding all the necessary info (mouse input, external data) to the current game, and then outputs what is necessary (console information, picture, sound, saved game, etc.).

I won't go too much into detail in this first development diary, but I might describe the structure in detail if people are interested ;) .

Anyway, for the moment, the brand new engine is working and running, and this is pretty much all it can do for the moment:

• Can read external files such as configuration files and localization files.
• Implements a console which incorporates a graphical display as well as a log (for debugging purposes).
• Can play game states, and also has a nice fade in/out effect when switching between screens.

What next?

Missing from the list, and which will be next are :

• Input/Output handling of the keyboard and mouse ( I use SFML for the input, but it does not provide all the control I need).
• A modular graphical handler ( considering the game uses both SFML and OpenGL).

Here, done with the first development diary, hope you enjoyed reading it, and please leave a few words, questions, advice, or just a constructive comment, and look forward to the following development diary in a couple of weeks.

Biosphere... Qu’es aquò ?

You are probably wondering what a game with a name like "Biosphere" is all about and where the idea came from, well here it is :

Where did it come from ?

A couple of months ago, I had the idea of testing my programming "skills" by trying to develop a short term application (given my spare time) based massively, if not exclusively, on procedural generation. I also had a few good ideas flying around in my head about a space colonisation game (probably triggered by an Alien movie marathon :) ...) and so it felt natural at the time to give it a shot.

What goals did I set myself ?

Initially, I was thinking of making a 3D game featuring procedurally generated planets, with fractal landscapes, atmosphere scattering, and all the cool effects... But then, a few seconds later, I realized how far I was from my initial simplistic and "short term" goal. I then set of to make a 2D game, and figured it would make the game more original and unsual anyway, as well as making it a lot easier to code. Again, to test my programming knowledge, I decided to settle on making a game that would be modular (allowing new assets to be added externally, support new languages, etc.), as well as small, fast and multi-platform.

What is the game about ?

My project is undergoing changes by the second, but the basic idea remains the same.

The year is 2258 and Human kind is struggling on its old wrinkled planet : Earth. As part of a global emergency project, a massive space colonial project has been initiated in order to explore the universe in search of resources and shelter.

In Biosphere, you play as the commander of one of these "missions", and have been sent to create viable settlements on non-viable planets, frequently lacking any atmosphere, and exposing your fellow settlers to harsh conditions, such as high temperatures, steep landscapes, and much more.

How does it work ?

Hopefully, the concept it quite clear. As for the actual gameplay, that is another question...

In my mind, I picture the game as featuring a 2D sliced view of a random planet with a high level of complexity, providing the player with a powerfull zoom feature. He would be able to manage his settlement from a close up view, as well as admiring his planet and its satellites from far far away (see the pictures below).

After having landed the headquarter module in the similar fashion to a lunar lander game (featuring the planets gravity, etc.), the player would see his first settlers walk around the newly formed colony, and start building various infrastructures from solar panels to hydrogen generators and greenhouses (technology has evolved quite a bit since) in order to produce energy and food for the settlers to survive and procreate. In the meantime, the player would assign his minions with various tasks, from exploration to mining, as well as altering the planets chemistry, and try and create a viable atmosphere (hence the name : Biosphere).

Once the colony becomes self sufficient, and if an atmosphere has successfully been created, the player would be free to takeoff again and move on to another close unhabited planet.

As part of upgrades and bonus for completing levels, the player would beneficiate from resources gathered in the previous planet and sent on demand, as well as special bonus buildings or resources summoned from Earth and sent in huge rockets.

The challenge and fun would remain in the diversity of the planets encountered (dry, sun exposed planet with a harsh landscape, to a flat dark icy planet), the amount of resources available initially, the choice of buildings and strategy, as well as having to deal with alien species (either animal, or plants, which would insure the planets ecosystem, meaning the players action could have disastrous unexpected consequences, similar to what happens when you wipe out the Amazon forest and worry about oxygen afterwoulds).

All in all, this game is intended to be semi-realistic, providing the player with a plausible background, but focusing more on fun, feeling, and gameplay, with a simplistic display and interface, but also fun, crazy and original buildings.

Stay sharp for the first development diary, where I will try and sum up what I have done so far as part of my prototype, and what I am currently working on...

Welcome!!

Greetings every one, and welcome to this blog dedicated to my work, and more specifically my ongoing game project : Biosphere.

For a quick brief of myself, I'm Craig (a.k.a Althar), 19, and have been programming for a couple of years now, as well as messing around with all the softwares I could get my hands on (graphics, audio, etc.). I have always loved creating things, and always wanted to make video games ( which is a blessing, considering I'm currently on a computer games programming course).

The reason I have set up this blog, is so that I could expose some of my work (of all kind), mostly done during my spare time, as well as give you some insight and ideas on game making, in a similar fashion to development diaries, and hopefully I could get some constructive feedback, and share ideas with all you visitors.

Enough with the boring introductory bit...

You can either be an amateur programmer like me, or the occasional stranger that got on this website whilst googling for some obscure words, I just hope you enjoy reading about my work, as much as I can when reading about fellow programmers from all over the net.

Happy reading !!