making a concept...AI!

So, now i am constructing the AI for the game, so, what is to do? First, the AI can "see" the ships by calling someship->position();, and the own ships may be moved per "shipnumber command option", for exampe "001 N 000" to navigate the first ship to 0 degree. So the AI only has the same options as a human player, but it is faster!

So, how to make a strong AI? The AI-Ships have to kill the enemyships, hoho! What would I do? I would navigate the ships to several positions to attack the enemy by all sides, may be good, but the AI has to defend their own ships, too :S. Ah, it doesn't have to navigate _ALL_ ships to the enemy, if it has to defend something like a huge, heavy ship. So now it would be in the right position to attack, now should all ships attack one enemyship, or one enemyship for one AI-ship? Hm, I will have to invest more time in it..!

Ship physics

I implemented most of the ship's basic movement physics the other day. We have so-called definition files which specify the physical quantities of a given ship type, such as its mass, its size, its shape, the force of its engines and the torque the maneuvering jets apply for rotating a ship. Furthermore, we also specify the ship's maximum velocity and angular velocity. There is no physical law in classical mechanics which would limit the ships' velocity, but it we don't want them to travel too fast as a game element.

The goal now was to find a way to compute the ship's acceleration based on the forces without getting significantly faster than the specified maximum velocity. In other words, we need to modify Newton's law to take into account the maximum velocity of the ship. I spent some thought on how to modify this so that it has the properties we'd like, and this is what I came up with: In this formula, the minus sign is used if the dot product of F and v is positive, and the plus sign otherwise. In the case that the force goes into the same direction as the current velocity, the additional term will lower the total acceleration by a factor of v/vmax. Therefore, when v reached vmax, a will be zero and no additional acceleration is possible anymore. Also, when, for whatever reason, the ship gained a higher velocity than vmax, then the additional term slows it down again.

On the other side, if F points into the opposite direction of v, then we are actually deccelerating. The dot product is less than zero, so the plus sign is used. In this case, the original acceleration is increased by a factor of v/vmax. This makes decceleration from high velocities take shorter than accelerating to such a velocity. This might not be realistic, but it makes it easier to avoid collisions, so I think it's a good thing. If we didn't want this, then we could simply drop the additional term when deccelerating, and we would still have the velocity limit in place.

Another thing to note is that if the ship is travelling at maximum velocity, then changes its direction arout 90 degrees and accelerates into a direction which is perpendicular to the current one, then the dot product is zero and the second term vanishes. In that case, we allow the total velocity to become greater than vmax. This is not a problem though, because of three reasons:

1) As explained before, the ship will automatically slow down again when travelling faster than vmax.
2) To permanently travel faster than vmax, one would need to change the flight direction very often, taking a zigzag-like route. In that case however, one would be faster when travelling at vmax using the direct route anyway.
3) The effect is very small: If vmax is 20, and one turns at v=19.99, then the highest v will be v=20.05 before it gets smaller again.

For rotation, the same formula is used, with the force replaced by the torque (also specified in the definition file), the acceleration replaced by the angular acceleration, the mass replaced by the moment of inertia and the (maximum) velocity by the (maximum) angular velocity. As there is only one direction for rotation (namely around the Z axis) we don't even have the possibility of gaining more angular velocity than the maximum here.

making a concept...a dark hole?

Now Echo gets in a hot phase. I spend many hours to consider some equitable principles of flight physics, interfaces and ship interacting. Todays topic is the ship Interface/Effects on the battlefield (sector).


The main problem is the overview about the sector with much interfaces/detailed ship info. So we'll found some shortkeys and other hacks to solve this tricky problems. Also we need to find some solution to make the departed flight routes of a ship visible. Currently we have the dots, but it isn't nice. Maybe we make some engine exhausts, contrails or somethin like this. We'll see.

On the picture you see such a concept.

New Delicious Menu

In the last few days ck and I worked on the main- and the options-menu. So, first i needed a concept for that, what options should be able for the user? Well, resolution sounds good, playername is a must, same as the playercolor, and we need a fullscreen/windowed mode! We will get an AI, so, how strong must it be? And what language do we use? And last, we want back to the main-menu.
So, now I had some options, but where should i place them? I am very creative, so all buttons/textareas/combo-boxes are 100x25px and 5px apart! :)
After fixing ~30 bugs we got a nice menu

Hm, i am missing labels for the text- and comboboxes, I will do this today.

So, and in the next days we will go ingame..!
(the Screenshot is from the Windows build, by the way)

Creators Portrait

So, today we will introduce ourself. Every Team Member has written his own text:

My name is Armin Burgmeier (ck). I'm 22 years old and I'm studying physics at the University of Karlsruhe, Germany in my third year. I'm also working (part-time) as a software developer for Openismus GmbH.

I'm writing Code for Echo and making sure the Linux version works as expected. I am especially looking forward to pwn Kanibal with echo.



Greetings, my Name is Florian (Nachtfalter) and I'm 20 years old. Currently I'm living in Berlin (Germany), originally I came from Klagenfurt (Austria). I have founded the Echo principle and work as the graphics guy here. I am designing the ships, concepts, GUI Elements and much more and maybe responsible for Mac Support.

I hope that one day we get a bigger community, which loves to play the game.



Hi, I (mralra) am 17 years old and in a technical school in Kapfenberg (Austria). I am one of the coders in Echo and the man for the windows-build.

I hope that Echo will be a very funny game.

SDL Bug wrt. mouse focus?

We have basically finished the GUI subsystem of the game. However, when writing the Code to handle the mouse pointer leaving the application window (for example, to remove the hovering state of a widget near the window border) I investigated a problem which I think is a bug in SDL.

When clicking into a different window, holding the mouse button pressed, moving the cursor into our SDL window and release the mouse button there, then we don't get an SDL_ACTIVEEVENT which reports gained mouse focus for the window. This is OK as long as the mouse button is pressed, since all mouse events are still delivered to the originating window then.

The problem with this is that when querying the application state via SDL_GetAppState, SDL still reports the window not having mouse focus until the mouse leaves and enters the window again. This confuses our code since there are some checks for the application having mouse focus before e.g. setting a button's state to be hovered by the mouse.

There is a quite easy workaround for the problem:

SDL_WM_GrabInput(SDL_GRAB_ON);
SDL_WM_GrabInput(SDL_GRAB_OFF);

This is executed whenever the mouse moves over our window or it is clicked and SDL reports that we don't have mouse focus. In this case we can be quite sure that the mouse actually is over our window, so the mouse grab does not warp the mouse cursor. However, this causes SDL to update the application's mouse focus state.

There is still a little issue with this: When the mouse button is released over a button, the the button is not shown hovered until the next mouse click or movement, since the application state is only rechecked on these two events. However, that's not a major problem, and we can live with it.

I am not yet sure whether there is the same problem on Windows, but I have tested it using GNOME with the Metacity window manager. Anyway, as a good net citizen I filed a proper bug report.

Graphics Initiation

Today, I'll show you some details about the ship graphics. For this, I'll take the big Battleship. All 3D Models are created with Maxon Cinema4D, Release 11. Remember: The game is 2D! Basicly, all models starts with a polygonal object, most of them with a simply cube. With some special tools I can form new points, edges, curves and more.


Step by Step the Ship takes a new shape, that grows with every detail. After the modelling part, I phaseout the mesh to paint a texture for the ship in Photoshop. For this point, it's necessary to keep a good and clean meshflow.

Addet some Ambient Occlusion, Global Illumination and Fill Lights/Effects for better quality will took the last part of making a model. Maybe add a little scene for some artworks is also requiered.

At this point, the ship isn't finished, lots of textures must be created at the next hours. Currently, the worktime for this will be at six hours, maybe eight too. The ship currently has 90k Polygons (because of many details at the nose!).

Composing images of multiple textures

For the curious: The game is developed with SDL using OpenGL for graphics output and will support all three major platforms: Windows, Linux and Mac OS X.

Yesterday, I wrote a class to load arbitrary-sized images into possibly multiple textures none of which is greater than 256*256. I don't know how restrictive modern graphics cards are in what texture sizes they accept, but this way I think we are safe to also support older cards. Everything went quite well, until I tried to render a rotated image composed of multiple textures. The result was something like what can be seen on the first screenshot. Somehow there were visible lines at the texture boundaries.

It took me a while to find out what happend here. The problem was that, when rendering a textured primitive with OpenGL, it repeats the same texture when specifying texture coordinates greater than one. Now, when drawing a rotated quad, OpenGL seems to have accessed such a texture coordinate for interpolation, even though I never gave a number greater than 1.0 to glTexCoord.

Once I understood the problem, it was easy to fix. Simply tell OpenGL not to repeat the texture, but clamp texture coordinates to the range [0,1]. This is done using glTexParameteri, by setting the GL_TEXTURE_WRAP_S and GL_TEXTURE_WRAP_T parameters to GL_CLAMP.

Another solution seems to be to set it to GL_CLAMP_TO_EDGE_EXT, but this requires the GL_EXT_texture_edge_clamp extension, and GL_CLAMP works well enough already.

Beginnings

So let's see where this takes us. There is not much to see yet, except for the beginnings of a framework for the ingame GUI. But I prefer to do some more work at the beginning instead of hacking something together which will reveal several drawbacks later.

The picture shows early concept art how the game might look like. It might turn out to look entirely different, though. Stay tuned!

Blog me

Project Echo has now his own developer blog. Hope we fill many pages with some interesting stuff.