Parade of Rain

Graduation is over . Real world here I come.  Anyway, going to be moving in probably a month or so. In the meantime I’ve got a lot more time to focus on some of my game projects. My main focus is finishing up an iphone game and it’s coming along great! Whenever I play it I end up playing it for a lot longer than needed for testing, so hopefully that’s a good thing . I’m still iterating on the gameplay and the aesthetics for it using placeholders and crappy programmer art. The current build in still shots looks like a ‘mess’ more or less. Won’t make for good app store screens looking like it is now because it’s too confusing. The very first version was very easy to distinguish the player from enemies because it simply had 3 colors (black, red, white). I may have to use that principle moving forward to help keep the confusion to a minimum.

The game is a tilt-controlled shoot-em up. Except the player cannot shoot directly . So during the game the player only tilts the iPhone and never touches the screen. Two big wins here:

1. Intuitive controls
2. No fingers getting in the way of the screen.

In order to destroy enemies the player must run into power ups. When they hit one it sets off an explosion affecting an area around the power up. The basic one simply kills enemies in the blast radius, while others have more interesting effects.

So here’s a few screenshots of the game from very beginning to the current ‘messy’ build.

The above screen shows the very first prototype. Green boxes were pick ups. People that played it enjoyed it despite the really simplistic look.

The next iteration had some basic placeholder graphics and a static background placeholder image. The gameplay also introduced pre-configured wave shapes for enemies to spawn in. So in addition to random spawning enemies could try to attack in lines, surround you in a circle, etc. It upped the difficulty a bit so some tweaking was needed.

This next iteration was focused on gameplay improvements and additions. I added a new power up (a type of explosion that spread from enemy to enemy), and a combo system along with a few other things. The new power up was added to counter-act the difficult spawning patterns of the enemies and it proved useful. It was almost too useful.

And that brings us to the current build. I redid a lot of the graphics and went for a simple vector-art look. Unfortunately, the overall look tends to be very messy in screenshots and the color scheme is ‘meh’. Though I like the look of the enemies, the explosions (particularly the redone viral spreading explosion) could use some work. The blue enemies are enemies that were hit with a freeze power up. There were a few more power ups added. In general, the game feels more solid but visually feels less focused.

Those that are wondering where I got the placeholder background images from:

• The Space nebula background can be found here
• The vector art background can be found here

I do not intend to use them in the final game as they will be replace by original artwork.

I’ll have more on the game’s features in the coming weeks as things start to finalize.

It has been a while since my last blog post . If you’ve been following my twitter account though you’d know it’s still been a busy last couple of months. I’ve been developing things on several fronts lately. For one, I’ve been busy developing some supporting code to hook Opensteer into C4 in a more seamless matter and work with C4’s constructs in mind. It’s a project related to some school work, which has proven to be challenging and fun. Hopefully the students in the video game design class that I did this AI library for will find my work at least useful for their games.

In other news, I had a inspirational fever lately as I’ve come to understand a lot more of how physics and animation work due to a class I’m attending. I decided it’d be a fun spring break project if I could apply what I’ve learned to a simple 2D physics demo. Maybe it’ll grow to something more, but for now it’s more of an exploration and an excuse to work in Blitzmax again.

I’ve started the registration process for developing on the iPhone and it’s proven to be rather headache inducing lately with trying to get all the paperwork in order. After yet another delay, I won’t be able to start deploying apps on my iPhone for at least another 2 weeks. Damn. The iPhone game development venue seems promising, but the window is closing fast for anyone wishing to make a decent amount of money with minimal marketing effort. With the announcement of iPhone OS 3.0, and all the new features it’ll boast it makes the platform even more exciting to develop for. One of the more interesting development I think is the ability to ’subscribe’ to apps and also buy additional content for particular apps. This type of business model would maybe give way to the first true ‘MMO’ (and I use the ‘Massively’ M loosely here) on the iPhone that can sustain itself? Interesting indeed.

Finally, I’m still chugging away at my Xbox Live Community Game. No idea when it’ll be done and there is no name for it yet. All I can pretty much say is it is a stylistic platformer. I recently got a parallax system working that I’m finally satisfied with. Also spent a couple of hours with Adam browsing music sites for potential audio soundtracks and we came up with some interesting possibilities. A lot of our musical choices leans more towards the ‘classical’ genre, so it’s not your typical uppity/pop/techno game music. I really hope as things solidify I’ll finally be able to post some media to show off the progress of my games. Until then, I’m focusing on finishing my last semester in school, looking for a developer job (preferably game industry related), and working on these game projects in the meantime.

I’ve decided to give this twitter thing a try. I’m going to try to keep that feed updated as much as possible on my progress throughout the several projects I’m involved with. I’m spread a little thin at the moment so trying to find time to come up with a substantial blog post is becoming increasingly difficult. I’ll try to come up with some blog posts when I hit some milestones for my projects in the future.

Yea, I’m a little late posting about the ‘new year’. My last post pretty much covered what I had to say about 2008. I’m still in flux at the moment getting settled into my new schedule for the semester. Just got off the phone with a colleague discussing potential themes, styles, and design goals for our upcoming XNA game. After spending 3-4 months prototyping the ideas we had in our heads I think we’ve cut the fat and finally have something we can focus on getting done.

Looks like this Spring I’ll be getting a heavy dosage of C++, C#, and Blitzmax. I’ll have a lot more emphasis on C++ since the majority my school work/research will be done in it. Gotta get back to working with Open Steer in C4 now. I leave you with a teaser…

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.

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 was made aware of a serious issue with detecting collisions between TGeom's recently. While it did not affect anyone who was using the engine and letting the TPhysicsSimulator run and manage collisions and dynamics, anyone who wished to use Farseer.BMX's collision routines separately by calling TGeom.CollideWithGeometry() ran into issues. The code has since been fixed and updated. Please update your Farseer.BMX module so you can continue using it without this annoying bug.

Download: Farseer.BMX v1.1

What if I made customizations to the Farseer.BMX code already?

Well thankfully, the bug was isolated to only one file, and in particular one method. If you wish to keep your custom build of Farseer but want to fix the issue then simply download this new version and take the Collisions/Geom.bmx file from it and place it in your corresponding Farseer.BMX directory.

If you happened to make changes to the Geom.bmx file itself, then simply search for the method 'CollideWithGeometry()' in the new version and place it in your current version. For those that simply want the code that's changed (since this is a small change) I pasted it below:

This was a minor update that I thought was critical to getting out there for those that may be experiencing problems, so there aren't any 'extras'. Documentation is still a WIP.

Quick status update on Wildboarders. Every week I tend to have small incremental goals to hit. This week focused on wrapping up the supporting code to allow me to generate levels for the game. I'm slowly starting to realize my current schedule isn't accomodating to my game dev time. It's actually the opposite, my game dev time is working 'around' my schedule. Looks like I'm going to have to rearrange a few things on my weekly schedule to actually get this game done on time and make game dev my focus for the next several months. Why do we only have 7 days in a week? Sheesh.

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...

Just wanted to post a quick update on some game development stuff I've been working on the past couple of months. Farseer Physics is just one of the few projects I'm working on. By the way, I'm still slowly working on Farseer physics, but don't expect an update on it for a while. I've mainly been giving support to those who are using it through e-mail. So if you're having issues with it or can't figure something out let me know and I can help you there. I also figured it was finally time to do some aesthetic work on the site. I like the way it turned out . All in all, things are doing great but I'm ever so busy! Over the last few months I've been neck deep in either Blitzmax, C#, C++, php, or mySQL.

Read the rest of this entry »

I've been working on a few projects that require blitzmax and a web-server (php/mysql) to communicate. Along came the need to hash files. This code archive entry was very useful . I decided to wrap it into  an object and add a new method to it. Even though it's a series of functions I still tend to make types with functions in them to help me organize them (it's like a cheap way of  namespacing). I needed the ability to hash a file using Sha-1 hashing. Seeing that php has a function called sha1_file($pathToFile) I figured I'd implement the equivalent on blitzmax. With this THasher type, I've added a SHA1_File(path) function also.

Why hash files?

There are many reasons to use hashes, but recently I used it to check for file changes. If you've ever wanted to find out if some arbitrary file has 'changed' since the last time you've opened it this can prove to be useful. If you save the hash beforehand then recompute the hash now and if they are different, then something's changed! Some applications of this are:

• Write a file-updater to quickly find out which new files need to be downloaded. Just comparing hashes would be sufficient in most cases, instead of having to go individually byte-by-byte or traversing the file structure to find a difference.
• help stop cheating. If you don't want users changing texture files to gain an advantage or don't want them 'mucking' with any other data file. If you check the current hash against a previously approved one and it doesn't check out then the file has more than likely been tampered with.

How Do I Use THasher?

If you want to hash a string using SHA-1 then:

Want to hash a whole file? Then:

Keep in mind you can hash any file, not just text files like in the above example.

Anyway, read on for the whole file. With the exception of SHA1_File() I did not write these hashing functions for Blitzmax. They were simply taken from Yan's very helpful code archives post .
Read the rest of this entry »

Yes, yes I know the documentation is lacking at the moment for Farseer.BMX. I'm still working on it on a few fronts. First, I'm trying to do api documentation (bbdoc mostly). Secondly, I'm trying to write tutorials/guides that help show how to use some of farseer's features. I had hoped that releasing the demo application source code would've covered this aspect as the demos cover pretty much each feature, but I guess since the demo source is a bit more complex in design (handling a lot of graphics related mumbo jumbo), the actual 'needed content' wasn't particularly easy to find. So I'm going to try to write up very simplified versions of some of farseer's basic features (minimal graphics, minimal code).

I've uploaded the first of these tutorials to the articles section. It covers creating concave polygons in farseer . More to come soon...