So, I’ve decided what I’m going to do for the Unity x LEGO® GameJam. I’m going to (try to) make an RPG, which I’ve tentatively decided to call “Monsters and Minifigs” (as is kind of given away by the post title here).
Mostly what I’ve been doing so far is creating models for the game, but I’ve been spending a lot of time on that. Time that I really should have been spending on other things. Like, uh, catching up on grading for my classes. I was afraid the number of complicated models I was using might slow down the game, but so far they don’t seem to—of course, the fact they’re mostly set to static helps. (And while they don’t slow down the game in the editor, I guess it remains to be seen how it’ll run as a WebGL game…)
According to the tutorial on building and adding new models, the LEGO Microgame (or rather I guess the LEGO Model Importer package) only fully supports a large but limited subset of the LEGO bricks available in Bricklink Studio—there’s a Microgame palette available to import into Studio to make sure you only use supported bricks. Now, when I hit upon the import feature myself when I was exploring the beta, I didn’t know about this, and I used bricks that weren’t in this palette, and with the exception of a few legacy bricks that I ended up having to replace (like part 702, the brick 4 x 4 corner), they seemed to import and work just fine. So I decided to chance it and not limit myself to the provided palette. I figure the probable worst case scenario is that unsupported bricks don’t have their connectivity and collision info fully set, but if they’re part of set models so I don’t have to connect anything new to them and if they’re either small enough or sufficiently surrounded by other bricks tha tit won’t be noticeable if the player phases through them, that shouldn’t matter. Hopefully this won’t come back to bite me later.
I did run into a few other import issues, though. One piece in particular imported in an odd position, elevated about one plate width above where they should be and rotated 135 degrees. It wasn’t due to its being unsupported, either, since this was a piece that was in the Microgame palette: part 32607, Plant Plate, Round 1 x 1 with 3 Leaves. There was a warning message on import, however, that gave some hints as to how to solve it:
“The following bricks might be placed incorrectly. Use alternative bricks, or add transformation information to ldraw.xml”
After some investigation, I eventually figured out what ldraw.xml was, where ldraw.xml was, and how to appropriately modify it, and I got the issue solved. For anyone else who might experience a similar issue, all I ultimately had to do was add the following line to the ldraw.xml file located in the project folder under Packages/LEGO Model Importer/Data:
<Transformation ldraw="32607.dat" lego="32607" type="to_lego" angle="2.35619449" ax="0" ay="-1" az="0" tx="0" ty="-0.32" tz="0" />Presumably I could use the same technique to resolve the similar issue I was having with part 2476 being offset in the models I made for the “lobby” for my first LEGO Microgame, but I haven’t bothered with that yet, since right now getting this GameJam game done is a much higher priority and I’m not using that piece for this game (at least, not yet).
I did have one other import issue, but it’s minor. One of the “unsupported” parts I used was a mushroom cap (well, technically I used two different mushroom caps), and importing the models including those pieces gave the following warning:
The following bricks contain decorations. Importing decorations is not supported. Add them manually after import.
And indeed, the spots or blotches that the mushroom caps sported in Studio didn’t show up in the imported models; the mushroom caps in the LEGO Microgame were a solid color. I haven’t really made any effort to figure out if it’s possible to add the decorations after import, and honestly I’m almost certainly not going to do so before the Microgame deadline; it would be nice for the mushroom caps to have those decorations, but my time is limited, and there are much higher-priority things I need to do.
And speaking of higher-priority things to take care of, I think the next thing I need to do is start the coding… because yes, this game will have enough deviation from the standard LEGO Microgame behavior that it’ll require some custom coding. In particular, the first thing and possibly the most important thing I want to code is for the player not to explode with a single hit, but to take damage and only explode when all their “hit points” are depleted. I’ve already created a player health bar—you can see it in the upper left of the image at the top of this post—but right now there’s no code behind it and it’s not functional; it’s there but it doesn’t do anything. So that’s the next thing I’m going to work on.
I’ve got less than two weeks to try to get this into a presentable state for the GameJam; we’ll see how much I get done…
