XNABulletML: Now Parsing From Scratch

Obviously, I don’t like the Bandle implementation of BulletML. It works, but there are a few problems.

The main problem actually isn’t the speed. It’s what I’ve been complaining about, but it’s 30000 bullets at 45 FPS on a clean thread on my computer. (I’m thinking it’ll only be 35-40 FPS on an Xbox 360, though. Maybe even just 30.) Super-danmaku games might need all 30000, but realistically only 15000-20000 would be necessary on a 720p screen. No, the real problems are XNA parsing and the target limit.

XNA isn’t perfect. Everyone knows that. But it works, and it works well for what it is: a game framework for a game-unpopular language. (Or at least it was unpopular. Got pretty popular, I think, after XNA Game Studio allowed us normal guys to make console games legally. But still not among the pros.) And it’s what I’m using.

Point is, I’d like to be able to use the Content Pipeline to be able to use BulletML’s .xml files like one would a .png file. I did discover on the internet how to put an XML file into a string or XmlDocument object as compared to processing it in the normal way. So I tried tossing BulletMLParser.cs into the Content Pipeline Extension Library. And guess what: it didn’t work. I don’t remember the exact error, but it boiled down to infinite recursion. And I have no clue how to fix it, since the Bandle parser and BulletMLTree.cs files are so damn obtuse. (Even worse, it’s all Japanese documentation.) The only reasonable solution is to code my own parser. (Well… that or just use it as is, but I don’t want to do that.) And in order to code my own parser, I have to code my own output holder. Which I’m now doing, but it’s not a Tree. Instead, it’s a pair of classes (in a single file), BMLFile and BMLFileElement. BMLFile objects contain BMLFileElement objects, which also contain BMLFileElement objects. And this layout (and actually understanding what’s going on) doesn’t tempt me to use Pool objects. They’re great for being faster than making tons of “new” objects, but they fry in potential infinite-recursion scenarios: the potential becomes the actual. Which I’ve just recently learned, by the way. So no self-replicating Pools anymore. And it also helps that BMLFile objects, unlike BulletMLTree objects, will only be generated by the Content Pipeline. (Or if someone ports my XNABulletML back to base C# – maybe even me – just through the BMLParser.cs file at loading areas.) This may or may not actually be faster at gametime (my term: where player I/O happens, as compared to merely runtime, where any I/O happens), but I think it’s better.

Also, there’s the target limit. BulletMLLib/C# sets a static class for the BulletMLManager. BulletMLManager gets basic information, such as rank, the random generator, and the player’s position. To a trained eye, this obviously presents a problem. (Even an untrained eye like mine will find it eventually.) If the class is static, and there’s only one set of methods (X and Y; only one method in my version, combined into a Vector2) that define the player location, then the entire program is limited to single-player. Which, by the way, is unacceptable for me. Especially after announcing Bullet Demon Summoners. (No, it’s not merely “one player per instance.” Since it’s static, there is only one instance. Thus, one player only.) So I have to make it so that there is a non-static version. If I could make heads or tails of Bandle’s source code, that’d be pretty easy. Just remove the “static” keyword from everything in the class, including the class declaration itself, then modify anything requiring that static BulletMLManager into requiring being passed a BulletMLManager. But I wouldn’t know how to do that without breaking everything. Thus, another reason for me to make my own from-scratch implementation. (Well… maybe I’ll use value parsing from BulletMLLib/C#, if I can’t figure that out on my own. But that parses way too much, instead of letting C#’s built-in libraries do the heavy lifting. And I’m using the Bandle enums.)

Now, I’ve already mentioned that I need to make my own parser for BMLFile, since it’s 100% incompatible with BulletMLTree. But it’s also incompatible with BulletMLBullet and BulletMLTask. (Both in the BulletMLBullet.cs file.) So I have to make my own versions. I don’t know how I’m going to do it; I was going to replicate BulletMLTask with BMLTask, but I just realized while typing this that that’s going to be a whole lot of new. And a whole lot of slow. So BMLTask is out, probably replaced with some way to tell how far into each BMLFileElement the bullet is in. (Element, Repeats, and Time.)

This is very much not going to be easy. I’m worried it’ll take forever without help, and I’m apparently not good at getting that. It really doesn’t help that I have no programmer friends and I’m pretty much isolated from the other VGP (Visual & Game Programming) students at Art Institute during class. (Thus giving me no chance to meet any of them, and really giving me a major disadvantage for the future. Damn, I really need to make that club to counteract that.)

Summary: BulletMLLib isn’t working for me for multiple reasons, and will be next to impossible for me to use for Bullet Demon Summoners. So I need to make my own implementation. To do it with the XNA Content Pipeline, I need to do it from scratch. Oh, and a mini-rant about not having help or friends.