Thursday, July 25, 2013

box2dweb, Refactored for Flexibility and Enterprisiness

I wanted to try my hand at making a physics-based HTML 5 game, so I thought I would start by refactoring the box2dweb demo (not working at the moment) into a set of loosely coupled compoenents as a springboard for a custom game engine architecture.  For various reasons, not all of which involve having a working game sooner, I'm gradually removing any dependency on box2dweb from the majority of the code.  Eventually, only adapters will interact with 3rd party software, except for requireJS.

What I have created so far is a refactored version of the demo (with a couple minor behavior changes that have to do with the first game I want to create with it) with a broken Maven build.  :)  The components so far are:
-main - entry point for loading modules.
-Input - takes input from the user and translates it into actions for other components to act on.
-renderingService - displays the state of the game to the user (i.e., does graphics), and also the inverse (translates x,y coordinates on the screen into x,y coordinates in the game world--more on why another day).  The implementation uses box2dweb's Debug view thingy, but the interface is implementation-agnostic.
-physicsService - does the physics.  The implementation uses box2dweb  but provides enough of an interface that other components should be able to use it without knowledge of box2dweb.
-EntityFactory - creates the entities--anything with location in space.  Entities are comprised of a physicsComponent that is a box2dweb entity, plus whatever extra data they need.  Later, they will probably have a graphicsComponent as well.  The box2dweb entity itself is exposed as-is, even though that means the app-at-large is dependent on box2dweb.
-game - runs the show.  Specifically, it does project setup, the game loop, and the master update routine.

I'm using requireJS to wire components together.  The Maven build is backed by the Javascript Maven Plugin.  I have had a lot of trouble getting this to work.  My current problem is that mvn install deletes require.js for some reason, making subsequent builds fail.

I hope to add a unit test or two later, then get serious about making a game with this.  It should be fun.

Tuesday, January 29, 2013

"In Practice" is just a theory too.

In the software development industry in particular, the phrase in practice is used to mean true, in contrast to in theory, which is a patronizing way of saying false, but well-intentioned.

The phrase in practice precedes a theory just as much as the prhase in theory.  In the best cases, it is a theory based on the experiences of many people, and maybe even empirical studies, and is likely true.  But in the worst cases, it preconceived notion from someone lacking real knowledge of the "practical" theory and the more "theoretical" theory.

Don't use in practice or in theory as spin words to assert your idea as right or belittle the opinions of others.  Share what you think and back up your position with facts and sound reasoning as much as possible.  What you say works in practice is a theory, too.

Ok, enough italics for one day.  :)