My week back in Java Post #15

This past week I spent 3 days working with the Parts & Portals game group.  Well...  really just Daniel and myself.  We had a fairly successful run of it.  We got the enemy units turning and jumping and the player shooting bullets and a little health powerup working.

The AndEngine has some interesting quirks and I didn't spend enough time to really get a good feel for it but the bullets took us a while to implement because of the way the engine handles dynamic object spawning.  The AndEngine requires dynamic object spawning be handled by a GenericPool class that the given subclass must extend.  This is because the small amount of phone RAM must be tightly controlled.  Java's regular garbage collection doesn't seem to cut it so it looks like the GenericPool class takes care of object loading from level to level.

If you don't want to use the GenericPool it seems like the only other option is to use the XML level editor to hard-code assets into the level.  This works out great for health and powerups but doesn't work for dynamic badguys and bullets.   It took us a few hours to figure all of this out but once we defined the two basic datatypes for the engine the rest of the work went pretty smooth.

Moving forward, once collision detection for bullets is in place, killing enemies should be a snap as the superclass already "knows how to die".  Which will bring the game to a point where you are being chased by enemies that can kill you and that you can kill (plus there's life!).

Overall we had a pretty good time getting over their engine hump and we will spend this next week getting me over my HTML5/CSS3 hump.

Thanks for reading,
-Clay

Combining Efforts Post #14

So I last decided to work on the off-line portion of the game:  UI, start/login screen, asset loading, etc...

As I started diving into a completely new version of the UI and map panning I ran into some really weird CSS problems with my z-index and mouse event handlers.  Somehow my event listeners aren't tied to the correct DOM element even though I'm working my way through a fairly good tutorial (that of course works just fine).

I'm not the only one hitting "critical mass" roadblocks or perhaps just project burnout?  One of the teams making an Android game is having engine usability issues and with my recent foray into game engines we both have skill sets the other team currently needs.  So our teams will spend the next week or so helping each other get our projects over this next little hump.  I think both of our groups are also at the point where we just need some new creative life breathed into us.

Oh.  It's the Parts & Portals game group (Daniel, Jacky and Jaron).

So the goal for my project for the week remains the same as it did for the past few weeks.  I'll be explaining in more detail where I'm at technically in the client thread.

Thanks for reading.

-Clay  

Decisions for moving forward. Post #13

After some careful evaluation we realized we weren't as far in the hole as we thought we were.  Yes the client still has a long way to come and we need it for play-testing.  But Zach has made pretty good progress on an ugly temp client in Elm that we will use to test vision, pathfinding and a few other "critical systems".

Once the Elm client is mocked up enough to show units and some basic terrain we can start testing.
Granted it won't be a visual feast but it will get the job done so we can keep moving forward with server logic.

Which means I will keep working on the 3D JS client.  I am going back to the Babylon JS engine to experiment with their object loader.  Now That I have some real JavaScript chops I am going to re-evaluate it's usability.  I'm pretty sure after using ThreeJS on it's own for the past two months that it was just my noob-ness causing my problems.

Side note:  I've heard some really good things about Visual Studio's JavaScript intellisense so I'll be checking that out this week as well.  It also has TypeScript support (which I'm only partially curious about but will give a look).

Currently I am working on the BabylonJS model loader and terrain generation examples, looking into how they will translate/compose with the ThreeJS implementation we already have.

Side note 2:  I have been informed that I once (maybe even more than once) promised videos of progress.  Sorry about being a liar but I won't be able to get to videos until after I get more done on the client.  I will put some videos up as soon as I have something worth showing.


So, goals for this week are:
   
     Clay:

     Get into the BabylonJS loader code and understand it's use properties.

     Get a simple scene loaded with a couple of units and a few buildings.
     (off-line, no server communication.  Well...  ideally it'd be spawning from the server)

     Zach:
 
     Getting Elm client to a critical testing point.

     Test vision on the Elm client.

   
Thanks for reading,
-Clay

Spring Quarter Refresher. Post #12

I broke it.

Not sure how.

But the client is most certainly, broken.

Just after getting things all piped up properly I broke the UI somehow when refactoring the button layout and somehow reduced the FPS to 2-8 or so.  Yup.

Put simply.  We might just be in too deep for a two man team with our time constraints.  The only way I can figure to lower the water level in the boat is to cut back on graphics as we aren't willing to sacrifice functionality or playability.  Additionally, it is fairly straight forward for us to add more dimensionality to the graphics because the overall logic will always remain 2.5D.

Zach and I will spend this next week tearing down all of our expectations and building a new super clean SAP model/design.  Granted, it feels like this will be a process of upheaval and chaos but it is really just the next step in creating a slick, maintainable end-product.

With our connection success we have proved that our framework does work.  The excitement of having a communicating framework has sparked debate about simplifying the client in order to speed up the iteration process.  We are actually both in agreement about the fact that simplification needs to be done (yet again), and are currently just debating which of the graphical components must make it into the SAP.

It seems we forgot to weight graphic workload as heavily as we should have.  I believe it was partly do to the artist in me not wanting to sacrifice all the pretty polygons.

Once we find the minimum balance between iconographic communication and speed of iteration we will be unstoppable.


Here's to a great quarter.

Thanks for reading,
Clay Francisco