ILoggable

State-aware programming in C#, part I

State as language syntax

While fun, that project didn't get very far, but I still keep coming back to first-class stateful programming from time to time. Now that XNA is out seems like the perfect time to revisit this, because writing your game logic in .NET would almost certainly benefit from the approach of UnrealScript.

There are three paths of approach to this problem that I think are all viable:

Implement an UnrealScript compiler for .NET

This would be a cool project and could be something to try to get Epic to pick up and have them embedd .NET/mono into Unreal. It would provides their clients with more programatic flexibility (i.e. more languages), a richer framework and might even add a good bit of performance (not sure how optimized the UnrealScript VM is by now). It's basically what SecondLife is up to.. Of course LSL was always a scripting language, and UnrealScript has been a bytecode compiled language from the start, so the comparison might be flawed.

Create a C# derivative that implements new state keywords

This is my fav, just because I prefer to have the C# as my foundation. While UnrealScript is probably one of the nicest game scripting languages for gaming, its syntax is still a bit strange to me at times -- like state() vs. state keywords and the lack of static methods. But it would be a major undertaking, so it's likely to be the ultimate, not initial, approach.

See what can be done in C# to create a stateful object framework

This is the path I've chosen for now, because it let me prototype the whole thing in a day, which is always nice. If that turns out to be useful, the prior approach can always be adopted from this work.

Design of a stateful C# framework

So what are my design goals for this stateful C# framework?

Different logic paths per state on state aware methods

Really the definition of state aware objects. If the state of my Bot is Idle a different code path for Hit() should be called than if the Bot was in state Attacking.

State specific methods should be inherited

Extend regular inheritance to per state logic path inheritance. I.e. a subclass should be able to override the existing default and state specific methods, as well as create state specific methods, where the base class was just using the default.

Default and state specific methods

A method that is declared as state aware should always have a default implementation, so that identical behaviors don't all create duplicate code or simple stubs that just point to common implementations.

Type-safe states

I always prefer strongly-type definitions, so enum's seem like the ideal way to express states. The biggest drawback is lack of inheritance in enums. If we used one enum for all states of all objects the state names would quickly become meaningless. So the design must allow for per class enumeration of states and the framework should not have a preconceived idea of the possible states.

Serializable state-aware objects

If our objects store state, we should be able to fully serialize them, including their state, so we can take a snapshot of our action at any point in time.

See State-aware programming in C#, part II for the syntax that implements this design.

posted by ether @ 6:44 PM 0 comments  

Not your iPhone's Multi-touch

And I guess the best thing is that this tech is going to hit the market, considering that half the interactions of the iPhone appear to be based on this research. Curious whether Han helped Apple or Apple engineers were inspired at TED. The article mentions PIXAR as an interested party, but not Apple. I do have to give Apple the nod for idea of taking multitouch to the phone. Seeing the multitouch video, I never even considered going to a smaller screen (and neither has Han if the new video is any indication). But it's perfect for the small screen, since that input device of all is the one that needs to be more flexible to what people want to do, and anticipate their input, since there isn't all that much room to get interaction from.

Any way you look at it, I wish Han's company Perceptive Pixel all the luch and funding to make multitouch the way we interact with computers in the future.

posted by ether @ 11:04 PM 0 comments  

Visible != You can see it

Simple example: You have a Control A in a panel and that panel is half off-screen (or at least half across the edge of its container. And A is in the part of the panel that's obscured. A is going to be Visible, even though its not visible.

The interesting thing is that the paint cycle knows this, and OnPaint won't be called on the Control. Now wouldn't it be nice if there was a property that told you that your Visible control won't be drawn? If there is a simple way to determine this, I haven't found it (especially not on .NETCF 1.0).

The way I do it now is that i use RectangleToScreen on the Control and then recursively walk up the parents, get their screen rectangle and call IntersectsWith on the control's Rectangle and each Parent. As soon as i find one that doesn't intersect, I know the Control is not going to be drawn.

posted by ether @ 12:37 PM 0 comments  

It's always the Invoke

Of course the Invoke facilities of .NETCF 1.0 are pitiful, lacking the things that make this whole single-threaded UI business bearable in regular Windows.Forms. There is not InvokeRequired for one thing, nor is there BeginInvoke. And even Invoke just provides the Invoke(Delegate) signature, not the much more useful Invoke(Delegate, Object[]).

Add to that that the only valid Delegate is an EventHandler, which takes two arguments, the exclusion of Invoke(Delegate, Object[]) really is painful.

posted by ether @ 11:25 PM 0 comments  

Of System.Diagnostics.Debug, ActiveSync & Sockets

Except, nothing showed up in the output window. Checking whether there was a config setting, then making sure that .NETCF 1.0 supported it, I was stumped. Finally I find out that the default TraceListener is only supported by VS.NET 2k5 if you use .NETCF 2.0. Now I don't know if you've looked at deploying 2.0 apps in a world where even the most modern phones still ship with 1.0, but I certainly couldn't find a clean and simple solution. Especially not one that didn't require being tethered and downloading 40MB from MS, just so they can run a couple hundred kilobytes of App. And it's a pity, because I run into something every day to which the answer is "Use .NETCF 2.0". I want to, really, I do, but deployment convenience trumps developer convenience.

Next up was writing a custom TraceListener and wanting to be as unobtrusive to my Apps operation, I built it on UDP, i.e. a UdpTraceListener. Console based prototype code was up in about 20 minutes for the UdpTraceListener and the console app for listening to the spew. Then followed a couple of hours of testing and stepping through debug and not being able to get anything to be sent from my Emulator cradled via ActiveSync.

I even thought it might be because the phone Emulator couldn't talk to the hosting computer and moved the console app to Mono on my server. That part worked flawlessly--copy the binary call mono UdpTraceConsole.exe and it was up and running. But it also received no data.

Then finally I find a chat log with the .NETCF team that reveals that UDP is not supported over ActiveSync. Nice.

Another 20 minutes of coding and i had a TcpTraceListener up in running in my console test harness. Woot. Time to put test on the phone, so i can finally get back to real coding....

Right. That would have been nice. The same game as before. Tried all sorts of permutations and received no data. Sometimes the debugger would throw a Socket Exception, usually it wouldn't. It made no sense. I knew that TCP worked because I use HttpWebRequest extensively. So I tried putting my console listener on port 80. Nothing. Finally, I decided to open up a port on my firewall and forward it back to my dev machine so that I could try to contact my console listener via a network address from the outside world. And that finally worked. Only theory I have right now is that the DHCP setup via ActiveSync is screwy and it just can't see any of my local net. I'll investigate that later, for now I'm just happy to have a working debug spew.

And here is the exceedingly simple TcpTraceListener. Note: I use '\0' to denote the end of any message so my debug messages can include linefeeds.

using System;
using System.Diagnostics;
using System.Net.Sockets;
using System.Net;
using System.Text;

namespace Droog.Diagnostics
{
  public class TcpTraceListener : TraceListener
  {
    IPEndPoint endPoint;
    Socket console;

    public TcpTraceListener(IPEndPoint consoleEndPoint)
    {
      this.endPoint = consoleEndPoint;
    }

    private Socket ConsoleSocket
    {
      get
      {
        if (console == null || !console.Connected)
        {
          console = new Socket(
            AddressFamily.InterNetwork,
            SocketType.Stream,
            ProtocolType.Tcp);
          console.Connect(endPoint);
        }
        return console;
      }
    }

    public override void Write(string message)
    {
      try
      {
        ConsoleSocket.Send(Encoding.ASCII.GetBytes(message));
      }
      catch
      {
        // this is for a debug spew. I'd rather swallow the exceptions
        // than have my debug code mess with my App.
      }
    }

    public override void WriteLine(string message)
    {
      Write(message + "\r\n\0");
    }

    public override void Close()
    {
      if (console != null)
      {
        if (console.Connected)
        {
          console.Close();
        }
        console = null;
      }
      base.Close();
    }
  }
}

posted by ether @ 10:06 PM 0 comments