Breaking Up the Solution, and How I Program
I expect, in the end, Nimble2D will be a rather full-featured library for making games -- graphics, particles, collisions, input, sound effects, music, etc. But to get there, I will need to break things up into manageable chunks, building higher priority things first, then fleshing-in the more detailed things. I expect there to be a core set of projects to handle graphics, input, and sound, with a few add-on projects to handle more specialized things such as asset handling, multi-language, tile maps, etc.
The expected core projects:
-
Nimble2D -- The Graphics System -- handling graphics capabilities enumeration & screen launching, game spaces, layers, cameras, sprites, trig, primatives, text, particles, and anything else that has to do with graphics.
-
NimbleLog -- Easy Log File Writing -- a lowly project, but quite useful ... I like to write log files -- not sure I have more to say on that topic. ;-p
-
NimbleInput -- The Input System -- handling keyboard, mouse, and game controller input, mouse-to-game-object relations, key-to-action mapping, and other things having to do with the player interacting with the game.
-
NimbleSound -- The SFX & Music System -- for SFX: volume/pan control, sprite-position-based volume/pan, delayed/repeated firing; for music: music file categorizing, queueing & shuffling, fade-in/fade-out ... and other things sound-related.
Some probable add-on projects:
-
NimbleMap -- Tile Map handling -- what's a good 2D graphics library without a nice-and-easy way to work with tile maps?
-
NimbleAssets -- Asset Data handling (aka "Pack File handling") -- a library-style approach to getting game assets and data out of packed and encrypted data files.
-
NimbleLang -- Multi-Language handling -- a library-style approach to getting language-specific text phrases and making multi-language support easier.
I expect to work on them essentially in the order I listed them. But, as I said, I will probably build working frames around the main features, move on to the next one, then come back to flesh something out in an earlier project as I find it needed.
This leads into how I work as a programmer. I am quite new to .Net, although I'm not new to VB. I broke my teeth on Commodore BASIC, Quick BASIC, and Pascal while I was in high school and early college. Then, I wandered in the wilderness for a while after changing my major in middle and later college. Once I was out in the working world, I became aware of VB3 and the VBA tucked inside MS Access 2.0. I quickly progressed to VB6 (which I've done both business and game programming in) and I'm still working with Access/VBA. So, it's only been a few months that I've seriously tried to work on VB.Net and C# projects, which means that I'm rather new to strong object-oriented approaches -- especially with games ... and I will likely be doing things "wrong" and in "non-traditional" ways. If you see something completely out of the norm, or something that can be done much more effeciently in another way, please be sure to make a comment or send me a message about it.
I'm a very practical worker, and while I can discuss and design just on theory, I usually need a practical example to develop for. In this case, the practical purpose for Nimble2D is to help me build my current game, "Air Ralley Ace" (ARA), which is an arcade airplane racing game involving scrolling landscapes, layered clouds, and lots of colored smoke. As I make progress, I will very likely be using ARA examples to show off capabilities.
So ... first-things-first ... I need Nimble2D to be able to let the game know a bit about the player's graphics card -- texture size/shape support, supported full screen sizes and color depths -- and be able to launch the selected screen style.
-Matt