Description: Rogue Drop B is a different kind of puzzle game! Smash, bomb, and drop your way through to enemy weak points to kill them, then proceed through the levels! Enemies will make it difficult for you! They'll throw garbage, send out minions, switch the blocks, maybe even get in your way! Can you clear out the enemies and get to your granpa in time before he makes a terrible mistake? Find out in Rogue Drop B! About: Rogue Drop B is a Tetris/Puyo/DrMario-like that wants to change the way you think about those games. In RDB, you will be challenged with a puzzle field, an enemy, and falling blocks to solve the stage with. Enemies will have a weakness to a certain kind of block. Sometimes there will be other stipulations attached to the weakness. The enemies will try to stop you from getting to their weakness. They'll throw extra garbage in the field. They'll get in the way of your blocks. They'll do other things too. The goal is to beat all the enemies and get to your granpa at the end of the game! Development: Why Rogue Drop B? I wanted to produce a game "this year". So I started something "short". The idea is to basically have SOMETHING in an app store. So, I thought, think about what a "Really Good" version of this game would be, then program the most basic version. That's what Rogue Drop B is. Rogue Drop B is a simple idea of a much bigger game. This way, should the game find traction, I could update it to the larger version of the game, hopefully. I hope people like Rogue Drop B, and will follow along as I continue to make it better!
Month 9 Progress Report Development History: As always, each game starts out as a prototype. I've tinkered with block games before, but haven't gotten anywhere with them. I figured with this one it'd be best to ignore the bugs and move forward. Here's what early versions of the game looked like, all the way back from early spring of this year! There was originally no spikes, because I thought I could fix the collision bug. But of course, I wasn't able to fix it. In one version, I thought of having the blocks just smash into the sides, but that wouldn't make sense. Then I remembered that open game art had really great assets, so I plugged in some spikes and that seemed to work and feel right. Enemies were part of the initial design sketch, so those didn't come until later of course. I'm not a pixel artist, so I had to find or buy some assets. Looking over the stuff on open game art can take awhile. There's a lot of good stuff there. Whenever I make a game, sound and music go last. So there's none of that in the game yet. I waffled on the main character a bit, before deciding on something I liked. Of course, these screenshots are from the windows version of the game. The android version has a little more space on the right side so I'll need to decide what to do with that. This is what the game currently looks like: I keep trying to fix collision problems. This yielded no results and made some weird behaviors. I keep trying to give players what you ought to expect in one of these. Neatly lined up blocks. Yet with the current system, I can't do that. Hopefully I'll be able to fix that in a new iteration but the idea of this game is to ship something. Which, I better get back to working on it if I want to do that. Will report later when I have something new to show.
Now's as good a time as any for an update! One of the goals I've been trying to set for myself was trying to get touch control working for the android version of the game. I finally sat down and did it today. It was, quite the headache. First I tried this sequence, which, didn't work. Then I tried the other, which, didn't work, then I tried something else, and it, didn't work. What I tried were all possible valid methods for getting objects to talk to each other in haxeflixel. But for some reason, weren't working in this situation. The example I had allowed for only one object to talk to the controller. So I figured if one object could talk to the controller couldn't a group of objects? Which, is what the shapes are and how they work. Sadly, it wasn't that simple. The answer was in the example and in my own code. I just hadn't looked down far enough yet. When you add an object in haxeflixel, anywhere below that line, the code knows it's there. Because programming works line by line. The shapes are a group of objects, created at the same time. When you create a singular object, you attach the single object, like a player, to the control. Now how to do that with a group of objects? The exact same way. Except you have to do it lots of times. You need to attach the controller to each of the separate group objects as they are created. Which isn't too bad. Considering there's only four at once time. I got so giddy when I finally started playing my game on my phone. It's like developing a game boy game. Maybe I'll get to one of those one of these days. So, as you'll notice there's four buttons. I like the arrangement, but I'm not sure about it. It'll just take play testing. And I have to learn how to play, my own game, on my phone. There's space for a fifth button. Which is where the bombs go. I'm not sure if I'll switch the switch and bomb buttons, or keep them the same. I guess we'll see when I get there. Anyways, NOW I can get back to the real fun part: Adding exciting features! Until next update!
