I have the parser nearly working! It should be running correctly now except for one detail: currently, the identifiers (names) for the systems will halt parsing as a failure instead of storing them for later resolution. They should basically act like variables in a programming language, but I haven't implemented the storage for them yet. Once they are de-referencing correctly, stage 1 of writing the parser in Haxe will be complete. I will be fully caught up with what I have in Scala, and can begin adding the rest of the mech building rules to the engine.
I've been writing unit tests while I wait for a response from the parsing library creator about my issue. Currently, I have implemented around 65 properties for various mecha components, and there will need to be 2-3 tests for each. Eventually, I will need to add tests for roughly 10-15 mecha systems, the 7 servos which house all mecha systems, and a number of tests for the special cases like propulsion systems and transformations. All in all, a couple hundred tests to ensure everything is working at a basic level. Not very exciting, but definitely worthwhile when I need to change something, and a test can tell me immediately if I broke some core functionality.
Also, here's an example of what the mark-up language looks like so far (it's just a text file). It's based off the original Gundam. Equal signs are essentially double-slash comments, anything after them on a line is ignored by the parser.
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.
So I've been working on a tool for building mechs in a tabletop rpg called Mekton Zeta. I have an "alpha" version working in Java/Scala, but as I've taken a liking to Haxe and it's portability, I'm attempting to port my code before continuing forward. For everyone eagerly awaiting updates for Mecha Gunbuster Squad, it's on hold for bit. Though hopefully I can find someone to cover the art side of things, since I don't find it very motivating to stare at a bunch of place-holding squares. Anyway, I may elaborate on what the tool does and how it works later, but for now I'm going to bed.
So yeah, missed a post for no real reason, felt kinda "bleh" about it all day. I haven't made much progress on my game all week, and this is just icing on the cake. My interest in MGS has waned a lot since I started, and I'm trying to determine if I want to continue or move on to something else. Maybe I'll just take a break for awhile... :\
Well, I was going to get a lot done tonight, but then I found out my cousin was in town from out of state, so instead I mostly looked at code without changing anything and hung out with him. These really short posts make me feel like I'm sort of cheating at keeping a streak going, but I guess it keeps the game in mind, so I remember to keep working on it. Even if I don't get anything done...
Yet again, not much done today. I mostly restructured and reorganized code, so everything's a bit cleaner now. At this point I have about three different tasks in various states of completion, though luckily, none of them conflict or depend on each other too much. I'm hoping over the next three days to iron out steering behaviors, fix enemy targeting (which broke while fixing the behaviors), and finally make some progress on generating the city these mechs are supposed to wandering through.
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!
Split my flocking component into multiple behavior components. This should help in the future, when I need the AI to change from staying with the herd, to finding cover, to attacking full force. Other than that, not much has been done though, mostly because I've been playing a lot of Heroes of the Storm lately...
Mostly thinking and planning today. I want the levels to be procedural, so I'll probably use Theta* with a range limit for path-finding. Not really sure how the group-to-group sighting and aggro should work though. I'll continue thinking, but if anyone has any ideas, I'm open to suggestions. For now, I'll get enemy mechs shooting back at the player, as well as damage and death working. Sadly, my time got eaten by chores. Boo. :P
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.
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...
While I'm not completely happy with my first music track, at this point I probably need to work on the actual game again, since it hasn't been updated in awhile. So here's the current form of "Hit the Streets", we'll call it version 0.7 for now.