Spacewalk - Part 1
During my practical course in experimental physics I decided not to use C++ this time, but rather a language which has a way more extensive standard library and is way easier to debug. Just a language.. that is easier, in a sense. Long story short: I chose Python and fell in love. I then decided in a few free days to write up a little engine which is very similar to Kiwi (my C++ engine) now called Pywi. A buddy of mine and me then decided to put this engine to test, so we can maybe use it for the upcoming Ludum Dare. At first we struggled a bit with finding an idea we both would like to implement, but after looking at one of my idea-lists, we decided to 2D-ify one, named “Spacewalk”. It essentially explores multiplayer deathmath and capture the flag in space, but with level geometry consisting of materials with a very high mass. We actually had a few videos which were a little more impressive and capturing the mind-bending-fast-paced-style we would like to achieve in the end more appropriately (just more appropriately but in fact not at all), but somehow Fraps broke these files and neither WMP, nor VLC and MPlayer could play them back. We made these videos almost one and a half weeks ago and were not able to work on this game together since, so it’s just this!
Polygons and Gravity
Technically we first weren’t sure if the level should consist of predefined elements, a huge image that’s used as a gravity-source or something polygony-vectory. Inspired by Soldat we decided to use polygons. We used Inkscape to draw these curves and export them to svg, which is then parsed, triangulated and rasterized. The rastered image will be interpreted as a cloud of point masses (every pixel drawn) and the resulting gravitational potential is stored in an numpy-array and saved (an image essentially). In-game we take the numerical pseudo-gradient grad V = (dV/dx, dV/dy) with dV/dx = (V(x + h) - V(x - h)) / 2h and h being one pixel and use this as the gravitational force. Also we calculate 1/(r + r_0) instead of 1/r to make the potential less steep, so we can choose a fairly high gravitational constant (because 1/r^2 decays quite fast) without the player sticking to the level geometry too hard.
Net
This was Jonas‘ (said buddy) first and my semi-first venture into the realms of networked programming. Both of us already used some high level network classes (e.g. Qt) and used BSD-Sockets a few times. I actually worked on a LAN-multiplayer-game recently, but didn’t get very far (moving and shooting and infrastucture without any optimizations or compensations). Just to start off we decided not to use ANYTHING remotely hard or an own reliabilty layer (to any extent whatsoever) (this has to be done some time though), client side prediction, lag compensation or proper interpolation and not surprisingly and very much to our liking this is more than appropriate over LAN. Very rarely though essential initilization packets don’t reach the client (or the server respectively) (for example handshake packets or map changes) so we somehow have to implement a reliable layer on our own or switch to ENet, which I used in mentioned former networked game. Apart from this we tried to reduce the rather jaggy movement by exponential interpolation (I’m not sure if it’s called like this - position += c * (target - position) with c in [0,1]).
Collision
Fortunately we had the triangulated polygons at hand and just had to implement Seperating Axis Theorem. There was only one thing we really struggled with for quite a long time, which is minimal translation vectors that, for reasons we didn’t really understand, pointed in the wrong direction. We decided to just flip them if they pointed along the vector between the two polygons center of masses (cosine of inner angle < 90° <=> dot product > 0)
Sorry for not really telling you interesting stuff, but this should be more of a documentary, rather than lessons.