University of Texas at Austin, Computer Science major, student.
About Furyhunter (twitter: @Furyhunter)
Ludum Dare 29
Ludum Dare 26
Ludum Dare 22
Ludum Dare 19
Progress is coming along on this strange tower climber. My adaptation of the theme is that of limited controls and drawing using only primitive shapes like squares. Not shown in this still picture is the effect in the background. Colors are tentative.
Like other tower climbers, you are not able to control your direction. You can only jump. The idea is to climb the tower by utilizing gimmicks along the path. I have a primitive level editor already made which I will use to produce levels in the last 4 hours of the event.
Warning: sappy emotional post below
The last Ludum Dare I was able to compete in was LD22 in 2011. Back then, and the year before, I was just getting my feet wet in game jams and learning how to rapidly develop well thought-out code and designs. I’ve since done a local 12-hour game jam and GGJ 2013.
This year’s LD26, however, is going to be a little bit different for me. And far more emotional.
On Sunday, my Java mentor and good friend Lance Colton (Tak) passed away in his home, with his fiance (and also my friend) Chrystal. Had he not been there in High School to bring me into the world of software development and open source, and to drive our Computer Science club, I would not be anywhere near where I am now. So, the game I make will be dedicated to him, in honor of him and what he’s done for my friends and I.
We had once planned to do The Jam together with a few of our friends when I first discovered Ludum Dare. That plan didn’t fall through, and it will never come to fruition with him involved. The least I can do is make something in his honor.
My tools will be either C++ with Vim, Cmake, and SDL as an OpenGL binding, or Java 7 with LibGDX, bfxr for sound effects, The Gimp for graphics, and either VGMM or Famitracker for music. I may also end up trying out Elisée’s amazing CraftStudio project instead. It’s all up in the air, depending on what I feel like using when the event begins.
See you, space cowboy.
They’ve been setting up SSL on the domain for the past few days, and it appears my subdomain broke, so my game can’t be downloaded at the moment. Sorry for the inconvenience, trying to get it working as soon as I can.
If you were trying to play my game in the past few days and were met with “Could not find main class alonegame.AloneGame”, please upgrade Java to version 7.
Ugh. I reached a total brick wall (hehe) and couldn’t think of anything to do with the game. I realized that I would have to make a lot more gimmicks in order to keep the dungeon interesting, and I simply don’t have the time to implement all of that. So, I’m releasing it as-is.
I did, however, learn a lot from the competition this time around. jMonkeyEngine is a bit impractical for 2D games with very basic entity behavior, but it can be done, and it is otherwise fairly robust. I feel as though if I had the time, I could very easily create a full, 3D game on the engine. I also learned how to do physical collision using ray-casting, and for the most part, the implementation in the game works perfectly (except for a little exploit that I wonder if many people will find… it was very fun to play with in testing).
If I hadn’t decided to build the game for the purpose of learning jME as opposed to taking an easy route and using Swing or Slick (like Notch is doing), I probably would have made it far more complex and long.
Oh well. It was fun, and I’ll try to compete in the April competition if AP studies don’t get in the way.
Here is the first build for testing. Simply double-click it on Windows, java -jar alonegame.jar on Linux, and whatever you OSX folk do, do what you do.
Stepping into the final phase of the game’s development! Mechanically, the game is complete, but now the entire dungeon needs to be built using the built-in level editor. I could have the game finished hours before the deadline!
However, it is sleep time now. I’ve been working on the game for 16 consecutive hours, with some pauses here and there. I’d say things are going a lot more smoothly than last time.
So far so good. I’m coding in new types of tiles and I’ve finally managed to get the light code working perfectly in all conditions. After I’m done implementing the various gimmicks, it’s time to start filling out the castle (and probably redo that character sprite, too cute lol).
Maybe I can program a cool distortion shader for the character sprite. Or use fog particles to indicate that he/she is ephemeral, like a ghost. And I’ve got plenty of time to make it all, after downing this Monster!
I have almost finished my level editor. It currently saves the world data to the models folder using jME’s BinaryExporter (wow, that saves a hell of a lot of time), and you use the mouse to place tiles, and the scroll wheel to cycle between tiles and objects. Right clicking removes the top-most tile (basically, the first one the picking ray hits).
I’m going to try using the lighting system to add some moody effects next, after I create some more graphics. It turns out, making nice tile graphics really isn’t that hard after all.
When I think about the progress that I’ve made in the game so far, I realize that my LD19 project took about half the entire event just to get the entity management working correctly. I’ve been working on a level editor and game mechanics for the past hour, and this time I have collisions working as I want them.
I bet I’ll be able to get more done, like cool sprites, music and sound effects, then I did last time.
but I have not! I have learned how to use ray casting to calculate the amount to “push” back on an object to ensure they don’t slide straight through it!
Unfortunately, my implementation doesn’t work at very low frame rates. Moving right along.
My plan right now is to use jME’s lighting system to add atmosphere to the game levels. The level will have a very dark ambient light added over the whole scene, and then stuff like torches will cast point lights.
No screenshots to share at this time; unfortunately, I spend the better half of this evening working out the collisions for player movement before doing anything else.
I have to use ray-tracing to physically simulate the collision, but there is some mathematical error in the way jMonkeyEngine calculates distance from the ray shot, which prevents certain directions from preventing motion correctly… you just get stuck to the wall. I’m not convinced this is a jME problem though. I think I have an idea of how to fix it, but I’m going to bed before I lose my sanity any more.