I was playing Borderlands all day the other day now that school is out of session and I discovered a neat glitch. The glitch allows players to skip rounds of enemies in the Mad Moxxi’s Underdome Riot DLC (a round-based tournament-style game mode). It got me thinking about how the inner workings of the game must operate; I figured out what checks their code must be doing simply by playing the game, and then the cogs started turning in my head. As a result some neat ideas for Moldering started popping in my head. One of these ideas was how to create a simplified system for “global objects.”

A global object in Moldering refers to any object which is independent of the map it is on. This means that any one of these objects designated a “global object” can move off the screen and into other maps. Not only that, but they won’t “reset” when a map is reloaded. So, for example, I can push a global box 7 maps over and it will stay there. Previously, whenever a map was reloaded it would re-instantiate each object stored in the map file corresponding to that map and as a result the map objects could not save their state through this (only a limited number of maps are in memory at any given time to save resources).

In order to designate an object as global, I also wrote the code and interfaces necessary to specify which objects are global and which are not in the Moldering Level Editor. Now, all that is left is to work out a few bugs with moving objects between maps of differing sizes.

-James

So, while designing levels in the level editor I was getting sick of scrolling through all the different tiles looking for the ones I wanted. So, I took matters into my own hands and created a class called Palette which extends Java’s JFrame. These little windows can be brought up allowing you to drag a collection of tiles/objects from the editor into them and use them from there.

The palettes can also be saved and there can be multiple on screen at any given time. It can be very useful to make different palettes for enemies, for different areas, or for anything and load them later.

Now, if I can find the time, I’m going to make a bunch of really useful palettes and save them all for when I want to do some serious level editing.

-James

I reworked the old lighting system and took out the translucent images we were using as light sources. Now, the game calculates the area of the map, subtracts from it where the light sources are, and draws just the outline of the shapes translucently with increasing stroke size. The result is that when the light sources meet there’s a nice mixing of the areas.

Here’s a nice article on strokes in Java that I used as a reference:

Java 2D Trickery: Light and Shadow

-James

We’re using Ogg because it’s royalty free and provides fine compression. Using J-Ogg, I’ve managed to get streams to play, but I ran into a problem. The game hangs when the song is finished (either that or it continually loops the last buffer)… so I’ve got to do some debugging before I can move on.

Anyway, Ogg streaming is great. We can have a large library of music without worrying about running out of memory. As each song is played only a small amount of memory is read in at a time directly from the disk, rather than loading multiple 1-3mb songs into ram or on the heap. Now we can have that huge soundtrack we always dreamed of!

-James

Solved: See this post.

So, now that I have drag, expressed as:

        k1=.09;
        k2=.01;
        drag=(k1*accAccumX)+
             (k2*(accAccumX*Math.abs(accAccumX)));
        accAccumX-=drag;
        grandVelX=accAccumX;

My objects will reach a maximum velocity and slow down accordingly. However, they don’t slow down appropriately when on the ground. What I need to devise is a friction when the player is on the ground. This way he doesn’t float along until drag is enough to stop him, but rather stops the player quickly when the controls are released. Like in real life, friction will stop you quickly instead of letting you drag on. Then I can change the value when the player is on ice, or sand, or just grass and have the appropriate effect.

I’ve been looking into it and I can’t find exactly what I am looking for.

Possible solutions:

1. increase the drag (or create a new one) when the player is on the ground, although this isn’t necessarily the best way.

2. Create a new variable ‘friction’ and do something like this:

      if (player is on ground)
          velocity = velocity * friction;

This doesn’t seem right either.

Any thoughts?

I’m reading Game Physics Engine Development by Ian Millington. It’s helping me figure out lots of collision and force related equations. However I still have a code problem this book isn’t helping to resolve. Let me break it down:

The game has a main cycle…

1. Update every object

2. Draw the result

3. Repeat

A problem occurs when an object applies force to another object and the second object appears to lag behind. What’s happening is that the lagging object was updated before the force applying object and as a result the lagging object doesn’t update until the next cycle. In this scenario the drawing function has been applied before it updates again and as a result it doesn’t reflect the new force.

I was thinking of several approaches:

1. Calculate any remaining force applications by adding a third aspect to the main game cycle at the end to make sure everything is up to date.

2. Create a “flag” in each object which tells an object whether to update or not and apply a second update while turning this flag off. I could have this flag automatically turned on again after every update.

3. My mind started to wonder about a contact resolver class and how I could implement something to mastermind all the physics equations.

EDIT:

I was able to fix this problem by keeping track of all the new forces and adding a third stage to the update process. During the original update stage all new forces are added to a list. After all the updating has been done, all the forces are taken care of. Thanks goes to h4tt3n for suggesting this was a good approach.

EDIT: This above is just an adhoc approach now that I’ve utilized and thought about it, it can be improved. Check back on this blog for an updated approach.

-James