Starting in on the process of making Level Two is a big wrenching moment, kind of like seeing my 2D game in perspective view. It becomes obvious how much is assumed, hardcoded, made of magic numbers. Wires must be pulled out. Questions as simple as "where does the player start" might have different numerical answers for each level. This is one of the most common questions on public game dev forums: "I have a bunch of information I need to put in the game, like a long list of magic spells with all their damage and cooldown numbers, how do I represent it?" In my case it's a fairly small list of things like the scene's loadable path, where the bus should pause to pick the player up, etc. but the principle is the same. The actual process I still don't really get, it's mostly cribbed from a few different tutorials, who have a few implementation bits in common but diverge otherwise.
I used an XML file and the System.Xml.Serialization namespace. One of the funny things about Unity is that as often as not when I'm leveraging its powers to do something I'm actually just leveraging the standard MSDN libraries, which hey, System.Xml has more things you can do with an XML file than I'll ever want or need, so why reinvent the wheel? Like I said, the tutorials I checked all have their own take. There's always an XmlSerializer and a FileStream, but sometimes there's an XmlTextReader (which I didn't end up needing), sometimes an XmlNodeList is employed (didn't use that either), but the end result is what matters, and what I got works. Also kind of cool that I have to use stream.Close() because I'm in one of the few corners of C# where memory isn't fully managed. It's like, retro vintage, man! The only annoying bit is that classes that are derived from UnityEngine.Object do not appear to be serializable, so if you need to pull something like a Vector3 you're stuck hacking in translation functions that will grab three float nodes and smoosh them together or something equally ugly.
I'm really grappling with the metadata syntax as well, and I'm getting a mental picture of them as sort of magnets that allow you to attach properties in your program to external data that may change outside the scope of the program in ways you don't want to worry about. Probably not exact, but a good enough image for now.
The sudden possibility of storing and using large amounts of easily tweaked data is of course leading me to all sorts of other ideas, but no, for now we will stick to the plan and the schedule. Last sprint wrapped, a few things got punted. Inevitable.
I am starting to understand enough coding to sometimes sense that I am making a poor decision, although not enough to understand what the preferable course might be. My options / death / audio menu is a flying carpet made out of GuiLayout.BeginArea and transform.position.y, where I'm doing a three-way switch in the Update() to decide which of three sets of (crudely laid out) text buttons to show. I've always had trouble with "layout languages" like CSS, or basically anytime I have to think in interconnected scaling squares with various interdependent attributes ... makes my head hurt. I've hacked it up enough to work, but I don't know, I might return to it.
Mostly though it's been sweeping up stuff like the transitions from one level phase to another - making sure we don't let the player move and shoot when the level end animation is playing, stopping some bugs where bullets got huge and lived forever, trying slightly to improve the art, various little tweaks.
It's going to be that way for a while, I'm looking down the list and it's a lot of menu this and the skeleton dies wrong that, and move the camera when you do the other thing. It's the long bleak desert of the real, Neo, it's game development.
No, once I get the structure set up to slip between levels I can plow through the art and design for the other neighborhoods and that will be a lot of fun. I just need to work a little faster...
No comments:
Post a Comment