• Advertisement
  • entries
  • comments
  • views

About this blog

a picture is worth a thousand words

Entries in this blog


Here is an update on the big spaceship. I have to add some content in the front hangar bay and I think I will be done with the geometry (unless I see something missing while texturing it).

The little thing next to it is the player.


I still have a lot of work on this one...



I am working on a big spaceship for the game. It is in an early stage but the main shape is here. The rear part is even less detailed than the rest. There will be the reactors and some "cargo" in the large empty space under the "wings".





Hidden gold


I did a little something the past few days. It is a cave made with polystyrene. I cut some pieces, scratched them with a knife to shape them:


I did two bridges and some details with wood and wire:


I then painted and glued the different parts:




I finished the sides using glue, salt and paint:



I added a wire tree and some rocks:


And I now have this:





You can see more pictures in the gallery:


(I did a small part with lights to go under the cave, I will try to take a photo with the lights on but I am not sure about the result)

Have a nice day !


After a long pause, here comes an update on my game project. But first, some information on one of the things that took me some time during this long silence. I did a little board game. In a few words, the goal, for each player, is to find a battery cell hidden somewhere in a space station floor and put it in the reactor to avoid the station crash on earth. Of course, some creatures are here to make things difficult. It can be played in cooperation or solo as it is possible for each player to go from a floor to another to help the others.

Some photos of the "construction"








And the initial state with only one player:


Attached to this post, you can find the rules (in French but if someone is interested I can do an English version), a "print pack" with the various parts as png files and an "edit pack" with source files (xcf, odt, blend).

I also did a simulation in Python to let the computer play for me a lot of games to check some parameters (player's health, medikit "power", turns). It is also attached (do not pay attention to code quality :unsure: ).

And now, my shoot'em up... I did a lot of things under the hood but I have some visible things too:

- the main menu allows the selection of a 1 or 2 players game,

- only one spaceship is visible when the 1 player game is chosen,

- the health level and the score of each player is displayed,

- the score is updated when an enemy is destroyed,

- it is possible to define the objects that will be considered as the "Boss" and its health level is also visible when it is close to the player,

- I improved the smoke and the explosions.

Here is a video with all of the changes (the capture is still not very good sorry):

Next: nothing visual probably as I have to change the way the objects that have to be updated or displayed are gathered across the level components...

See you soon I hope.


The work on the effects took longer than I thought but the result is not far from what I was expecting. It is now possible to create things like smoke trails, explosions and maybe other effects that can be achieved with the system. They can be associated to objects as active effects, that is while the object's energy is above 0, or they can be associated to objects as destruction effects and triggered when the object's energy reaches 0. Each category can have more than one effect.

In the video below, you can see smoke trails, small impacts of shots on the structures and big explosions.

How it works.
The definition is similar to the one of the weapons (https://www.gamedev.net/blog/635/entry-2261780-collisions-and-weapons/):
- the different effects are described in a file
- the objects have 0 or more effects instances associated to them in the objects description file. An instance is a reference to an effect and its location relative to the object.
- the objects instances (from the level file, referencing an object) have effects states that are references to the effects instances and the dynamic properties (number of points, current radius, ...).

The effect can be of type "trail" or "sphere". It is defined by a material ID, the number of sides (think of a lathe), a maximum number of points, an initial and maximum radius and a few other parameters. The "trail" and "sphere" are defined in the same way. The effect state contains a list of points/radius couples. The "sphere" type is created by adding at once the maximum number of points along the diameter with, for each point, the radius of the corresponding latitude circle. The "trail" is created by adding a point calculated from the parent object position at each update (the oldest point is removed when the maximum number of points is reached).

The level maintains a list of the active effects states. The list is built from the visible objects and the effects still active after the parent object was destroyed. These effects are updated at a specified rate (set in the effect description, can be different for each effect type). The effects in this list are given to the EffectsVisual in charge of the building of their visual representations as geometries. Finally, the geometries are rendered as any other objects by the renderer.

The EffectsVisual converts the effects states points into a group of cones/truncates cones/cylinders depending on the radius associated to each point.

And voila.

I did not do a lot of optimization for now as I may rework some parts when adding more types but it is fast enough for now.

Bonus image: a wire-frame view. It is clear that I have to work on some lighter trees and grass.

Thanks for reading.

Let's rock

I don't have a lot to show this time. I fixed a few things and added others. Here is the list in no particular order:
- Disable light when linked object is no more active. The bug was visible in the latest video.
- Corrected weapons group activation. In the previous video, a weapon was not shown because the activation was not correct.
- Added guided missile weapon type (for players and enemies).
- Corrected pattern following. The optional pause at any control point was working only when at the first control point.

For the guided missile weapon type, it was not really difficult: in the same manner I have a pool of objects instances for shots, I added a pool of patterns (like the ones used to move objects in the demo menu and enemy ships in the level) consisting of only two control points. The first point is always <0, 0, 0> and when a guided missile is fired, I update the first control point tangent to be the "X" vector of the weapon, the second point to be the position of the target and its tangent to the vector "target - weapon". When the shot object is updated, if it has a target, I keep updating the second point of the pattern to match the relative position of the target. All the movement is done by the existing code for pattern following. The added code is small and it is working quite well.

I also played a bit with Blender. I wanted to rework my rocks. I had a simple way to create one (I may have seen it somewhere but I don't know where) and finally did a small script to generate it automatically. The method is:
- create a cube
- create a plane
- rotate the plane and move it away from the cube centre
- cut the cube with the plane
- repeat with more planes
This is a very basic method but it gives what I need. I added a few things:
- the resulting object is bevelled
- a parameter allows to smooth or not the final object

Here are rocks generated with this method in only one action:

I attached the script if someone is interested. Maybe I will add a UI to set the parameters instead of modifying the values in the file. Just load the file in the text editor of Blender, empty the scene and hit Alt+p.

Have fun.


The hard work is going on. Here is the list of what you will see in the new video:

  • Enemy firing

    I have a dummy object (no geometry associated to it) with the camera locked on it that moves forward in the level. When an enemy is close enough (in the "X" direction) to this dummy object, it starts firing. The weapons properties (fire rate, delay between bursts, burst number of shots, ammo...) can be used to limit the time of the attack. In the video, I put the second spaceship in front of a enemy to get it destroyed.

    • Auto-fire

      A key can be associated to the auto-fire action. When enabled, every weapon will fire as soon as their properties allow it. In general, it is a good idea to activate it but in some places, it can be preferred to disengage it: some powerful weapons will take some time to reload and it can be necessary to control when they are used. Here, I activate it at the beginning, cut it and re-activate it near the end of the video.

      • Pick-ups

        I added the pick-ups. For now, I have energy and weapons activation pick-ups. The energy pick-up restores a fixed amount of energy to the player. The weapons activation pick-ups are used to enable more powerful weapons. I added one of each type in the level. The first one is the energy restoration one, then each pick-up activates a different weapon in the order they will be available through the game. For now, there are 8 weapons groups (see https://www.gamedev.net/blog/635/entry-2261780-collisions-and-weapons/). The pick-ups geometries are not finished. The shot geometries are far from final and some are not of the correct type ("classic" missiles instead of laser or homing missiles).

        • Laser

          I added a laser weapon. It needed nearly no additional code. It is very simple: a sphere and a long cylinder with small thingies around it (again, I will work on the geometries later). The laser is an object defined with a very short life time, a high rotation speed around the X axis and a really large amount of energy (it will not be destroyed when colliding with an object, only when its "life time" will be exhausted). The weapon has a big fire rate. I added the cylinder bounding type and added the collision code for it. The Blender script to export the geometries has been updated to allow the definition of the cylinder bounding volume. The only "problem" with that is that the laser goes through objects and can destroy more than one enemy at a time. I think I will make the one in the video not very powerful. It is not visible in the video, but the last weapon will be a very big and powerful laser with a medium reloading speed.

          A little word on the pick-ups. I added a Bonus class. In the level definition file, a bonus is defined by its type and an object instance (defined like any other in the level). At first, the associated object instances were added as any other in the vector of dynamic objects. I had the "clipping", the update and the collision for free. But I had this problem: I was able to destroy the pick-ups by shooting at them. I could have added a "type" property to the object instance but I was not happy with this as this property may only be used to distinguish a pick-up from any other object. So, what I did is this: the small amount of pick-ups that will be present allows me to add the "Bonus"es in the level class and go through them all to check for collision with the player. The associated objects on the other hand are added in a specific vector of the level sectors, to avoid sending them all to the rendering part.

          I think that's all for now. In the next update: something like homing missiles, particles or the "HUD" who knows ?

After quite some time, here comes a new video showing a very early sample of collisions and weapons. What you can see in the video is the player shooting missiles bursts. An enemy spaceship is destroyed by one and others are colliding with a building.

The collisions: in Blender, I define a bounding sphere using a spherical "empty" that allows to specify the location and size of the volume. If there is none defined, a default one is created in the exported file. The game code is meant to accept a hierarchy of bounding spheres but it is not needed right now so the implementation is not complete. Various collision checks are done:
- players / [enemy shots, objects of the visible sectors, objects generated by the layers (trees and rocks in the video)]
- players' shots / [objects of the visible sectors, objects generated by the layers]
- enemies' shots / [objects of the visible sectors, objects generated by the layers]
Enemies / objects collisions are not tested as they will be constrained by fixed paths. It will be easy to add if needed later.
I separated the shots objects to ease the updates and limit the collisions checks to do.

The weapons: for now, only simple missiles are present. They are created at a specific location of the parent object and in a defined direction. After that, they will travel in the same direction. Weapons are described in a separated file with: type, fire rate, burst rate, number of shots per burst, maximum ammo and object ID (it defines the geometry, the collision damages, speed, ...). I have then the following organization to describe an object "template":
- an object (let's say a spaceship) has one or more weapons groups
- a weapons group has one or more weapon instances
- a weapon instance has the matrix for relative position/orientation of the weapon on the object and is referencing a weapon (the one from the weapons file)
- a weapon has the type, fire rate, burst rate, ... and is referencing an object (what the shots will be like)
In the level I can now have:
- an object instance (the player's spaceship) that is referencing an object (the spaceship) and that has weapons states
- a weapon state has the current ammo count, the fire timer, the burst timer, the group active state and is referencing the weapon instance

With this, it is really easy to share descriptions of weapons between objects, it avoids too much duplication of data and is easy to customize. I can have weapons groups with different weapon types, the same weapon at different locations on the parent object, it is ready for new weapons pickup (that is in fact a simple weapons group activation), ... In the video, I did only one weapon group with four times the same weapon around the player.

Next things to do: disable the shots when they are going out of the world boundaries (or after some time), make the enemies use the weapons, other types of weapons like guided missiles, lasers. Mines are already available: I just have to set the shot object speed to zero and I can define a large "empty" in Blender to get something like proximity mines for free.
Thanks for reading.

Lights and shadows

The lights are now working. It is possible to have point lights and directional lights. I also added shadows using a simple shadow map. For now, only one directional light can have shadows. I will try to improve this.
In the new video, I have one directional light casting the shadows and two point lights (yellow and blue) are attached to the ships.

After uploading this "ugly" video, I found this page https://support.google.com/youtube/answer/1722171?hl=en that explains how to push better quality videos. Here is the second try:

Next in the TODO list: do some clean-up and try to get more shadows...

Have a nice day.

Progressing slowwly

I finally started the layers system. For now, I only have "objects" layers.
In the following images, one layer is set to add trees, a second one to add grass and a third to add two types of rocks.
The layers here only add objects on the ground. It is possible to use them to populate a "box" with floating objects (for an asteroids field for example). The layer definition indicates the volume of a layer chunk (size is chosen to be compatible with the terrain chunks), the number of objects to add by chunk, the min/max distance between two consecutively added objects, a "spread" factor, a list of object ID (one layer can add multiple objects types) and the option to get objects on the ground.
The layers not only generates positions for objects but also 2 random values. The first one is for now hard-linked to the rotation around Z and the second one is meant to be used as a "color factor" to add diversity. I would like this "randomness" feature to be configurable for each layer.

A second layer type is planned: the terrain "patch" layers as I did in a test application. This type will allow to add random features to the terrain.

I did a video capture.
Sorry for the quality, the upload to youtube killed it. I will have to capture at a bigger resolution the next time...

See you soon.


I uploaded the 3 videos I currently have of the game development.
The first one is the old terrain + paths test:
- infinite terrain
- terrain "patch" system to create craters
- random tree placement (with the same system used to place craters)
- paths for the red triangles

The second one is the menu with a single rotating object behind:
- SDL2 window and keyboard events
- OpenGL rendering
- Truetype font rendered in a texture atlas at start-up
- 3D object made in Blender rendered with a simple shader
- object loading, placement and rotation is hard coded in this video

The third one is the current state. The same menu as above but with a demonstration of various path options for the dynamic objects. It will be used to define the movements of the enemies and various objects during the game:
- object geometry, description, placement and movement loaded from files
- closed/open paths
- optional movement pause at any path control point
- linear or bspline interpolation
- object orientation along path or not
- rotation independent from movement along path
- paths can be shared by many objects
- path starting point can be different for each object

I think it is all I have for now.

3D model

I did a lot of work in the game these days. Now, I can export meshes from Blender, read description files for fonts, materials, objects, levels and render the level. Everything still needs a lot of work but the results are encouraging and I can check visually what I was working on all this time.
Some screenshots of what I have (the jpg is killing the menu, I'll have to tweak the compression settings next time)...
The main menu can have a full 3D level behind it but I am not sure if I will use this feature. For now, the level is only one object as a unique geometry using a unique material (the code is made to handle more complex setup but it needs to be finalized). I am rendering it with a very simple shader. Loading of it is hard coded and it is used for any object present in the level for now. It may be my third shader ever so it is really basic (and not very well written) but to test what I currently have, it is more than enough.in vec4 pass_Color;in vec3 pass_Normal;in vec2 pass_UV;out vec4 out_Color;uniform sampler2D diffImage;void main(void){ // fixed light direction vec3 lightDir = normalize(vec3(-1.0, -1.0, -1.0)); // calculated diffuse float diffuse = max(0.0, dot(pass_Normal, lightDir)); // ambient float ambCoef = 0.25; out_Color = min(diffuse + ambCoef, 1.0) * vec4(pass_Color.rgb, 1) * vec4(texture(diffImage, pass_UV).rgb, 1);}
The spaceship is the player's one. The Blender export script produces a file with the vertices, colors, normals, UVs and bounding dimensions. The association with one or more materials is done in a separate file allowing the declaration of objects with the same geometry but different rendering properties.

The next things to do:
- finish the code to use more than one geometry and one material per object
- code more level content: cameras, lights, terrain description, enemy waves, ...
- more complex materials with specific shaders
- and a lot more items in my ever-growing todo list

Until next time...

Light Metal Universe

Still no game screenshot for today but I finished two metal models:
I had to use tweezers (some parts are 1-2mm wide) and various sizes of screwdrivers (to shape the cylinders).
Two more to go (a Tie Advanced and an AT-AT) !

- "Flying 'cross the universe"

Rover and menu

The papercraft Moon rover is finished
Concerning my game, I do not have a lot of things to show but I have a working menu
A lot of things are done but they are behind the scene. It is not visible here but in the screenshot, you have:
- SDL2 window,
- OpenGL4 context and view
- "game" loop
- menu data from a configuration file
- working keyboard input with key/actions mapping from a configuration file
- shader loading
- text font texture generated at startup from ttf (freetype2) with correct kerning and all
- geometry generation from text string (letters rectangles + colors + UVs) + menu items backgrounds
- OpenGL rendering
And a lot more things not visible. I am currently working on the level classes. I think I am far from a new screenshot but who knows...
Until next time, have fun.

In progress

The system to get objects moving along a path is done. The path interpolation can be linear between the control points or following a b-spline. The orientation can be fixed or also following the path. One path can be used by many objects each having a position offset or a different speed or a different start time. At each control point, a pause can be specified.
I improved the terrain patch functions. I now have more shapes: rectangle, disc, ring, dome, each one with or without border smoothing. Various modes of application are available: "set", "add", "sub", "min" and "max".
Here is an example with craters manually added using a "add"-ring with border smoothing and a "sub"-dome:


Now, the system that will be used to add trees, rocks, asteroids or other things can work in combination with the terrain patches. Here, the craters position and size are automatically generated:

You can find a small video of the test application here: http://www.mediafire.com/watch/y03p4zz33n8mhzl/2014-10-30-moving.ogv

Now, I am working on collision and will think of a way to get water on the terrain. Maybe these features will be in the next entry...

The new project

It is time to briefly present my new project: Shoot (a codename until I can think of something better). It will be a shoot'em up with the player controlling a spaceship.
Here is the spaceship made in blender:
The red parts are the weapons.
And a quick mock-up, in Blender too, using some old models to get an idea of the style and the view:
I would like to use this view but I will have to check if it is playable and not too difficult to code the bullets trajectories. I have a simple way of handling this, I will have to validate it.
The action will take place above ground (low and high altitude probably), in deep space, above huge stations or spaceships maybe, ...

I am currently working on some individual parts in small test applications:
- random terrain generation
- "manual" terrain modification
- automatic objects placement for rocks, trees, asteroids, ...

I think the next step will be to make some code to get objects moving on fixed paths and finish writing the "story" with the descriptions of the various environments.

The return of papercraft

I uploaded photos of papercraft models I did during these past months in a new gallery:
I did not create the models, I "only" built them with a lot of paper, glue and time...

I am currently doing a rover from the movie "Moon" (https://en.wikipedia.org/wiki/Moon_%28film%29) from here: http://www.paperaviation.de/Lunar_Rover/lunar_rover.html

Some images from the gallery:


Stay tuned for a next post where I will briefly present my new game project.

Alfith -

Something unexpected

After years spent doing nothing with it, my game is available. I recently worked again on this project to add musics, more sounds, fix a few things in the code and in the level and get a game that can be played.
It is available for download here: https://www.mediafire.com/folder/8hlrizqd9u2rl/DDream as 4 files:
- ddream_exe.tar.gz : the main content with Linux executables of the game and the level editor. The game files are all present in this file except the sounds and musics. The game can be played with the content of this file.
- ddream_sounds.tar.gz : the sounds and musics. The "sounds" folder in this archive must be put in the main game folder.
- ddream_graphics.tar.gz : all the Gimp and Blender files I produced for the game (some are just tests not present in the game). The Python script to export from Blender is also present. A map (close to the final version) of the level is available (level_001_plan.png).
- ddream_src.tar.gz : the complete source code of the game and the level editor.
(tell me if there is a problem with the downloads, I will try to upload the files somewhere else)

In each archive, the same README explains how to play the game, how to use the editor and various other things as the sounds and musics attributions.

I know it is not polished, my TODO list is not completely empty on this one, but I do not think I will work on it any more.
All the files I produced (ddream_exe content, ddream_graphics content and nearly all the ddream_src content; see the README for details) are placed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/).

I hope the next project will take less time to complete...

Blender vs Papercraft

In this post, I will give some tips I learned when I did the papercraft harvester for my son using Blender (see https://www.gamedev.net/blog/635/entry-2255522-rock-paper-scissors-but-with-a-blender-instead-of-a-rock/)


1. The model.
I did it simple for a first try using many individual parts all in the same object. I split the geometry in separated parts to get a more rigid result. The other option was to create an armature hidden inside the model but it could have been tricky and it can be difficult to print.

2. Prepare the unwrap
Select edges that will be cut and use the "mark seams" feature.

To get a correct unwrap, edges that has to be folded must be aligned. If they are not, a cut must be made.
Here, the cyan edges are to be folded but they are not aligned.

If you do not mark a cut here, you get this unwrap

As you can see, the shaded face is no more a square. The model will not be correct.

The selection of the edges to cut can be difficult.

It is sometimes easier to completely separate a bunch of faces from the rest of the model.

3. The unwrap
In step 1, I said to use only one object made of several parts. It is needed (as far as I know) because you probably want all your pieces to share the same scale. Using only one object, you can unwrap the whole model at once and get perfectly scaled parts.

Do not forget to set the "margin" parameter to an adequate value to get room to cut the flaps.

I then exported the UV layout as an SVG file so I can create the paper model the size I want in Gimp. The harvester is an image of 11400x11400, but it is a bit too much, the final print was made on 6 A4 pieces of paper.

I thinks that's all. Try this at home !

3D Video

I tried the automatic 3D conversion from Youtube on my latest video (clic on the "3D" button on the player tool bar)...
I just have to find red/blue glasses to check the result cool.png
That was a long silence. I would like to say I worked a lot on the game but I can't. The only thing I coded is the subject of this entry: a python script to "patch" binary files. I am posting it here as it could be useful to someone.
I tested it with Python 2.6 and 3.2. If you want to use the "crc" command, the "crcmod" package is needed.

The python script is used to apply modifications to one or more binary files using a really simple scripting "language". You can:
- read/write/swap values
- do simple calculations
- insert bytes (from other files or using a specified value)
- import other files inside the one being processed
- export/delete parts of the file
- use loops, if/else, macros
- send parameters to the script using the command line
- calculate crc, xor, ...

A small sample script to add 1 to each even byte of a binary file (even length) can be:

cursor 0 //set cursor to the first byte (it is done by default, this line is not needed)
loop SIZE2 #1 // SIZE2 is a constant representing the size of the file divided by 2, #1 is the variable 1 used to store the current loop index
read @0 #0 // read the byte at cursor position and store its value in variable 0
sum #0 1 #0 // add 1 to the variable 0 and store the result in variable 0
write @0 #0 // write at the cursor position the value of the variable 0
cursor @2 // move the cursor 2 bytes

Commands and usage are described in the python file header.

Archive content:
- patch_bin.py: the python script
- demo.patch: demo script
- demo.bin: binary file to update with the demo patch
- import.bin: small binary file imported in the demo.bin by the demo patch


Alien test

A quick test of OurBricks (see Gaiiden post about this) with the alien. I will have to see why the smoothing is not exported but it is working really well (it took me longer to find how to embed it into this post than exporting the model and uploading it on the OurBricks site... I was pasting the "embed" link instead of the "link to this model" one).

edit: I opened my eyes and discovered the "export normals" checkbox in the OBJ export in blender. I tried it with my Minotaur...

A new video

It is incredible: I did code for my game ! I added two new "events": one to move an object and one to display text. They are both demonstrated in a new video I put on youtube here:

What is shown:
- a few monsters cleanup
- some "bonus" pickup
- text displayed when entering an invisible area
- teleportation of the player when approaching the gate
- activation of a particles emitter when the player arrives at destination
The video is not always smooth as it is a bunch of pictures saved by the game in 1024x768 every 40ms in BMP format.

The next step is to update the level editor to allow event edition. For now, I put them directly in the level description file using a text editor...
  • Advertisement