Thursday, November 30, 2006

My Webgame Blog

Update coming soon - I'm working steadily on RGB the game, and I've added some interesting features like rope physics to it.

But for the moment, just wanted to extend an invitation to come over to my web game blog and check out what other people have made - I promise, most of the games are great, with the exception of an occasional "Worst of" post that you will probably enjoy anyway. After all, American Idol taught us that it's always more fun to celebrate our artistic excrement than it is to bury it!

Tuesday, November 28, 2006

RGB the Game

To view this content, you need to install Java from java.com

Controls:
  • r, g, b keys
  • Drag mouse in circular motion around character

Source code: rgb1 Physics Player Solid Utility World

Built with Processing

This applet is a proof-of-concept for my RGB game. This started as a C++ project last year, but I've recently migrated it to Java. It uses Verlet physics, and the character is controlled by springs - this level is just a test, and there's no purpose. To get an idea of the gameplay, though, try to do a lap in each direction. Clockwise is easier, but counterclockwise is possible, so don't give up!

Tip: if you want to climb the two walls on the right, try to bounce back and forth between them while keeping the rgb close to level. The key is to only hit the wall with one color at a time when climbing.

I'm not going to say more at the moment; play around, see what you think. I'll update and perhaps explain some of the algorithms at some point in the future.

Saturday, November 25, 2006

A Longish First Post

Hey there and welcome to Third Floor Games: The Blog. My name is Eric, and I'm a physics and math major with a strong interest in programming and no full time job. So it only makes perfect sense that I would start a game development blog. The "Third Floor" is, in fact, a glorified attic; if I ever get a working digital camera, perhaps I'll give you the grand tour. I've got kind of a crappy computer, which is great for game development because it means that if I can run a game, so can you (probably). A huge mistake is to build a game on a high end gaming rig only to discover that 90% of the public can't play it. Especially with webgames, your primary audience is people on computers that their schools or companies own, which means they probably suck, especially when it comes to graphics. Keep it in mind...

I'm an open source idealogue, so anything I do here I will be sure to provide the code to, with one exception: if I get around to making high score tables on a server or anything like that, I'm going to hold back the key that you need to submit scores to my server so that people can't cheat. You can always substitute your own, though, or if you care enough, decompile the game files and read it off so you can cheat. If we ever get there, I'll explain possible ways around that, too.

As this is the Internet, I want to do this stuff in a net-friendly language, i.e. one that outputs something I can embed in a web page. For the moment, that means basically either Flash or Java, neither of which is entirely desirable. I could go through the pros and cons, but I don't really want to get into it. All I'll say is that I've dealt with both, and for my purposes, Flash doesn't quite cut it. For your purposes, the Flash IDE is a damn expensive piece of software, whereas a Java compiler is free. Of course, it's not incredibly difficult to translate between Java and Actionscript, so I'm sure that even if you work in Flash you might find something useful here.

So your first mission is to get a Java compiler. One option is to go here (to Sun's site) and download a recent version of the Java SE Development Kit - at the moment, it appears to be 5.0 update 9, but that will certainly change. If you go this route, I'd also suggest picking up Eclipse, which is just about everyone's IDE of choice.

However, there's another option that I'll strongly recommend: head over to Processing.org and pick up the Processing IDE with Java. Processing is a bare-bones IDE, but it shines because everything you do inside it takes place within a very well constructed class that gives you extremely simple access to a lot of things that are difficult to do in Java. Ever struggled with getting an animation loop running smoothly in Java? Well, if you use Processing you won't even need to think about it. You'll write frameRate(30) and provide a draw() method, and draw() will be called 30 times a second. End of story.

Even better, you can do 3d graphics inside of Processing. It has both a software renderer (called P3D) and OpenGL support; unfortunately, to use OpenGL in an applet, the user is required to click a security box. Fortunately, Sun itself has signed the JOGL library, so this is not a huge problem (sadly, most users just click those things without reading them anyway!).

In any case, most of what is done here will take place within Processing, but make no mistake - this is Java code. Certain functions are only offered through Processing, but if you're willing to fight your way through Swing/AWT, you should be able to reimplement them with no problem. The guts of most algorithms should work in any Java program.

One note: in Processing, everything that you do is put inside the environment's uber-class, PApplet. This means that, for instance, when you declare a Vector3d class (this will be one of our first missions) in a tab, it is actually an inner class. So you can't have static variables, for one. Just something to keep in mind.

Anyways, take a look, it's definitely a worthwhile environment to use, and the libraries that exist for it are pretty good, too. Next time we'll do some real programming.

Before you move along, check out Zombie 4, a simple but addictive game written in Processing (nope, I didn't make it - John G in the Processing.org forums is to thank for this one). The 3D graphics are done entirely through the software renderer, and I think the results are great. Also see The Sand Game for a completely different style of gameplay; this was also done in Processing, so I'm told.