Developmental Zenith

Over the course of this project, it became more and more apparent that the Marte Engine wasn’t going to work for me for several reasons, not least of which was that the way it’s set up leaves no room for unit testing without building a mock environment. Also I saw some ugly inheritance issues looming on the horizon.

After having considered how best to resolve these problems (with a great deal of advice from my friend Alex), I decided to migrate to a component system. I did some research on some existing component frameworks (Artemis, for example), but I was concerned that I’d run into some of the same problems with other existing frameworks. The only way to be sure an engine or framework is going to work the way I need it to is to write it myself, so I have been.

Alex recommended I use PicoContainer to handle my component instantiation, which turned out to be brilliant and exactly the sort of tool I needed. I’ve also switched over to Scala, partly because a future project with which I will be involved will be in Scala, but primarily because it allows me to directly solve some problems that java would make me circumvent.

I’m not nearly at the same place I was when using Marte, however, I’m farther along on my engine in Scala than I was in java. Using PicoContainer Script, an extension for pico that enables container construction from XML or a variety of scripting formats, I’ve built a complete entity creation system, wherein I pass an XML file in one end specifying what sorts of components the entity needs, and get a fully populated (and functioning) Entity instance out the other side. I’m very pleased.

The next step is to figure out a way to parse an XML file and create a Reader of some sort with only a specific block. For example, I want to have all the entities that exist in a given level in the same XML file with all the tiles and so on.

<entity>
    <container>
        <component-imlementation class=”some.package.Class” />
        <component-implementation class=”some.other.Thing” />
    </container>
</entity>

The XMLContainerBuilder only cares about the <container> block. I’d like to extract each such block to squeeze through the builder without having to have a separate file for each one.

In this case, it’s very very nice that scala and java are interoperable. This would all be hellish otherwise. Instead, it’s quite fun!

makeagame:

Today a forum-friend of mine ( we linked up at a game programming forum) who happens to be someone working for a game company pointed out that my interest and my learning process was not matching each other and Since I am more interested in gameplay programming and AI for games, I should focus on gameplay programming. His Exact words were:

…

So, I suggest you to put your study of DX11 on hold and start making something using any of the game engines available to you, that will certainly help your portfolio rather than learning DX11.

…

Okay, so that’s the whole story, So I now have to re-think my learning strategy. I might put DX11 on hold for now although I’m sure the skills I have learned using DX so far will be helpful for me in making games using other engines as well.

In the meanwhile I am looking for a suitable game engine. Any Ideas would be helpful!!!

I found myself in a similar place when I first started on my journey to game development. I was armed with a copy of Killer Game Programming in Java and a general idea of what I wanted. I started out following KGPJ and trying to make a basic platformer, but that required writing a render/update loop, a physics engine and using Java2D. Yuck.

Thankfully, a friend recommended I check out Slick, and from there I encountered the Marte Engine. I can definitely appreciate not having to reinvent the wheel, and instead focus my attention on the actual game code.

I wish the original author the best of luck in choosing a game to make. Cheers!

Super Metroid, being among the ranks of many a “Top X Games of All Time” lists, is also one of the major influences my current project. Since a large portion of the gameplay will involve 2D platform action, I can’t imagine how anyone could fault me that, nor the ‘borrowing’ of several of SM’s mechanics. 

For instance, my entity damage handling is modeled after that of SM. When an entity takes damage, there is a small knockback and a period of invulnerability. During this period, the entity can clip through its enemies, much like a certain bounty huntress. The knockback and period of invulnerability weren’t all that difficult, especially since I could handle both in the collisionResponse() method of the Entity class (the latter with the help of a boolean called ‘isVulnerable’). 

The clipping was another matter entirely. For those of you unfamiliar with Marte, entities have a ‘type’ field, which is a hash table in which type strings are stored. These types are used in collision checks and responses. For example, a block may have the “solid” type, which would mean that, under most normal conditions, other things shouldn’t be able to pass through it. In fact, this behavior is baked into the PhysicsEntity (hereafter PE) class. If a PE is moving along and encounters a solid, their movement stops. Furthermore, PEs gain the “solid” type when constructed.

My initial plan was to remove the solid type from enemies, which would allow the player to clip through them. However, that would then mean that enemies could all clip through each other and stack up unless I were to override the movement mechanics in the PE class. Also, I would have to then deal with the fact that enemies were, though not marked as such, quite solid for the remainder of the game’s development. Messy messy messy.

Instead, I took a different tack. After looking through the PE class’s movement code, I realized I would need to override it anyway. So, caffeine on hand and some industrial music playing to set the mood, I set about it. 

In the stock code, the entity checks for collision with a solid on both the x and y axes in turn. If it encounters one in a given direction, it stops movement, preventing such things as falling through the ground for example. To fix the clipping thing, I overrode two methods, motionx and motiony. The relevant bit of the stock code looks like this (taken from motionx; The motiony method has nearly identical code, but for the y axis):

//if we don’t hit a solid in the direction we’re moving, move….

if (e.collide(SOLID, e.x + Math.signum(spdx), e.y - s ) == null) 

{ … move …

The parameters going into collide are (type, x coordinate, y coordinate). What I needed to do was make the function also check to see if the entity in question is invulnerable, and if so, ignore collision with enemies. To do that, I instead store any entity we might collide with then set a boolean based on whether the player is invulnerable AND the other is an enemy. If so, we can clip through them. It looks like this:

// store the entity that we would collide with

Entity other = e.collide(SOLID, e.x + Math.signum(spdx), e.y - s );

boolean clipThroughEnemy = false;

// if there is an entity…

if (other != null){

boolean otherIsEnemy = false;

//iterate through MY_ENEMY if any of the other’s types

// and see if it matches one of our enemy types.

for (String type : MY_ENEMY)

{

if(other.getType().contains(type)) otherIsEnemy = true;

}

// if we’re invulnerable and the other is an enemy, we can clip

clipThroughEnemy = (!isVulnerable && otherIsEnemy);

}

if (other == null || clipThroughEnemy)

{… move ….

I intend to make a base class for PEs specific to my game that all the rest, the player included, will extend. This class will include things such as the clipping code and knockback. You’ll notice that I passed MY_ENEMY into the type check. MY_ENEMY is a constant String[] that will be part of the aforementioned base class. For the Player class, it will most likely include “enemy” and “hazard” (spikes and the like), whereas the same field in an enemy class would contain “player” and “bolt,” the type of the projectiles which the player fires.

Because Tumblr makes code blocks nearly illegible, here’s a paste.

Since I’m not 100% sure about the legality of posting Marte Engine source (edited or no) without their license, you can find it here.

After much consternation and fiddling, I got enemy sight mechanics working. The idea was to have enemy aggro behavior triggered by spotting the player. I planned to accomplish this by reusing the bullet code I already had to make an invisible “sight bullet” that would periodically be shot toward the player’s position. This bullet would be destroyed when colliding with a solid object to alow players to hide behind walls and such. When the bullet stikes the player, it calls its owner’s playerSpotted method and reports the player’s position to the enemy. playerSpotted then sets a boolean to true indicating aggro and sets an alarm to track enemy interest. If the player hides for long enough, the enemy then sets the aggro boolean back to false signaling that it should return to default behavior. Next on the list is fixing knockback for real and for good, as well as making entities clip through other entities during the period of invulnerability following damage. This will most likely require overriding the entirety of the movement code in the PhysicsEntity class. Such is the way of things.

I had a great time this past week with my family. We went to Virginia Beach and made historical outings such places as Thomas Jefferson’s Monticello and Jamestown. We had freshly caught seafood and lots of sun and sand adventures. It was wonderful.

Unfortunately, it seems that I’m having trouble regaining the momentum I had before we left.  I’ve got a guy working on some concept art, got a bug pertaining to player damage knockback half fixed and some fresh ideas rattling around, but the code isn’t flowing from my fingers as freely as it did. Much of it has to do with my poor documentation and poor code organization habits. I think I’m going to buy myself a yardstick and whack my knuckles with it when I catch myself not documenting a new block, at least cursorily. 

I also have a procrastination problem. For example, I might sit down to bang out enemy sight mechanics or finish debugging the aforementioned knockback function, but instead write a blog entry. *sigh*

I suppose I should suck it up and dive back in. I need to get more acquainted with how Marte’s PhysicsEntity class behaves. Cheers.

I have a one-year-old daughter named Evie. Although she can stand assisted and even by herself for a short time, she still hasn’t mastered the fine art of controlled falling. You may know it as walking. She can move along while holding on to something sturdy. The baby experts call this ‘cruising.’ 

Having been programming at a hobby level intermittently from the time I was 12 (14 years ago), taking on an indie game project has been quite humbling.  I’ve been battling rust on the gears in the part of my brain where Java lives and concurrently looking for room to file away Slick and Marte Engine information I’ve been learning at full-tilt recently.  The battle is a glacially-paced thing, punctuated by vacation, VVVVVV, and Atom Zombie Smasher (games from the Humble Bundle).

Much like my daughter, I don’t feel comfortable yet in the nuances of Java and the libraries I’m using to fully strike out on my own and take those bold first steps. If you were to sift through my code, you’d find that much of it is at least loosely based on example or tutorial code given on either the Slick site, or the Marte one. That’s not terrible, though, as I’m still in the sketch phase. Much like a captain will take any port in a storm, I’m willing to settle for borrowed code until my mechanics begin to at least resemble what I intend for the final product.

Eventually, like every game developer aspirant, I hope to release a clean game that people will enjoy and possibly even pay for.  I have the advantage of an almost crystal clear vision of the finished game, so as long as I don’t get derailed by the programming, I believe my goal is most certainly attainable.

After much procrastination and other such tomfoolery, I finally decided to make a blog to chronicle my adventures in programming, especially as they pertain to my current project, an action puzzle platforming game.  Expect frustration, anger, joy, and exultation as I stumble through the process of making a independent video game while also juggling class work, house work, and taking care of my daughter.

In other words, please keep your tray tables up and your seat back in an upright position. Fasten your seat belts. We’re in for some turbulence.