2011/08/09 (Villainmad): A Not-Quite-So-New Beginning
First of all, we finally get to see Shintear's rendition of Villainmad himself! Thank you, Shintear, this is everything I could have hoped for! Except the shoes, but that's understood to be for another day.
Second of all, you know the drill by now. Here is build, here is source, XNA hasn't gone anywhere. The engine is now functionally at pretty much the same place it was when I started the Major Revision. A few remarks ...
- You can now do "widescreen" fullscreen-resolutions from config.exe; I have not fully tested these, partly because one of them is bigger than my monitor's resolution allows. I may end up having to change how the config stores them altogether, for backwards-compatibility if I reorder them. (The "windowed" resolutions are most likely going to stay where they are regardless.)
- Stage-levels and whatnot are compiled directly into Villainmad.exe, rather than being plaintext-compiled-at-runtime. Sorry, if anyone wanted to mess around without firing up Visual Studio.
- Basis and GameState ended up keeping their names. Also, I am not using Nuclex's Game State system, just my own. It was just easier, really.
- With a few ifs and buts, I fundamentally redid just about everything except the config. "Loading content" is a system that's used similarly by GameStates and Stages, instead of directly being a part of them, for instance. Menus and Stages inherit the "Command User" class, which (along with Game State) inherits the "Draw, Update and Take Input" class; Stages and GameStates (but not Menus) also inherit the "Content Load" interface, which requires that you have arrays of strings containing the filenames of the stuff to load. Shared data (stuff I want to be accessible and changeable within the GameEngine part of things but not the Game itself) is stored in an internal static class called DataStealer.
- I have entirely done away with the system of EntityRefs and Used/UnusedIndices and whatnot, as it was almost entirely superfluous given what you can do with the List class. The system now deals with the GameEntity list directly. A side effect is that you can no longer change a GameEntity's "type"; I decided that there really weren't enough situations where this would be an actual problem. You now reference the GameEntity directly.
- By the same token, each GameEntity type is now restricted to a single layer.
- Game-makers now have read-only access to the entire list of Game Entities and Queued Commands
- Added partial support for XACT, but I haven't really tested it yet.
- I was unable to implement the "menu uses a screenshot of the previous screen as its background" deal; the most feasible way of doing so isn't actually possible if I want it to be compatible-in-general (i.e. with my Crappy Lappy) instead of just compatible-with-the-latest-and-greatest.
- Pretty much everything else I mentioned in the Major Revision section last month (Except that I did put the entire engine into config.exe ...)
Some of the bugs I had were ... fun. And I wasn't able to see very many of them at the time, because I didn't have enough basic functionality to even start, until finally I was ready to implement the Stage class and augh nothing's working! The bugs included trying to use & to add to a bitflag-list instead of | (hint: & means "only things which are contained in both lists" instead of "all things which are in either list," and since they didn't have any in common, it emptied the list). Or the time I copied "check if the player is pressing up or down; if so, set the player's vertical movement; if not, set the vertical movement to 0" and pasted it so I could use the same setup for the horizontal movement ... and then forgot to change "set vertical movement to 0" to "set horizontal movement to 0."
My "favorite" bug, though, was when I had a List Of Indices Of Items To Be Removed From This Other List. The thing is, though, when you remove an element from a List, all subsequent indices change. When you want to remove 3, 5, and 9 from a list ... after you remove 3, the other two become 4 and 8, and 5 and 9 point to the old 6 and 10. Which made a mess. (My major code-malfunctions seem stem from not paying the precise amount of attention I should be. But I always figure things out EVENTUALLY!)
In other news, I'm thinking of migrating to another game-system. Apart From Anything Else, I've started to run into XNA's limitations for things like sounds; you can't really control them beyond "play, pause, stop" and "turn looping on/off" — you can't, say, specify what point in a sound-file you play at, or synchronize two music-tracks. (So no recreating Ten Desires, not that this was likely to come up in Villainmad, but for the long-term ...)
But there's also the lack of cross-platform compatibility, and I don't meen Microsoft's definition of "between Windows, Xbox 360, and Windows Phone." XNA's a bitch to get running on other systems, even by the usual standards of "put a Windows program on Mac/Linux." Then there's the fact that you just can't load fonts dynamically at runtime (or at least at load-time), which makes language-files a bit more ... touchy to deal with, so to speak.
In no particular order:
- Collision detection
- Finish dealing with fullscreen-resolutions
- Finish making the config-form.
- Text/language services
- Saving score
- Use serialization to save/load the above two? Hmm ...
- 3D backgrounds, although this is longterm on the "making multiple games" scale (as opposed to the "after I finish collision-detection" scale); Villainmad has always been going to be 2D, and games have been ruined before by unnecessarily doing 3D when 2D was perfectly fine.
So, yeah. We are, in fact, approaching "fully-functional game" territory.
Previous: 2011/07/13 (Villainmad): MWAHAHAHA I CAN DO ANYTHING NOW
Next: 2011/09/01 (Villainmad): The Collision-Detection Update
Back to Villainmad
Back to My Games
Back to Main Page