Tired of Lurking
by Griffin Milsap · 06/25/2008 (5:10 am) · 8 comments
Pulse Downloadable - Long Dead Project
Yeah, Its been a while.
Pulse is long dead. Heres a downloadable version. It doesn't work very well, but gives you a sence of what I was talking about so long ago.
Download it HERE
If your computer has a dual core AMD 64 processor, TGE 1.3 didn't like dual core, so you need to install the dual core fix in the game directory.
First thing, take a look at the pretty menu demo. Wait for the music to start to work up, and watch the level dance to it.
Next, after a minute of clicking around the menu, you'll realize the menu doesn't work, and the game crashes when you try to load a song. You have to hit escape on the main menu, click yes to get to the real menu. Click "Game Start!", and then "Choose Your Own Song". None of the other game modes work. The Mp3's I included in this distribution, I have no right to distribute. I'm gonna call this fair use, but if people have a problem, I'll get rid of the music files it comes with. Use your own Mp3s by putting them in the data/songs/user directory.
Gameplay is simple. Put your fingers of both hands on the s, e, f, j, i, and l buttons. hit the E button when a red square matches the red square on your moving reticle. Press the F button when a Green square matches the green square on your moving reticle, J is for Blue, and I is for Yellow. When the squares aren't on the right side of the track to match up with your reticle, hit the s button to rotate counter clockwise on the track, or the L button to rotate clockwise on the track to be able to hit more beats.
After seeing gameplay, you'll understand why I dropped it. It sounded fun, but in practice, was too complicated, gave me a headache, and wasn't as fun as originally intended. The game suffers from MANY bugs and memory leaks. In fact, when you're done playing a song, you'll have to exit the game and reload the game to play another song. After a long string of accurate button presses, the game speeds up (as it is supposed to), but the beats get out of sync. Oops.
It could have worked if I had followed the following guidelines
1. Fully implement and document all facets of a feature before moving on to the next one.
2. Make sure the code you write plays nicely with the engine archetecture.
3. Make sure to check comments of resources you use for bugfixes and optimizations.
4. Don't get ahead of yourself implementing graphics changes to make things shiny and pretty in a prototype.
5. Take your time and do it right. You'll thank yourself later.
If you look through my project directory, you'll find all script files included. Have fun poking fun at my terrible coding style. If I used one of your resources, thank you. I unfortunately lost my list of included resources.
I'm done with this project. I thought I'd put it out there as a warning to what rushed programming does. Sorry to those who wanted the FMOD/Beat Detection resource. I wanted to put it out, but was embarrassed at how terrible the coding was, how hacky the implementation was, and that it was mostly untested. It worked, but that is only one step in the battle.
What's Next?
I'm working on a head tracking rail shooter which uses Johnny Chung Lee's Wii head-tracking model (www.youtube.com/watch?v=Jd3-eiid-Uw). The game will be an arcade "House of the dead" type shooter which attempts to take itself seriously, but ends up being really campy in the end. The head tracking will be used for the player to change their view slightly like in Resident Evil: The Umbrella Chronicles (Great Game, BTW).
I've already put together a demo using TGE, two wiimotes, and my IR glasses. Too bad they aren't as awesome as Mr. Lee's.
I'll be springing the extra $25 for TGE 1.5.2 soon, so I'll be restarting my project adhering to my guidelines as outlined before. I hope to have a working prototype out before summer's over. I'll be porting my wiimote implimentation from TGE 1.4 to 1.5.2 as soon as I procure a license, and I think things should go smoothly. When I get a COMPLETE AND WORKING implementation of wiimotes in 1.5.2, I may post a resource.
One wiimote sits on top of the TV and looks at the IR dots on the glasses, used for headtracking. The other wiimote is used as a lightgun for the player to shoot with. My Prototype runs very well on my laptop, and was actually kind of fun. I had the Bots resource for zombies to shoot, modified the object selection resource for the player to shoot where he clicks, wrote custom code for following paths, and head tracking. All in all, things work quite well!
Currently, I'm using the WiiYourself! library, and a bluetooth stack to interface with the multiple wiimotes. I'd like the final product to be able to work with and without wiimotes, so that users without the know-how to connect wiimotes can still click zombies to death (erm...). Perhaps, if things go well (Pipe dream alert!!!) Wiiware?
Thats all for now,
-Griff
Edit - Fixed Markup
Edit2 - Fixed Link
Yeah, Its been a while.
Pulse is long dead. Heres a downloadable version. It doesn't work very well, but gives you a sence of what I was talking about so long ago.
Download it HERE
If your computer has a dual core AMD 64 processor, TGE 1.3 didn't like dual core, so you need to install the dual core fix in the game directory.
First thing, take a look at the pretty menu demo. Wait for the music to start to work up, and watch the level dance to it.
Next, after a minute of clicking around the menu, you'll realize the menu doesn't work, and the game crashes when you try to load a song. You have to hit escape on the main menu, click yes to get to the real menu. Click "Game Start!", and then "Choose Your Own Song". None of the other game modes work. The Mp3's I included in this distribution, I have no right to distribute. I'm gonna call this fair use, but if people have a problem, I'll get rid of the music files it comes with. Use your own Mp3s by putting them in the data/songs/user directory.
Gameplay is simple. Put your fingers of both hands on the s, e, f, j, i, and l buttons. hit the E button when a red square matches the red square on your moving reticle. Press the F button when a Green square matches the green square on your moving reticle, J is for Blue, and I is for Yellow. When the squares aren't on the right side of the track to match up with your reticle, hit the s button to rotate counter clockwise on the track, or the L button to rotate clockwise on the track to be able to hit more beats.
After seeing gameplay, you'll understand why I dropped it. It sounded fun, but in practice, was too complicated, gave me a headache, and wasn't as fun as originally intended. The game suffers from MANY bugs and memory leaks. In fact, when you're done playing a song, you'll have to exit the game and reload the game to play another song. After a long string of accurate button presses, the game speeds up (as it is supposed to), but the beats get out of sync. Oops.
It could have worked if I had followed the following guidelines
1. Fully implement and document all facets of a feature before moving on to the next one.
2. Make sure the code you write plays nicely with the engine archetecture.
3. Make sure to check comments of resources you use for bugfixes and optimizations.
4. Don't get ahead of yourself implementing graphics changes to make things shiny and pretty in a prototype.
5. Take your time and do it right. You'll thank yourself later.
If you look through my project directory, you'll find all script files included. Have fun poking fun at my terrible coding style. If I used one of your resources, thank you. I unfortunately lost my list of included resources.
I'm done with this project. I thought I'd put it out there as a warning to what rushed programming does. Sorry to those who wanted the FMOD/Beat Detection resource. I wanted to put it out, but was embarrassed at how terrible the coding was, how hacky the implementation was, and that it was mostly untested. It worked, but that is only one step in the battle.
What's Next?
I'm working on a head tracking rail shooter which uses Johnny Chung Lee's Wii head-tracking model (www.youtube.com/watch?v=Jd3-eiid-Uw). The game will be an arcade "House of the dead" type shooter which attempts to take itself seriously, but ends up being really campy in the end. The head tracking will be used for the player to change their view slightly like in Resident Evil: The Umbrella Chronicles (Great Game, BTW).
I've already put together a demo using TGE, two wiimotes, and my IR glasses. Too bad they aren't as awesome as Mr. Lee's.
I'll be springing the extra $25 for TGE 1.5.2 soon, so I'll be restarting my project adhering to my guidelines as outlined before. I hope to have a working prototype out before summer's over. I'll be porting my wiimote implimentation from TGE 1.4 to 1.5.2 as soon as I procure a license, and I think things should go smoothly. When I get a COMPLETE AND WORKING implementation of wiimotes in 1.5.2, I may post a resource.
One wiimote sits on top of the TV and looks at the IR dots on the glasses, used for headtracking. The other wiimote is used as a lightgun for the player to shoot with. My Prototype runs very well on my laptop, and was actually kind of fun. I had the Bots resource for zombies to shoot, modified the object selection resource for the player to shoot where he clicks, wrote custom code for following paths, and head tracking. All in all, things work quite well!
Currently, I'm using the WiiYourself! library, and a bluetooth stack to interface with the multiple wiimotes. I'd like the final product to be able to work with and without wiimotes, so that users without the know-how to connect wiimotes can still click zombies to death (erm...). Perhaps, if things go well (Pipe dream alert!!!) Wiiware?
Thats all for now,
-Griff
Edit - Fixed Markup
Edit2 - Fixed Link
About the author
#2
I'm using the WIDCOMM stack right now, but apparantly, WiiYourself! isn't picky about what stack you use. I wish there was an easier way to sync the remotes with this stack though. I can't put the device into discoverable mode from my application, and sync them at run time. The player would need to pre-sync the remotes using a crappy wizard. :(
I'm very interested to hear what you've been doing with the wiimote. The IR glasses used to have actual filament light bulbs in them, which are turned on when the batteries in the fold-down sides are pushed up to the contacts on the glasses body when worn. They're terribly uncomfortable, and really quite ugly. As soon as I get an opportunity to get a decent pair, they work though.
-Griff
06/25/2008 (1:48 pm)
@Michael - I'm using the WIDCOMM stack right now, but apparantly, WiiYourself! isn't picky about what stack you use. I wish there was an easier way to sync the remotes with this stack though. I can't put the device into discoverable mode from my application, and sync them at run time. The player would need to pre-sync the remotes using a crappy wizard. :(
I'm very interested to hear what you've been doing with the wiimote. The IR glasses used to have actual filament light bulbs in them, which are turned on when the batteries in the fold-down sides are pushed up to the contacts on the glasses body when worn. They're terribly uncomfortable, and really quite ugly. As soon as I get an opportunity to get a decent pair, they work though.
-Griff
#3
One of the applications I wrote acted as an emulator for mouse and keyboard, much like Glovepie.
While looking for low level API functions to perform the emulation, and researching the Wiimote functionality, I kept coming across Bluetooth code. There is definitely a way to perform run-time syncing. Worst case scenario is that you have to write a driver that gets installed with your game.
I almost made a pair of IR glasses, but I was more interested in the "finger tracking" stuff Lee wrote. If you really expand your Wii code to handle multiple IR devices, having the head and finger tracking would be a slick combination.
06/25/2008 (1:55 pm)
Before I was forced to work on other projects, I was researching a method to perform run-time syncing of the Wiimote (plus chuck). I too hate the GUI wizards for the sync process.One of the applications I wrote acted as an emulator for mouse and keyboard, much like Glovepie.
While looking for low level API functions to perform the emulation, and researching the Wiimote functionality, I kept coming across Bluetooth code. There is definitely a way to perform run-time syncing. Worst case scenario is that you have to write a driver that gets installed with your game.
I almost made a pair of IR glasses, but I was more interested in the "finger tracking" stuff Lee wrote. If you really expand your Wii code to handle multiple IR devices, having the head and finger tracking would be a slick combination.
#4
06/25/2008 (3:26 pm)
This got to be the most funny postmortem EVER!
#5
-Griff
06/25/2008 (3:43 pm)
I'd have to say its less of a postmortem, and more of a - "I wash my hands of this dire pit of a project." I realized bugs weren't going to get fixed, and the game idea was terrible. 3 years of prototyping later, I decided that the project wasn't going to get anywhere, and I had sunk too much time into developing it to just delete it. I thought I'd put it out there as a warning.-Griff
#6
06/25/2008 (6:35 pm)
That video with the VR is incredible, a game like that would be amazing. Are you just going to use the head tracking for viewing, or will it actually have an effect on the character. Such as a part of the game when you're taking cover behind a barrel, and you actually have to stand up to shoot over it and duck down again to take cover (think like Time Crisis, but without a foot pedal to keep track of that) or dodging missiles by twisting your body (and with it your head) to the side. I don't care how cheesy or campy some of the levels would be to be able to use that, it would just be amazing.
#7
Currently, the head tracking gives me an X/Y for the position of the player's head. I have it controlling pitch and yaw of the camera. I'll be playing around with what control feels the most natural and seems the most fun.
-Griff
06/25/2008 (9:54 pm)
Thats exactly what I was planning Morrock. I'm still working on how I want to go about it. I don't know if I want a direct one to one correspondence to the position of the camera, or if I just want the avatar to duck when the player moves his head below a certian Y value.Currently, the head tracking gives me an X/Y for the position of the player's head. I have it controlling pitch and yaw of the camera. I'll be playing around with what control feels the most natural and seems the most fun.
-Griff
#8
06/26/2008 (11:01 pm)
I just had an idea about this. If you used the motion tracking just to control the avatar's movement (either with a one to one correspondence, or with a threshold) instead of changing the camera perspective you could implement multiplayer with cool duck and dodge features. You would of course lose the changing camera perspective which makes it so cool in the first place however.
Employee Michael Perry
Sorry to hear about Pulse, it's still a sweet project. I'm very happy to find another Torque developer toiling over the Wiimote integration =)
WiiYourself! is my favorite library to use so far. Which Bluetooth stack are you using? Blue Soleil?
Johnny Lee's videos are frikkin' awesome. If you ever wanna talk Wiimote integration stuff, shoot me an e-mail. I have some cool things you might want to look at.
Great work, especially on your IR glasses =)