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.

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:

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:

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:

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!

I'm beginning to wrap up most of the 'content' code such as tutorials, in-game events/dialogues for the first level of the game. It's taken a while to complete the first level just because there's some start up development that needed to be done. I've designed a lot of the systems to be data-driven so ideally, level creation will be a speedier process. The only portion I'm not too satisfied with is the cut-scene/event code. Most systems like tutorials and dialogue lend themselves rather nicely to simple data-driven designs. Trying to orchestrate multiple custom in-game events for several of the levels is a daunting undertaking. I do not have the time to and resources as a single developer to go off and create a complex in-game event/cut-scene editor just for this game. The good thing is that the majority of the gameplay code is already complete, so it's these 'exceptions' that are mostly left to deal with. Below is a 'work-in-progress' screenshot of one of the in-game events. Your character, Indy, took a bad fall and ate snow! At the moment I'm using pretty much 100% placeholder art, most of which is from the previous version of wildboarders.
 

So much to do... so little time...

Blitzmax

In Blitzmax news, I'm still working on my little framework that sits on top of Blitzmax. It's going along pretty smoothly and I have basic functionality already implemented to create simple prototype games. It's using a component-based architecture, which I came to learn about when I first started using XNA and read more about through some game dev books and blogs. So far it's been working out great in terms of flexibility. It's been pretty easy to add new systems with minimal changes to the core code. I'll just run down some of the things that are implemented or planned for the framework

2D Scenegraph

A Scenegraph test using a gunstyle map

This is fully functional at the moment and is resolution independent, which is handy.  This is kind of the bread and butter of the system and what most of the game code interacts with. I've designed the scene graph so that it's independent of actual art assets. This'll make it easier to create dedicated servers in the future that will use the scenegraph to manipulate networked objects...

Another scenegraph test using VGF in blitzmax

Resource Management

This one has been tricky. Initially, it was simple to just manage textures, sounds, and bitmap fonts in a single 'resource manager' that would make sure duplicates aren't loaded into memory. Recently, it's gotten more complex as I've created a new type of 'resource' that represents a 2D Model. This allows me to create character  and object sprites with moving parts and animations. I wanted to be able to just load a model and then use it with minimal hassle. It works nicely now on the game code level where you just state:

 
but the underlying code has to do a lot of trickery to get that to work to allow you to load multiple model instances. So in the end, I've found the resource manager to be rather difficult to 'extend' to more complex data-types. But I wonder if that's just the nature of the beast, as many other engines and systems seem to have rather complicated sub-systems in place to manage things like these (XNA has a whole 'content pipeline' just for this purpose).

GUI System

The GUI is rather bare-bones at the moment. This system is what wraps the game elements into a set of screens. Each screen has widgets you can attach to it where the screen can manage on it's own. For example, the whole 2D scenegraph system is a widget so you simply add it to a screen to view the scenegraph. I've implemented only buttons and labels so far, so it still needs lots of development. Transitions are inheritenly part of the gui system as each screen and widget has an API you can extend to manipulate how they get onto the screen and off the screen.

Networking Layer

This right now is in the early planning stages with some proof of concepts and prototypes in development. From the beginning I've wanted my framework to incorporate networking but in a modular way. So if you wish to create a non-networked single player game, then it's no hassle for you to continue coding as you usually do. Ideally, it'd be nice to just add a 'network component' to any object you wish to network, but from the looks of it, there may be some other house keeping that just has to be required in order to get the performance needed for a game. Simplicity is what I'm shooting for here. It's probably going to take several attempts and prototypes to get this to be easy to manage.

C++ & C4 Engine

So over the summer I worked on a fishing game with a friend for a game design course. It turned out pretty neat for our first foray into 3D and C++. It was a 2 player networked game where two fishermen move their boats around a waterworld fishing for unique fish. The gameplay centered around the fishing mechanic, which was a simple rythm mini-game. The waterworld had beacons of different color lights that burst out from the water signifying the difficulty of the rythm game you'd have to complete in order to catch that fish.

 

Then there was the 'multiplayer' aspect to it. When you caught a fish, the weight was deteremined by how accurate you were at the mini-game. Now all your fish go into a shared inventory where the oponent can see which fish have been caught, how heavy, and by who. If your opponent catches the same fish but heavier, he 'steals' the credit for catching that fish. Anyway, originally we wanted to just make it an exploration and cooperative game where both work together to catch all the fish, but in the end the added competitive features helped make it a bit more exciting. These are some pictures of the game in it's two main modes: fishing and viewing the inventory.

XNA

Oh, XNA how I love/hate thee! On one hand you give us some of the most productive game production tools with Visual C#, TorqueX, and the XNA framework. On the other hand, you trap us eternally onto a platform they call the Xbox 360. With that said, I'm still developing for it. In fact, my current major project is in XNA and my Blitzmax framework is just a weekend thing. I've currently been working on a new version of Wildboarders for the Xbox 360. It's been in development for about 2 months now. I can't say much else about it not because I'm trying to be 'hush hush', but because there isn't much else to say at the moment. In the coming months I'll be sure to post some more info on game. Now I need to go figure out why my Xbox live account no longer works and why I can't access billing.microsoft.com anymore . While I'm in a ranting mood:

I find it rather silly that I have to 'check in' with MS whenever I deploy a build to the machine by requiring a connection to XBL. I guess that's what we're all willing to put up with since Xbox360 is a 'closed' platform. This certainly wouldn't fly with developers on the PC...using Windows...Vista.

On the gaming front, Gears of War kicks major ass. I was skeptical after the initial announcement many months ago. I just couldn't see how the gameplay would end up interesting, but the graphics were sure a joy to look at. Regardless I caved into the hype. Fortunately, it has lived up to the hype in every way if not more. The gameplay truly delivers and it's a very well polished (understatement of the year) game. Got Tony Hawk's Project 8 also. Haven't played a Tony Hawk game in years, so coming back to it was a bit refreshing. Haven't tried online yet, but the leaderboards for the single player game are great on their own. Wii is coming out at the end of this week so I can't wait to get my hands on that! In between all of that I'm still playing BF 2142 somehow. Yea, I'm pretty...um...deep into the whole gaming thing, development and all. Not sure I still manage to make time to go out on the weekends . Either way, this fall/winter should be an exciting time for gaming and game development!

I'll post a new entry when I get the tutorial updated. But that's it for now. See you next week, bye!