So I've actually moved a significant portion of my Scala code to Haxe, though I've ran into a problem with the library I'm using (though it could be on my end...). The tool itself is meant to have two parts: the engine, which consists of a mark-up language of sorts and a parser to check the design calculations; and the UI, which (hopefully) will end up looking like a HUD or datapad ripped from 80's/90's mecha/cyberpunk anime (Gundam, Akira, Evangelion, etc.). I haven't even started the UI, though the Scala-version of the engine is around 20-25% of where I want it, mostly a proof-of-concept.

The idea is to make the design as simple as possible. Instead of writing out every detail of price/weight/damage/etc. for each item in the mech, you list the mech's equipment, structure, and load-out, and the tool analyzes your design and lists any errors or inconsistencies in the calculations. Using the engine directly would be similar to using a compiler for code. You give the engine a text file, and the engine returns the exact same file with added notes where appropriate. Eventually, the UI would work by updating an internal "file" in memory, feed the file to the engine, and use the errors and such to respond to the user with various cues, (such as simple color flashes, sound clips, or text hints) hopefully in a way that mimics the feel and images of those famous shows.

Also, I'll return to MGS eventually. I love Mechs, and I most certainly want to finish my game with them. I just tend to get too wound up in details and "the systems" of a game after working on them for too long, so I'm taking a break to refocus and gather my thoughts.

I've been adding interposition and hiding behaviors to the enemies. Interposition will probably be used with mechs with shield abilities, while hiding will be a thing with sniper type mechs. I can't really test the hiding behavior though, since I don't have buildings or cover yet. So I know what I'm working on next!

Still working on flocking behaviors and level generation, apparently these are much larger tasks than I initially thought. Oh well, I'll just keep on truckin'.

Finally fixed what was causing some weird behavior in my flocking algorithm. Still working on level-gen stuff. Also, pun intended.

Enemy mechs now shoot at and follow the player when close enough. Still working on level-gen stuff. Tired now. going to bed.

I added a flocking algorithm to the mechs for now. I'm hoping it will lead to some interesting movement from squads down the road, once shooting and dodging AI are added as well. I added it to the player too, since I want the mechs in your squad to also swarm around at random while fighting. It hasn't created any weird behavior yet, but I don't think it will be too difficult to fix even if it does.

If anyone has ideas on how to record gifs, or to get haxe to give me a simple web build, I'd be happy to post builds as I go along. But since I haven't figured out how to do any of that yet, here's an application build, if you dare! (also, sorry mac users, linux, mac, and ios builds are disabled since I'm on windows)

Edit: Forgot to mention, left mouse-click to add an enemy, right-click to add the player, arrow keys to move, 1234 for abilities (though only 3 & 4 do anything unless you run in a command prompt), and F1 to activate debug mode.

Added collisions, and a bunch of minor code-tweaks and fixes. Enemies would push you around as they moved to the player, but now they stop at a minimum distance, for... reasons (I felt like it mostly... <_<).

Also now that I have Git all set-up with Sublime Text, the number of commits I make per day have increased by something like 20 times. So yeah, all the commits.

And I made a thing for Alien Frog, because why not?

Okay, so I've finally settled (for real this time... seriously) on using Haxe and Luxe as my weapons of choice. Hopefully that's a good decision since the guy running this streak is on the freakin' Luxe demo page! Anyway... I'm apparently also using Github for source control, which is fine. My project's at Mecha Gunbuster Squad now if anyone wants to follow along.

Unfortunately, actual game progress has regressed, since I'll need to re-implement everything in Haxe. That's not a problem though. What is a problem is the incorrect tutorials and the general lack of documentation. For instance, the tutorials want you to use Luxe.loadTexture('file_name'); to create an image, except that Luxe.loadTexture() doesn't exist. Luxe.resources.load_texture() does, but it returns a Promise, which means I'll either need to figure out how to use the Luxe resource manager, or how to use Promises (which aren't that hard to understand, but seem overly difficult to use). This is assuming, of course, either of those options actually do what I want in the first place, since nothing explains how anything works...

But on the positive side, I can use colored rectangles for now, so I can still get a very abstract (we'll say it's "stylized") game working for the time being.

Mostly went through Haxe tutorials on how to create custom GUIs. Useful, since HaxePunk doesn't have built-in UI classes. Eventually, the gui will find its way into MGS, but it may be awhile before things are working correctly again.

Because I'm once again getting tired of Java's insipid need for everything to be declared over and over (and over and over and ...). I've started looking for a different library/language/toolset to continue building MGS. Currently, I'm looking into a Haxe + HaxeFlixel or HaxePunk combo as they seem particularly designed around portability and ease of use, plus it seems like it shouldn't be too hard to port what I have using either library.

Yes, I know. It's rather weird to switch programming languages in the middle of building a game. I just tend to learn new things easier that way, and maybe one day I'll find the "one", that special language that has everything I could ever want (which so far, Scala is the closest, but it's still not quite there).

I finished the music system, and music now plays while playing the game. None of it's polished mind you, but that will come later. The only thing that worries me, is that music is currently a component. Meaning, for a music track to play, it needs to be attached to some other entity, like a mech, or bullet. This seems odd to me, but maybe I'm just too used to thinking in "objects" because of my job. I suppose I could just make a music entity with the music component attached, and have it switch out tracks as needed, or just attach a music component directly to the player.

Anyway, I haven't finished the sound system yet, as 1) I have no sound effects, and 2) again, I don't know if effects should have their own entities, or get attached to others. Or other option: have a sound component be a collection of given sound effects, which can then be activated by the attached entity as needed. Either way, I'll need some effects to populate the game, before I really get the system working.

Began adding the music and sound systems to MGS. They're implemented as separate systems, because one needs to play one thing all the time, whereas the other needs to play all the things one time. Since I'm building the game with an entity-component-system design, it's fairly easy to add new things quickly, but it's slightly harder to make sure each piece of the game only does the one thing it needs to. And does it right.

But at least with an ECS design, it's also easy to tear things out and replace them, so I'm not too worried about getting everything perfect at the moment. Maybe after I get the audio working, I'll add some level generation, or AI to the game. Hmm, decisions, decisions...

Fixed another rendering bug that popped up, game could tell where the collision area should be, but the texture wouldn't render.

The player can now shoot, collision effects work correctly, timers work now (so shots time-out once their lifetime is reached), texture layering works (for when the player runs/shoots behind a building), and probably a few other things I don't remember.

Levels still generate statically, which will need to change eventually, and nothing besides the player spawns. Plus there's no game controller of any kind. So there's plenty to do still.

Day 7:

Weapons proving to be more difficult to implement than previously expected... One can only hope tomorrow I will fare better. Image supplies dangerously low, have yet to find a new source of pixels, lack of a web-based run-time is a severe hindrance to the search.

Day 8:

This is in the future, so unsure of what it will hold. Not actually sure why I chose to write this part of the entry today...

Finally added collisions to the game! Now to get weapons working again. Still no images though. Hopefully, next time.

I had a bunch of other stuff to do today, so unfortunately all I did was clean up the debug mode and fix the animation bug. I'm hoping to get collisions and weapons working soon and possibly figure out how to post some pics or something.

So I have the level map displaying again, and the character shows up again, but there's a weird animation bug. On the plus side, I've managed to implement a debug renderer alongside the texture renderer, so I can have cool wire-frame lines everywhere!

Next is to fix the bug, and re-add projectile spawning so the weapons work again.

In the process of restructuring things, I've managed to regress the game to the point where there is only a blue screen. I am fervently hoping that bouncing back will be quick and painless. Though just one is fine too...

So I decided to restructure almost all the internals of the game, because it should help in the long run. Basically, I went from tossing everything into one giant pile of stuff to tossing everything into several smaller, slightly more organized piles of stuff. Because smaller piles are better right?