Collisions

My main character is a rolling ball. It has objects attached to it which stick out from the ball, but don’t roll (guns, actually). What I wanted to do was joint the physical rigid bodies together in such a way to achieve a nice physics-based simulation of what I want, which would also mean that the protrusions from the ball would collide and react with scenery and other world objects.

After singing Jitter’s praises last week, I’ve now got to pull it down a notch or two. Jitter is a great solution for simple rigid bodies all colliding with each other; but what it lacks is some good joints between those bodies. There is a basic joint type; but it’s a bit buggy – Jitter’s creator claims that it’s because the system doesn’t loose any energy which makes the joints squishy and not solid.

I attempted some fixes to the squishy joints, but I decided to leave it alone for now and work around the problem. The spherical ball character is what’s important, but I don’t want things that stick out from it to go through the walls. My current solution is to place a collision hull slightly away from the walls such that extrusions from the ball model don’t pass through the walls. I’ll build the hull by hand in Radiant so I can specify very specifically where the hull should be; calculating it automagically would likely result in more issues right now.

This approach has caused it’s own issues though, because the Quake3 BSP loader I have is only at version 0.4 and doesn’t support the many surfaceparm values that I need for things like clip objects.

Also, the traditional Quake3 clip brushes (using the nodraw texture) are not exported as faces by q3map2 which is what I need to collide with. They are exported only as brushes, which are convex polyhedrons made up of a finite number of planes. The collision hull I’ve built for use in Jitter uses a polygon mesh in a octree, the definition of a brush doesn’t contain polygon data. It only holds planar data. For the simple collisions of Quake3 this was an acceptable method for the computing power of the machines of the time. These days collisions are done on a per-poly basis for much more accuracy, so that brush data is slightly redundant.

There are algorithms out there that can triangulate such data into a mesh, but it’s a long-winded approach to the issue. Another option is to use the invisible texture of Quake3, which exports all the required faces for building my collision mesh but renders a transparent texture on them.

There were two issues with the invisible texture approach, firstly objects that have this texture still cast shadows. This can be solved easily be tweaking the Quake3 shader that associated with it. The second issue was that transparency doesn’t seem to work in my engine; I just get black where it should be clear. I’m not quite sure where the blame lies for that – but a few simple attempts to fix it by manipulating XNA 4.0′s BlendState didn’t bear any fruit.

What I really wanted was a flag on the faces that I don’t want to draw so they don’t get added to the render list. Ideally, that flag should be a surfaceparm and should be passed through to the engine. So, I fixed that.

After updating the Content Pipeline (which is what creates and/or copies the data files over) so it now supports the surfaceparm values I can now use those in the engine as I see fit, unfortunately many of the values have a bit of a dual-purpose use between q3map2 and the engine so I’m inventing my own for engine usage only. The first being an ‘invisible’ flag. As I mentioned, the way this was achieved in Quake3 was to render a transparent texture – regardless of my transparency issues it also seems like a bit of a waste of a render call, so instead I’m now setting a flag such that those faces never get drawn in the first place.

I also seem to remember that the extravagant curves that were in Quake3 had no collision data on them; you couldn’t run directly on a curved surface – a bit of clever fakery was used by the level designers to achieve that effect when it was needed. Now that I’m using the polygon data; collisions on curves should also be a fairly simple matter.

After sorting all that out I now have a bespoke invisible collision hull on my level, and after a little more coding I got the camera following the player object in a simple 3rd-person fashion. A ray is cast out from the player position in the opposite direction to that which it is facing; and is truncated if it collides with the level. It can result in a very close view of the player if you back into a wall; but I’m going to leave it at that for now.

The target for next week is some kind of local multiplayer with an aim for online multiplayer via Xbox LIVE. Multiplayer is my final major hurdle before I can get on with a bit of actual game development as opposed to engine development.

Wednesday, 18th September 2013 at 08:30

BSP, Physics, and XBLIG

I’ve been busying myself with getting a game engine of sorts up and running on my newly purchased Xbox 360. I had two main criteria for the engine which I’ve managed to get working. The first was the ability to load Quake III Arena style BSP maps that have been compiled out of Radiant. The second criteria was that it had to have some level of acceptable physics, specifically for spheres.


BSP

My opening task was trying to find if anyone had done this before, and after some searching about I found a few different BSP loaders. Though as I’m aiming to release on XBLIG (Xbox Live Independent Games) all the code must be written in C#. I finally found XNA Quake 3 Lib which looked promising, but was last updated in February 2009 – over 4 years ago. XNA has changed quite a bit since then, so the libraries needed some revamping to make the code work with the newer XNA 4. Luckily the Q3 BSP file format hasn’t changed in a long time, so the majority of the code was still sound. This saved me from delving into writing my own BSP loader; which was a nice shortcut. So thanks to the guys who coded that up in the first place and put it under the Eclipse Public License.

After I had their example level running on the Xbox 360 I naturally wanted to try out my own level. I knew that Q3Radiant (my favourite) had been replaced by GTKRadiant somewhere around the year 2000 by TTimo, but after downloading GTKRadiant (and swearing at it a lot) I found a better maintained version now going by the name NetRadiant. There was, and still is, much swearing while I use it – it just doesn’t feel as fluid as it used to. Maybe I’m getting old. I managed to put together a few test levels coated with a grid dev-texture, but the development pipeline from the editor into my engine is a bit wonky. I’ll be improving it with a few automated scripts in the near future.


Physics

A few lighting bugs later… the level loader was up and running. The next hurdle to clear was physics. I’ve done a lot on sphere-poly collision before and have quite a number of well drawn notes about collision and resolution with the maths and the theory behind it. So, I set about writing my own physics routines and systems. It went… okay. The basics of colliding with polygons in the BSP model were done – but the task of then adding mass and gravity and body-to-body resolution, joints, physic materials, and so on was a bit daunting! So I went searching for an existing solution.

Like the BSP code, I need the physics to all be written in C# and commercially licensable. I found Jitter Physics, and should have gone down this route first. It’s a brilliant physics engine and only took me a few days to get working very nicely with the mesh of my loaded BSP model. It features everything I need and then some; the newest feature being cloth physics which gives me some nice ideas for my development.


XBLIG Game

I’m going to be experimenting with a third-person camera next and a few simple level designs to trial my game theory and work out if what is in my head will actually be fun. In short though; I now have a Quake3 style engine with great physics to start sandboxing out some ideas to release on XBLIG. The fun has just begun!

Wednesday, 11th September 2013 at 22:52

Smith

Now my site has a new look, it’s time to move onto more important things. The most important being games development. I’ve had a game idea called Smith for a few years. It’s been bounced around in my head a lot and is the most mature of my ideas that hasn’t been shelved or forgotten. There’s no clever new game mechanic for it, it’s just a game with a story.

The story came first, before I considered the style or genre of the game. It came about because I wanted a protagonist who was a bit more real; not a hyperactive teenager or a brooding war hero. I wanted a hero who had a wife, a family, a whole life. He is Smith. The name didn’t come about from a desire to be generic, the original game title was Blacksmith – that’s what he is – then it changed to Weaponsmith, and finally just Smith. None of the other characters have names yet, and he doesn’t have any children. I couldn’t write children into the storyline without it feeling forced so I dropped that idea.

As expected, Smith has to save the world from impending doom. Fighting evil and saving lives. His personality has started to develop in my mind over the past week or so, which is effecting some of the storyline. You can think of him as a medieval John McClane, gritty, witty, and a bit irritated about the whole situation.

The game is set to be an adventure platform game. Parts of dialog and character interaction, and parts of hack & slash platform-running mayhem. There’s currently a bit of sneaking around as well to break up the action; whether that works or not will be subject to quite a lot of gameplay testing.

I’ve started using the Unity engine for development. after a bit of a steep learning curve with the tools it’s proving to be great for rapid production. I’ve got quite a lot still to learn about it, but I have two test levels and an animated interactive character that the player can move about. I am impressed.

I’m at a point where I’d like to bring an artist on board for doing some concept work. If you’re interested I’ve put together a page here that describes the game in a bit more detail along with some inspiration for the ‘feel’ of the game.

I’m not going to procrastinate too much by blogging or tweeting about development, so it’s back into Unity for me to experiment more with level design over the next week.

Sunday, 7th April 2013 at 16:51

Rethemed

I’m going through the process of updating Wexion.net’s theme to be much cleaner. As I don’t have a staging site this is being done live throughout the day. So the fun thing is that you get to see all my experiments and my mistakes while I’m playing about.

First is the main blog area (that’s this part) then I’m going to update the pages, like the About section. After that there are peripheral features like search and galleries which I’m not sure I’ll even use; but I will see how it all goes. The theme is mostly white – I don’t expect that to change much. I like this Josefin Slab font from Google’s Web Fonts, but I’m not convinced it’s the most readable font. That may require more experimentation.

I’ve noticed some of my past posts are a bit ranting, and not very well written. I’m going to leave them there though as a reminder to improve on the content on my site.

∼∽later∽∼

I’ve decided to leave the Josefin Slab font as the main one for my site. If anyone with a designers-eye would like to tell me how it looks; I’ll take any criticism. It’s only taken a few hours and things are looking much tidier around here now.

Friday, 5th April 2013 at 00:42