Friday, November 23, 2012

OMG Hax



The problem with user-created editor extensions is that they are not meant to be universal or universally supported, the tools dev has done this out of the kindness of their heart, and if it's not working how you expected, well, your options are to either hack in your desired functionality, find a way around it, or become one of those people who haunts the extension's github page petitioning your grievances.

Since there's a decent chance that my headaches are simply a result of not knowing enough about the tools, I'm loathe to waste other peoples' time and most likely will attempt the middle option, using the aspects of the tool that work for me and otherwise freeballing it. An example: this game features a pretty standard thing where the player character will pick up a "weapon", which will then stick to him while he moves around. Rather than create alternate weapon-holding verisons of the sprite (which would be problematic because the size and shape are different), I decided to spawn a new sprite, parented to a "socket" attached to the player. Pretty basic, and RagePixel has a nice concept of numbered layers, where you can force sprites to render in the order you want without mucking around in the z-axis. It worked great when just dragging the new sprite into scene view, but what was required was to create the "weapon" during runtime, when it gets picked up, which meant instantiating it from a prefab. Here's where things got weird.

When instantiating a RagePixel sprite in the same area as a pre-existing sprite, the engine stubbornly refused to accept RagePixel's layering functionality, placing the new object visually behind the one onscreen, regardless of my settings. It was hacking time and I had a few options:

  • Dig into the RagePixel core scripts and locate the layering code, then play around with it until it starts working. I admit with some shame that I did not seriously consider this option for very long. I mean, I'm sure it would be an educational experience, but no thanks.
  • Work some magic with Unity's own tags / layers system. This would involve assigning objects to layers, then using multiple cameras and culling masks so that each camera would show only a certain layer (scenery, characters, props), in whatever order required. I get a sense that I'll need to do something like this eventually, and I wandered gamely down this path for about half an hour before finding myself even more confused, at which point I had a slightly better idea:
  •  Bump the "socket" where the object gets instantiated out a few pixels on the z-axis, so it's effectively hovering in front of the player.
That did it, giving me the visual on the right side of the picture above. I'm somewhat concerned to have broken out of the 2D world and into the z-axis when maybe I didn't strictly need to, I hope that doesn't result in complications down the line, but at this point it gets me past that hump and allows me to move on to other stuff. For this feature, the next step is drawing item animations to match each of the player's movement animations, so as the player walks I can paint their hands etc in place on top of the weapon without having a third layer of sprites. I sincerely hope this is a good way to go, as my number one bottleneck right now is hand-drawing frame after frame of animated mediocre pixel art ... but no one can say this was not a bed I chose to make. Next game is going to be constructed entirely of royalty-free stock photographs.

The only other really scary thing here is that little voice in the back of my head that keeps whispering "overdraw ... overdraw" ... i.e. I'm drawing multiple layers of pixels to the screen on top of one another, which will eventually result in a performance hit, most likely when and where I can least afford it. There's a good chance that the simplicity of the project, combined with the environment I'm aiming it at (average computers using their web browsers) means that this will never really matter, but then again it might. 


I've been told to "beware of premature optimization", so that's the story I'm sticking to. I also noted that Unity apparently has an overdraw visualization mode, so hopefully when the time comes I can once again stand of the shoulders of really tall people when approaching the problem.

No comments:

Post a Comment