I’m finding it hard to believe its almost 2009 already! I guess it’s that time of the year where I start reflecting on my accomplishments and shortcomings. Back in January I had set the goal of completing a commercial game. Well, that never came to fruition for various reasons. It was mainly a conflict in balancing school responsibilities with game development (which at this point in time couldn’t be considered anything but ‘hobby’). I guess my flaw was not taking it seriously enough, as I can recall on more than one occasion where I could have been a little more productive over the weekend with the time I had.

But after all is said and done, I’ve certainly made great progress towards that goal over the year. For instance, I’ve been writing a framework over this year to help me aid in making a game and its shaping up to be really great in terms of speed and productivity. Another nice thing that came out of my ‘venture’ into making frameworks was porting Farseer Physics to Blitzmax. Now users of the Blitzmax language have another ‘option’ for a physics solution. And finally, I’ve been making a lot of progress on my XNA game that will hopefully be released onto the Xbox Live Community Games.

I am feeling a bit stretched thin trying to juggle several exciting projects at once, but I’ve dropped the ones that were not vital to me achieving my goals and I’m pretty much focusing on 3 separate projects at the moment.

XNA Game

So I’m currently working on a new platformer for the Xbox 360 using XNA and TorqueX. This is my ‘short term’ goal of releasing a full game (I’m loosely using the term ‘short’). Currently, the team consists of me and one artist. Since January we’ve been prototyping different types of games, and always coming to the same conclusion: this game wouldn’t be worth polishing up. In the back of both our minds, we were wanting to do something a little more ambitious, but were trying to stay ‘practical’ and do something small first. In the end, I couldn’t muster up the motiviation to work on something that I didn’t fully believe in. So we went with the platformer idea. The basic ‘platformer’ mechanics exist, but it’ll have several twists in terms how one navigates and interprets the world. So we’re both excited about that. The unique ‘navigation’ mechanics we plan to implement are looking to be very challenging. On the technical side of things, since I’m using TorqueX the biggest challenge I’m hitting is TorqueX’s way of handling how a platformer should work. We don’t want to give up the tool set that TorqueX comes with, as that is the main reason why we want to use the technology. So I’m having to try to work in the ‘constraints’ of how the engine deals with collisions and rendering. Hopefully it’ll work out :).

Blitzmax Game

Blitzmax development is where a lot of time has been spent in the last couple of weeks. My ideas and projects are more ‘long term’ in Blitzmax than it is in XNA. Hence, why I’m taking my time building up a more robust code base. The last couple of weeks I’ve been deep in development of a networking module that works with my framework. It’s functional currently, and the API is seemingly easy to use I suppose. I’ve essentially taken Blitzmax’s built in TStream object, extended it as TUDPSocketStream, and allowed my game to use a ‘connection based’ protocol similar to TCP, but it uses UDP underneath. Why not just use TCP? Well I’m needing the flexibility of sending different types of data with different priorities. The 4 priorities I’m designing into the net code are:

  1. Unreliable Unordered – this is basically just UDP with no extra bells and whistles.
  2. Unreliable Ordered – Its important for the game code not to work about getting ‘out-dated’ data, but doesn’t necessarily care if a few packets don’t get to their destination. The networking layer will manage the ordering of these packets and only make them available if they are ‘newer’ than the last one it got.
  3. Reliable Unordered – This will be useful for messages that don’t need to be sent often, and are not temporally related to their previous messages.
  4. Reliable Ordered – the ‘heaviest’ of the 4 channels. I’m actually implementing this rather closely to how TCP deals with reliability, but using UDP as the underlying protocol.

The networking layer has proven to be rather challenging and complex. When I first initially started out, I had basic networking done in about a sitting or two. But as with anything dealing with networking, there’s a lot of work that has to go into all the unreliability of networks and how to deal with that. Trying to get the code stable so that it isn’t ‘sensitive’ to one or two lost packets is not trivial unfortunately.

I’ve tried to design the lower-layer networking close to how Blitzmax operates with normal streams.

Local msgSize:Int = \_socketStream.Receive()

That’s essentially all that is needed for the UDPSocketStream to ‘receive’ messages. One important distinction, is that it is non-blocking. If you use Blitzmax’s built in TCP and UDP sockets as-is it becomes difficult to implement a single-threaded program where your main loop looks something like this:

while running

Local msgSize:Int = \_socketStream.Receive()
... do some net code

Update()
Draw()

...

wend

TUDPSocketStream does use Blitzmax’s socket API, but does a little ‘outside the box’ tinkering to get non-blocking IO working in a native Blitzmax fashion. My socket stream has a method that makes this easy by calling some ‘undocumented’ functions that map to the standard sockets api:

‘bbdoc: enables/disables non-blocking on the socket
Method SetNonBlocking(enabled:Int)
Local b:Byte[1]
b[0] = enabled
ioctl\_(_socket.\_socket, FIONBIO, b)
End Method

One thing to note is  ioctl_() is defined internally by blitzmax, and FIONBIO is a constant used by the sockets API. I had to look up the constants values,  and it currently works in windows without a hitch. To get it to work on Mac/Linux I would have to find the right constants for the ioctl() function that work under that OS. Here is the extern needed to gain access to those functions in Blitzmax:

‘ the socket options

Extern “os”
?Win32
Const FIONREAD:Int = $4004667F
Const FIONBIO:Int = $8004667E
Function ioctl*(socket:Int, opt:Int, buf:Byte Ptr) = “ioctlsocket@12”
?MacOS
Const FIONREAD:Int = $4004667F
Function ioctl*(socket:Int, opt:Int, buf:Byte Ptr) = “ioctl”
?Linux
Const FIONREAD:Int = $541b
Function ioctl\_(socket:Int, opt:Int, buf:Byte Ptr) = “ioctl”
?
End Extern

BLide

For anyone that is doing any serious development in Blitzmax, I can’t see anyone in their right mind not using BLide. It’s a professional grade IDE for people who wish to develop professional grade applications/games. I’ve seen many who are still ‘clinging’ to the default Blitzmax IDE for whatever reason. At this point, if I’m working on anything that will require more than a day’s (hell, 30 minutes) worth of work then it’s worth opening BLide.

I’ve been working on a rather ‘large’ plugin for BLide that will allow users to download add-ons directly from within BLide. It also tracks updates so you can easily update from within the BLide editor. This will be great for those that are making add-ons to BLide and wish to reach their primary audience in a more direct way. The initial ‘proof of concept’ allowed for downloading of add-ons but the new version provides both a way to ‘upload’ new add-ons, moderate add-ons, as well as download them. So it’s an all-encompassing plugin that automates the delivery and deployment of add-ons. I’ve yet to come up with a name for the whole system, but as it comes closer to ‘beta’ I’m sure I’ll think of something :).

Onward to the Upcoming New Year!

I’m hoping to get the first complete pass of the networking layer done by year’s end. I’m focusing on building up my framework for the remainder of this month, being that it’ll be a rather hectic holiday with plenty of travel, it won’t be too bad if I don’t get as much done on it as I intended since its a long term project. Come January, I’ll be primarily focusing on my XNA game and an that interesting BLide plugin. The start of a new year is exciting because it always brings a ‘clean slate’ and allows me to gain some perspective on what my goals for the year will be. I hope by the end of 2009 I’ll finally be able to say I’ve ‘released’ a game successfully, be it indie or otherwise :).

Now, I’m off to go snowboarding for a week! Merry Christmas and a Happy New Year!