Preliminary indications point to me being surprisingly capable of goaling. In fact, it's scary how well things are progressing.
Saturday morning, I get busy. I fire up Genny, the computer I do my designing and programming on, the IDE, start my Pat Benetar CD's, and reflect on what I had been thinking about the night before. See, usually, when I program, I take care of the game itself first, then build the title screens and game over stuff around it. This can be problematic with the scripting engine, but the title screen isn't the selling point anyway. But I wanted something with some polish to it, figured it's easier to bake everything in at the beginning. So I started with a somewhat animated title screen.
The title screen is just the title, copyright, and "Press I for instructions, Press ENTER to start" bullshit. I chose a sky blue background and just made the title screen transparent where the letters weren't. Not bad, a little plain. So I put in some clouds going by in the background. Dresses it up a little. Next, the instruction screen. For Lightning Strike, Failboat, and The Sire, I just had the computer reload the game when you left the instruction screen. I wanted background music playing, and thought it would be jarring. Since I'm just changing the letters, I made it do that and revert when you were done. Clouds still going by, music still playing. I needed placeholder music, just to get the feel of the game. I ripped a couple of tracks from my Tales Of Phantasia soundtrack and used those.
Not too bad. I had wanted, when the game started, for it to look like the camera was lowering you from the sky where the credits were to the playfield. Since the background is static, I just had the clouds and title card scroll up. Once they exited the screen, they triggered the playfield pit to scroll up from the bottom. Originally, I was just going to have the water appear in the pit, but a desire to ztjuz the program hit me. When the game starts and it looks like the screen is scrolling down, a dive alarm sounds. After the pit rises into view, the water level actually fills it up as sound effects of water filling a sink sound. I set the clip to end just as the water reached the top of the pit. The effect is really nice.
Strictly speaking, that was the milestone I set for myself. I was anticipating a lot of prep work to get things ready. And originally, it was just going to be placeholders. Instead, I had the full blown title screen, instruction screen, and game start flow done.
Why stop there?
First thing I did was I decided to add a little animation to the water. Nothing fancy, just some wave-like shimmies. Took a while to get it to look right, but I did. I also colored the water with different bands to make it easier for the players to see when the level is dropping. Just trying to keep it fair.
Next, added the score display and the sun. The sun is going to be the round timer -- when it crosses from the left side of the screen to the right, the round is over. Had to tweak how long it took, and I'm still dialing that in.
I thought about calling it a night at that point. It was 9PM, and I was feeling the burn. But I couldn't help myself. I started working on the cloud generation. I got it working right -- the cloud would appear, and the water level would drop by one row. The question I was facing concerned the actual game mechanics. The way the game works is you spray water in the air to make the cloud too heavy to float away. Running out of water ends the game. So what do I do to make the computer realize that there is no water in the pit and no other clouds in the air, in case one of them is dropping down and will replentish the water?
I took a walk, and a solution hit me. I set up a cloud counter. Each time a cloud is generated, one is added to it. When a cloud drifts off the top of the screen, the computer checks the counter and the water level. If both of them read zero, it's game over. If there is even one more cloud anywhere on the screen, the argument evaluates to false and things continue. By now, it was pushing midnight, so I shut Genny down and went to bed.
Next morning, I start pacing. The engine doesn't use objects. An object in computer programming is a wholly functioning entity. You give it instructions how to behave, and it does it's thing. And let me tell you, objects are tits. The Sire game originally had a whole different design, but because I couldn't use object, I wound up overloading the engine and the game never worked right, prompting me to scrap the whole design. Now, I was looking at multiple clouds, each of which could work as an object (floating up, going down, etc.). Tying each one to its own variable set would mean I was limited to how many I could create.
Then, a possible solution hit me -- treat each cloud as a simplified object. Basically, each cloud, behaves a certain way (you can clone them all you want). If anything happens to produce a status change, a new cloud with different characteristics is created and the original gets deleted. It's a very crude workaround for objects, but I tried it out and it works like a dream. Anything I could want, controling movement, changing the water levels, etc., can all be done there.
In order to really test that this would work, I had to incorporate the player character. I reached into my sprite library and pulled up some Sailor Jupiter animations and created the waterspout effect. No problems putting her in and getting her to move, and launching the water was easy, too.
As I tested it, I realized something. I have a playable game. It's simplistic, sure, but it's playable. I was not expecting to be at the beta stage in less than a weekend.
I did a quick compile to test it on Kylie. I realized I had a problem with how I positioned things on the screen. The pit is so compact, that if the game runs on Kylie (1028 X 600 display), you only see the upper half of Sailor Jupiter, you can't even see the water level. I tried the Alt-left click trick to move the window up higher off the screen to show the rest of it. For some reason, the build of Ubuntu will not let you move windows off the top of the screen. Or at least, it won't on that machine. When I had Ubuntu on the Clodbook, I could do it no problem. I tried the compile on Pam. Can move the display off the screen no problem. The game doesn't hang at all on Pam, so I'm looking at three possible solutions:
1) Use Pam as the demo machine. The only problem with Pam, besides her size, is that her battery only lasts for 50 minutes. I would either need to take the bricks with me (each one gives Pam an extra three hours of battery time) or budget her use carefully.
2) Redesign the screen layout to move everything higher. Based on Sailor Jupiter's appearance, I would need, under the stock configuaration, to move the play field up about sixty pixels. If I move the menu and desktop bars to the sides of the display, you can see just about everything, so a redesign may not be necessary yet.
3) Get another computer to demo the game with.
"You're actually thinking of buying ANOTHER computer? Just to demo a game?" one of the coders asked me.
Well, to be fair, I was thinking about it long before I started this project.
So, as I write this, I'm considering my next move. During the week, I will get to work making the sprites for the character in the game to make it legal. I'm searching through my stock music libraries for music I can legally include in the game. I also need to figure out how to ramp up the game, adding more challenge without confusing the engine. But if this keeps up, I just might have a game ready for testing by next Sunday.
If this doesn't get picked up, it won't be because I didn't give it my all.