I have decided to migrate this site to a Simple PHP Blog based system located in here. This will enable readers to comment on news and to establish light discussions about development. If this system proves to be a working solution, this site will become deprecated.
Basically all game elements for the first release start to be in place. The teamplay code is quite done and we had another three player test sesstion the other day. I have also fully implemented a bleeding and treatment system: a gunshot will always induce bleeding, which the player can stop by applying a tourniquet. This will change in the future so that only team members can treat each other, but not themselves. The weapon accuracy and recoil are also now affected by stance and aiming down the sights. It is also possible now to switch between semi-automatic and full-automatic firemodes.
At the moment some systems are yielding a bit too low FPS figures, which I suspect is related to VBO usage in the terrain rendering code. This should be resolved before the release. In the meanwhile, please feel free to check below the new game description, which I rewrote to reflect the current visions.
I updated the feature listings below to reflect better the current state of the project. I've been also working on the player team system that will be seen in the first public test. At the moment the basic team structure exists and players are assigned automatically to the most disadvantaged team. Also the score board now lists players under proper teams and displays the total team score. I still need to figure out the most efficient way to assign proper team-skins to players.
I was so excited about getting the real-time shadows working, that I decided to complement this with a dynamic sky. Now, making a physically correct model for the scattering of light in the atmosphere is beyond the scope of this engine, but a skydome and a simple fragment shader can yield graphically quite pleasing results. I have uploaded a combo screen shot showcasing different times of day and the appearance of the sky and environment. Of cource a video would deliver the experience more vividly, but for now this will do. I'm considering, that the dynamic day-night rotation could actually play an important tactical role in the game: the shadows of the night could be used for sneaking and flanking, but the muzzle flashes would give away the position. During the day, one should be aware of walking against the bright sky.
At the beginning of the engine development, I decided not to pursue great graphics, but rather to concentrate on the most crucial components needed to build a network game. I think I already reached this point some time ago. I remember reading about shadow mapping and stencil shadow volumes already about 8 years ago, when I was starting OpenGL coding, and I certainly remember how frustrated I was realizing how many hacks the robust implementation of either would require. This is basically why I was ready to give up any real shadowing in this engine to keep things simple. Yesterday, after a moments thought, I started to look for shadow mapping articles and tutorials to see what modern implementations would look like. I was a little surprised how easy a GLSL based implementation can be today. So after coding long into the night, I now have implemented simple shadow mapping based on FBO and GLSL! This awsome advance will take the game into truly modern level in graphical features. Please, check out the new screen shots. At the moment, the shadows look quite aliased at close up, but otherwise the implementation is quite robust in the sense, that it can be used in a real game scene, not just in some well confined demo scene. I will soon look into soft shadows by using variance shadow mapping technique.
Yesterday we had another 3 player test session on the new map, which is the most versatile map so far. The gameplay feel was very good in general, at least for me with almost constant clamped 60 fps (running on Ubuntu 10.04 on i7 920 and GTX 260). Surprisingly the only slightly lower-end machines running Windows pushed only 30 fps, which I need to investigate. I used some time to improve the player-world collision detection and response, making it more reliable. It still seemed, however, that sometimes a player could go through an object. These things usually result in round-off errors in floating point arithmetic and require a ton of hacks to become reliable. See some new screen shots that were compiled from the test session.
As implied, the game is quite ready for a public test. I have started to write the mandatory README and LEGAL notes and to design the final packaging. There will be 32-bit and 64-bit Linux binaries and a 32-bit Windows binary, but most probably no OS X binary, since I would need a Mac for setting up the compilation environment (I will not consider cross-compiling, not after the brain melting last attempt). I'm still planning on exactly what features would need to be added for the first release. Most probably it will be much as it is now, simple death match, but I might still add e.g. bleeding and a more realistic damage model.
It has been a while since the last news entry, and development has been slower than before. Periods of this sort are to be expected, but hopefully a burst of development will follow soon. I'm hoping that an open gameplay session could be arranged during the summer to see how the game works with more than three players. For this I still need to add support for team based death match and make the program more reliable in the many situations that arise during gameplay. I uploaded a new screen shot showcasing a pair of shacks in a work-in-progress map.
Some time ago I started modelling a vehicle model, the infamous UAZ. It's not intended that players could actually drive vehicles, but as static meshes they add realism to the game environment. Check out the screenshot of the fully textured and normal mapped mesh from here.
I added the capability to specify particle emitter properties in files, and also user can now load a particle system in the edit mode for quick testing. To try this out, I created a few new debris and bullet impact particle emitters for the game. Check out a new video on this in the media section. I also reskinned the assault rifle with more detail this time and created brand new animations. See also the "loading" image I created with blender from here.
The development team of three took a short network game test sesstion to see how the game play feels at the moment. Several minor areas of improvement were found, but the gameplay felt already quite smooth. After the most troublesome shortcomings are fixed, we need to try to test the game with far more players. The minimum player count target is 4 vs 4, so the network code and engine performance need to be tested with eight players at some point. If you are interested in participating in the testing process, feel free to contact me by email. See the media section for screen shots from the test session.
As May begins, I report an advance in the terrain renderer, which now supports Vertex Buffer Objects with indexed arrays. This significantly improves terrain rendering efficiency by taking advantage of modern GPU vertex pipeline. Additionally, terrain renderer now minimizes texture bindings to further improve efficiency. I also started modelling a new map, which is based on a tropical setting. Please check out the new screen shot.
I have uploaded a video showcasing a map that I have been building up while developing the engine. The video illustrates also some of the basic map editing capabilities that are currently implemented. The video is encoded with MPEG4 (xvid). As soon as the network code gets a bit smoother and some more character animations get done, I will make a gameplay video.
I connected the player-world collision detection code to the quadtree structure to speed up things. Now having thousands of meshes over the map does not slow down the game due to collision detection. I also added the possiblity to add ambient sound easily to maps, as these lift the mood of gameplay a lot.
The FPS game -section was updated to reflect the current ideas of the game more carefully.
Finally I managed to complete one of the most important graphical features, namely the level-of-detail system for static and skinned meshes. What this means is that an artist can define several versions of a mesh, each version being a representation of the mesh but with varying number of polygons. Then game then displays higher detail version the closer the mesh object is to viewer. This allows the game environment to have a huge amount of detailed objects. The test map that I have been running has over 1k objects and the game is pushing 60 fps fine (actually the terrain renderer is now the bottleneck, VBO should fix this).
I also added different stances for the player, that is crouch and prone. This is currently only visible for the avatar, but I will add the proper animations to the character soon. I uploaded four new screenshots so check out the media section.
In addition to only minor tweaks for the engine, I have spent some time with blender making a few new models and animations. This time I took full advantage of normal mapping and baked normal maps using low-poly and high-poly versions of a mesh. The new view weapon has a fully functioning and aligned ironsight. See the new screen shots a the media section.
These new models do not represent the final models that will be in the game, they are merely training pieces from my behalf. Very detailed player and weapon models have been under development for some moths now by two artists Mika Malin and Riku Malin who are also participating in this project. Hopefully the models are finished in a copule of more months so that we can get a real picture of what to expect from the visual aspects of the final game.
A month has passed since the last news entry and the development has been a bit on the slow lane. Mostly due to being occupied by work and studies but also because I wan't to wait until new weapon and character models are done. I have decided to modify the terrain texturing somewhat. Before the terrain was textured in a single pass with up to four different detail textures. Each detail texture had an associated color. The result looked quite dull in color and detail, so now I'm going to change the approach. Firstly I will add normal mapping for terrain also. Additionally an arbitrary number of textures can be used in the terrain and all is rendered in multiple passes. Only four textures can be blended locally together, though, but globally the number of textures is not limited. Basically texture weighting will still be done per-vertex, which will limit texture blending resolution. I have also played around with an idea of adding the capability to create roads and road networks on the terrain.
March is pushing on, and so is the graphics frontier. I have developed a nice looking water shader, which should add to the overall visual output of the game. It is quite a simple combintation of dynamic normals maps and cube reflection maps. I decided to go the cheap way with the reflections: only the sky is reflected, not the terrain nor other objects. This probably won't look too bad, if most of the time the water is observed from a semi-convex terrain. Check out the new screen shots.
So, eventually I managed to solve the problems that I faced with the GPU skinning implementation. Now it is working, but the maximum number of bones is currently limited to fifty, since the code does not yet split the mesh into submeshes with fewer number of bones. Shaders can only handle up to around 512 floats as uniform variables, so to have more bones requires the mesh to be split up. But the performance of skinned mesh rendering is very good now, and I expect the engine to handle animated characters that consist of thousands of polygons.
I also did some basic work towards implementing decent terrain editing tools. Currently user can lift and lower terrain areas simply by dragging mouse over the terrain. This is very cool already, but I intend to add also a smoothing function and the ability to paint detail texture weights.
I decided to take a slight deviation from the keeping-it-simple plan and implemented normal mapping in the lighting shaders. Actually, implementing normal mapping is not a complicated process nowdays, since the shaders support a wide range of functionality. The only thing that requires more work is to build the tangent space basis, which is actually quite simple in the end. One consequence of this feature is that skinning will be even more demanding on the CPU, since the tangent vectors need to be transformed also. So I decided to implement GPU skinning and while this is quite far going already, I'm having some troubles with it. Hopefully I get it to work soon. I have no new pictures to show regarding the normal mapping, since I really don't have good normal mapped meshes to go.
The rendering pipeline optimizations continue as I have implemented a fairly simple yet effective visibility determination scheme based on the quadree datastructure. The idea is to recursively divide objects in the scene into square areas, which are divided into smaller quadrants until a certain object per quad threshold is obtained. The visibility of these quads can then be efficiently determined. Also the terrain subgrids are now frustum culled. These measures are essential for the realization of moderate sized and detailed game environments. The terrain LOD and quadtree constitute a major milestone in the development of this engine and I'm quite pleased with how far this project has evolved in such a short time.
Finally I took the first step towards more flexible terrain rendering and implemented a level-of-detail (LOD) system. It is based on the idea of geometric mipmaps (or geomipmaps). This means that the vertices in the terrain are divided into square chunks, and the amount of detail in each chunk is determined by some error metric, which takes into account the terrain detail in the chunk and the distance of the chunk relative to observer. Ideally, the implementation should be able to relate the error in lowering the detail of a chunk directly to pixels observed on the screen, but this is still under development. I also added a console command, which can be used to place an arbitrary number of static meshes around the terrain randomly. I tried this out with around 700 trees, and then it started to be obvious, that a proper frustum culling and mesh LOD is going to be needed if scenes of this complexity are desired (FPS dropped to slightly below 20). Check out the new screenshots below.
I started playing around with frame buffer objects (FBO), which consitute a rather common OpenGL extension on today's hardware. I was able to implement quite a neat "pain effect", which is displayed when a player is hurt. The screen will redden and go blurred (see the new screenshot here). This is achieved by rendering the scene into a frame buffer object, which is bound to a low-resolution texture. Four screen-sized quads is then drawn with this texture bound, to give the blurred effect. Also, I did some preliminary work towards implementing a locational damage model. At this point, a head shot is recognized and will cause instant death. In the future days, I will try to add some bleeding-feature, so that each wound will cause, in addition to instant health loss, a bleeding whose degree depends on the hit location.
OpenAL is a very versatile audio interface, but my experiences with it have not been too positive in the past. Getting the many parameters it offers, specifically the distance models, set up correctly is a lot of work. So I decided to go along the major lines of this project and take the simpler route here also: I'm adapting the SDL_mixer for sound interface. It only offers the most basic sound features, but I'm sure this will suffice. The engine supports now point sound sources with a simple but effective stereo 3D audio impression. The panning and gain depend on the position of sound source relative to observer. Basic stuff. To add a bit more, the game chooses between two samples for gunshot sounds depending on distance. With large distances, a low-pass filtered, slightly echoed, sound is played back, to give the impression of uneven frequency component decay that can be observed in real life too. Additionally, there is a semi-realistic finite sound propagation velocity model, so that gundshot sounds and explosion sounds will be percieved with a delay relative to the visual feedback. This is rarely seen in games (I think Operation flashpoint: Dragon rising did this) although the implementation is very simple.
Currently the CPU skinning is a major bottleneck in the engine performance. I did a few optimizations to this. To mention one, I converted the rotation of points by weighted bones, which was done by quaternion multiplication involving three quaternions, into 3x3 matrix-vector multiplication. It would be nice to have around 4000 polygons in character meshes in the game, but I think the current implementation of CPU skinning is not going to manage this. I'm considering two choises here: precomputing all animations at say 30 frames per second or implementing GPU skinning in vertex shaders. The first option will hog a lot of memory, but would be easy to implement and it would certainly be fast. The second one might be a bit tricky, since the skinned mesh needs to be split into peaces, because all the bone matrices cannot be passed to the vertex shader at the same run. I will propably also add multithreading via OpenMP to some parts of the skinning process, as this is easy to do and most people nowdays have at least two-core processors, many have four.
I have been familiarizing with the concept of reliable packet transfer protocol, since this is not built into UDP. Most of the packet transfer in a fast paced network game need not be reliable as much as it needs to be fast. If a position update packet gets missing from time to time, it is barely noticable. On the other hand, when a player joins the game or sends a chat message, it is important that packets are guaranteed to reach the destination and do this in order. To implement this over the UDP, I have created special routines that add a sequence number to each packet to guarantee right ordering. Also, when sending a packet, the packet is added to a queue and is sent repeatedly with regular time intervals, until an "ack" (acknowledgement) message is received from recipient. I have tested this protocol with chat messages and plan to implement it shortly in other places where deemed necessary.
I have been struggling to get the Windows binaries compiled from current source base. The optimal solution would be that I could cross-compile Win32 binaries on Linux box, but after trying this in vain for some time, I decided to install the MSVC++ on my Windows. To ease the compilation of native binaries for different plaforms, I have gotten rid of some dependencies. These include DevIL, which was replaced by SDL_image, and libconfig++, which was replaced by a very simple code that I wrote. Even after this I needed to compile FreeType 2 and FTGL from source on Windows. Finally, after minor changes to the original code, I was able to compile and successfully run the Windows binary. Hooray. I'm quite sure I was very colse to accomplish the cross-compilation. The source code did compile, but linkage failed. I will try to return to this problem at some point. I'm sure that also OS X binaries could be compiled quite easily (crossing fingers), but until I obtain a Mac, I will not be able to test this in practice.
What comes to the engine itself, I have added a routine for checking line-OBB intersections (OBB meaning oriented bounding box). This is now used to do pre-tests to line-mesh and line-terrain intersection tests to significantly increase performance. The generation of OBB:s from mesh data still needs some work (some unexpected problems there).
Additionally, I have managed to get two more people involved with the game project. They will be fabricating character, environment etc. meshes and textures and perhaps animations. We also try to plan the game concept more carefully together. More on this after we have some new graphics to show around.
I had some free time last week since cources have not reched the full pace yet and I'm doing only part-time job this spring. So I've attached a particle system from my old engine project successfully. There's also fully working line-mesh and line-terrain intersection tests, which are already used for mesh picking in edit mode and to trace bullets in game mode. Intersection test also works for skinned meshes and as I have also implemented a basic player class, it is possible to go around shooting and inflict damage to "dummy" players (there's not AI). I've also implemented a 2D collision detection and response for meshes, which is used to test player's collision with world objects. To top all this, I have also implemented Vertex Buffer Object rendering for static meshes. This should give a notable performance boost for high polycount objects or for scenes with many objects.
In the future, some optimization will be definetly needed for skinned meshes, as the implelentation is quite slow at this point. The problem lies in the transformation of the vertices. Modern solution for this is to transform the vertices in vertex shaders, but this would not work for me, because I want to be able to do intersection tests with skinned meshes and maybe stencil shadow volumes at some point. Also, I will add a quadtree structure at some point to improve performance in rendering and intersections tests as these are quite brute force right now.
I added a brief video clip in the media-section. It illustrates the basic gameplay elements and editing that is currently possible. You can also get the video by clicking this.
Although Arbaro can produce quite detailed tree models, it seems to be quite hard to convert them into lowpoly meshes. I made two tree models with blender, though: a pine and a spruce. They were made by rendering each branch into a texture and applying these textures to crossing planes that intersect the tree trunk. The branches that were rendered into a texture were basically modeled starting off from a single needle. See a new screenshot here.
I'm planning to use the Arbaro tree generation program (http://arbaro.sourceforge.net/) for generating various trees for the game. The program will generate a very detailed and highpoly mesh, but the idea would be to render the branches into textures and the create a lowpoly tree in blender by using the tree trunk with several planes that use the branch textures.
This is a hobby project of mine started in the late 2010. The idea is to develop a simple 3D FPS game / game engine based on OpenGL, SDL and other strictly cross-platform libraries. The programming language of choice is C++ and the development takes place under Ubuntu Linux using mostly free software.
I am currently a science grad student at the Tampere University of Technology with major in technical physics. I'm working as a researcher in the optics laboratory located at the university. So what is this then, you ask. Long before I started my science studies, I used a lot of time learning about game and 3D engine programming, just for fun. I never really finished any of my projects, which is a shame. So with this project I will try to finally carry a game project to the end. Or at least to a stage where the game is fully playable.
The motivation of this project is fully narsistic. I develop the code and content because I find it creative and in some twisted sense fun. I realize that there are more state-of-the-art 3D game engines (open source and commercial) with longer life spans out there, and it is not the intention of this project to compete with these. If you are interested in indie game / engine development, feel free to follow the progress of this project via this site.
Due to my commitment to studies and research there will be long periods when nothing gets done on the side of this project. Whenever I find an appropriate time, I will try to add new content.
The following represents the current vision of the game. Not all the features mentioned have yet been implemented.
The game is an online multiplayer first person shooter with weight on team based tactics. Players are divided into two or more teams, which consist of riflemen and support gunners. Team members can also have other attributes, such as the team leader and the team designated medic. Teams have dedicated home bases, where players can respawn in regular time intervals and where equipment can be refreshed.
One or more carryable objects are semi-randomly placed around the game environment at the beginning. The team who carries all of these objects to the home base wins the game. Once an object is brought to the base, it should be guarded, because another team can try to reclaim it for themselves. This leads to many different tactical approaches: you can decide to allocate all your resources for obtaining one object at a time so that you have good chances of getting it, but then the other team may collect the remaining objects meanwhile or collect the ones that you have at the home base. Alternatively you could e.g. keep one player guarding the home base and attack the enemy base while the enemy is busy collecting the other objects.
The game has an experience point system, which aims to augment teamwork. Objective completion and teamwork are rewarded with more experience points than enemy kills. Shot accuracy also affects experience and friendly fire severely decreases it.
The game engine is developed alongside the game and is thus specifically designed to provide everything that is needed and nothing more. This results in a clean and compact code base and gives full control over the game development.
One of the main disciplines of this project is Linux support. The programming is done primarily on Linux, although Windows builds are also released. The reason is that I'm an enthusiastic Linux user myself and I have always wanted to see this kind of a game on Linux.
The engine, as discussed more thoroughly in the engine features section, is designed to handle large outdoor environments and indoor environments of certain degree. The latter means basically that player can go inside buildings, but there cannot be floors on top of each other that the player could enter. An important feature of the engine is dynamic illumination and shadows, which are utilized in continuous day-night rotation. Day and night provide whole different tactical settings.
The game is almost exclusively based on outdoors environments. A few square-kilometer areas of e.g. forests, deserts, farms etc. provide settings for secure and extract missions. Each map will contain concetrations of buildings: villages, city ruins, military installments and such. The engine allows a lot of detail to be added, so that there will always be many objects to provide tactical assets and graphical richness.
One central feature of the engine is an integrated and intuitive map editor. Players can easily modify existing maps or create their own from scratch. Basically map creation consists of shaping and texturing the terrain and placing static meshes. User can seamlessly jump between game and edit modes so that map creation can be as much fun as playing the game. Thanks to fully dynamic lighting and almost exlusively outdoor settings, there is little to none pre-processing.
Each team consists of riflemen and up to one or two support gunners. The rifleman carries a standard issue assault rifle which can be modified with sights, bipods and grenade launchers. The agenda is to only include a few weapons in the game but make the implementation as good as possible.
The assault rifle.
Fragmentation grenades have more important tactical role than in most online FPS games. The kill radius of grenades is set to a realistic 15 meters, so that they are very effective also in open ground. To balance, holstering a weapon and drawing grenades takes time, so that if enemies are nearby, it is a necessity to have a team mate covering. Smoke grenades, on the other hand, are useful when rushing to pick up an object from open ground areas and in concealing the extraction route.
Players register user accounts that are used to save game statistics on server side. This way players can keep track of their skill, such as weapon accuracy and objective completions. If user allows it, his statistics can be displayed in the public ranking list.
By eliminating enemies and completing objectives, players receive experience points and equipment points. The experience points rank the player and can be viewed in the public ranking list. The equipment points can be used to purchase weapon mods, grenades and so on.
Detailed damage model is the heart of realistic combat simulation. A player will not perish instantly from a gunshot to guts or a leg, but start bleeding from each wound, eventually dying of blood loss if not treated properly. A team mate can apply a tourniquet to stop the bleeding. All players are able to treat each other, but there is a team designated medic, who has more tourniquets and can do the job faster. After bleeding too much, a player will become incapacitated until treated by a medic. Only the designated medic can revive incapacitated players. Moving while hurt increases the rate of bleeding and often the best choice for a severly injured player is to remain in prone stance and wait for a medic. Medical treatment increases experience, which motivates teamwork.
The weapons are modelled with detail to make it difficult to engage targets at long range, but so that it is possible to significantly develop skill. Many factors contribute to both accuracy and recoil management: stance, health and breathing. Aiming down the sights is always recommended, except maybe in close quaters combat situations. Further, there are factors that affect accuracy via visual feedback: illumination, sun glare, weather and health (bleeding may cause blurred vision).