Today I looked at the HTML5 Boilerplate and KnockoutJS.

• HTML5 Boilerplate is an application framework, meaning it’s a bare-bones way of structuring the way your HTML5 app loads resources and starts up. The alternative is to come up with your own organization.

• KnockoutJS is a pure Javascript library that implements a “Model – View – ViewModel” pattern in a clean, declarative way. I don’t yet know exactly what the ramifications are, but there’s an awesome interactive tutorial that walks you through it.

Exploring these two environments today gave me additional insight into Javascript Weirdness related to its super-flexible object-oriented underpinnings. Basically everything is an object, even the ones that look like they might be functions or expressions. Writing Javascript is like living on the frontier, where STREET JUSTICE prevails over centralized language specification. There are no police. It’s up to you to enforce good programming habits, because Javascript doesn’t have any built-in to save you from shooting yourself in the foot.

As a result, you need to explore the Javascript community for a bit to understand what the law of the land is. Here’s some of the ones that I collected yesterday:

Functions and Parenthesis

The jQuery library is used everywhere, as it is one of those libraries that makes cross-browser DOM manipulation more “write-once” than “hope and pray it works in every browser”, which was the reason I avoided Javascript for so many years. To start executing your code that uses jQuery, though, you need to make sure it’s loaded. Since browsers load resources asynchronously, and also have slightly different ways they do it, jQuery itself provides a means to call your important startup function: $(document).ready(). The ready() call takes a function as an argument, which is executed when it’s time to run.

Unfortunately, in the non-trivial code examples, the ready() sometimes looks like this:

(function($) { 
    $(function() {
        // code using $ as alias to jQuery
    });
})(jQuery);

Note the enclosing parenthesis. WHAT IS THIS? The short answer is that it converts the function() definition into an object expression which is then executed immediately, with the jQuery object passed to it as a parameter. WHY IN THE WORLD would you want to do something as convoluted as this? It’s to make the variables in your code private through the implicit creation of a Javascript “Closure”, which is the variable scope/state within a function. Since scripts in a browser all run in the same global namespace, they can overwrite each other. The code here creates an anonymous function, which in turn has its own closure with the $ variable assigned to the jQuery object. Everything inside has its own private space to declare whatever variables it wishes. Furthermore, the variable state exists after the code finishes running (another aspect of closures which is a bit different from other compiled languages), so you can safely assign event handler functions that refer to variables inside; they remain persistent.

The enclosing parenthesis is not necessary, but is added so you can tell right away that this is the case. Technically, Javascript will do the closure thing because of the (jQuery) tacked on the end, but it is unclear that it’s not a function definition until the very end. Adding the explicit () around it turns it into an explicit EXPRESSION instead of a function declaration; this is pure coding style because the () at the end also turns the function declaration syntax into an expression, but you see it all the way at the end and then you’re like, “damn, this isn’t a definition that’s called, it’s something that runs right now”.

You also see stuff like:

!function($) { 
    $(function() {
        // code using $ as alias to jQuery
    });
}(jQuery);

I KNOW…WHAT? The ! is the unary negation operator, and it has the side effect of telling Javascript that an expression follows it. This is the same effect as using (), which is the arithmetic precedence operator. Both, being operators, turn the function into an expression, which is OK because expressions can be executed when a () is after them to turn it into a function invocation. That executes immediately. You could also use + or – as well and get the same effects…it’s purely for code readability.

It seems stupid, but it’s necessary to establish a private namespace (via closures) so you can write code without side effects like name collisions. Other languages have explicit ways of establishing a namespace, but Javascript does not.

Well, there is stuff like this:

var myNameSpace = myNameSpace || {}
myNameSpace.myProperty = 1;
myNameSpace.myFunction = function(x) {};

This creates an object with objects assigned on-the-fly. Although since I used var, it’s local to the closure that the namespace is declared in. If I didn’t use var, I think that means it would be in the global namespace. Argh.

Anyway, that is enough of this for the day. Here’s the links that helped me understand this:

• http://michaux.ca/articles/an-important-pair-of-parens
• http://blog.themeforest.net/tutorials/ask-jw-decoding-self-invoking-anonymous-functions/
• http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth

Yesterday I’d started to gather materials on HTML5 online before remembering that I had a book. I septn a little bit of time before going to sleep skimming the HTML5 and Javascript references I have, and came to the conclusion that HTML5 itself is just a bunch of new features. The ones I’m interested in are the Canvas, Sound, and Event models.

I need a very basic app to get focused. It might be instructive to write a simple GUI that gets something done. That would familiarize myself with a few things

1. Basic HTML5 Layout of Elements
2. Using jQuery to bind events to the Elements
3. Writing some Javascript core code to send events and data requests to my own server using JSON or something

I think I’d like to make a basic two-column text editor. This is something that’s been on my mind for a while.

I’m kind of tired, so I think I’ll do the setup of a framework later today or tomorrow. My testbed will be the davidseah.net server, where my other experiments live.

Here’s what the HTML5 page needs:

• HTML5 markup!
• A place to LOAD script libraries!
• A way to detect no javascript and gracefully degrade
• A way to debug!

That’s a good enough starting list.

I’m starting an HTML5 crash course for myself. I’m applying the 15 minute ritual to this. This is the first 15 minutes.

What I know about HTML5 is this:

• There are a bunch of new semantic elements, like <section>. I’ve read that this should be ignored because they’re really not the point.
• More interestingly, there is a refined DOM and new Javascript features related to new objects like <canvas> and <audio>.

To get my head wrapped around HTML5, I need to do the following:

• Find a good reference for HTML5 features, in a nutshell. I know I’ve seen them.
• Consolidate my Javascript knowledge and workflow for editing and debugging.
• Set up a development environment where I can play and keep track of samples, maybe in a VM
• Maybe pick a framework to start with?
• Or a project to build?

There are some issues with HTML5 that prevent adoption by a broader base of users, I suspect.

Getting Familiar

• HTML5 Rocks – some kind of aggregator
• HTML5 Test – for browser compliance, rated.
• HTML5 Demos – a questionable demo site…have to review
• Smashing Magazine HTML5 tags – worth browsing?
• html5.org – might be useful?

These references, so far, kind of really don’t give me a starting place. Let’s look for Javascript HTML5 next. Oh, I forgot I had this book:

• HTML5 Up and Running – by Mark Pilgrim. My cousin Ben recommended this to me.

Development

• HTML5 Shiv – some kind of IE9 enabling script
• CreativeJS – neat javascript examples.
• CraftyJS – some kind of framework, it looks like.
• Maintainable Javascript – by Nicholas C. Zakas, also recommended by Ben.

OOOPS, out of time!

Post Notes

• Dive Into HTML5 – Apparently this is the source for the HTML5 book, maintained by the community.
• Ben mentioned “Phonegap, HTML5 Boilerplate, jQuery Mobile”. What are those? Hm.
• HTML Boiler Plate – Ben said this was worth looking into.
• The question: Do I want to make HTML5 my new interactive platform for development? That’s what I’m trying to find out.
• Can I alternatively just have other people do my interactive work? My thoughts: no. I want control over this so I can wield it as an expressive medium for demonstrating my ideas. It would take a pretty exceptional developer to meet my needs. Perhaps if I could afford to pay someone, it’s worthwhile.

Anyway, there’s always a little bit of magic involved in setting up a new “Hello World” style program. As is the norm, the official “Getting Started” material that I could find is simplistic to the point of uselessness…who writes these things? I don’t want to print “hello world”; I want to set up the basis of a rich flourishing application. Here’s the basic steps I followed with Flash Professional CS 5.5.

1. Create a New Project

Switched to the “Developer” Workspace Layout, which exposes the Project Panel. Created a new project, which creates a Flash .FLA stub file. We’ll be setting properties here later.

On a side note, the Project Manager is as terrible as I remember it from 2007, but at least it is just a mirror of an underlying directory structure. Nothing fancy here!

2. Create the Startup Class

The Flash file will end up holding any static library assets I create such as animations and graphics, but I will be using code attached to instances I create dynamically with my own scripting. Rather than stuff this all in Frame 1 of the timeline, there’s a way of binding a particular class to the Flash file. This is a class that is instantiated on startup. It’s known officially as the document class, and you set it under Properties for the .FLA file.

Class files in Actionscript 3 have the .as extension, and the filename must match the class name. There is also the notion of packages. I created a package path of dseah, which is implemented as a folder relative to the .FLA file.

project_folder/
    dseah/
        MainClass.as
    DaveTest01.fla
    DaveTest01.swf

My DaveTest01.fla file is at the same level as the dseah folder. Inside this folder I created MainClass.as, which is declared as follows:

package dseah { 
    
    import flash.display.MovieClip; 

    public class MainClass extends MovieClip { 
        public function MainClass() { 
            trace ('Hello World'); 
        }
    } 
}

Two Important Notes:

• See how MainClass extends MovieClip? That’s because the class we’re setting as the document class is a representation of the .FLA file, which is a MovieClip.
• When we go to properties to set the document class, we also have to use the entire package path, which here is dseah.MainClass.

3.0 Compile and Test!

I clicked the “Test Project” button and did see that the trace worked, outputing “Hello World” to the console. Whee! So that’s it. Took me 90 minutes to dig up these basic setup facts while I was at Starbucks. I suppose that if I’d had a copy of Colin Moock’s Actionscript 3: The Complete Reference I would have saved myself some time. Grumble grumble.

…

There were a few bugs leftover from the last attempt. I needed to specify the data directory, get rid of some overzealous try/catch exceptions which masked some important errors, and also add a specific enclosing XML tag in the data files. Updated the GameData.XML reader routines in BaseGameData, as well. Its XML reading is set up differently that in SettingsManager, which bugs me a bit, but I’m going to leave it alone.

And that about does it for the XML reading. I now have the following capabilities:

• Read key/value pairs from an XML file for common settings
• Read Game setup data from an XML file

Next up: Exporting a textured 3D model from Modo, Importing into XNA, Refactoring the View and Camera Classes.

Anyway, what’s in the current codebase is this:

• A startup sequence that works within the confines of XNA’s notion of a Game Loop + Initialiation.
• A pretty well-defined procedure for handling the creation of my own main game objects of various type and vintage within the context of the XNA Game Loop + Initialization.
• A rudimentary Debugger and Console, though I haven’t rewritten the command stuff yet
• An Input Manager
• A Settings Manager
• A package hierarchy
• A Mercurial repository and central Bitbucket.org repository
• A rudimentary event listener structure and inter-object communication setup for main game objects
• Graphics Initialization and Debug messages written to the console

What was most important to me was to get the procedures, settings, and debugger setup so I could start building the rest and have some way to debug it. There are a lot of different things I could implement next, and I’d love to just dive write in and port the graphics routines. However, this routines are already written; what I should work on first is a new object creation language.

Currently, game engine 1.0 uses XML files to define everything that appears in the game at the Piece, Visual, and Player level. However, all this does is declare and name pieces and their associations visuals, along with players and their associated pieces. Also, the XML definition is a bit cumbersome, requiring multiple definitions to set up even a simple test. What I’d like for it to do is be a lot less redundant, and scale from very simple declarations of a handful of pieces in a space to complex hierarchies with behaviors attached to them. This GameXML language should be strive to minimally describe any game startup sequence. Each GameXML file also should serve as the defining datastructure for any level, presuming there are multiple levels in the game.

I’m thinking of something like this:

• [piece name="uniquePieceName" [attributes]] is the way to declare any piece. This automatically adds the piece to a global piece dictionary if the name doesn’t exist, or updates its attributes if it already does. If the name attribute doesn’t exist, the piece is created with a unique name.

• If the piece declaration occurs inside a [player] declaration, then the piece is created as described above AND it is added to the player’s piece array.

• A piece can appear in multiple contexts like [player] and possibly other groups that are of interest to the game.

Pieces have the following attributes:

• name = unique identifier of this piece
• template = a piece name to copy attributes from

Initialization that may execute a script somewhere to complete the initialization as well as tagging the pieces with this role

• type = type of piece, as defined in the game
• visual = the type of visual to associate with this piece
• role = logical role(s), comma separated
• tag = logical tag(s), comma separated
• behavior = an AI behavior
• init = an initializing script to use to initialize any other parameters

3D world representations

• position = vector3 coordinate of where this piece exists in space
• scale = the size of the piece, defaults to unit 1 meter
• direction = vector3 pointing
• speed, maxspeed = how fast this can go up to maximum
• turn, maxturn = how many degrees per second this object is allowed to turn

So, the next step would be to write the parser that reads this information and calls a myriad of functions and factories to set all this stuff up. Not the most fun, but it will make creation much easier. After that, we’ll port the visual classes to verify that it’s working correctly. Then, we can port the physics engine and AI behaviors. Then, we can write game logic for the referee classes.

…

AFTER SLEEPING ON IT

The very minimal piece would be to do the piece reading, and maybe read player and visual data structures. So let me start by porting the GameScreen.Prologue() routines XML reader, and see what I can do to encapsulate it.

Where to put this routine? GameScreen.Prologue() is executed as soon as the screen is created and pushed on the stack, which is handled in the LoadContent() part of the call. So that’s where I’m going to put it in the new architecture, except we don’t have a GameScreen to hold this data. So where does this live now?

For now, I think it makes sense to store this information in BaseGame somewhere. Creating a BaseGame Data.cs partial class and a Game.XML file. I also need to create a rudimentary piece class now.

PORTING

BaseGame Data has a new InitalizeDataStructures() and LoadDataStructures() methods that are called from the corresponding BaseGame.Initalize() and BaseGame.LoadContent() master entry points.

The piece-building logic is built around XmlReader, and there’s the option of having a validating reader that using an XmlSchema. I’m going to disable this for now. Related to this, though, is a class called StringUtility that converts the strings in the XML file. The current implementation uses default values in case the attribute being read doesn’t exist. This makes the code not only harder to read, but it also will mask problems with the game initialization XML file. I’m going to remove this feature.

First thing first…setting up!

1. Installed Mountain Lion, Clean, on my MacBook Pro 17″ from late 2007. It’s old, but it works.

2. Installed Xcode via the App Store.

3. Installed GitHub for Mac.

4. Downloaded the project from Github.

5. Tried to open the project file and run it. BOOM. Missing header files. I wondered if I had to install the TestFlight SDK, so I emailed Al.

6. He emailed back that he was using CocoaPods, which is a “library dependency manager” for Objective-C. You can specify the library you want to use, and CocoaPods takes care of grabbing everything that this library needs to work properly so you don’t have to do it manually. It relies on something called /ruby, which is a package manager for programs written in the ruby language, which I needed to install.

After some farting around, I found I had to go to XCode’s Preferences and under Components select “Install Command Line Components” so I could run the sudo gem install cocoapods command (gem was already installed as part of the dev tools, I believe), followed by pod setup. I also had to run sudo gem update --system to get the most up-to-date version of whatever gem is.

After that, I went to the directory where I downloaded Al’s source, and typed pod install per Al’s instructions. It started doing this:

    Installing Objection (0.13.0)
    Installing TestFlightSDK (1.0
    Installing OCMock (2.0.1)
    Using Objection (0.13.0)
    Using TestFlightSDK (1.0)
    Generating support files

Al then said to look at the “workspace file” that has been created, which I’m guessing is the file that ends with .xcworkspace. I double-clicked it to see what would happen. I was able to build the project and run it in a simulator. Very exciting!

I poked around the file explorer in xcode, and was reminded of just how old-school Objective-C is compared to C#. I’ll have to read up a bit on this.

ROUGH NOTE CAPTURE MODE

Ok, I have a ScreenDisplayList and that maintains a list of things for it to draw. Subclassers of the base Screen class can use that to handle the Load(), Unload(), and Paint() virtual methods to handle a display list. However, for our console screen, I think it will work a bit different and hold lines of text.

I just realized that the DisplayList class I made is really just a List. DUH.

DELEGATES?

Anyway, let’s grab the old DebugManager implementation for the console. It has a HandleKey to manage the text structures. We need to register DebugManager for Key events. Do I need to use a delegate? What’s the way to do this in C#? A delegate is a TYPE that can hold a reference to any function that matches its signature.

public **delegate** *function signature*

where an example would look like this:

public delegate int MyDelegateFunction(int x, int y);

In this case, MyDelegateFunction is the delegate’s name. I’d declare it like this:

MyDelegateFunction myFunction;

and I can assign it to any other function declaration that matches the original declaration’s function signature. So if I had a pair of functions like this…

public static int PlotPoint (int x, int y) { blah blah blah } public static int PlotPoint2 (intx, int y) { more blah blah }

…I could do something like this, if I’m understanding this right.

MyDelegateFunction myFunction;
myFunction = PlotPoint;
myFunction(1,2);
myFunction = PlotPoint2;
myFunction(1,2);

You can pass a delegate as an object! So you can use it for asynchronous callbacks to handle events. A delegate object can also hold MULTIPLE methods to invoke. You can also assign a Delegate object a method within an object instance, and that works too. Pretty swanky. It’s described here.

So what do I know now that helps me write my thing? I need to add some delegates support to the InputManager class. However, if there are multiple listeners, I need to check the return value of EACH listener, and abort if the key event is handled. After doing some digging, I used the Delegate.GetInvocationList() and just called them one after the other. This seems to be what you’re supposed to do.

So now, the DebugManager needs to hook itself up to the InputManager and do some wiring in BaseGameINIT and BaseGameRun. Now using Console.WriteLine() to see if I’m capturing anything…cool! It works!

• There’s some interesting stuff here with Asynchronous callbacks…hmm. Any delegate type has a method called BeginInvoke added, which takes your parameters PLUS an AsyncCallback delegate and an object that “passes information into the callback method. It’s of type IASyncResult, and has some data in it (and probably other interesting things). More of this is described on the Calling Synchronous Methods Asynchronously page.

• On a side note, you can also create a delegate by calling new() on the type, initializing it with an existing function or method.

  delegate void MyDelegateType ( int index ); MyDelagateType delegate = new MyDelegateType( someobject.somefunction ); delegate ( 10 );

Mysterious and cool! I’m capturing text. Now I need to DRAW it.

PRINTING OUTPUT TO OUR OWN CONSOLE

Another source of text in our DebugConsole window will be a regular DebugManager. I just looked at the built-in System.Diagnostics.Debug and Trace classes, which seem to do a lot of the same thing. However, I’m not seeing a way to actually redirect the output back into our system so I can write it to the screen as an overlay.

I’ll sleep on this a bit and tackle it again tomorrow. I might as well just port the old code and use that, as it does work.

AND WE’RE BACK

Each type of Screen (ConsoleScreen, for example) is designed to integrate with a certain kind of visual data. They are what keep track of all the visual-related classes that draw things. I’m thinking that a GameScreen probably maintains the list of Visuals as associated with Pieces, and Pieces no longer maintain them. Each Screen-derived subclass would be initialized with a list of pieces it was interested in, and it would then create the visuals that go with each of those pieces. The pieces may have hints as to its appearance, name, and other unique qualities.

A slight detour: The GameXML file that defines all the elements of a working game will be split into multiple files. Pieces can be defined within various context like Player, etc. They have at minimum a unique Name. If a piece is declared for the first time, it is added to the global piece list, and also added to whatever context (e.g. Player)’s list.

Screens also declare what pieces it is interested in, though it can refer to any containing context (e.g. Player) also to read in all the pieces as needed.

Handling RenderPasses: A Screen may have several renderpasses. I’m not very clear on the architecture of HLSL shaders and renderpasses, so for now I’m going to just assume every screen has one renderpass, during which all visuals are drawn.

Ok, let’s get back to consolescreen…

BaseGame.Draw() is where the magic would be happening. It needs to tell the ScreenManager to draw. Let’s let’s add that.

… hours pass …

Ok, I have implemented the following:

• Diagrammed the correct startup sequence for the XNA Game Class. Initialize() is followed by LoadContent() which is then followed by Update() and Draw() in a loop, until the game quits.

• In Initialize(), called the constructors of all “main game objects”, which create local data structures only.

• After all main game objects are constructed, each of them gets their Initialize() function called.
• After all main game objects are Initialized(), they are allowed to MakeConnections() with other game objects

Then, XNA Game called LoadContent(), which is when other major game objects get their LoadContent() called as well.

This is a bit messy and confusing, so let me think about this a bit:

• What is a Main Game Object (MGO)? Generally, they’re singletons that perform some function, and there’s only one of them. They’re usually a manager class of some kind.

• There are different categories of MGO. Some are System-level, like GraphicsDeviceManager, ContentManager, which are responsible for implementing the XNA subsystem and loading content that it can use. Related are MGOs like a SoundManager and InputManager. Let’s call these the HARDWARE LEVEL MGOs that encapsulate what the hardware and operating system can provide in a game-friendly package.

• There are some high level MGOs that aren’t related to hardware/OS, such as DebugManager and SettingsManager. They are foundational and are used by everyone else.

• The other MGOs implement systems that are used for the game portion. ScreenManager manages Screens, which uses the A/V MGOs to draw graphics. PhysicsManager imposes physics on pieces in the game. Players also manage pieces. Referee monitors the state of the game.

• Game Loaders, Persistent Storage, Level Loading and State Preservation are high-level MGOs that manipulate the state of the game-related MGOs above.

There’s some fishiness with the way I’m creating the ConsoleScreen. Currently, DebugManager is the data holder, and it maintains a “DebugBuffer” class with all the string tables and offsets that it needs to keep track of. It’s a class because they can be passed by reference to ConsoleScreen, which keeps its own reference to that datastructure so it can draw from it.

ConsoleScreen is created by a call to ScreenManager by DebugManager sometimes after DebugManager is fully initialized. This means:

• all MGOs constructed!
• All MGOs initialized!
• All MGOs have loaded content

At this point, any MGO can request information from any other MGO and be confident that it’s ready. Right now, that is handled in the Start() method, which is called at the very end of BaseGame.LoadContent()

And that closes out this phase of development. We have a clean, ready-to-use base that can print text to the screen.

SO FAR:

I’ve ported some really basic stuff, refactoring along the way:

• BaseGame.cs split into partial classes BaseGame Init.cs and BaseGame Run.cs
• Singleton Pattern, made less twiddly to use, the basis for all Manager classes
• SettingsManager.cs, cleaned up

I’m now at the point that I want to port over something that actually draws on the screen. This is a complex subject, because we need to have a system for drawing, with a well-defined order of operations coordinated between multiple system objects.

THE OLD SYSTEM

Just about every modern video game uses multiple framebuffers, showing a completed frame while drawing on a hidden one before switching. Drawing a frame usually consists of multiple drawing passes, such as a 3D view with a 2D user interface superimposed on top of it. The drawing process itself may require multiple passes as well for special effects.

In our old game, we had the notion of “Screens” managed by a “ScreenManager”. Screens shared a common subclass that defined typical game loop behaviors, namely:

• Update() – processing time to do calculations
• Paint() – the command to draw to the current framebuffer
• HandleButtons() – event handling for gamepad button presses
• HandleKey() – event handling for key presses
• HandleRepeatedKey() – event handling for repeating key presses
• Prologue() – pre-run initialization of data structures
• Epilogue() – post-run cleanup and release of data structures

There were three types of Screens defined: GameScreen, GUIScreen, and DebugScreen. ScreenManager managed them as a stack, drawn in the order listed.

What I didn’t like about this arrangement is that GameScreen is essentially the game program. It’s buried in the class hierarchy under Classes/Layout/GameScreen. I would never have thought to look there for game initialization and running, expecting it to be more top-level in the hierarchy. The second issue I had was that a Screen seems more like a display device to me, not something that would even have high-level logic in it. I can accept the notion of a Screen being smart enough to draw a display list, but I don’t like it having player AI and level logic stored in it. I’d prefer that to be somewhere else.

The other main screen is DebugScreen, which is what draws the debug console. It works in concert with the DebugManager, which is what keeps track of all the debug messages and processes commands. DebugScreen knows how to display that data using drawing commands, which I have no problem with. It is a cleaner separation between display code and data management. GUIScreen is a hacky screen that draws between GameScreen and DebugScreen, and was used for display giant bitmaps as signage when no one was playing the game in the museum space. It’s used by WorldPlayer, which is what implements the game logic through its various stages. This is a little screwed up too, so I’d want to clean it up.

THE NEW SYSTEM

I’m moving the game logic out of GameScreen. Screens and the ScreenManager will be implemented differently, as sets of display lists that are bound with data from other system players and objects. Instead of having game-functional names, they will have be organized by displaytype. For example:

• ThreeDeeScreen – draws a 3D world from its displaylist consisting of Visuals
• ConsoleScreen – draws 2D text from its displaylist consisting of lines of text and other properties
• SpriteScreen – draws 2D sprites from a displaylist consisting of sprite elements

The ScreenManager will maintain a stack of these screens, and will also be called directly by the Game Loop. ScreenManager will know how to construct its screen stack based on XML files. Screens can be active or not, toggled by external controllers.

To handle actual text input, there’s a new class called InputManager that consolidates the gamepad button and keyboard state into one place. It’s called once during Game Loop so that all interested subscribers can receive notification. The DebugManager will be one of these, as will any Players that may need control input. There are some additional complexities that may be added, but for now we can just implement this pretty simply.

I’ve just written InputManager, and at a minimum I need to rewrite the Screen and ScreenManager so I can write ConsoleScreen. While the ScreenManager will eventually be initialized from a config file, for now I can just hard-code the creation chain.

SCREEN CLASS

Has notions of visibility, event consumption, viewport, and name. Virtual methods are Load(), Unload(), and Paint().

A Screen needs to have a source of data to draw, the “display list”. Should the base class have the notion of a DisplayList bound to it at creation time? Maybe something like ScreenDisplayList, ScreenDisplayList generics. ScreenDisplayLists would accept an ADD command. The subclassers of Screen are responsible for implementing storage of a ScreenDisplayList.

This might be overly fancy for what I need, but we’ll see how it goes.

Intentions

The name of our Visual Studio 2005 project, started in 2009, was “BaseSystem” out of no other reason than it was the base. I’ve named the new version BaseSystem2.

The strategy will be to port function from the old into the new, cleaning up along the way. There are some basic 2D graphic routines I want to port just so we can write text on the screen and support our console functions. Then, I would like to add some basic 2D GUI functions that make more sense than the old widgets. Toward the end of the project, we came up with better ways to organize 2D screen content on top of the 3D.

There is also a matter of just revisiting the game initialization and setting of XML-based runtime parameters. There’s plenty to do. I’ll document this step-by-step, and clean it up later.

Create the Project

I installed Visual Studio 2010 Professional, and then XNA Game Studio 4.0 Refresh on it. Created a new C# Windows Game solution called BaseSystem2. This created a few default program files:

• Program.cs
• Game1.cs

I also opened BaseSystem under Visual Studio 2005, and did a side-by-side comparison of Program.cs. This is the stub program that contains the Main() entry point in the Program class. It’s a static entry point, and I think all C# programs start like this.

The only thing it really does is create a new Game instance, and then calls its Run() method. This is where all the XNA magic happens, so that should be far more interesting.

Comparing this to the BaseSystem (hereafter referred to OldBase), there’s some additional things we’ve crammed in here that I’d forgotten about. There is a global exception handler adopted from doogal.co.uk. This writes our error logs to disk for us. It’s part of our Utility classes. I think we can create a place for it in a Debugger namespace. I might as well move that code now.

Ooops, have to download the OldBase code, so I can copy it to NewBase. Ugh, I don’t like the way that VisualStudio named the various components…too many folder named BaseSystem2! I renamed the files and directories, then edited the .sln and .prj files to refer to the new directories after double-clicking the .sln file showed that there were reference errors. Double-clicking the solution file didn’t open Visual Studio 2010 the first time, though, after making this edit. Somehow the “default program” was set to use “Visual Studio 2010 Version Selector”, which didn’t do anything, as a result of that error. I just reset it to use VS2010.

Ok, now I can copy/paste some classes in! Creating “Debug.Logger” for these logger classes. I first tried to “add existing item”, but this didn’t create the folder hierarchy. I had to create the folder structure first, then add the files to that folder. I guess that’s OK…the folder hierarchy in the Solution view doesn’t have to match the disk layout. That’s probably more flexible.

I probably have to rewrite the namespace declarations for these files too. I’m also noting that TextFileLogger and LoggerImplementation can’t see the System.Windows.Forms package. VS2010 suggests I’m missing a reference. Let me see what references are here in the Solution Explorer:

• Microsoft.XNA.Framework.*
• mscorlib
• System
• System.Core
• System.Net
• System.Xml
• System.Xml.Linq

It’ll be interesting to look through this later and see what’s in those references. A reference is how one links to a library, I guess, in Visual Studio 2010. I wonder how they are implemented or exist as files? Looking at the properties for the “System” reference:

• It’s an “Assembly”
• C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\Profile\Client\System.dll

A C# program maybe isn’t statically linked as in the old days. Perhaps this library is a hardcoded path and the system loads it on demand. Will have to read up on that. ANYWAY, let me see if there are difference references in OldBase:

• FarseerPhysics
• Microsoft.XNA.Framework.*
• mscorlib
• Softimage.XWImporter
• System
• System.Data
• System.Web
• System.Core
• System.Net
• System.Web
• System.Windows.Forms
• System.Xml
• System.Xml.Linq
• XSIXNARuntime

So there are some differences. Three of these are game-specific (Farseer, Softimage, XSIXNA). The others might be new to Net 4.0 or renamed. I see I have to add System.Windows.Forms here. But how? Let me try right-clicking.

Add Reference -> .NET -> System.Windows.Forms…. that was easy. Let’s see if the errors have gone away in the loggers…yup.

At this point, we should be able to build…oops a few missing references. A function called HttpUtility.UrlEncode() doesn’t exist. Doing a google, I find it’s part of System.Web. I add that reference…but wait, System.Web isn’t listed. STUCK! A quick google, and apparently System.Web is part of the .NET 4 framework, but Visual Studio defaults to something called the .NET CLIENT PROFILE, which is a subset of the complete .NET framework. The idea is that it’s smaller, and therfore deploys smaller. Changing the “Target Framework” can be done by going to the project properties (Project Menu) and selecting the Application tab. I changed it from “.NET 4 Client Profile” to “NET Profile”. Now I see a lot more System.Web references available, including the one I want. Success!

The two remaining errors refer to missing stuff from OldBase. One is a reference to BaseGame, which is called Game1 in NewBase. I need to move this, actually, into my namespace hierarchy and clean it up:

• My ‘Engine’ solution has a classes folder, which might not be good practice. I probably should just let the folders live outside of this.
• However, there are other folders in this same level, the bin and obj folders. I’m going to rename them to _bin and _obj so they sort toward the top by modifying project’s Build properties…however, i don’t see a place to set the obj output. Hm. Google shows that you can add two properties to change this by editing the .csproj file. I did this, and it works.
• I’m just trying to make a clean directory here…sigh. I’ve made a directory manually called _src, and will try adding an existing item. Argh, this is annoying. The folder hierarchy in the solution explorer is what matters, apparently.

Oh well. I reverted all those changes and will live with “source” being in my namespace. It seems retarded…I must be missing something. I supposed I could manually rename all the namespaces as I create new files, but I would rather not.

…

I’ve added the stuff in, and commented it. I added a Singleton class based on Bretton’s original, except I added an “S” accessor variable in addition to the verbose “GetSingleton()” call. Also documented some of the interesting features he’s using with the Generic class.

So what do I have now? The beginnings of BaseSystem with a skeleton outline.