What do you in Bot Escape? Drive around a robot and look for a door. How do you do it? glad you asked.
Use a controller! One of the purposes of this project was to learn how to get controller input and that works.
Keyboard Controls (keyboard controls can be changed under options)
‘e’ shoot missile
Here’s some screen shots
Even More About The Game
Generally don’t expect too much. This project originated as a way to learn about box2D, controller input, Wang tiles, and maze generating algorithms. I think there’s some potential to be a decent game if some good levels are designed. I tried my hand at designing two levels and have come to the conclusion that level design is hard and I’m not currently in the mood to do it. So who knows when we’ll get real levels for Bot Escape. In the mean time try out the maze and let me know what you think of the controls.
Sometimes the robot catches on horizontal surfaces in the generated mazes. This is an artifact of box2D, jump to unstick the robot.
Well I’m back from vacation, but I’m apparently still running on vacation time. The good news is I did some coding over vacation, which means we finally have some screen shots. Woot!
I’ve been using the working title BotEscape for this project for a few months since one of the original thoughts for this project was that you’re a robot escaping from your alien overlords, a crumbling factory or some combination of the two. As you can tell from that detailed description, I haven’t developed a storyline yet, so the current “levels” are just piling all the pieces together to make sure the interactions are working correctly. I haven’t checked to see if this name overlaps with any existing properties so I’m just going to run with it for now. It might get changed later if it looks like it poses a conflict with existing works.
There are three main tasks that need to be completed before I put up a demo of sorts:
A health system (read: a way to leave you a twisted pile of scrap metal)
A couple of levels that have some thought in them and aren’t just piles of clutter.
So over the next few weeks I’ll be working on these and any thing else that comes up to get a demo ready.
It’s definitely been a slower week. Mostly I’ve been working on the animation for breakable crates. I tried a couple out and have settled on this one for the time being.
Not exactly sure what’s going on with the crenelations at the top of the box, but those were the shapes I got when I subdivided the original crate. Fun fact since it’s animated I can use lower resolution images and still not have it look terrible; so that little *.gif is pixel for pixel the final size.
Beyond the crate I made a number of other fixes to the working graphics for the player and the HUD.
Contrary to all appearances. Since starting my new job I do have a substantial amount of time work on games. I’ve just been doing other things.
Currently I’ve decided to let Malwrath stay on hiatus, and work on something new over the next couple of months. I have three reasons for doing this
I’m out of practice reading and writing code. And since it’s always easier to start at the beginning than remember what’s going on in the middle. new project!
I wanted to experiment with level loading which is something that will be necessary for Malwrath.
I wanted to experiment with Box2d since it popped up on the list of libgdx options. And the idea of using a complete physics engine sounded neat.
So I’ve set about making a platformer (what better way to try out a physics engine?) about a small robot who jumps over aliens who are on fire.
I’ve been working on this for a couple of weeks and what have I learned so far. Maybe Box2d is not the best back end for a platformer. To start with this guy at GDC points out that jumping in platformers rarely if ever follows a consistent physical model. There are also some other articles around the web discussing other issues with using physics engines modeled on the real world as back ends for platformers. Frequently sighted is how to implement platforms that move without having them fall. Box2d, fortunately, has a work around for this by having an object (body) type that doesn’t respond to external forces. However after implementing all this I have a new issue which is the player sprite/physics object doesn’t want to stay on or ride platforms that move horizontally. And the solutions I’ve read for that all seem kind of kludgey.
There is no name yet, and maybe we’ll have some screenshots next week.
It’s been a month of working on Malwrath’s Tower. and we’ve made a decent amount of progress if not as much as I’d like.
Somehow I got tasked with the exterior ground tiles. So the basic tiles are done, but they still need to be blended at the edges. And the more I look at the grass the more low frequency artifacts I see; so, we might have to revisit that one. We’ll see when we get some more decorations on top of it.
In terms of code I’ve got the monster and the character mostly set up. A basic AI that can move the monster around. A solid path finding algorithm. And if you whack the monster with your gray stick thing it dies and re-spawns immediately. Anyway enough of me babbling take a look at some screen shots with my awesome placeholder rectangles.
And that brings us to the schedule. Which is more or less on track although I did sop up a fair amount of buffer by reallocating it to extra blog posts I’ve done in April.
Since we dropped no hints about a new project last week, and we’re not serial developers you’ll be shocked, SHOCKED! to learn that we’re starting a new project. In slightly surprising news this will not be a space/scifi themed game. This time we’re working on a fantasy RPG called
Malwrath’s Tower is currently a hack and slash heavy and story light invade the evil wizard’s tower take his stuff and kill him style game, but with roughly nine months of development time in front of us we’ll see where it goes. We’re hoping the engine will be flexible enough that we can use it for a couple of future games too.
And now the moment everyone has been waiting for the schedule update. We’re currently looking at a Q1 2017 launch. Why is it going to take so long? 0) this project is big we’ve got engine + graphics + levels that need to be done. 1) we all have day jobs so we can’t put that many hours into this every day.
The android version of Stoned in Space has finally achieved escape velocity. This time it only took two more weeks than I would have liked which makes it much faster than Cosmic Bootlegger which I believe took over three months to bang into a releasable state for mobile devices. Anyway Stoned in Space is now available on Google Play
The premium version gives you access to the other 1/2 of the ship configuration options, and three free continues of each type every day.
Also, we made enough tweaks that I felt compelled to update the desktop version you can find the updated download on the games page.
Stay tuned for information on whatever our next project turns out to be.
So what’s the whole story line for this game anyway? I’m glad you asked…
Meaningless Flavor Text
While couch sitting in a basement with your friend, said friend bogarted all the Funyuns!
Since couch sitting is hungry work you have decided that you need to go get some more. Fortunately there’s a convenience store just a few 100,000 km away on the other side of that asteroid field. You think briefly of plotting a course around the asteroids when your stomach says, “Grrrrrrrr need Funyuns NOW!” Quickly, to the ship and straight through the asteroids we go!!
Unfortunately all of that basement sitting has left you with a bad case of “can’t fly straight”. So the odds are that you’ll just keep flying faster and faster in loops through the asteroids. But, hey, funyuns are worth dying for and you’re in a rush.
You’ll be flying endlessly through an asteroid field trying not to hit anything hard or run out of fuel.
Before each suicide run you’ll get to pick the configuration of your ship because you’re rich!
Each hull has a different size body, a different sized fuel tank and consumes fuel at a different rate.
Weapons Nuke A – shoots a cluster of asteroid destroying missiles.
Nuke B – shoots a different cluster of asteroid destroying missiles.
LASER – shoots a powerful asteroid vaporizing LASER straight ahead.
Wave – a gravimetric distortion pulses outward from the ship for two seconds causing nearby objects to disintegrate.
Shields Barrier – puts a force field in front of your ship.
Bubble – puts a force field around your ship.
Shrink – makes your ship smaller but provides no other benefits.
Extra Tank – attaches an extra fuel tank to the shield mounts.
Special Dooms Day – destroys all asteroids within view.
Invincibility – makes you immune to asteroids for some time.
Cluster Bomb – launches a cluster of anti-asteroid bombs forward.
Converter – passively increases the number of fuel asteroids encountered.
Things You May Encounter in Space
Asteroid – it’s a rock.
Fuel Asteroid – blow it up to release a fuel ball.
Fuel ball – fly over it to replenish fuel.
Hull Patch – can be used to continue after a collision. Expires after 1 day. Made from two part epoxy nanites.
Aux Fuel Pod – can be used to continue after running out of fuel. Made from an isotope with a short half-life… it’s useless after 1 day.
And since a monthly update wouldn’t be complete without a schedule update.
We’re currently going through testing on the mobile version so that should be released soon. And the people rejoice yaaay.
Rho_bot has been hard at work on the graphics and I think it’s safe to say that the artwork is done. While some final layout adjustments need to be made. Which means, of course, new and updated screenshots.
In other exciting news the sounds are pretty well wrapped up. All of this points to Stoned in Space going to beta testing sometime next week. We just have to do a few minor tweaks and an in game tutorial.
And that brings us to this month’s schedule update.
Squinting at the right side you’ll notice the dramatic 2-3 month pull-in of the completion date in the last couple of days. Well, after the third straight month of push outs this time for no easily explainable reason I did a quick estimate of the expected completion date by hand on an envelope and found it to be near the beginning of March. Much closer than the scheduler was predicting. After a quick perusal of the scheduler’s code a bug was found and crushed, and henceforth schedules will be ‘totally accurate’. Well they’ll at least be somewhat more predictive at least.
It’s a good news bad news month. Bad news is; We’re still not actually getting any closer to the completion date. This time due to really poor estimation on the schedule. Basically numerous tasks in the spec for the game were inappropriately rolled into one task and that task was allocated about 10% of the time it should have been. It’s possible that the Holidays didn’t help, but I don’t think that contributed to the bulk of the continued delay. We now looking a release some time in April.
For good news; rho_bot is back and has completed many of the graphics. With mostly screen backgrounds left I’m hoping those will be done by the end of January. We also have enough of the game together to start tweaking the difficulty, and we’re slowly moving away from the initial state of absurdly easy.
Also in an effort to prevent a further push out of the release at least initially some features will be dropped these will mostly be special asteroids or critters which hadn’t been well thought out in the first place, and the global leader board.