So I just registered over at Experimental Gameplay, a project that apparently grew out of a few crazy grad students' dreams of writing a whole crapload of games in a very short time. I haven't done anything there yet, but I find the idea very interesting. Basically, they suggest throwing together really quick prototypes of games rather than sweating out all the dirty details for too long - if it doesn't work, throw it out and start something else. Sounds good to me, though I'm not sure if it's quite my style yet.
These guys have written a very interesting piece over at Gamasutra (another indispensable resource for budding gamemakers) that explains how to get a good game out in less than a week. They have put out quite a collection of games that all look quite impressive; unfortunately I can't currently play any of them because they all seem to be PC-only, and I am on a Mac right now (yeesh, I know, but don't worry - I'm not becoming one of those people, it's just that I don't have a laptop so I stole my brothers for a trip overseas).
Anyways, check out Experimental Gameplay, it's got some cool stuff, I suspect these guys will put out many good things in the years to come. Hopefully I can contribute to the effort in some minor way, we'll see...
And yes, I'm still working on several games, but I'm picky and have yet to release any of them. Patience, young grasshopper, patience...
Wednesday, February 28, 2007
Monday, December 4, 2006
Slime Hackeysack
Nothing new to report. My computer is in my car because I took it with me on vacation and have yet to set it up, so I'm writing right now from a freshly installed Kubuntu box - great system, if you want to wean yourself off the Microsoft teat I highly recommend giving it a try.
Since there's no activity on the RGB front for the moment (all my code's on my other computer), I'll direct you to check out a game I made a few months ago, Slime Hackeysack. Ironically, as I'm currently on a Linux computer, I can't play it because it requires Flash 8...ah, Macromedia, why do you hurt us by only releasing certain versions of the Flash player for Linux? Anyhow, the game is pretty simple, you basically just hit the ball and keep it in the air as long as you can. It gets heavier as time goes on, so it becomes difficult by the time you reach 50 or so. The people who got >500 all exploited a cheat in the game, I think - if you're really careful you can trap the ball on the left side of the screen and use extremely tiny movements to bump it no more than a few pixels at a time. This is one of those things I really should fix, but honestly, without a major change to the game dynamics it would be almost impossible to take away that possibility. Physics is physics, and sometimes physics lets you cheat. Maybe at least I should change the scoring system so that if you do cheat you get penalized. That's how it's done in real life, after all!
While you're there, check out the rest of the Slime games. They're cute, and simple; there's something of a cult following as well. I'll probably do a sequel to Slime Hackeysack eventually, maybe something like a Slime Breakout clone. Or slimes throwing shit at celebrities - that's always fun!
Since there's no activity on the RGB front for the moment (all my code's on my other computer), I'll direct you to check out a game I made a few months ago, Slime Hackeysack. Ironically, as I'm currently on a Linux computer, I can't play it because it requires Flash 8...ah, Macromedia, why do you hurt us by only releasing certain versions of the Flash player for Linux? Anyhow, the game is pretty simple, you basically just hit the ball and keep it in the air as long as you can. It gets heavier as time goes on, so it becomes difficult by the time you reach 50 or so. The people who got >500 all exploited a cheat in the game, I think - if you're really careful you can trap the ball on the left side of the screen and use extremely tiny movements to bump it no more than a few pixels at a time. This is one of those things I really should fix, but honestly, without a major change to the game dynamics it would be almost impossible to take away that possibility. Physics is physics, and sometimes physics lets you cheat. Maybe at least I should change the scoring system so that if you do cheat you get penalized. That's how it's done in real life, after all!
While you're there, check out the rest of the Slime games. They're cute, and simple; there's something of a cult following as well. I'll probably do a sequel to Slime Hackeysack eventually, maybe something like a Slime Breakout clone. Or slimes throwing shit at celebrities - that's always fun!
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!
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
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.
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.
Subscribe to:
Posts (Atom)