Lazer Bee

Strasteo

  • Posts: 322
Strasteo's Report #4

Doing alright, yeah. I'll be out of commission for most of the day tomorrow apart from the morning, but most of the graphics are finished, it's just implementation of them and touches. Will be back Saturday though.

-Logo
-Laser actors
-Proper background
-More block type actors
-Laser hit animation
-Elemental effects
Inferno
Tornado
Waterfall

-Font

Graphics to be revised:
-Lazer Bee moving animations
-Color indicator icons
-Proper HUD graphics

Luyren

  • *
  • Posts: 1704
Luyren's Report #5
Made a lot of sound effects, imported graphics, made the unlockable stages in puzzle mode (they even show high score), added the score and combo to the hud, added damage on collision to the blocks, fixed some bugs I hadn't noticed and improved the performance.

The thing that was killing most of the frame rate was unused code. Since I'm using my RPG Platformer kit, it has a lot of behaviors and extra options that Laser Bee does not need. Collision was also killing the performance. I had to disable collision for the blocks, so the focus of the game is no longer in assembling a lot of same color blocks together and creating a huge chain reaction, but rather evaluate the given scenario and decide what to destroy.

Arcade mode still lags a lot after a while, and even if I use a bomb to destroy all blocks, it stays at a very low fps.
Working.

Luyren

  • *
  • Posts: 1704
Luyren's Report #6
Today I mostly worked on fixing bugs and making the transition between scenes (title > puzzle select > puzzles). Also added a button to restart the level and another to go back (either to puzzle select or title screen). Added a bunch of sound effects, finished the title screen loop (very short) and reimported the Bee's final design. Created a set of tutorial levels to explain the game.

Since Strasteo will handle the puzzles, my main concern was trying to optimize arcade mode. I've got it to play at 10 fps when the screen is full of blocks. Well, before it was unplayable, so it's definitely an improvement. Hopefuly puzzle mode won't suffer the same fate.
Working.

Strasteo

  • Posts: 322
Strasteo's Report #6

Made a lot of graphics both yesterday late night and today. Don't quite feel like listing them now, but I'll show you guys the Title Screen for a 'teaser' of sorts.



I'm going to be working on puzzle mode and tweaking animation frame rates here and there. Add or revise things while Luyren works on some more music.

Chances are the game isn't going to be 'completed' tommorrow, but very close to it. We're going to be adding more things to it definitely.

Luyren

  • *
  • Posts: 1704
Luyren's Report #7 - Final
Play the Laser Bee Demo here!

It's been a very interesting week to say the least. I've learned a lot of stuff with this experience. One tip I can give you all is: remove unused code. It got me a big performance boost!

This little challenge has served it's purpose. We both recovered our motivation to work on game development, and that was the whole point. I think we also learned that we have to be very detailed when explaining ideas during a brainstorm. This was the first time we had almost completely different visions for the game, so it took some time to get the concept done.

The end result is only a demo. I'm still not satisfied with the music I made for this game, so none is included. Puzzle mode got only a mini-stage, and arcade mode is running a little slow. Still, if you can forgive the slowdown, arcade mode can be quite addictive!

Our plans for the future:
-Reduce the height. The game will probably have 5 or 6 blocks per column, and tweak the speed of the blocks as well.
-Wipe-out bomb when respawned. I'd love some feedback to know if this would be necessary or not. It's definitely a no go for puzzle mode, but for arcade mode I'm not 100% sure.
-Trap blocks: blocks whose only purpose is to harm the player. We need these to give some live to puzzle mode, and some more action to the game.
- Achievements, of course! I want to make a "frustration" achievement (loose a 100 hit or bigger chain reaction...), as well as some score, combo and puzzle mode related achievement.

It won't take us too long to finish though. It's a matter of adding the new stuff, creating the puzzle maps and we are done. Add to that play testing, and we'd take one more week, I believe.

Thank you very much to everyone who was following our progress, as well as to those who offered tips and advices! We hope you enjoy our demo for now, and look forward for the finished version!
Working.

Strasteo

  • Posts: 322
Luyren summed it up nicely. We're going to add more things, polish it up, and wrap it up by the end of this week. I definitely learned a lot graphically; tried some new things like the elemental effects. I think they turned out well. Especially for my first time trying water.

However, the main purpose was really to gain back some motivation and drive to make games. I guess you can relate it to a 'warm-up' for bigger projects, which I think we will try to do next.

Criticism and comments would be much obliged, and we hope you enjoy the demo!


NobodyX

  • *
  • Posts: 1228
Congrats on making it to the end!

The gameplay seems a bit too luck-based, there doesn't seem to much strategy about the order the blocks are destroyed in. Maybe it would be better if they fall down, like was mentioned before. I like the aesthetics of it, I'm digging the sounds.

Is there are reason you cannot switch colours right after you shoot?

Luyren

  • *
  • Posts: 1704
Thanks! We owe it to you for the initiative on your 4-day-game challenge, so thank you very much!

It is a bit luck based indeed. The thing is decide what are you going to destroy, based on the upcoming blocks. I'll try again to see if gravity can be enable without sacrificing performance. There was also a problem where the blocks weren't falling alligned with the grid, I have to check that as well. Can't promise anything though. D:

About switching right after a shot, the swap weapons behavior check for the same boolean for both bombs and lazers. If this boolean is true (It's in the middle of an attack), you cannot swap. The reason for this is that you were able to swap weapons while you were charging the bomb, effectively swapping its damage type. So with the right timing, you could turn a red bomb into a blue bomb, for example. The downside is that your blue beam would be lost, so I opted for this little delay to avoid problems.
Working.

NobodyX

  • *
  • Posts: 1228
Thanks! We owe it to you for the initiative on your 4-day-game challenge, so thank you very much!
Cool! Glad to help.

About blocks falling, wouldn't there be some way to use code to have it check whether there are blocks below or not? How about this:

As the blocks are created, each block stores the block above it as an attribute. When the block is destroyed, or falls, then it signals the block above to fall down.

That should work, right?

Luyren

  • *
  • Posts: 1704
I can try that. Though I'd have to enable collision between the blocks, and I've started becoming a little paranoid with the game's performance. But thanks for the idea!
Working.

NobodyX

  • *
  • Posts: 1228
Why would you have to enable collision between the blocks? Can't you just make them shift downwards one square once signaled that the block below is removed?

Luyren

  • *
  • Posts: 1704
The only way I can think of for a block to detect another is through collision.
Working.

Hectate

  • *
  • Posts: 4643
You could use a small region to move around and see if a block is located inside of it at the intended destination. That way you can detect actors without requiring collision shapes, I think...
:
:
Patience is a Virtue,
But Haste is my Life.
Proud member of the League of Idiotic Stencylers; doing things in Stencyl that probably shouldn't be done.

NobodyX

  • *
  • Posts: 1228
What I am suggesting is that when a block is removed, then the block above moves down exactly one square. Or if a block is signaled to go down a second square before it "falls" the height of the first, then it just adds the distance it has to fall before stopping itself. And I guess a removed block would have to link the block below and above together, so that the block below knows which block is above it for when it is removed. (does this make sense?) If I'm thinking correctly, there would be no detecting necessary at all.

The "falling" would be a behaviour that shifts the block from one position to another, not the scene's gravity. And there would be no "detecting" because it would only be blocks telling other blocks what to do.

NobodyX

  • *
  • Posts: 1228
My idea works:
http://www.stencyl.com/game/play/5487

Would you like me to upload it to Forge?