I just pushed a new feature to AngelXNA which integrates a very simple (and currently fairly dirty and incorrect) lexer / parser into the console. The nice thing about this lexer / parser is that it allows the Angel console to now track C# objects, instead of just strings. In addition, you can bind various properties and methods of those C# objects to be console callable, which has made actor and level definition pretty easy to do in the new versions.
Here's an example of the old Angel adf files:
ActorFactoryInitializeActorClass PhysicsActor ActorFactorySetColor 0.5 0.5 0.8 1.0 ActorFactorySetSize 3 3 ActorFactorySetDensity 0 ActorFactoryAddTag maze_wall
Each of these was marked with the [ConsoleMethod] attribute bound to their singleton via reflection. It was cool, and it worked, but here's the new system:
ActorFactory.InitializeActor(PhysicsActor.Create()) Color = Color(0.5, 0.5, 0.8, 1.0) Size = Vector2(3, 3) Density = 0 Tag("maze_wall")
In the back end, ActorFactor.InitializeActor and PhysicsActor.Create are static methods on C# classes, marked with [ConsoleMethod], and the Console class automatically finds them. Initialize actor has an implicit "Using" which means that the object passed to it is the subject of any calls until an EndUsing (or EndActor). So, in reality, the new adfs are shortcuts for console scripts that would look like this:
ewActor = PhysicsActor.Create() newActor.Color = Color(0.5, 0.5, 0.8, 1.0) newActor.Size = Vector2(3, 3) newActor.Density = 0 newActor.Tag("maze_wall") World.Add(newActor)
Each of the calls to set actor properties (Color, Size, Density, etc.) are all just properties on the C# Actor object, marked with [ConsoleProperty].
What all of this means is that if you want a class that's accessible from the console and has properties and methods you can call here's what you do. First, create a class that has methods and properties that you want console accessible tagged appropriately, like so:
public class MyConsoleClass { public MyConsoleClass() { } [ConsoleProperty] public string Name { get; set; } [ConsoleProperty] public string Value { get; set; } [ConsoleMethod] public string GetMyInfo() { return String.Format("{0}:{1}", Name, Value); } [ConsoleMethod] public static MyConsoleClass Create() { return new MyConsoleClass(); } }
Second, compile and run you AngelXNA application. It will automatically detect your new class and allow you to now issue the following commands in the console:
myVar = MyConsoleClass.Create() myVar.Name = "My Name" myVar.Value = "My Value" Echo(myVar.GetMyInfo())
So, that's pretty cool! The whole system needs work, as it's fairly dirty. The execution / parse tree can't handle chaining right now, so commands like myVar.Actor.PerformAction() won't work. In addition, there's a lot of boxing / unboxing of values going on, and some wonkyness where the console works mostly in floats. I'm not sure how much of this I'll have a chance to correct, but hopefully much of it as we move forward.
In addition, this whole system needs documentation on our wiki. If you want to help out please let me know.
Lastly, Ian Bogost and Borut Pfeifer have pointed out (via twitter) that AngelXNA definitely needs to be more user friendly to start with. As Ian said, we need things that " will help people get started' and "help them get up and running" quickly. Borut pointed out we may need more screens for the Intro game to explore a lot of the features, but I'm thinking we need more than that. For people that have tried Angel / AngelXNA, what keeps you from starting work quickly? What's confusing? How can we improve the experience and get you working on prototypes quickly and efficiently?
