In the game I’m currently working on, it appears that I’m slowly drifting
towards a design that’s a close resemblance of the Model-View-Controller
(MVC) pattern, despite originally rejecting the idea because I
believed it would require my game world to expose too much of its
internal data just so the view could keep track of things.
Because I originally believed to be building a very simple game with very
simple logic, I chose a design that would create a nice, non-fractured
interface to the world so I would have an easier time building the AI
and player controls on top of it:
In this design, everything could access everything else – a monolithic
world component where the public interface was well encapsulated,
but that allowed the implementation to take the most direct path possible.
"Everything could access everything else" doesn’t mean my
objects directly modified each other’s state, but it meant, for example, that
a building had a reference to the island it was placed on and that it could
call an internal method in the Island class to inform it when
the building was destroyed or moved.
A full design, in contrast, would give the buildings an interface through which
they determined properties about the ground (is it too rough? underwater?) and
some events so its owner would know when the building was destroyed.
If I had only taken game logic into account, this all would have worked out
very well. But there were some things that added a lot of complexity…
I have updated my input library to a level where I think I can release it
into the Nuclex Framework now. The design was tailored to make
the input manager mockable (replaceable with a dummy object for
unit testing), but the effort of mocking the entire input manager (versus
just one input device) on an ad hoc basis was a bit too high (or too
unreadable when using a dynamic mock object library).
So the final revision has mocked input devices and a matching input
manager built in:
Developers following my twitter feed may already know that in
the past few days, I’ve been working on a new component for
the Nuclex Framework: Nuclex.Input. This component aims to
solve all problems I ever had with input devices in XNA 🙂
It’s a very simple library that provides input device classes
similar to the ones in XNA (Keyboard,
but instead of 4 game pads, there are 8 (with indexes 5-8 for
DirectInput-based controllers). All input devices
provide events (like KeyPressed and
CharacterEntered on the keyboard or
MouseWheelRotated on the mouse, for example).
Here’s a quick run down of the features:
Well-behaving keyboard text input
Honors keyboard layout and system locale
Supports XBox 360 chat pads
Very easy to use: just subscribe to an event
Support for standard PC game controllers
Works with any DirectInput-compatible controller
Mouse movement with sub-pixel accuracy(postponed)
Finally put those expensive high-dpi mice to use 😉
Allows event-based input handling
Fully type-safe: events instead of message objects
Only compares states if events have subscribers
Mouse and keyboard don’t have to compare states at all
Zero garbage: doesn’t feed the garbage collector
During usage, the library produces zero garbage
Curious? Click on “Read More” to view some code samples!
Last Friday (and I only now notice it was Friday the 13th :D) my screen stopped
working. I dismantled it and found some bad capacitors, then decided to do a small
foto story showing my attempt to get it working again:
My Screen went
Today the electronics components I ordered arrived and I could finally replace
those capacitors I found to be broken last time.
Soldering in the new capacitors was surprisingly easy. I remember that when I
did this in my childhood, I spread solder everywhere except where I wanted it to 😉
In the old design, an IInputReceiver was fed by one of
two classes: one was the XnaInputCapturer which relied
completely on XNA’s input device classes (Keyboard,
to track the status of any input devices, the other was the
WindowInputCapturer which intercepted incoming window
message for XNA’s main window to obtain the status of input devices:
This wasn’t even nearly an ideal solution because now I would have
to copy & paste the game pad polling code from the
XnaInputCapturer to the WindowInputCapturer
if I wanted game pad input on Windows. The new design should fix this,
but still follow the concept of routing all input through a single
interface (IInputReceiver) to allow users to easily
attach the GUI to their own input handling code.
Earlier this year, one of my monitors started behaving strangely
each time it was turned on the first time for the day. The image
would flicker on and off, first very slow, maybe twice a second,
then faster and faster still until it displayed a permanent and
Over time, things got worse. First it would take just a few seconds,
then two months later, the screen would stay black for minutes
before the now familiar flickering started and the display settled.
This morning, the display just remained black.
Some googling revealed the likely cause: bad capacitors. Between
1999 and 2007, many electronic parts were sold with bad capacitors
because, at least that’s a popular story, one Taiwanese company had
obtained the knowledge to build electrolytic capacitors via espionage,
but the informations were incomplete and the electrolyte was missing
and certain agent that prevented the hydrogen from escaping.
Whatever the reason, my TFT’s production date falls into the problematic
range and symptoms are similar to things other people reported. So I
went ahead and tried to take a look at the thing, documenting each step
with my camera.
XNA provides a neat little system for you to organize your
game’s different parts in: GameComponents.
You can use them to modularize your game’s subsystems,
eg. have a GuiComponent, PhysicsComponent,
SceneGraphComponent etc. so you avoid having all that
code in your Game class, or can use them for your actual
game objects in smaller games.
However, the GameComponent and
DrawableGameComponent classes provided
by XNA force you to reference the Game
class. This is unfortunate if you want to use those components
in a WinForms-based XNA application and gets in the way
when you try to write unit tests for your components because
now you have to create a dummy Game
instance as well (and better hope that component won’t
go shopping for references in the Game‘s
Components and Services
collections as well).
The first thing I did was, of course, to adapt SunBurn to Ninject, a very tidy
dependency injector that works on the XBox 360 and even on Windows Phone 7,
into the SunBurn example application. This article gives a short overview about
the overall structure and provides you with an example application if you want to
give Ninject a try yourself.
Whenever I needed a screenshot of some application for this website, I used
an image editor to cut out the window’s drop shadow, generated an alpha channel
from its luminance, added that as a layer behind the actual application window
and saved the entire thing again.
Today I wrote a small utility to automate this process for me: AeroCapture.
Pressing the “Print Screen” key will take a screenshot of the active window,
and save it as a .png in the My Pictures directory, retaining
the window’s drop shadow in the image’s alpha channel.
You can download it here:
[rokdownload menuitem=”17″ downloaditem=”42″ direct_download=”true”]AeroCapture.7z[/rokdownload]
(C# source code included)
This got me thinking. Somehow, whenever I have the choice between…
spending 2 minutes doing a repetitive task that I’ve done a few dozen times
before already (like fixing up the screenshot for my website)
or spending 4 hours to automate the task
…I always choose the 2 minutes approach. I can continue working on what I was
planning to do and I don’t have as many utilities to maintain.
I’m very excited about .NET 4.0 because this is the first standalone
release of .NET since 2.0 came out, meaning that it doesn’t bundle
any of the older runtimes. As you may know, .NET 3.5 is actually just
.NET 2.0 with some more assemblies – all the magic required for
LINQ, extension methods and lambda expressions happens in the
The new Visual Studio UI also looks very nice and the darker
background puts the actual work (the code) into focus. But there
have been some changes like the apparent removal of the
Debug/Release combo in the toolbar and the ability to add your own
External Tools to the Tools menu in the Express Editions (don’t
worry, both are still there, I explain how to enable them a bit down
in this article).
So I decided to write a small heads-up on why I think Visual Studio
2010 and .NET 4.0 are cool and how to get back your favorite options
if you’re already used to the Visual Studio 2008 Express Editions.