2011/07/13 (Villainmad): MWAHAHAHA I CAN DO ANYTHING NOW
Created: / Modified:
I have implemented ... MENUS! And from here I can do ANYTHING I WANT! AAAAAHAHAHAHAHA!
*cough* Uh, here's the source and here's the binaries. And here's XNA. I have renamed the BaseGame class to Basis (this will probably end up getting another rename to just "Game"), and GameController to GameState. I have just about everything necessary for a "basic game" except possibly collision-detection. I've also set it up so that you can detect keys which have just been pressed and just been removed on the input-call. I can see the end of the journey ... but there's a big scretch right in front of me:
These are things which will necessitate undoing and rewriting things I have already done. I'll be able to copy some stuff over; I'll have to scrap other stuff. This stuff is REALLY major. I won't be redoing things from the ground up, but definitely from the foundation up.
- General reorganization, so that different sections of classes will be in their own files, and I don't have to hurriedly paw through Stage.cs trying to find the specific method for queuing a command and then look for the definition for the apropos Property ...
- Structure - It will be divided between the "engine" (the underlying framework) and the "content" (sound, graphics, stages). The former will produce an EXE file for the configuration and a DLL containing the engine itself,1 and the latter will eventually take the form of an XNA project template, with one project for the EXE file and one project for the XNA-content like a usual XNA game.
- The "C# scripts" will be compiled into the EXE, rather than hanging out there as text files to be "compiled" at runtime.
- Common very useful class-references (i.e. the current stage, the current menu, the current GameState, etc) will be accessible via static properties on the Basis class, so that you can get at them from all over the place and I don't have to give each individual object an internal reference.
- Stages, Menus, etc. will be controlled and accessed from the outside. Your stages won't have a "load content" method and suchlike; instead, an external class will handle loading, the texture-lists, and so on.
- The "Stage" will inherit the "menu" class, due to all the functional similarities they have.
- When calling a stage, it will remove all menus "beneath" it by default.
- As an aside, I think the dialogue-screens will also be a type of Menu. This probably means that the background will be frozen in place and you won't be able to move your character around during dialogue-bits like you can in Touhou, sorry.
- Reduced access to the SpriteBatch; you'll use my custom drawing-methods instead.
- There will be no further use of override-methods from base classes that will require you to include "base.ThisMethod()" in the code for them to work properly. If it somehow matters whether you do something before or after the base-method is called (i.e. in the pause menu, the Draw() method draws a black rectangle over the stage before calling the base), there will be "before" and "after" methods (i.e. DrawBackground() and DrawForeground()).
- Most of the content-files will go into the XNA Content project and compiled into .xnb files.
Not the font-files, those will mostly stay outside for the purposes of the language system.Edit: Never mind, you really can't load fonts dynamically, I'll have to be clever with the preprocessing at compile-time.
- This will enable me to use XNA's SoundBank system for music, and cut the size of the music files into one-tenth. (I mean seriously, just that 8-second loop is a whole goddamn megabyte and a third.)
- I may use more of the Nuclex framework than just the DirectInput deal, if I find a use for it.
- Maybe some sort of external identifier for enqueued commands, so you can cancel them if necessary. Currently, they can be attached to a GameEntity, and the command will be deleted if the GameEntity is, but I think that's a bit too specific.
Stuff which won't involve undoing and rewriting because I haven't started them yet. However, if I do add a given item before the revisions, I may have to change them when I go and do the revisions.
- Support for fullscreen widescreen resolutions: 1280x720, which will add black bars to the left and right like a sort of reverse-letterbox, and 1280x800, which will also have a black bar at the bottom.
- Figure out how to work with/make bitmap fonts (or at least "use images for fonts") so I can do things like Touhou's fancy score-count.
- Give Menus the option of taking a "screenshot" and using that as their background image, rather than simply having the menu below it continue to draw itself. This will behave recursively.
- Finish the config.exe
- Collision detection
- Text/langauge services
- Saving a score-file
- 3D backgrounds? I admit I haven't even looked at how to do 3D graphics in XNA.
So, yeah ... I have a lot to do! But then, I had a lot more to do when I first started, didn't I? And really, revisions happen; you can't know everything in advance, and I didn't know half the stuff I knew when I first started. The "stage = menu" thing, for instance, only occurred to me when I started working on menus and noticed that they have distinct similarities. Like I've said before: this is a speed bump, not a roadblock.
1I'm not sure how to handle this in such a way that you can't access the Config-projects from outside. Or at least, not without either duplicating code, which is a Bad Thing, or putting the config-system and the game-engine into config.exe, which would be silly.
2Which will be a major game in and of itself. Saving input and seeds will be easy; the tricky part will be saving the input parameters, such as who the player-character is. And then loading them.
Previous: 2011/06/29 (Villainmad): Oh, This Is Still Here
Next: 2011/08/09 (Villainmad): A Not-Quite-So-New Beginning
Back to Villainmad
Back to My Games
Back to Main Page