zaterdag 31 oktober 2009

Update on the leveleditor..





Hey everyone, just a quick update on the leveleditor:
Features so far:

* Multiple layers containing objects.
* Objects have multiple 'vertexloops'
* Vertexloops add and subtract to make holes using the OpenGL tesselator.
* (UN)Linking textures to objects
* Deleting Objects
* Zooming, Panning, Changing layers

What has yet to be done/fixed:

* Moving / deleting vertexloops & vertices
* Moving objects
* Moving objects between layers
* Adding widgets (restricted to the widgets layer )
* Adding game elements (restricted to the structures layer )
* Saving & loading level files
* Switching between parallax background & normal background viewing
* Much, much more...

Apart from all this, the main problem I'm struggling with right now is to get the texture mapping to work nicely with the tesselator. I can't seem to figure out how to manipulate the texture map coordinates so that they will work out nicely. Although I'm happy that this sidetrack has really helped my knowledge of OpenGL/GLUT as well as refreshed my programming skills, I'm really anxious to get this thing finished so I can continue with the actual game!

See ya!

dinsdag 27 oktober 2009

Network code and Leveleditor

Hey there,

I haven't had much time to code today and yesterday, but during the remainder of the weekend I've been able to make a good start with network code:

It's not much yet, but the server listens and waits for the appropriate packet header, returning an accept packet to the client containing information such as the level filename, the server name, the player's team, etc.

I tried to implementing this in the client and realized client.c had become one giant mess of code, so I decided to clean up both the client and the server and split their functionalities in different source files. Some globals and routines are shared by both server and client, so they get used in both, but my goal is to keep any GL/Audio/Image loader dependencies out of the server code, so it can basically run on a text-only distro.

When the functions were split out I started to realize a major influence on the structure of the traffic between server and client depended on what the game mechanics and levels looked like.
I decided to start working leveleditor for a couple of reasons:
  • Designing the level editor forces me to focus on the internal representation of the level and the game, and how it will be drawn, processed and communicated.
  • Working on the editor gives me a little more time to get to know opengl/glut
  • When the drawing code is finished for the editor it can be directly fit into the client in a more basic shape.
  • With a finished level editor the basic game mechanics can be programmed and the game can be fully tested, with stub textures and icons, if needs be.

Anyway, so far the editors allows for creating a bunch of vertex points that will form a closed polygon and lets you switch between those:


A problematic discovery was that the openGL GL_POLYGON primitive only draws convex polygons correctly. (convex polygons are polygons that have no interior angles greater than 180 degr). In order to draw concave shapes correctly, they need to be split into triangles, the official term for which is 'tesselation'. I'm now trying to figure out the built-in OpenGL tesselator, which should allow all the following fancy things without problems:

(image source: The Red Book. Couldn't find any copyright information)

All this stuff is not really necessary: I could just program the editor to construct only triangles, but this would be alot les nice for the user and this approach will allow for some pretty fancy game effects later. Let's hope I don't go crazy in the process.

zondag 25 oktober 2009

Yesterday I've been struggling to get the lighting of the ship's window to be the way I wanted. I stimulated a rotating window in blender to confirm my suspicions that the specularity on an ellipsoid is also an ellipse. I then worked out the math and coded it into the spaghetti that is now Shipz Reborn 0.01. Here's how it looks:


Ofcourse this is a detail and something you would normally do at a much later stage. I considere it a small indulgence and a way of getting to know OpenGL. I'll now focus on the networkcode.

vrijdag 23 oktober 2009

I've gotten a mail response from Jorgen Lundman, the developer of the LiON library. He explains the lion_poll() function will call the user_data function when called.

The theory behind the collision detection and deflection is resolved. See collision_detection.jpg (TODO).

Furthermore, I've looked into dead reckoning princples again. Compared with the previous shipz, I want to make the following enhancements:

* The server is to keep track a latency for each player by sending out a tiny packet containing only the PING header and server time to each client who then have to return this package immediately, containing that same header, their measured time difference and absolute time.

* When a client sends a location update or bullet spawn, the server will use an average measured latency of the last few measurements to update the location before relaying it to other clients.
The amount of measurements used for the latency average is to be determined experimentally.
When the server sends updates to clients it will also include this latency average so that the client may perform the same extrapolation.

* I want to try to implement latency targeting : This means that for the example of bullets, the firing client sends out the original firing location, and this is send through by the server alongside the calculated location as discussed in the previous point. The recieving clients can then display the bullet being fired at the original location, but will speed up the bullet to make it converge to the actual location.
It's desirable to do the same for the location of players themselves, but my gut feeling says this will be very very difficult.

I'm still not decided on which audio library to use, and I will delay that decision for a while, as it is i in my opinion of the lowest priority.

I've drawn up some preliminary drawing layers:

Background group
layer 0: Background textures
layer 1: Background widget layer. These widgets translate, rotate animate according to their description in the level file.

Foreground group
Layer 2: 'Middle Ground' This will probably never be used, but it allows the level designer to draw things that move with the foreground and appear behind the following layers. Think shadows of huge rocks, static decorative fog, etc.
Layer 3: Effects, bullets & players. The exact drawing order of these are yet to be determined. Explosions should be covering players, exhaust gasses shouldn't. (or should they? hmm.)
Layer 4: Bases and other structures that are placed 'on' the foreground.
Layer 5: Foreground
Layer 6: Foreground Hallways. (Fly-through)

The idea is that everything in the foreground group scrolls at the same speed. That means that when the viewport is moved 10 px to the right, everything in the foreground moves 10 px left, ( added to the individual movement objects in the foreground might have in that instant, of course).
Everything in the background group scrolls slower to give the feeling of depth. Think of the Worms 2d engine.

I've decided to make up the entire levels of triangles, because I feel it will make coding alot easier, especially in the collision detection department.

donderdag 22 oktober 2009

Problem: GLUT VS LiON, Fight!

There seemed to be a problem with combining LION with GLUT, because GLUT demands the program control with glutMainLoop().
It seems, however, that freeglut3 allows you to call glutMainLoopCycle() which only performs one cycle. This way the user can keep control in his own event loop.

The question is, how does lion_poll() work if both parameters are zero? Does it specify a data change and then relies on the user calling a blocking poll to let the callback function be called?

Furthermore, there is an idea for a collision system. If the server returns the point of the colision and the reflection vector, the user can adjust his position according to that vector, and unless the latency becomes very high, this will look and work very reliable and natural.

The problem is to calculate the damage done to the ship. It's probably a function of incident speed, ship mass and angle of incidence..

dinsdag 20 oktober 2009

Some Initial Ideas

I've managed to get a simple program up, but it doesn't display the rendered quad and triangle correctly. I'm guessing it might be a hardware problem, an ubuntu problem, or simply some code fuckup, as I've used many different sources for coding inspiration. This is what it's supposed to look like, according the tutorials at NeHe's. All I get is a black screen.




I've drawn some sketches of the game's looks, as well as a diagram containing the client-server game loops and interaction:

I need to draw up a major schematic of the data structures and look into network programming again in order to be able to do b-spline correction on lag etc.

Finally managed to render a square on the screen. I'm not kidding
I proceeded to try loading alpha textures, which I have working now.
Apparantly, OpenGL doesn't care which texture is farther away, as long as it's drawn LATER. This means all the 2d objects in the 'foreground' can be drawn last and the blend order will look allright.
Still having doubts about doing the game in 3d, but it will have major consequences for gameplay, system requirements and the like.

have to investigate the following:
* what is orthogonal view in opengl, and what does it do/allow. What are the drawbacks of keeping this in perspective mode?
* what is a good cross platform network library & a good sound library.
* investigate into what makes good gameplay and design the gameplay
* design the game experience: what are the main things I want to embody in the design of the levels etc?
* what is the story behind the game? Why are the shipz fighting? How do I make this believable

maandag 19 oktober 2009

Started exploring libraries. OpenGL with GLUT seems the best for portability. Discarded using librsvg and cairo to draw scalable vector graphics which would keep the app small and well downloadable -- the glib dependency is too heavy and writing a good svg renderer is tough.

Still need to find a good & simple network library, as well as a sound library.
I'm considering using the .ogg format for files, so that I don't need to mess with any .mp3/lame protected algorithm stuff. Both libraries need to be portable.