Ok, Bit of a Setback, Here…

I had to reinstall both of my operating systems today. Windows 7 and Android.

Android was crashing on me and being useless when it wasn’t crashing. So I went from AOSP-based ICS back down to MIUI.us Gingerbread. I’m really not happy with it, and I’m probably going to move over to another ROM. I talk about it more in-depth on my personal blog.

Windows 7 was pretty much doing the same thing. Slow, wouldn’t copy more than around 50MB before the copy hung Explorer. 16 icons hidden in the system tray (about 10 too many, honestly). I just couldn’t use it anymore. Had to reinstall.

So… because I have to reinstall EVERYTHING, progress has now been set back a few days.

CardGrid Retry 2012

Yeah, yeah. I know. Why can’t I just get it right in the first place?

For one, do I REALLY know what I’m doing? Of course not. I’m stumbling in the dark here, with both C# and Python. (More Python than C#, but that’s the less important one at this point. Python will be more important in the future, when I get the C#-based framework working.)
Second, I AM working alone. Doesn’t exactly help much. When my code works, it’s good but dirty code. But being alone and an unskilled programmer and negative-skilled artist, things don’t work out well all that often.
Third, of course, is the depression. Discouraging. It’s not helped by the fact that no one can tell me whether or not the ideas I come up with are any good. (My brother is unreliable in this: he believes that his interests is the Alpha and Omega of what is good.)
Fourth is school. That can’t be helped. I need to be going to school, and I need to do my best to graduate. Even at the expense of all else. (Except that where it suffering would prevent my graduation, of course.)

Anyway, Retry 2012 is going to be in multiple steps. I haven’t worked it out yet, but a functional CardGrid is not going to be an early step.

First is getting the interface into the Retry 2012 version. Second and third, simultaneous and parallel, are 2.) more properly figuring out IronPython integration, and 3.) figuring out how to create unique cards referencing the same source data. Haven’t decided whether networking comes before or after getting the game working. Probably throughout.

Oh, and Retry 2012 is probably going to end up being a multi-year project. Starting second-half December 2011 and likely going well into 2013, should the most likely possibility of the end of the Mayan calendar (it’s a replaceable calendar, just replace it) be the right one. (Come on. You know the world won’t end. Not unless some psycho manages to get the world’s nuke supply launched and armed.)

If I deem myself to have time or I can’t resist, Retry 2012 starts tomorrow.

Been a bit; it’ll still be some time.

Sorry I haven’t been working on CardGrid. No, the project is not cancelled. After all, it’s been only a few weeks. I just have other stuff on my mind.

Most important: This. This is why I probably won’t be working on any personal project for a while, much less CardGrid. If you don’t want to click the link, the gist is that, due to a deep, deep depression, I just don’t have the motivation to do ANYTHING useful. I do what is necessary to stay alive, but I cannot get myself to function normally.

CardGrid, you’re turning into a general projects blog. Stop it.

Ok, this one is self-explanatory. I’ve been posting too much on this blog about ShooterPvP, about BulletML, about Bullet Demon Summoners. I haven’t done a CardGrid-related post in at least two weeks. That last part is fine if I don’t have progress. (Less fine is the fact that I don’t have progress.) But using CardGrid’s blog for non-CardGrid-related stuff isn’t. Thus, I have made a few changes.

First, I’ve changed my username on WordPress to Formedras. Now it actually reflects me, rather than just my project. Plus, if I end up getting someone to help make CardGrid, having a noticeable persona would probably help.

Second, I’ve created a second WordPress blog that I’ll be fixing up (the default is UGLY) and then start posting all my subsequent non-CardGrid stuff and reposting some CardGrid stuff on that. That will also allow me to post personal stuff, non-technical stuff.

So, in summary, this blog is now solely about CardGrid. As it should be.

XNABulletML Progress

I finally figured out how to get the serialization on BMLFile/BMLFileElement working, and I know that it would also work with Bandle BulletMLLib. In order to get it working, I had to go into the BMLFile.cs’ BMLFile and BMLFileElement classes, find every declaration of a BMLFile or BMLFileElement object, and give it [ContentSerializer(SharedResource=true)] as an attribute. This only works in XNA: the ContentSerializer attribute and its parameters are in the namespace Microsoft.Xna.Framework.Content; it’s probably only used by the Content Pipeline.

I’ve completed the BMLFile class and its directly-related items. Now I just need to code the BMLBullet class and its relatives to work with the BMLFile and BMLFileElement classes. (Actually… I also need to figure out how to parse the BulletML number value fields. But if I can’t, I can probably directly pull that from BulletMLLib. (I resist calling it that: it’s also the name for the C++ implementation of BulletML, and using the suffix of -Lib is more common with C++ than is with C#, which tends to suffix -.NET, or XNA, which suffixes -.XNA. I’m not sure how the namespaces work on those, though. Probably just omit the .NET/.XNA suffixes, unless both .NET and XNA versions exist.)

I’d like to mention something, though. I’ve added an optional file extension to XNABulletML, .bulletml. This allows the system to know that the file is a BulletML file before trying to do something stupid with it, like opening it directly in IE. It’s an approach I’m also using with CardGrid, where I use the .cardabs and .cardexp extensions for the corresponding XML file types. Basically, even though I’m using standard XML, I think it better to re-extension the files so that, if necessary, I can double-click in Explorer and open something to more properly handle the file. Plus, .bulletml is completely unused for any other purpose. (I’m betting unlike .bml.) Anyway, this provides absolutely zero drawbacks to XNABulletML, and only a minor inconvenience to the other BulletML implementations. XNABulletML can still import .xml BulletML files, and most BulletML implementations, I’d bet, don’t have to have a .xml file extension in order to import a BulletML file.

I just realized something: with the mutating BulletMLTree class replaced with a static BMLFile or BMLFileElement (probably BMLFileElement), and just having BMLBullet keep track of what step it’s on directly, I may actually get the speed increase I’m looking for, and possibly even enable multithreading. (Or I could get reduced performance or even break the damn thing. But isn’t it worth it just for the discovery from the experimentation? I know I haven’t pointed that out, but isn’t it?) Even if I can’t directly do multithreading (maybe the multithreading kills off the Parent, Prev, Next, and Children declarations, which I’m reducing to BaseFile, Parent and Children), I CAN set it up in such a way that Bullet Demon Summoners can use one thread per player.

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.

BulletMLLib/C# vs XNABulletML: Speed

Ok, it’s pretty close to fast enough. I’m getting 30000 bullets on my stress test BulletML file and getting a framerate of around 45, running the bullet updater on a separate thread. I want 30000 at 60, though. But I’m not getting it in any version of C# BulletML. Neither Bandle’s nor mine. Actually, although I’m pulling about 80% of my code from the Bandle version, I’m getting a framerate of only 40 when I’ve got as few as 30 bullets onscreen, and I’m only keeping 30 until around 1500 bullets. Obviously, my code ain’t cutting it. I’ve taken out seemingly unnecessary elements. Although, most of my proc time taken is from one routine, and I have no clue why it’s eating up so much proc. It’s taken virtually straight from the Bandle version. It’s BulletMLAction.Run(Bullet bullet). (The Bandle version’s parameter is “BulletMLBullet bullet”.)

EDIT: I pushed my version onto a second thread, and I start at around 60 FPS, but I can only get to 5000 bullets before I’m down to 30FPS. The Bandle version is already on the second thread. Splitting the workload on the Bandle version onto multiple threads (Such as 1 and 3, as far as the Xbox 360 goes) fails at about three seconds in. I’m going to try it on my version. And it fails, due to null values. I fixed one null value problem, and I get another. Looks like I’ve got work to do.

I know, by the way, that it’s BulletMLAction.Run because I downloaded EQATEC Profiler and used it on the programs in question. The BulletMLAction.Run routine is taking up more time than almost anything else. (Only thing taking remotely as long is the Pool’s IEnumerable stuff, and that’s going through a lot more calls for slightly less time.) I’m thinking it’s something to do with the “while (repeatNum < repeatNumMax)” loop. (I changed it to a for loop since repeatNum just gets incremented by 1 if the routine doesn’t return. Didn’t help.) The parser is exactly the same, save for any necessary changes to work my reduced Tree class and XNA’s Content.Load<T>, so it’s not that. (Speaking of Content.Load<T>, that “load XML using a custom importer” thing is what I’m using, and it is a better way than XNA’s built-in. Tutorial coming soon.) I know it’s somewhere in the Bullet and Tree files. First, I need to prove it, then I need to fix it. Then I can work on replacing the parser with an XmlDocument-based one. (XmlDocument in, Tree out.) The replaced parser, by the way, is necessary if the Content Processor is going to be what changes the XML to a Tree. Otherwise, it spits out Infinite Recursion errors. (Heck, it still may happen.)

Well… after I get all of that done, I’m going to be starting to work on yet another project. Right now, but probably not all the way through to release, it’s called “Bullet Demon Summoners.” If it’s not obvious, Bullet Demon Summoners is a Bullet Hell-oriented game. What I know isn’t obvious, though, is the source idea. It’s not “create a Bullet Hell game.” Bullet Hell is just the method. The source idea: “Rip off Twinkle Star Sprites.” Why? Because it hasn’t really been done much, if at all. So what’s Twinkle Star Sprites? I really wouldn’t be surprised if you didn’t know. It’s a pretty obscure SNK game for the Neo-Geo. It’s a Top-Down Shooter/Summoner Duel game, basically multiplayer Puyo Puyo (read either: “Robotnik’s Mean Bean Machine” or “Kirby’s Avalanche”) translated to a shooter. Here’s a video of a Kawaks-emulated full run. Enemies spawn, you shoot enemies, your kill combos translated to more enemies for the opponent and vice versa. It’s actually an interesting style of game. And that’s why I’m going to pull inspiration from it.

That’s pretty much all I have to say about both XNABulletML and Bullet Demon Summoners right now. XNABulletML I’ll talk about when I get progress, and Bullet Demon Summoners I just don’t have any other ideas.

Stall and Distractions

Obviously, CardGrid will have hit a stall. In fact, it hit it one week, 6.5 hours ago. That was the day my first class, Fundamentals of Design, started. I have not typed a character into CardGrid since then, and I think for a few days before as well. Even with school, I have no excuse: I only have three real classes (Fundamentals of Design, Drawing Fundamentals and Perspective, and Color Theory), and one zero-credit class (Portfolio Fundamentals). I have no job. I have nothing necessary to occupy more than half my waking hours.

So why no CardGrid work? Because I’ve been working on other stuff. No, not ShooterPvP. That’s something I should also be working on, but I haven’t. But I have other things on my mind. Currently, the thing occupying it is Kenta Cho‘s BulletML. That will help on the for-sale, closed-source version of ShooterPvP, which I’m calling Bullet VS right now. It will also allow me to make other danmaku (Bullet Hell) games, such as for Windows Phone. The problem, though, is that there is only one C# implementation of BulletML, and it’s not a very good one. For one, despite BulletML being intended for a world audience, the C# version by Bandle Games is documented almost purely in Japanese. (And not very well even with that considered.) Two, despite using XNA for its demo, I can’t tell if it’s for general C# or for XNA. (And even then there’s the problem of it using XNA 3.0.) (Ok, it’s meant for general C#. No excuse for using XNA and being somewhat confusing.) Three, it uses Lists for things that really demand Pools. (There’s a forgivable reason: Pools aren’t actually implemented in Microsoft C#.) Four, it pretends that there’s something called Extended BulletML, when there isn’t, unless they made it themselves. (The “Extended” part includes two variables, but probably not uses: BulletName, and Visible.)

So I’m obsessing over all this. I got BulletML working with XNA on all three 4.0 platforms. But the inherent limitations of the library mean I can’t get more than maybe 2000-3000 bullets onscreen. (Maybe 200-300 on WP7.) (I have a stress test BulletML file, StressCirclet, that makes many, many bullets. I’m getting about 9 FPS with only 600 bullets, but that may be the generation of the next 4800. Or many other things. But it still shows that the speed is insufficient.) That may have been all well and good on 640×480 screens, but assuming 8-pixel-area bullets, and a 720p screen, I want to be able to put nearly 30000 bullets on screen. (Maybe that’s a pipe dream, actually. But damn well over 3000 should be possible, especially with Xbox 360 and Core i5 hardware.) EDIT: My computer’s just going slow right now. Don’t know why. So maybe I’ll get 10000 bullets on Bandle’s code once it’s fixed.

Thus, I will rewrite Bandle Games’ BulletMLLib code (or at least I’ll start), intending much faster processing. I will try to document in the universal programmer’s language, English (I only consider it universal because that’s what all the major languages seem to be based on), what I’m doing, and maybe get a bit more speed in through multithreading. Not quite obviously, this will be in XNA. So I think I’ll call it XNABulletML. No periods; if I end up making that the namespace, I don’t want to deal with unnecessary periods. (I’ll probably just use the BulletML namespace, though.) It will be designed with extensibility in mind, like Bandle’s version. But it’s not just going to be called “ExpandedBulletML.” And it won’t be fixed extensibility. (That is, the extensions won’t be baked into the base version and let that be that. The extensions will be intended as a seperate Namespace, using inheritance.)

Please don’t think that I’m calling Bandle Games subpar in any way; they did what they thought was right, and with their limitations, it probably was. (Except for that Japanese-language internal documentation.)

Anyway, BulletMLLib was split into three files. (Definitely less than Kenta Cho’s Java implementation. Why’d he do it in Java, anyway? Isn’t he primarily a D programmer? EDIT: He prefers Java, apparently.) BulletMLBullet, BulletMLParser, and BulletMLTree. Bullet is, obviously, the file and classes for individual bullets. Tree, as far as I can tell, is where you can tell what bullet is made from or by which bullet. Parser is the custom XML parser. Basically, load an XML document and BulletMLParser will get the rules for bullets from that document. That is most likely to be changed the least.

I’ll make XNABulletML into two Visual Studio projects: BulletMLImporter (as both an importer and a processor), and BulletML… I don’t know what yet. BulletMLSystem, possibly? (Maybe just BulletML.) Parser goes into Importer, while Bullet and Tree go into the other one. They’ll be both written as Windows projects, because I’m thinking that that’s what the Importer needs since it’ll have to reference the other. (Obviously, Importer inherently needs to be Windows.)

You know what? I’ve been talking too long about something completely unrelated to CardGrid in this CardGrid blog, and I’m not even teaching something. If you want to know more (and why would you if I haven’t even done anything yet), my email account is a Gmail account. Username is same as here. (Telling you this way is anti-spider, while still telling you everything you need to know.)

Stall Upcoming; Also, ShooterPvP

Unfortunately, I won’t have as much time to work on CardGrid as I’d like. But there is a good reason for it: I’ll be going to the Art Institute of California – Orange County starting tomorrow.

I will have some time: I’m only going there three days out of the week: Monday, Thursday, and Friday. However, since all of my Monday and Thursday classes are Drawing classes, I will have to do quite a bit on the days I don’t have class. I’m not good at drawing, as evidenced by the fact that I haven’t created any art assets for CardGrid. This will hopefully make me passable. Then I could create sketches of my Characters and other cards, so that someone with more skill can make the real card art. (Or maybe I could make the card art myself.)

Also, I’ve been working for the last 24-36 hours on a new version of my first game, ShooterPvP. I’ve open-sourced the old version and plan to release the new one under the same license. (MIT, because I hate GPL at its core.) You can download the binaries and source at SourceForge.

Since I haven’t really mentioned ShooterPvP, I’ll talk about it now. It’s a Twin-Stick, (hopefully) Bullet Hell, Versus Shooter. At the very least, that’s the concept. It’s a game using the XNA 4 Framework, so you’ll have to download the runtime for it. Basically, you and your local friends (no network play at the moment) control small round ships, and try to destroy each other. You only get one life, but there is a health meter. You move with the Left Stick, shoot with the Right Stick by pressing it in the direction you want to shoot in, and boost with the Right Trigger. Shooting and boosting both cost energy, which is shown next to the health meter. Energy is automatically replenished over time if you aren’t shooting or boosting. Also, there are pickups that improve your ship. There are 7 pickups, each doing something different.

ShooterPvP is currently a very basic game, but I’m implementing some options into the new version to change things a bit, such as the level 3 bullet optionally causing explosions, being able to disable boost, etc. Also, I’m really cleaning up the code. I mean… it’s definitely going to be less dirty code than the old version. (Still some dirty code, I expect, but not nearly as much.)

Do note that you will need some Xbox 360 controllers attached to your PC to play. (You can emulate them, if you only have twin-stick gamepads, using X360CE, or if you have PS3 controllers, using MotionInJoy. But twin-stick pads are a must.)

Card Editor v2 Complete

I’ve completed the Card Editor for the current codebase of CardGrid.

It doesn’t edit 100% of the card. That is, it can edit everything user-viewable (except the images), but it doesn’t do the Python method code behind each of the Actions. That is intentional, though it may not be that way forever. It would be nice to have a fully-integrated card editor.

There are three dialog windows in the program. The first two edit the Subtypes and Armor Weights. The third is the Action editor; it edits all the XML-based Action code. So the program does everything from the card name to the description of what each Action does.

And it even writes a boilerplate Python source code file (which I just remembered I have to tweak because it has a dash in the middle of the class name; oh, well, it was only my second try) for the CardABS. (That is, the Card Absolute, or the Card Rules file – as compared to the CardEXP, or Card Expansion, or Card Art file.) (Ok, tweak done in about a minute 30.)

On a personal note, I really did not expect to get the Card Editor done tonight. Really. With the amount of complexity I’m putting into even the test programs (I’m pretty much putting full functionality into the server engine even though it’ll only be using about 40% of it), I expected the Card Editor to take another day or two. But it’s right there, right now, at 90% functionality. Only missing Python method code and image support.

This, of course, doesn’t make programming the server any easier. But at least I got something done.