Bot Escape – Sarcasti Blog

Bot Escape Demo released

Hey Look A Thing!

You can download the demo release here.

About the Game

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)

‘a’ left

‘d’ right

‘w’ jump

‘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.

Known issues

Sometimes the robot catches on horizontal surfaces in the generated mazes. This is an artifact of box2D, jump to unstick the robot.

Platformer Update 9 – Bot Escape

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:

Menu screens
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.

Platformer Update 7

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.

Continuing Fun Times With Box2D

I’ve spent most of the week working on making destructible boxes for the platformer. The actual mechanics of this are fairly simple, and psedocode for the process is below.

if condition is met then

destroy box

The conditional statement can be checked during the regular update cycle (otherwise known as polling) or whenever a different condition is met (otherwise known as a listener).

For the destructible boxes the condition would be met if the impulse on the box would exceed a threshold value. I decided to use the listener method of checking the destruction condition; since, I already had a Box2D contact listener for the projectiles.

And now the fun starts so let’s add some equations. first impulse courtesy of Wikipedia.

$\mathbf {J} =\int _{t_{1}}^{t_{2}}\mathbf {F} \,dt=\Delta \mathbf {p} =m\mathbf {v_{2}} -m\mathbf {v_{1}}$

According to our good friends at Wikipedia impulse is the sum of the forces applied over a time period (t1 to t2) which can be expressed as a change in momentum and as mass times change in velocity. hyper physics

It is not surprising then that the initial implementation measured the change in velocity between when the Box2D contact listener called beginContact() and endContact() on the destructible box. (there are legitimate issues with this implementation I know about them. If you’re having trouble imagining them think of someone pushing a sled gradually up to speed and then the pusher stops abruptly.) This was done because velocity is relatively easy to visualize and calculate. for example if the box were to start falling and impact the ground the some time later. The impact velocity could be calculated using either the fall time or the distance. Assuming the velocity prior to impact >0 and immediately after impact is <=0. This should make it easy to tune the destruction velocity threshold depending on how many stories an object is expected to fall and remain intact.

After doing some mathematical manipulation and assuming initial velocity is zero. we get v² = 2ax. And we’re already to pick out some velocity thresholds. So let’s move into the real err platformer world; where I took the liberty of having destructible box impact velocities logged for the record as well as start heights.

Experiment	acceleration	distance	expected velocity	actual velocity
Experiment 1	12 m/s/s	7.4 m	9.4 m/s	2.4 m/s
Experiment 2	12 m/s/s	7.3 m	9.4 m/s	1.99 m/s
Experiment 3	12 m/s/s	20.5 m	15.7 m/s	3.4 m/s

Something weird is definitely going on here. I’m currently assuming this is an artifact of how I was getting the velocity from Box2D. But I didn’t really dig into it too far since I realized there were other problems with this method, and switched to getting a ‘PostSolve’ impulse reading from Box2D which is closer but still different from the values I’m calculating. I suspect that I’m getting readings at the wrong time or that Box2D is taking additional things into consideration that were left out of the simple motion equations. (e.g. friction).

My conclusion for the week is, since a 10 cm difference in height resulted in a massive shift in impact velocity. This is annoying because it means that objects will require manual tuning of impact forces.

Platformer Update 5

This week I created a bug/feature list to better keep track of issues and what I wanted to do. And the list says that this week missile rate of fire was limited, explosion rendering was fixed, the player’s physics body was updated, jumping was converted jumpjets rather than legs, the player can now be controlled using an x-box controller, and work was started on a HUD. That sounds like progress to me! w00t!

Platformer Update 4

This week’s accomplishments are mostly of the bug crushing variety. I reduced the likelihood that the ‘no more jumping for you error’ occurs. I’m not convinced it’s completely resolved. What exactly is this error you ask, well let’s start with a screen shot (finally) of physics body debug render. The player is represented by the small square on top of the circle on the bottom about 1/3 of the way in from the left side.

Since jumping is conditional on having something to jump off of at present, the circle fixture checks to see if it has contact points near it’s bottom. if yes then jumping is allowed if not no jumping for you. At various times during testing the player stopped responding to jump commands while appearing to be grounded visibly and with in a few thousandths when the numbers were reported. The cause of this phenomenon is it seems that when Box2D contacts are reported to a libgdx box2d contact listener only the most recent contact point is retained. So if the player is contacted from the side, by let’s say a box propelled by an explosion, the circle would record a side contact and decide it was hovering making jumping impossible. The solution I used was to shrink the size of the circle ever so slightly, so that the box now projects out past the sides of the circle slightly. This has eliminated current instances of this issue, but I’m not convinced all cases have been eliminated.

In other news Rho_Bot stopped by long enough to find a problem with the explosion system. Basically too many explosions (to put a number to “too many” somewhere 3-4 range) in rapid succession caused the program to hang while the physics calculations were completed. This was solved by limiting rocket ROF which was planned anyway.

Platformer Update 3

I’m beginning to remember why I didn’t want to do a status update post every week when we started this website.

It’s that what gets accomplished in one week tends to be easily summarized in a few words. For example this week I got projectiles working completely and explosions working partially (unless being able to walk on compressed air waves is a feature in which case explosions are done), and while someone who does game development would think that’s a reasonably productive week when combined with bug crushing. Those of you who are not developers are likely thinking, ‘that doesn’t sound like much. Why didn’t he do more? And where are the screenshots.’

Well the screenshots are coming … eventually. I could post some box2D debug renders, but that’s just a bunch of rectangles outlined with different colors. Ahh the days when someone around here did artwork.

Speaking of Box2D I’ve got more things to say about it. Some good some bad.

The Good

I used Box2D to implement the explosion. I think it is fantastic and reasonably straight forward now that I’ve done it once.

The Bad

Things get stuck at the seams of butted objects; not always but often enough to be annoying. This is a known issue and is supposedly being worked on. Currently suggested is don’t place objects contiguously. This means that loading a world tile by tile is a no go.

On first implementations of things I frequently pass bad data or make inappropriate calls to the Box2D world. This is a normal part of the development process however since I’m developing on java and Box2D runs in native libraries I get lovely unhelpful error messages like.

Process finished with exit code 255 (Box2D, java, libgdx)

Which I got when I tried to add a new object while the world was stepping.

And

EXCEPTION_ACCESS_VIOLATION (0xc0000005), AL lib: (EE) alc_cleanup: 1 device not closed – (Box2D, java, libgdx)

[Update] which was caused by attempting to address(dispose of) a body that had been disposed of.

I also had an equally unhelpful error when I disposed of a shape before instantiating a fixture based on that shape. I’m too lazy to reproduce this error so no console capture for that one.

Since these crashes happen in native code that means that lost objects aren’t cleaned by the java garbage collector, and it’s entirely possible they sit around causing a memory leak. yay. Oh wait that other thing, booo.

Platformer Update 2

Last week I mentioned screenshots for the platformer, and everyone here to see those will be disappointed, because instead of spending time adding content and updating graphics I decided to reorganize how level data is organized. Why exactly did I do this?

Because I could.

Also levels were defined in a combination of *.xml and *.json and I wanted to standardize it a bit. Now all level data is stored in a single *.json file. I also wanted to move level loading instructions into their own class. Previously level’s loaded themselves; however, the level class was getting long and moving the loading functionality seemed to be a logical way to split up the class.

So not a very exciting week when viewed from the easily demonstrated progress dimension, but streamlining level files and improving class compartmentalization should make things smoother going forward.