Things have been incredibly slow as of late and there isn't very much to report at all. Work on the game project has been, essentially, zero for the past 10 days. In the meantime, I have been tinkering around with a few new things during the short time I have before classes start up once again. One of the "bigger" things was OpenGL support in OSX. I threw together a 3DS (3D Studio MAX) model loader. While it doesn't work correctly (some faces are drawn when they shouldn't), it was a neat experience in writing a straight OSX app that has OGL support.
Alternatively, on the Windows side of the world XNA was released. This is the developer toolkit for creating Windows/XBox360 games with ease. I have tinkered around with it just a little bit and it seems pretty decent. I'm interested in seeing where Microsoft is going to take XNA and what their offering is really going to be for doing commercial games for the 360. Currently, the cheap developer account you can get with them to allow you to play your own games on the 360 prevents you from going commercial. Consequently, it's also a royal pain (as in probably impossible) to allow someone who doesn't have the toolkit as well as the paid developer account to even play something someone else has created.
Neither of these efforts have been 100% serious. They were mostly just playing around with some new things. Hopefully I'll be able to get back into the groove and throw some more stuff together on the current game. I'm a bit unsure as to how far I'm going to let this run. I've been working on the project for an inordinate amount of time, yet it still doesn't ring in as fun for the wider majority of people. I have considered simply releasing it in the state it's in (albeit a bit more polished up, of course) and leaving things as they are. What this really means is that the graphics will not be overhauled before a release, and if an artist so chooses to want to upgrade them, then they will. Otherwise, the game will essentially be complete but with less visual bells, whistles, and other goodness that one would come to expect.
Archives - August 2006
2006.08.31
2006.08.21
I'm a bit late in playing through and uploading the latest level set by Damien, but it's up at last. Go grab Zep's Odyssey now! It's full of challenging and unique levels.
2006.08.16
The forums seem to be dead for the time being. I'm not sure what happened, but as usual I'm going to give it some time to figure itself out. It usually does within a day or so. I'm giving the problem the benefit of the doubt and assuming some kind of updates are going on, server end.
2006.08.07
Speedhack 2006 was held this past weekend, and I participated. It was a lot of fun, and the Rule-o-Matic picked out some really wacky rules:
It's amazing what one can write in such a short amount of time. The completed game that I submitted still has some bugs in it such as jumping being a little broken and being able to "wall hack" and eject yourself outside of the map boundaries. Other stuff, such as lack of sound, was simply due to the time constraint. There are lots of things missing, but that sort of thing is bound to happen with the product of a relatively short-timed competition.
Here is some eye-candy from development:
I titled the game Fruit of the Loomsoft. I'm uncertain at this point whether I will take this game concept further than what I put together for Speedhack. I think it makes for a pretty good time, and coupled with a larger world and a more generous amount of interactive objects it could potentially be a really great title.
In any case, enjoy the fun little world of talking fruit, and be sure to check out the rest of the 2006 Speedhack entries.
- General requirements
- Insanity!
- Technical Requirements
- Time
- Multiple Players
- Artistic Requirements
- Show No Humans
- Bananas!
- Bonus
- "Act of Act of Recursiveness"
It's amazing what one can write in such a short amount of time. The completed game that I submitted still has some bugs in it such as jumping being a little broken and being able to "wall hack" and eject yourself outside of the map boundaries. Other stuff, such as lack of sound, was simply due to the time constraint. There are lots of things missing, but that sort of thing is bound to happen with the product of a relatively short-timed competition.
Here is some eye-candy from development:
I titled the game Fruit of the Loomsoft. I'm uncertain at this point whether I will take this game concept further than what I put together for Speedhack. I think it makes for a pretty good time, and coupled with a larger world and a more generous amount of interactive objects it could potentially be a really great title.
In any case, enjoy the fun little world of talking fruit, and be sure to check out the rest of the 2006 Speedhack entries.
2006.08.02
The player's sprites have been completely updated to use the new managed version in place of the old unmanaged version. While it doesn't offer any visual difference, the code change was much needed. Everything looks a lot cleaner, now.
In addition to that, I've started coding some changes to the main enemy of the game. Currently he's quite static, only moving in a pseudo random pattern from the left to the right. I'll be modifying him to move to a much larger portion of the screen. This will allow for some nice breaks in repetition and also remove the necessity to constantly be double jumping in exactly the same way in order to damage him. I'm not sure if I will keep this setup, but I think it will work for the better rather than worse considering how things are now.
Another design idea that I've come to finalization on was the level progress "enforcer." Currently, there is nothing forcing level progression at all. There definitely needs to be, however, as the user can simply sit on level one and if they're patient enough get the highest score. This is against how the game should flow. In order to enforce level progression I initially thought of a countdown timer where the level must be completed within the time limit. While this is essentially what I have decided on using, it came about in an interesting way. Currently there are two ways to die during gameplay: either the player's health drops to zero, or the "earth's" health drops to zero.
The way things are set up now, it's very rare that the cause of death in the game is the Earth's health dropping to zero. It simply has an incredible amount of health. Instead of making a separate countdown timer that the player has to watch in conjunction to two health meters, the earth's health meter will simply deteriorate over time as well as take damage from seeds crashing into it.
I believe that this scheme will actually work quite well in forcing the player to progress through the levels, as well as face some difficult decisions. Once the Earth's health meter has started to drop dangerously low, what actions can they take? They could hope for the special combo which will heal the draining health meter. They could also do their best to simply complete the level. I like there to be multiple paths of remedy to events that happen during gameplay.
I hope that these two elements can help boost the fun-factor of the game. This is one of the things that I'm battling with constantly: how to make the game genuinely fun. Sometimes I'm a bit disheartened when I realize that I've been working for almost two full years on this project. It's not all bad thoughts, however, and this is something I'd like to discuss if only briefly.
During the course of working on this project so far, there has been a lot of progress in two realms: the game itself, and core classes which can be reused in other games. If, as unfortunate as it would be, the game--even after lots of retooling--caters to a small crowd, there will still be a great deal earned. Firstly, that crowd will have a game they like to play! Additionally, all of the core classes I've created concerning sprite animation, text display, etc can be reused for whatever project I plan to tackle next.
So, while it's taken a long time to get to this point, I'm not only working on the game itself, but also making robust reusable code chucks that will prove invaluable in the future.
In addition to that, I've started coding some changes to the main enemy of the game. Currently he's quite static, only moving in a pseudo random pattern from the left to the right. I'll be modifying him to move to a much larger portion of the screen. This will allow for some nice breaks in repetition and also remove the necessity to constantly be double jumping in exactly the same way in order to damage him. I'm not sure if I will keep this setup, but I think it will work for the better rather than worse considering how things are now.
Another design idea that I've come to finalization on was the level progress "enforcer." Currently, there is nothing forcing level progression at all. There definitely needs to be, however, as the user can simply sit on level one and if they're patient enough get the highest score. This is against how the game should flow. In order to enforce level progression I initially thought of a countdown timer where the level must be completed within the time limit. While this is essentially what I have decided on using, it came about in an interesting way. Currently there are two ways to die during gameplay: either the player's health drops to zero, or the "earth's" health drops to zero.
The way things are set up now, it's very rare that the cause of death in the game is the Earth's health dropping to zero. It simply has an incredible amount of health. Instead of making a separate countdown timer that the player has to watch in conjunction to two health meters, the earth's health meter will simply deteriorate over time as well as take damage from seeds crashing into it.
I believe that this scheme will actually work quite well in forcing the player to progress through the levels, as well as face some difficult decisions. Once the Earth's health meter has started to drop dangerously low, what actions can they take? They could hope for the special combo which will heal the draining health meter. They could also do their best to simply complete the level. I like there to be multiple paths of remedy to events that happen during gameplay.
I hope that these two elements can help boost the fun-factor of the game. This is one of the things that I'm battling with constantly: how to make the game genuinely fun. Sometimes I'm a bit disheartened when I realize that I've been working for almost two full years on this project. It's not all bad thoughts, however, and this is something I'd like to discuss if only briefly.
During the course of working on this project so far, there has been a lot of progress in two realms: the game itself, and core classes which can be reused in other games. If, as unfortunate as it would be, the game--even after lots of retooling--caters to a small crowd, there will still be a great deal earned. Firstly, that crowd will have a game they like to play! Additionally, all of the core classes I've created concerning sprite animation, text display, etc can be reused for whatever project I plan to tackle next.
So, while it's taken a long time to get to this point, I'm not only working on the game itself, but also making robust reusable code chucks that will prove invaluable in the future.
2006.08.01
A bunch of progress today in terms of updating the AI of the enemies. Each enemy now reacts, for the most part, more realistically. There are a few actions that enemy types may take which still need a bit of work, but for the most part the game has already been made a great deal more playable. I've compiled up a new version and shot it out to a few people for testing. Hopefully the consensus is that since the demo the game has really moved in a positive direction.
During this process of updating the enemy AI, I had to draw a few more sprites. First off, I completely forgot that I was missing the death animation for the flying enemies. This was a considerably easy animation to whip up. While not intricate, it does look pretty interesting. The enemy simply disintegrates from the bottom up! In addition to that sprite I also had to whip up an animation for one of the flying enemy's regular attacks.
Along with the newly created sprites, I've updated a handful of sprites to use the new managed version as opposed to the older unmanaged version. This is something that I will have to do for many more objects in the game--especially the player. Thankfully, however, using the managed version of the ls_sprite class is incredibly easy.
During this process of updating the enemy AI, I had to draw a few more sprites. First off, I completely forgot that I was missing the death animation for the flying enemies. This was a considerably easy animation to whip up. While not intricate, it does look pretty interesting. The enemy simply disintegrates from the bottom up! In addition to that sprite I also had to whip up an animation for one of the flying enemy's regular attacks.
Along with the newly created sprites, I've updated a handful of sprites to use the new managed version as opposed to the older unmanaged version. This is something that I will have to do for many more objects in the game--especially the player. Thankfully, however, using the managed version of the ls_sprite class is incredibly easy.