User:IneQuation.pl

What follows is a draft of my GSoC 2009 application.

Hello!

My name is Leszek Godlewski and I would like to apply to work on BZFlag in the course of this year's Google Summer of Code. I might be known for some of you from the IRC channel, where I go by the nickname of IneQuation.

The man

Education

I'm a high school student in the final year of pre-university education, attending a class with focus on mathematics and physics. If all goes well, I'm hoping to go to the Silesian University of Technology [1] next year to study computer science.

Games...

I got my first computer at the age of five (it was an 80MHz 486DX2 with 16MBs of RAM – those were great times!) and instantly fell in love with games. Having spent countless hours gaming over the years, sometime around 2000 I had what could be described as my first attempts at game modding. It wasn't long till I noticed that changing the way the games are played is actually more rewarding than playing them. Soon I became involved in the modding communities for several games, such as Medal of Honor: Allied Assault, Wolfenstein: Enemy Territory or Quake 3.

...free software...

My first experiments with free software took place in the summer of 2003. I wanted to try Linux, having read a lot about it, and someone pointed me into the direction of Slackware (to this day I wonder whether that someone was just playing a joke on me). As you could expect, I ran into all kinds of problems and was on the verge of giving up a few times, but with the help of the Slackware community I managed to successfully dual-boot Windows 98 and Slackware 10 for almost 2 years. I gave Linux up for some time, but returned to it last year with the installation of Debian, and my PC has rarely run Windows ever since.

...and a mix of the two

Being a FLOSS enthusiast (I've done some volunteer work for a Polish FLOSS support foundation, FWiOO [2]) and having a game modding background, it was only natural to try free game development. I had a number of projects based on the 2005-released GPL id Tech 3 (a.k.a. Quake 3 engine) source code; unfortunately, I failed to bring any of them past an early alpha stage. At some point I decided to learn something and move away from modifying ready-made solutions to coding something from scratch. This resulted in a sloppy, SDL-based multi-player top-down 2D shooter, whose code-base later served as a starting point for my biggest project so far, Destination [3]. It hasn't reached any usable state yet, though.

My humble contributions to free software can be viewed at my Ohloh account [4].

The plan

UPDATE: Disregard this, rewrite needed

Well, there are actually two. I'm probably going to apply for both. :)

Proposal 1: Game logic modularization

Abstract

In its current state, BZFlag has the game mechanics code mixed up in many places with the engine code. This is a legacy of the project's early development; the engine has been tailored specifically for the game and for a long time there was no apparent argument against tying the two so closely. However, today BZFlag is a project with a long development history, PC hardware performance improved greatly and this setup becomes very inconvenient when it comes to modernization and adding new features, such as fitting a 3D engine like OGRE or Crystal Space in to improve the game's visuals. The goal of this project would be to separate the game logic from the engine entirely, so that the game world presentation technology could easily be changed without interfering with the game mechanics. Another possible advantage is the simple introduction of mods.

The solution I'm presenting here is inspired by my past experiences with id Software's technology (Quake and Doom engines), which is renowned for its outstanding performance in networked multi-player action games and which I had a great opportunity to acquire an insight in as a game modder. I have also successfully implemented such a model in my Destination game engine.

The elements

If we are to separate something, we are bound to receive at least two products. Here, we have the engine (which is the game's main executable – bzflag or bzfs for the client and server, respectively) and the game library, a.k.a. libgame (which could be just a set of source files whose objects are linked into the main executable, or a separate static, or even a dynamic library, as is the case with id Software's technology).

Engine as the puppet

First of all, the role of the engine would have to be reduced to merely a tool to present the game world to the player. That is, it would contain code for video and audio rendering, network transmission, collision detection etc. – all the facilities the game may need. This functionality would be exposed to the game via a simple API (possibly via a pure virtual class defining the API and an object of a class descendant of that one implementing the actual calls), containing entry points for all the engine-provided modules.

The list of such entry points (on client side) could include, but is not limted to:

• print – dump text to game console
• load level – load a level from the VFS
• collision trace – check for intersection of a shape (e.g. a ray or a box) and the game world and/or other game entities
• add object to scene – add an object such as a tank, a bullet or a flag to the 3D scene
• render scene – flush all added objects to the scene and render it with the given point of view and field of view parameters (engine handles GL marix generation etc.)
• play sound – start playing a sound, given some parameters: location in space, volume, falloff etc.
• retrieve input data – retrieve player's input that occurred since the last frame
• retrieve world snapshot – retrieve the current state of the game world, as assembled from the other players' actions

And so on. A server's engine API would be similar, minus the audio and video functionality, of course.

WRITE ABOUT THE ASSETS HERE

Game library as the master

With the engine's role diminished, we'd have to allocate the released control somewhere. Obviously, it would be the game library – in the new model, it'd be here that all the important things would take place.

Similarly to the engine, the game library would expose its functionality through an API, possibly as small as three entry points:

• init – called at game initialization time
• frame – called every frame
• shutdown – cleans up resources, shuts the game down

The show

So, how would the two interact?

While the engine would perform a servant role in relation to the game logic, it would still have a great influence on the shape of things. After all, it would still need to load the game library and call its functions, and could shut it down and unload at any time.

In a normal client program flow, this is what would happen:

• engine (main executable) starts up
• engine loads the game library
• engine calls the game library's init entry point; gives control to game
  • game performs its initialization routine – allocating resources, setting up default values etc.
  • game calls the engine's load level entry point
    • engine loads the level's collision, 3D geometry data and imagery (textures)
  • game calls the engine's asset loading (smaller collision/geometry data, imagery, sounds) entry points
    • engine loads the requested assets, returning handles to them
  • game finishes initialization and returns control to the engine
• engine enters the main loop
  • for every frame the engine calls the game library's frame entry point; gives control to game
    • game advances the world – runs collision tests
      • engine performs the collision tests and returns their results

Erm. This is it for the time being; I've got to go now, but this is to be continued. :)