the xna machine

The WPF Machine

2008-10-14T11:27:00.000-07:00

Well I'm abandoning my XNA development efforts in favor of WPF/Silverlight. Primary reasons being:

WPF/Silverlight does not have a language barrier (you can use VB, etc.)

The distribution agility of Silverlight vs. XNA is off the chart. The Silverlight plugin does not require Windows (let alone the .NET framework). It's simply a browser plugin ala Flash, available for both Mac and Windows.

XNA Click-once. Very cool for C# XNA developers, but the prospect of creating a Click-once VB hack/workaround/replacement for VB XNA apps really ups the proverbial "is this really worth it" ante.

The basis of my 2D XNA engine (i.e. the matrix hierarchy, and a scripting engine (which I never covered, but basically it allows you to target any property of a specific data type and interpolate it over time)) this was all very cool indeed. And it all already exists, practically verbatim, in WPF*.

*While it's a bit satisfying to see I came up with the same solution that Microsoft did for scripting any object with time-based animation, it's also a very major /facepalm to see I've been reinventing the wheel for the past several months!

WPF appears to be the future of Windows development, which I'd like to stay on top of for both my career and personal interest. What's more, you can totally make games with it. You can even use GPU shaders. No, it's not as powerful as XNA but you have to admit; the whole ordeal is rather neato.

So someday a new blog might crop up somewhere with my WPF/Silverlight stuff on it (altho for now I'm still pretty green). I still have those game ideas tucked away waiting for implementation... someday.

Off topic

2008-06-20T03:18:00.000-07:00

As a potentially negative side-effect to now giving these blog posts more descriptive labels, there are now several non-XNA related topics on this blog.

Namely, Off topic.

Here are some Off topic links I highly suggest:

LINQ to SQL Server CE

2008-06-19T13:32:00.001-07:00

In Visual Studio 2008, when trying to drag a local SQL Server CE database table onto your LINQ design surface, you receive the following error:

"The selected object(s) use an unsupported data provider."

This message is a little misleading, because you can in fact LINQ over your SQL Server CE database; it's just the drag & drop LINQ design surface in Visual Studio that doesn't know how to interact with SQL CE.

To work around this limitation of the IDE, you can call upon Microsoft's SqlMetal utility to create a .dbml file (aka, a new LINQ to SQL item) on your behalf. Here's a reasonably simple way to accomplish it:

In your project's solution explorer, right-click the node containing your .sdf (database) file and "Open Folder in Windows Explorer". In the resultant window, create a new text document called MakeCeLINQ.bat and edit it, entering this command:

C:\"Program Files\Microsoft SDKs\Windows\v6.0a\bin\sqlmetal.exe" /dbml:CeLINQ.dbml Database.sdf

Replace Database with whatever your .sdf file is called. It's important that this batch file be created in the same folder as your .sdf file, since the command is structured in such a way that assumes the .sdf file is sitting next to the batch file. Close & save MakeCeLINQ.bat, and double-click to run it. SqlMetal will create CeLINQ.dbml.

In Visual Studio, click the button to show all files for your project and include your newly created CeLINQ.dbml file. Include the "MakeCeLINQ.bat" file, too - strictly speaking it's no longer required, but you may find it convenient to keep it with your project.

So now you should have something like this:

You can now work with the CeLINQ object within the IDE as normal (with the ever-present exception of drag & drop functionality). If you change any of the schemas in your CE database, simply re-run the MakeCeLINQ.bat to update the CeLINQ object.

LINQ

2008-06-17T03:12:00.000-07:00

I did a little project for my wife this weekend and used LINQ for the first time. Visual Basic's implementation of LINQ over XML is just about the greatest thing since sliced bread.

Looking at my Web Updater, I get an xml file called the "wum" (web update manifest, which contains a list of server-side files to compare against a client for making decisions about which files to update). To read these wum.xml files in my Web Updater, I was using an XMLReader to simply parse the file in a serial fashion. Which worked fine, really; although there was not any "knowledge" of the xml document itself within the IDE or the Web Updater code, per se; the parsing routine was a bunch of XMLReader.Read statements, with the occasional variable assignment thrown in whenever certain nodes were reached. Without any prior knowledge of the XML file in question, the parsing process is not exactly intuitive to behold, let alone modify/debug.

With LINQ, this task of reading the wum.xml to determine which files on the disk require an update can be accomplished in a radically different fashion.

First of all, rather than simply associating a wum.xsd schema with the XMLReader's xml settings, you can drop said schema into the solution explorer / project itself and in doing so, define an XML type much in the same way you'd define any given class. With the xml schema now available to the compiler, VB provides you with "xml intellisense", allowing you to traverse an xml document in no less than xml statements such as objMyDocument.<customer>.<name>.<first>.Value and things of that nature. It's a little strange at first but pretty fantastic. This obviously injects a great deal more knowledge of the xml structure itself into the code - now someone viewing or even editing this code for the first time has a far less abstract situation on their hands.

If that weren't enough of an improvement, I realized I didn't really have to serially process the wum.xml at all. I can take that XMLReader I'd been using to create an Xml.Linq.XDocument. An XDocument is basically an xml document instance but it's queryable by LINQ - so you can treat it like a database. Now I can save literally dozens of XMLReader calls & parsing effort by simply querying the XDocument Where Not IO.File.Exists OrElse IO.File.LastWriteTime <> (queryResult.LastWriteTime) and viola, an IEnumrable object of XElements matching the query are returned. In addition, the query result can be stuffed into any given appropriate class of your choosing, so you don't even have to deal with XElements in the result set if you don't want to, and then ultimately .ToList(ed) into a generic List(Of <whatever>).

It's all slightly mind-blowing the first time you sit down to use it, particularly when you consolidate 50 lines of mundane XML parsing into a single LINQ query in a matter of minutes, never even having used LINQ before. Just imagine what you can do with this stuff once you actually know how to use it... pretty cool!

Scope creep

2008-06-14T16:36:00.001-07:00

I updated the graphics of this blog a little bit. I'd been playing around with a VB/XNA logo hybrid in photoshop so I thought I'd use it for something.

I've been working very hard on my Web Updater and Wummer applications over the past 2 weeks and I haven't been able to resist putting more and more functionality into them. They're turning into things which may actually be quite useful.

The Wummer will now let you split up the files you want to publish over however many different hosts you specify; so for instance if you have 3 hosts at your disposal but they're slow uploaders (eg., homebrew DSL & Cable broadband line hosting like I use for most things) the Wummer allows you to divide the publication of files amongst multiple hosts, and the manifest now groups files by host.

You can also change the relative path binding of each file, so that any given number of remote URLs can map to the same local client install directory. This all required a somewhat extensive storage system for the Wummer, so I chose to use an sql server ce database, which keeps track of all the projects and files and hosts etc. of every probject you've ever published using the Wummer.

In addition to being able to react property to the new manifest files, the Web Updater will now also attempt to update itself by temporarily cloning it's own executable and launching it with the Web Updater's own manifest file specified. In this way the Web Updater sort of "cheats", using a copy of itself to update itself, which I thought was cute.

There are a few small but important touches to add to the Web Updater before it's ready for prime time, right now I've got the XNA Content Assistant performing updates with it and it's working pretty well, it's just not quite as elegant as I would like yet (currently there is much shutting down and restarting of programs during an update process which, while automatic and not necessarily cumbersome to the user, is unprofessional looking and some of it can be avoided).

At some point I would like to consolidate all this into an "xnamachine software portal" application, which installs the prerequisites & runtimes on your PC (such as the Visual C++ redist for XNA games, .net 3.5, sql server ce, and provide convenient links to the XNA redist & DirectX web installer, which are easier for the user to just run themselves at this time). That way, there would only ever be 1 thing you would ever have to "install" from xnamachine.com in order to use anything I release. The portal would be an updatable application launchpad that provides links to whatever I make available; the Wummer, the XNA Content Assistant, templates for Visual Studio, XNA games, whatever. Such a thing would not be very difficult to make so I may go ahead with that as a software distribution plan, unless I think of some horrible drawback to doing it that way.

The wummer

2008-05-24T02:24:00.000-07:00

The core of the Web Updater program is complete; it can now connect to web servers, obtain wum.xml files, validate them against a public wum schema, perform a differential check against the locally installed files on the client and download the obsolete/missing files. After downloading it can now replace the files on the client via decompression (if the wummer tool had compressed them when publishing) or, just renaming them into place.

My "wummer" publishing tool is finished, save a few UI nuances, and so together they have created a functioning publish/update circuit.

The Web Updater still needs a few more things; certain disaster recovery scenarios still must be accounted for, like if it can't access files it's trying to update or it's connection drops while downloading. It also still needs the ability to accept command line arguments when it runs, and finally it needs the ability to re-launch the target application it's updated. So I guess it's about 85% complete.

Here it is, dutifully "updating" a bunch of nonsense files. I added the little treeview to it this evening, just for fun.

wum

2008-05-20T01:12:00.000-07:00

So the XNA Content Assistant is largely finished and I wanted to distribute it using some kind of web update model, to make it easier for all of you to update the Assistant in the future. So I built a little update functionality into the Assistant under the Visual Studio ClickOnce model.

ClickOnce is really neat and very easy to use, but unfortunately for the XNA Content Assistant it is unacceptable. The problem is that you can't effectively launch a ClickOnce application from another program e.g. via Process.Start while passing command line arguments. At best, you can submit a query string to a web-based application, but having the Assistant be entirely web based is not acceptable. The Content Assistant must be installed on the local machine and must be callable via command line with arguments.

Therefore I abandoned the ClickOnce model and for the past couple days I've been crafting a web update system. This is something I will require anyway, to allow updates to my future XNA applications, so it's somewhat of an inevitable project.

The Web Updater does its best to be somewhat generic; in a nutshell it just needs to know the URL of your application's "wum.xml" file (Web Updater Manifest), a simple xml file which describes the current files available on the update server (name, size, last update, etc). The Web Updater grabs the wum and checks it against whatever application it's updating on the local machine, and updates files as necessary.

To that end, now I'm in the process of writing a companion tool for wum publishing called the Wummer. The Wummer is for developers, we point it at our Release folder (or, whatever you want to publish), and the Wummer uses an IO.CompressionStream to publish your application to your web host as .gz files, creating the wum.xml file for you (an otherwise tedious task).

So I've been pretty busy working on all this lately, juggling work and 3 of my own little mini-projects! I believe these will all be helpful tools though and I hope to have them finished up pretty soon.

XNA Content Assistant

2008-05-14T16:46:00.000-07:00

The logistics of how content gets built in the VB template will change when GS 3.0 is released. Rather than hard-code all of the content building specifics into the VBContentManager class, this functionality has been moved into a stand-alone application, which will act as a bridge between a non-Game Studio project and the Content Pipeline. This application is called the XNA Content Assistant, and is a Windows form application with a graphical interface. However, it also supports being called from the command line in an invisible mode.

I'm currently putting the XNA Content Assistant through beta, naturally I want to debug such an important component thoroughly. It is functional at this time, and so here's a preview of what it looks like, and what it does:

You start out by opening your game's Visual Studio or Visual Express project file. (when running from a command line, you would supply this as an argument)

Based upon the location and contents of the specified project file, the XNA Content Assistant will automatically determine where your content folder is (even if you did not name it "content"). It will then automatically determine which XNA framework version your game is programmed against. The XNA Content Assistant understands how to build content for Game Studio Express (1.0 Refresh) projects, Game Studio 2.0, and Game Studio 3.0 projects created in either VB or C# in Visual Studio 2005, 2008, and the Express editions.

On the GUI, we can see the Assistant has successfully harvested content from my "Timeclock" application, and I am proceeding to select a platform (this would be the 2nd and final parameter you would need to supply via command line)

And lastly when we execute the build process, we can see that MSBuild's output is integrated nicely into the Assistant's UI, to help troubleshoot build issues such as missing fonts, etc. It also exports a log and a copy of the content project submited to MSBuild in your project's folder for reference.

As future XNA versions are released, XNA Content Assistant will be updated and your existing template can simply continue to utilize the updated Assistant, rather than requiring code changes to the template itself (i.e., the VBContentManager class, which will be largely obviated by the Assistant).

XNA 3.0 CTP

2008-05-10T12:47:00.000-07:00

The XNA/GS 3.0 CTP is out and I'm in the process of updating the VBContentManager in preparation for the official release.

XNA 3.0 content processing expects to use the .NET Framework v3.5 edition of MSBuild. For those not interested or ready to move to XNA 3.0, XNA 2.0 compatibility will be retained in the VBContentManager.

To that end, the GS 3.0 release will mark a small change in how the VBContentManager works. A version enumeration is now required by the VBContentManager class, and moving forward, the VBContentManager will be augmented with new version support (rather than replaced wholesale) so that future editions of the VBContentManager can target prior XNA versions (dating back to 2.0). Just pass in which XNA version you're targeting, and it will process your content accordingly.

The VBContentManager currently available for download was never updated with functional, XACT-based audio importing. I do have this working in my "production" VBContentManager, and as part of the 3.0 update I will include this for backward compatibility with 2.0's XACT-based audio. And of course the new audio importing for 3.0 will be available as well, which is what I'm working on now.

Microsoft.VisualBaggage

2008-05-10T00:22:00.000-07:00

Here's an interesting article on Paul Vick's blog (not exactly new, but it was to me): VB Runtime agility, Orcas and new platforms.

Touring

2008-04-20T23:02:00.000-07:00

Someone asked the creator's club a question about writing a Mille Bornes game. I remember liking that game as a kid, but the first version of it I played was the older more simplistic game of Touring.

I've been thinking of putting together a simple game to test the XNAMachine engine with, something a little more simple than Star Maze just to see what it's like to build something with it, and this seemed like the perfect thing. So rather than completely rip off that guy's idea of making Mille Bornes, I've been putting together a Touring card game (ok, so I'm mostly ripping off his idea...)

Making a 1-player Touring game would be a little "too easy" I think, so I'm building both server & client programs to allow for multi-player sessions of Touring to be started by whomever wants to play. If the engine proves to be a decent performer for this application I'll begin the process of "porting" what's completed of my Star Maze project over to the XNAMachine engine.

At this point I've got most of the object structure done for Touring, the game logic is easy, and so now I'm writing the network code for the server. There are no movement predictions or tight synchronizations to worry about here, the server & client really just need to relay simple commands & acknowledgments back & forth so it's a really good starting place for network code I think.

At the risk of enduring a copyright violation lecture I've obtained some rather pristine editions of old Touring games from eBay as texture sources, and I've been browsing around a neat little website called soundsnap, which has a lot of nice free sounds & music loops.

This is something of an unexpected diversion but I guess that's typical; the hardest part about programming is finishing something, right? No worries...

Vacation 2

2008-04-08T14:48:00.000-07:00

I'm in Japan this week. I don't speak or read Japanese so sometimes it feels a little crazy, but at least we haven't gotten lost yet. The train system here was a challenge at first (especially to a foreigner from a small US town without any serious public transport in the first place). But a lot of things are in English of course so it's not so bad. Today we're in Kawaguchi which is a small country town just north of Mt. Fuji. Just hanging out here, it's like a mountain resort type of place.

I wanted to get some good work done on the XNAMachine engine on the 11 hour flight, but after a couple hours I realized I didn't have the right power adapter for the plane's weird DC plug.

The XNAMachine

2008-04-03T01:00:00.000-07:00

I'm continuing to plug away at my new engine here and there, mainly by jotting ideas down into classes & interfaces, and then shaping them into workable objects. It's kind of like throwing lumps of clay down into the IDE & then shaping them into recognizable things. It's probably the world's most inefficient way to design something but I'm having fun with it.

The XNAMachine (my obvious name for this new engine) has grown into 5 primary categories which I've split into as many Namespaces within the project. The primary namespaces are, in no particular order

Core - this contains classes such as the base Game class, the VBContentManager, a static math helper class, all the primary singleton stuff

Objects - the base game object is defined in here along with a base game component for including objects in the XNA Game's components collection. Future items in here will be other common bases; screen, camera, and some sort of base spacial partitioning class either a grid or a quadtree or both

Augments - a base class + various primitive implementations of game object expansion pieces

Automations - this is the bit I've been working on the past couple of days, it's a system of rudimentary classes that primarily hold information which can be used to modify various properties of augments. Automations are intended to be Augments, but it's such a big category of "stuff" that it got it's own namespace. An example of an Automation Augment would be, for example, if you have a Transformation augment attached to a game object, the game object gains the ability to be transformed by a matrix. You can then attach an automation augment to that game object, specify which element of the transformation object you want the automate, and this will allow for "scripting" various activities over pre-defined times & destinations. I have a system like this now, it's just not nearly half as elegant as this revision will hopefully be

Augment Update Services - the way I'm experimenting/planning to update augments is to create a collection of service implementations that perform various tasks, each built to accept a single augment at a time. Every single augment will have a reference to the service it uses to update itself, so when an augment wants to update, it simply passes itself in to it's service reference.

So that's kind of the gist of it so far, and I'm getting reasonably close to finishing up the classes in the Automation Namespace, but my wife is hardcore giving me the stink-eye so I better turn my laptop off before I get busted.

Composition

2008-03-23T14:05:00.000-07:00

Well I've been bitten by the Composition bug. In a big way. So to satiate my newfound curiosity, I must confess I've been spending time on an experimental clone of my 2D engine using a technique of dynamic Composition.

The Composition version of the engine is based around a single "Game Object" class. This class is effectively nothing more than a collection of IAugmentation interfaces.

In my existing engine, the Sprite class has become quite large; what's more, not all Sprites always utilize every member and feature of the class. By partitioning this class into several different stand-alone "mini-classes" (all of which implement the IAugmentation interface), these mini-classes become "Augmentations". From this, one can start with an empty game object and build it into anything by adding the appropriate behavioral and/or data Augmentations to it's IAugmentation collection.

What's seductive about the Composition model is that this building process is not significantly different between design time and run time. To me this is the primary advantage of using Composition over Inheritance, which AFAIK is largely static at run time. I.e., once you define your class that inherits from <whatever>, you're stuck with that at run time. With Composition, you could simply remove one Augment and add another.

My only concern with what I've developed so far is that dictionary lookups are becoming somewhat frequent - i.e., I find myself querying whether or not a game object has been augmented with <augmentX>, and if so, retrieving that augment for use. These queries don't exist so much in the Inheritance model, and this aspect may require some fine-tuning as things get progressively more complex. But, we shall see.

Fun stuff!

PointAt v2.0

2008-03-11T21:41:00.000-07:00

In Tutorial 6 (The PointAt method), I suggested a way one sprite can "point" at another, given totally arbitrary tree nesting / matrix transform between the two objects. The code was:

''' <summary>
''' Point one sprite's origin at another sprite's origin
''' </summary>
Public Sub PointAt(ByVal thePointer As Sprite, ByVal theTarget As Sprite)

Dim objTargetWorldPosition As Vector2

If theTarget.Parent IsNot Nothing Then
objTargetWorldPosition = Vector2.Transform(theTarget.Location, theTarget.Parent.DrawMatrix)
Else
objTargetWorldPosition = theTarget.Location
End If

thePointer.Rotation = 0

With Vector2.Transform(objTargetWorldPosition, Matrix.Invert(thePointer.DrawMatrix)) - thePointer.Origin

thePointer.Rotation = CSng(Math.Atan2(.Y, .X) + (Math.PI / 2))

End With

End Sub

And that works, but I realized an alternative way to solve the same problem today. I haven't compared the raw performance of this new way vs. the other, so I can't say if it's faster... but I suspect it might be.

''' <summary>
''' Gets the radian between two sprite origins
''' </summary>
Public Function PointAt(ByVal thePointer As Sprite, ByVal theTarget As Sprite) As Single

Dim a, b, c As Vector2

Vector2.Transform(thePointer.Origin, thePointer.DrawMatrix, a)
Vector2.Transform(theTarget.Origin, theTarget.DrawMatrix, b)

c = b - a

Return CSng(Math.Atan2(c.Y, c.X) + MathHelper.PiOver2)

End Function

I made it a function that returns the radian value, so that you can do with it whatever you so choose - either assign it to the Rotation value of thePointer, or just query the angle between two things for whatever reason.

Uninventing some wheels - Stacks & Dictionaries

2008-03-07T12:37:00.001-08:00

You know the "Hashtable(Of Type)" class used by the VBContentManager?

There's actually a generic Dictionary class in the .NET framework that serves the same purpose.

The Dictionary class provides two type predicates, one for the key and one for the value, whereas my Hashtable class simply presumes the key to be of type String. We could do away with the Hashtable(Of Type) class all together, and simply start using Dictionaries.

The other thing I started messing with is the generic Stack class. My current ScreenManager class keeps track of Screen order via some rather sloppy and unnecessary list manipulation. But all of that can be done away with and replaced with a Stack(Of Screen).

Stacks are a very convenient way to maintain Screen order within a ScreenManager, because there is a natural synchronization between the inherent nature of Stacks and the way we display Screens.

At the beginning of the program, push Screen1 onto the Stack. When you transition away from that Screen1 to Screen47, pop the Stack (removing Screen1) and push Screen47 onto the Stack. If you want to display Screen2 over Screen47, simply push Screen2 onto the Stack. Now Screen2 is above Screen47, which is exactly what we wanted to display. When Screen2 is finished, pop it off the Stack, and Screen47 resumes the top position. It's a very convenient way to maintain the order of Screens, and I will employ this technique in the Screen tutorial.

Obligatory update

2008-03-05T18:21:00.000-08:00

I've been busier than usual for a while, doing some work on my car (painting wheels - my garage looks, and smells, like a paint shop) and also I'm going through a crunch phase at work, making a great big middle-tier ADO.NET engine which will really expedite creation of business objects & UIs, which is rather cool.

But anyway, I'll be up to my eyeballs in that for another week or so, after that I can get back to continuing with more XNA stuff.

Tutorial schedule

2008-02-25T21:12:00.000-08:00

While I've rambled on about Screens, Scenes and Cameras I haven't really put up any tutorials in 4 months since "Tutorial 8" and I'm getting a little bit ahead of myself.

So here's a rough TODO list, sort of making this for myself, but it's what I want to cover in detail before I get too off track here:

Screens - a proper introduction to Screens, adding a base Screen class to the Engine

Screen Manager - a simple little tool to help shuffle Screens around

Scenes - like a Screen, but bigger - huge, even. I may rename Scenes to... "Worlds" or "Levels" or, something. Screens and Scenes are conceptually similar with similar names, kind of has an inherent confusion built into it

SceneCameras - this will be the in-depth tutorial on what I've been doing lately. Cameras physically exist on Screens, and are used to peek inside of Scenes

Automation - I have an automation system written, which I can actually take the opportunity to improve upon a little bit as I write it up here on the blog, which allows you to "script" change in game object properties over time. Things like movement, rotation, alpha (fade in/out), changing texture, scaling, stuff like that. This is a very useful for doing UI-ish tasks, like Screen transitions, but I use it for all sorts of other stuff

SceneGraph? QuadTrees? - In a big Scene with lots and lots of game objects, for efficiency sake we will need some way to make quick collision checks between potentially thousands of objects. If a bullet is flying through a level of your game with 5,000 potential objects it could strike, you don't want to check for collision with all 5,000 objects if you can help it. I haven't tackled this yet so it's coming up next on my R&D list

AI - Another R&D project

Level Generation - I've been reading up a little on algorithms for creating random mazes, it's kind of interesting and thankfully not too complicated. I'll use it in the Star Maze project

Sound - I'm assuming this won't be too difficult to implement (famous last words)

Star Maze - take everything covered and use it to re-create a classic 2D game

And beyond that... - like most wanna-be game hobbyists I have an ambitious vaporware project I want to turn into a reality. But first I'll create Star Maze, get some good practice there, and if all goes well we can start to tinker around with other things

So that's the plan. There's no ETA :)

www.xnamachine.com

2008-02-25T11:37:00.000-08:00

xnamachine.blogspot.com should now redirect you to www.xnamachine.com. www.xnamachine.com is now the "official" address.

Nothing else is different, I just decided a more succinct name would be cool.

Well, ok I changed the layout just a little bit... just for fun (I don't know how IE-friendly it is yet). I noticed my formatted code posts don't show up right in IE, so that's kind of a bummer. I'll try to fix that... eventually.

SceneCamera class nears completion

2008-02-17T05:35:00.000-08:00

Here is a video demonstrating the features of the SceneCamera class as it nears completion:

direct link

All SceneCameras will by default perform a translation of the subject (e.g., follow it's X/Y position), and all SceneCameras have the ability to scale (zoom in/out). In addition to these two default behaviors there are two optional properties to specify camera style.

Rotate with subject: If this property is True, it causes the SceneCamera to lock rotation with its subject. This creates a camera style whereby the subject appears fixed and the entire Scene rotates. In the video, the SceneCamera on the right side rotates with it's subject. The SceneCamera on the left side has this property set to False, creating an opposite effect (the Scene appears fixed and the subject rotates).

Clamp to Scene: If this property is True, the SceneCamera is not permitted to exit the perimeter of the Scene. In the video, the left side has this property set to True, and it is False on the right side.

Finally, there is a 3rd SceneCamera moving around the perimeter of the Screen to demonstrate the "game object" nature of SceneCameras. Like a Sprite, a SceneCamera can easily be any size, and can move around the Screen without disturbing it's ability to view a subject.

What I will be adding next is a property for Chase lag, so the SceneCamera can be given a variable amount of imprecision when following its subject. Once this is done, the SceneCamera class should be adequately functional.

How to modify the VBContentManager to load other content types

2008-02-06T11:53:00.000-08:00

Here's an example of how you can teach the VBContentManager to load other content types.

This sample code below shows you what to add (in bold) in order to load .fbx models. Please note that to actually display a 3D model, you'll have to write your own 3D rendering code - 3D is out of scope of my 2D engine blog. This just demonstrates how you can teach the VBContentManager to load other content types, the example just happens to use .fbx models.

Public Class VBContentManager
Inherits ContentManager

'Add a Hashtable(Of Model) called Modles, to
'give your models a place to arrive in memory...

Public Models As Hashtable(Of Model)

'Add "intDupeModel" variable to this series...
'This allows the VBContentManager to append a
'unique number to any duplicate filenames it
'may encounter when loading models from disk

Private intDupeSound, intDupeTexture, intDupeFont, intDupeEffect, intDupeModel As Integer

'Add "Models" to the ContentTypes enumeration,
'and make it the next available value

Public Enum ContentTypes
Textures = 0
Fonts = 1
Sounds = 2
Effects = 3
Models = 4
End Enum

'Add "FbxImporter" to the ImporterName enumeration
'Make sure it has the same value as Models in the
'ContentTypes enumeration...

Private Enum ImporterName
TextureImporter = 0
FontDescriptionImporter = 1
XactImporter = 2
EffectImporter = 3
FbxImporter = 4
End Enum

'Add "ModelProcessor" to the ProcessorName enumeration
'Make sure it has the same value as Models in the
'ContentTypes enumeration.

Private Enum ProcessorName
TextureProcessor = 0
FontDescriptionProcessor = 1
XactProcessor = 2
EffectProcessor = 3
ModelProcessor = 4
End Enum

'In Public Sub New, add code to instantiate the Models hashtable
'you added above

Public Sub New(ByVal ServiceProvider As IServiceProvider, ByVal ContentFolder As String)

'(existing code omitted)

'Add code to instantiate the models hashtable

Me.Models = New Hashtable(Of Model)

End Sub

'In LoadAllContent, add a Try block for Model importing in the
'Catch block for Effects, and move the unknown file handler
'to the catch block for attempted Model load

Public Sub LoadAllContent()

'(existing code omitted)

Try

'Effect?

With file.FullName.ToLower
Me.Effects.Add(file.Name.Replace(file.Extension, ""), Me.Load(Of Effect)(.Replace(Me.strExecutingFolder & "\", "").Replace(file.Extension, "")))
End With

'Instead of giving up at this point, catch this as notAnEffect,
'and add 1 more check to see if the file is a model...

Catch notAnEffect As Exception

Try

'Model?

With file.FullName.ToLower
Me.Models.Add(file.Name.Replace(file.Extension, ""), Me.Load(Of Model)(.Replace(Me.strExecutingFolder & "\", "").Replace(file.Extension, "")))
End With

'If that doesn't work, then I've run out of things
'to try, so...

Catch unknown As Exception
strUnknownFiles &= vbCrLf & file.FullName
End Try

End Try

'(existing code omitted)

End Sub

'In HarvestContent, add code to search for .fbx files. Also,
'I'm going to add code to look for .tga texture files as well
'in case I need those too.

Private Sub HarvestContent()

'(existing code omitted)

'Add code to look for .tga files...

For Each texture As System.IO.FileInfo In objRoot.GetFiles("*.tga", IO.SearchOption.AllDirectories)
If Me.objContent.Contains(New ContentFile(ContentTypes.Textures, texture, texture.Name.Replace(texture.Extension, ""))) Then
Me.intDupeTexture += 1
Me.objContent.Add(New ContentFile(ContentTypes.Textures, texture, texture.Name.Replace(texture.Extension, "") & Me.intDupeTexture.ToString))
Else
Me.objContent.Add(New ContentFile(ContentTypes.Textures, texture, texture.Name.Replace(texture.Extension, "")))
End If
Next

'Add code to look for .fbx files... these are similar
'code blocks, just change the ContentType enumeration and the
'extension we want to look for from all the existing ones in
'this sub

For Each model As System.IO.FileInfo In objRoot.GetFiles("*.fbx", IO.SearchOption.AllDirectories)
If Me.objContent.Contains(New ContentFile(ContentTypes.Models, model, model.Name.Replace(model.Extension, ""))) Then
Me.intDupeModel += 1
Me.objContent.Add(New ContentFile(ContentTypes.Models, model, model.Name.Replace(model.Extension, "") & Me.intDupeModel.ToString))
Else
Me.objContent.Add(New ContentFile(ContentTypes.Models, model, model.Name.Replace(model.Extension, "")))
End If
Next

End Sub

The VBContentManager code should now be able to import .fbx files. Create a folder called Models in your Content folder in the solution explorer, and put .fbx files in there:

Here I copied all the models (and textures) from the SpaceWar example, and they now compile & load into the Models hashtable of the VBContentManager.

SceneCamera

2008-02-02T02:19:00.000-08:00

I got a chance to get a little more camera work done over the past couple days. What I've made is a 2D camera which is a game object (as such it can be placed onto a Screen just like anything else). These cameras point at "Scenes", which are similar conceptually to Screens, but unlike Screens a Scene is not meant to "draw itself", it just sits in memory. You use a SceneCamera to view a subset of the Scene.

In this demonstration a Scene exists in memory, it's a simple repeating tile grid w/ a user-controlled ship. Multiple SceneCameras are implemented to demonstrate the concept of viewing a Scene through a SceneCamera. All of the SceneCameras are pointing at the same ship in the same Scene.

Pardon the obnoxious music, I was just having fun with Premiere:

direct link

It's still pretty beta-ish but it basically works, I'll do a write up after it becomes more properly solidified.

Tell Microsoft you want VB support for GS

2008-01-28T18:53:00.000-08:00

Microsoft is offering a survey to XNA/Game Studio users for feedback on the XNA/Game Studio product. There are one or two questions on the survey which give you the opportunity to suggest the support of other, non-C# .NET languages. If you would like Game Studio to support VB, you should fill out the survey and mention it.

Screens & the Screen Manager

2008-01-16T11:39:00.001-08:00

Screens

Screens are what I've been using, prior to implementing Cameras. So they may change. Here's how it all works now, and while the names may change in the future, the basic concept will probably remain mostly the same.

In Tutorial 7 we defined custom game objects as separate classes in our project. In doing so we abstracted a lot of detail out of our game class; not only the construction of the little ship & turret tree, but also the Update code that moved a ship back and forth across the screen. The primary focus on putting these things into a Ship class was to make them readily reusable - but did you notice it really helped tidy up the Game class? In part there is a philosophical benefit to abstraction in that it simply helps to keep things looking tidy, if you're into that sort of thing.

In the previous article A forest for your trees, we simulated this strategy somewhat in a hypothetical Game class that defined some make-believe game objects as members:

Public Class MyGameTutorial
Inherits Game

'Main menu stuff
Private objNewGame As NewGame
Private objGraphics As Graphics
Private objQuit As Quit
Private objContinue As Sprite

'Game stuff
Private objShip1 As BadGuyShip
Private objShip2 As BadGuyShip
Private objPlayer As PlayerShip
Private objHighScore As Sprite

'Initialization, etc.

End Sub

We ended up with 8 game objects or trees, like so:

And in theory you would manage (update/draw) all 8 of them directly from within the game class. That's not too bad, but, half of these objects are meant for the main menu game state, and the other half belong to the actual "playing the game" game state. The only way to know which ones even belong to which state is to read the comments above the member declarations! I'm no coding guru, but even I know that's turning into a sketchy situation.

If we take the time to define custom Screens, just like we defined custom game objects in Tutorial 7, we can perform yet another level of abstraction that will not only help organize us, and help us maintain game state, it will again make our game class a more tidy, simple thing to work with.

Tutorial 7 also walked us through creating custom game objects by deriving new classes from Sprite. You do something like this...

Public Class MenuObject
Inherits Sprite

Private ChildOption1 As Sprite
Private ChildOption2 As Sprite

Public Sub New()

Me.ChildOption1 = New Sprite()
Me.ChildOption2 = New Sprite()

Me.AddChild(ChildOption1)
Me.AddChild(ChildOption2)

End Sub

'Update, Draw etc.

End Sub

We can do the very same thing to create custom Screen objects from our base Screen class. Let's build some hypothetical screens to abstract those 8 game objects into 2 screens representing their respective states. First here's a pseudo Main Menu Screen class:

Public Class MainMenuScreen
Inherits Screen

Private NewGameChoice As MenuObject
Private ContinueChoice As Sprite
Private GraphicSettings As MenuObject
Private Quit As MenuObject

Public Sub New()

Me.NewGameChoice = New MenuObject()
Me.ContinueChoice = New MenuObject()
Me.GraphicSettings = New MenuObject()
Me.Quit = New MenuObject()

Me.AddChild(NewGameChoice)
Me.AddChild(ContinueChoice)
Me.AddChild(GraphicSettings)
Me.AddChild(Quit)

End Sub

'Update, Draw etc.

End Sub

It looks like this:

Now how about a pseudo game screen class:

Public Class TheGameItself
Inherits Screen

Private Ship1 As BadGuyShip
Private Ship2 As BadGuyShip
Private Player As PlayerShip
Private HighScore As Sprite

Public Sub New()

Me.Ship1 = New BadGuyShip()
Me.Ship2 = New BadGuyShip()
Me.Player = New PlayerShip()
Me.HighScore = New Sprite()

Me.AddChild(Ship1)
Me.AddChild(Ship2)
Me.AddChild(Player)
Me.AddChild(HighScore)

End Sub

'Update, Draw etc.

End Sub

There we go:

Nevermind the naming mis-match on the diagram; the "game" node represents the "TheGameItself".

Now instead of adding 8 game objects to our game class and organizing them with code comments, we can use two Screens with names that convey their purpose:

Public Class MyGameTutorial
Inherits Game

Private MainMenu As MainMenuScreen
Private TheGameItself As GameScreen

'Initialization, etc.

End Sub

This gains us a few benefits. With the addition of a Screen node, we can now transform (move rotate scale etc) an entire Screen of "stuff", be it the main menu or the game itself, something we couldn't do easily prior to implementing Screens. This also gives us something of a "choke point" for state management - if we want to draw the Main Menu, we just tell the main menu screen to .Update or .Draw and thanks to the underlying Sprite class, the rest more or less runs itself. All our Game really has to worry about now is calling the Update & Draw methods of whichever Screen(s) are appropriate for the current Game State.

XNA.Framework.Game.Components and the ScreenManager

This has all been very cute, but it seems that all we've done is shuffled the question of which Game Objects to draw to which Screens to draw. What we've done so far helps organize us, but it hasn't helped us answered that important question.

You may be pleased to know we can eliminate the need to ask this question all together. We can simply update/draw whichever Screens happen to be Enabled and/or Visible at the moment. For this, we will borrow upon the Components member of the XNA.Framework.Game class.

In brief, XNA.Framework.Game has a built-in Components collection. This collection is meant to hold objects which derive from GameComponent and/or DrawableGameComponent, but in truth can hold any object which implements the IGameComponent/IUpdateable/IDrawable interface(s). The Game.Components collection is handy because, similar to how our Sprite class was created to automatically draw & update it's children (if any), XNA.Framework.Game understands that if it finds anything in it's Components collection, it should Update and Draw whatever it finds in there. There are a few useful features of this which we're going to borrow upon:

The IUpdateable and IDrawable interfaces have UpdateOrder and DrawOrder properties, respectively. When XNA.Framework.Game processes it's Components collection, it uses these values to determine which objects get Updated first and which ones get Drawn first
The IUpdateable interface has an Enabled property (Boolean). The Game class will only Update components where Enabled=True
Similar to Enabled, the IDrawable interface has a Visible property and only objects which are Visible will be Drawn

This is a convenient little system to plug our Screens into.

Now you may have noticed some Interfaces being included in the base Screen class in the previous article, let's get another look at that:

Public MustInherit Class Screen
Inherits Sprite
Implements IGameComponent
Implements IDrawable
Implements IUpdateable

'etc

End Class

Implementing these interfaces allows our Screen class to be "registered" or added to the Game.Component collection. Alternatively, you could be dealing with classes that inherit from GameComponent or DrawableGameComponent, which Implement these interfaces for you. Since our Screen inherits from Sprite, this hasn't been done for us so I'll just have the Screen class implement the necessary interfaces.

The Screen Manager class is going to be our middle-man between our game code and the Screens stored in the Game.Components collection. The Screen Manager is going to add our Screens to the Collection for us, set DrawOrder for us, set Enabled & Visible for us, all that stuff. We'll just use the "Add", "Load" and "Unload" methods of the Screen Manager, for the most part. Here's the class, which I'll post for your amusement. If I get around to making a video about this I can go into more detail:

Public Class ScreenManager

Public Shared Game As GameEngine
Public Shared Root As Root
Private Shared NameToGameID As New Hashtable(Of Integer)
Private Shared GameIDArrangement As New List(Of Integer)

Public Shared ReadOnly Property GetScreen(ByVal ScreenName As String) As Screen
Get
If NameToGameID.Contains(ScreenName) Then
Return CType(Game.Components(NameToGameID(ScreenName)), Screen)
Else
Return Nothing
End If
End Get
End Property

Public Shared ReadOnly Property CurrentScreen() As Screen
Get
Dim objRet As Screen = Nothing
For intX As Integer = GameIDArrangement.Count - 1 To 0 Step -1
If CType(Game.Components(GameIDArrangement(intX)), Screen).Enabled Then
objRet = CType(Game.Components(GameIDArrangement(intX)), Screen)
Exit For
End If
Next
Return objRet
End Get
End Property

Public Shared ReadOnly Property IsScreen(ByVal ScreenName As String) As Boolean
Get
Return NameToGameID.Contains(ScreenName)
End Get
End Property

Public Shared Function CreateRoot(ByVal YourGame As GameEngine, ByVal objRootSize As Vector2, Optional ByVal strTextureName As String = "", Optional ByVal strTextureNameItem As String = "") As Root

Dim objRetVal As Root

'make a new root object of the specified size at 0,0
objRetVal = New Root(YourGame, Nothing, "root", True, True, strTextureName, strTextureNameItem)
objRetVal.Size = objRootSize

Return objRetVal

End Function

''' <summary>
''' Adds a screen to the screen manager. Adds to the top of the stack by default, but does not alter Enabled or Visible
''' </summary>
''' <param name="obj"></param>
''' <remarks></remarks>
Public Shared Sub AddScreen(ByVal obj As Screen)

Root.AddScreen(obj)
Game.Components.Add(obj)
NameToGameID.Add(obj.Name, Game.Components.Count - 1)
GameIDArrangement.Add(Game.Components.Count - 1)
obj.Initialize()

End Sub

''' <summary>
''' Sends the specified screen to the bottom of the stack and excludes it from the update/draw loop
''' </summary>
''' <remarks></remarks>
Public Overloads Shared Sub Unload(ByVal intScreenID As Integer)

'Remove this screenID the update/draw loop
With CType(Game.Components(intScreenID), Screen)

.SetVisiblity(False)
.SetEnabled(False)

.IsModal = False

End With

End Sub

''' <summary>
''' Brings the specified screen to the front of the stack and includes it in the update/draw loop
''' </summary>
''' <remarks></remarks>
Public Overloads Shared Sub Load(ByVal intScreenID As Integer, ByVal Modal As Boolean, Optional ByVal TransitionIn As Boolean = True)

Dim ModalScreen As Screen
Dim tex As Texture

'Bring to the front of the stack
ScreenManager.BringToFront(intScreenID)

'that changes the gameIDArrangement (this screenID is now at .Count-1 and all others have been pushed -1)

'Include this screenID the update/draw loop

With CType(Game.Components(intScreenID), Screen)

.SetVisiblity(True)
.SetEnabled(True)

'Set modal state
.IsModal = Modal

If TransitionIn Then
.TransitionIn()
End If

End With

'Now if we have just shown something modal, we need to stay in a loop here so the calling code
'can resume when the screen gets hidden. For as long as we are modal, this loop continues

ModalScreen = CType(Game.Components(GameIDArrangement(GameIDArrangement.Count - 1)), Screen)

If ModalScreen.IsModal Then

While ModalScreen.IsModal
Game.Tick()
End While

Game.GraphicsDevice.Textures(0) = tex

End If

End Sub

''' <summary>
''' Brings the screen to the top of the render stack. Does not change Enabled or Visible
''' </summary>
''' <remarks></remarks>
Public Overloads Shared Sub BringToFront(ByVal intScreenID As Integer)

'If this screen is already in the show stack, remove it
If GameIDArrangement.Contains(intScreenID) Then
GameIDArrangement.Remove(intScreenID)
End If

'Put this screen at the top of the show stack
GameIDArrangement.Add(intScreenID)

ScreenManager.SetDrawOrders()

End Sub

''' <summary>
''' Syncs the draw orders of the screens with their positions in the show stack
''' </summary>
''' <remarks></remarks>
Private Shared Sub SetDrawOrders()
For intX As Integer = 0 To GameIDArrangement.Count - 1
CType(Game.Components(GameIDArrangement(intX)), Screen).SetDrawOrder(intX)
Next
End Sub

''' <summary>
''' Sends the screen to the bottom of the render stack
''' </summary>
''' <remarks></remarks>
Public Overloads Shared Sub SendToBack(ByVal intScreenID As Integer)

'If this screen is already in the show stack, remove it
If GameIDArrangement.Contains(intScreenID) Then
GameIDArrangement.Remove(intScreenID)
End If

'Put this screen at the bottom of the show stack
GameIDArrangement.Insert(0, intScreenID)

ScreenManager.SetDrawOrders()

End Sub

Public Overloads Shared Sub Load(ByVal ScreenName As String, ByVal Modal As Boolean, Optional ByVal TransitionIn As Boolean = True)
Load(NameToGameID(ScreenName), Modal, TransitionIn)
End Sub

Public Overloads Shared Sub Unload(ByVal ScreenName As String)
Unload(NameToGameID(ScreenName))
End Sub

Public Overloads Shared Sub BringToFront(ByVal ScreenName As String)
BringToFront(NameToGameID(ScreenName))
End Sub

Public Overloads Shared Sub SendToBack(ByVal ScreenName As String)
SendToBack(NameToGameID(ScreenName))
End Sub

End Class

You'll see some funky oddities in there but it's not too scary.

Let's sum this situation up here before I get carpel tunnel:

Sprites are the building blocks - they contain the code to invoke the Matrix cascade and contain the code necessary to facilitate the creation of tree nodes.

Game Objects are reusable custom Sprite classes, typically with their own custom Update code and usually contain other child sprites to create small trees.

Screens are the building blocks of State management. They derive from Sprite but typically don't require a texture, per se. They mainly exist to act as parent nodes so that we can graft related Game Objects and Sprites together into a Game State context.

We use the Screen Manager to Register screens with the Component collection. We use the "Load" and "Unload" methods of the Screen Manager to basically set the DrawOrder, Enabled and Visible properties of Screens, which in turn causes the Component collection to change their order, start/stop Updating, or start/stop Drawing them.

Game State is defined by whatever the state of our Enabled/Visible properties are on the Screens in the component collection - when a game starts, it registers it's Screens through the Screen Manager and Loads the Main Menu Screen. The Game State simply remains on the Main Menu Screen until changed, leaving no real need to question Game State (we simply allow all Enabled/Visible components in the Game.Component collection to Update & Draw as per their Enabled/Visible properties).

Once you've got this in place and you make a game, add some screens with the screen manager and Load one, you essentially Update and Draw your game by calling MyBase.Update and MyBase.Draw from your game class. This will trigger the underlying XNA.Framework.Game to Draw & Update, which will cause it to process it's Components collection where your Screens live. In the end, you remove all Update and Draw calls to custom objects & screens from your game class and just let the underlying XNA Game process it's Components collection, using the Screen Manager to control which Screens in the collection end up getting Updated & Drawn.

My apologies for the verbosity, I guess it's a lot to cover. There's still more to come...

A forest for your trees

2008-01-14T13:28:00.000-08:00

Trees

The "parent/child" relationship afforded by the Sprite class can be thought of as an unordered tree structure:

In Star Maze, I've got a game object called PlayerShip. Like all game objects it inherits from Sprite:

Public Class PlayerShip
Inherits Sprite
'Update, Draw, etc.
End Class

Considering Sprites to be tree nodes, any class inheriting from Sprite (including PlayerShip) becomes a valid tree node and can be diagrammed as such:

It's not much to look at on it's own so let's use the AddChild method of the PlayerShip to attach a Turret sprite:

PlayerShip.AddChild(Turret)

The thrusters for the player's ship are separate game objects. Like the PlayerShip (and like all game objects we'll make with this engine), a Thruster is another game object derived from Sprite:

Public Class Thruster
Inherits Sprite
'Update, Draw, etc.
End Class

We'll add a couple afterburner sprites to the Thruster,

Thruster.AddChild(YellowAfterburner)
Thruster.AddChild(BlueAfterburner)

and here's the resultant tree diagram for the Thruster object:

Now we've got two different game objects, both of which inherit from Sprite: "Ship" and "Thruster". You can also interpret this as having two sprite trees: the PlayerShip tree and the Thruster tree:

So far in the tutorials we've been using the AddChild method to append simple "leaf" nodes to sprites, but we can also do something slightly more profound, and that is to graft one entire tree onto another:

PlayerShip.AddChild(Thruster)

By adding the root node of the Thruster tree as a child of PlayerShip, the entire Thruster tree is grafted to the PlayerShip.

Thinking about Sprites as tree nodes just gives us an alternate way to describe or illustrate the "parent/child" system Sprites employ.

Trees in a Forest

The "games" created in the tutorials thus far are simple programs meant to demonstrate classes like Sprite and VBContentManager (et al). None of the tutorials have put much thought into organizational techniques yet. A typical tutorial is structured like this:

Public Class MyGameTutorial
Inherits Game

Private GameObject1 As SpriteTree1
Private GameObject2 As SpriteTree2

'etc.

Protected Overrides Sub Update()

GameObject1.Update()
GameObject2.Update()

'etc.

End Sub

Protected Overrides Sub Draw()

GameObject1.Draw()
GameObject2.Draw()

'etc.

End Sub

End Sub

There may be some game object classes defined somewhere, but the general structure so far has been to create instances of game objects as private members of the Game class, and then simply Update & Draw them from within the Game's Update and Draw methods. Which is fine for a quick tutorials dealing with a limited number of sprites and game objects. But when we eventually get to the point where we're creating an actual game, we're going to end up with a lot more than just "a limited number of sprites & game objects". Our lack of organization will turn into a problem.

Consider a tiny, theoretical game with 1 player, 2 bad guys, and a high score. This game starts up on a "main menu" with various options (new game, continue, quit, graphic settings). You can assume game object types such as BadGuyShip and PlayerShip (etc) to be irrelevant, all that matters is they derived from Sprite and are therefore valid tree structures of some kind:

Here's all of our game objects, in tree view.

When this game runs and the update cycle comes around... which game objects do we update? High Score? BadGuy #2? The "Quit" menu item? We're now having to ask ourselves a new question: "Where am I?".

There's a few ways to answer this question; you could just define a string called WhereAmI and if WhereAmI = "MainMenu" then you update/draw main menu stuff, and if WhereAmI = "PlayingTheGame" you update/draw the game stuff. And that would work, but as you add new features and possible "places" you could potentially be in the program (main menu, the game, the inventory screen, the game over screen, any of those but paused, etc) it becomes apparent that there may be better approaches.

First of all, we need to get organized. We need a better method of organization for our game objects. Knowing where we are, ergo what to update & draw, will tie closely into our organizational strategy.

Ironically enough one path to organization can be found in adding more Sprites. Not just any Sprite though; a special game object which is a bit of a Sprite hack, to tell the truth. It's called a Screen:

Public MustInherit Class Screen
Inherits Sprite
Implements IGameComponent
Implements IDrawable
Implements IUpdateable

'etc

End Class

Screens are going to help us turn this:

Into this:

Once you're comfortable with the idea of Sprites as tree nodes, this is pretty simple; you define a MainMenu Screen and then just graft all your main menu game objects via MainMenu.AddChild(). A Screen is basically a container, a bucket into which we can toss game objects; it's the forest of our trees.

Now anything we do to the Screen node - position, rotation, scale - the matrix cascade is going to apply that to every single attached child as well. This is our secret weapon that will let us make fancy screen transitions without too much of a problem.

Ok this is just the beginning of what I want to get into with this, but it's taken me 2 days just to get this much done so I'm going to publish this and start working on part 2 - the Screen Manager, which is what we'll use to show / hide / order screens, we can even use it to show screens & dialogs "modal", continuing to update and draw our game but without loosing our place in code. And then, the great paradigm shift: Cameras, which may change all of it.