🔒 Locked 🎮 Unity

[C#] Creating a debug option "tree"?

Started by Kath May 28, 2009 at 6:17 AM 2 replies 1.8k views

Original Post

May 28, 2009 at 6:17 AM

Hello, I want to add a debug menu to my XNA game as to make tweaking and changing options a little easier on 360. I'm also running out of buttons on the pad to turn things on and off. I was thinking of a tree based sort of menu that looks something like this:

MenuRoot
 -Rendering
  -ShadowsEnabled false
  -DoLightingPass true
  -DoPostProcessPass true
-Physics
  -SimSettings
    -WorldGravity -9.8
    -WorldBounciness 0.1
  - Enabled true
+Scene <- *Node not expanded*
-Player
  -CurrentAmmo 15
  -GodMode false
+ .. other menus ...

Start would bring up the menu, Up/Down to traverse, Right/Left to expand or close nodes, Press A on a editable node to edit and press Up/Down to change the value. I usually code in C++ and am rather new to C# so I have some questions about the best way of coding this. I don't want to reinvent the wheel when there's a C# feature I could have used like I seem to keep doing [smile]. So on with the questions... How should I store the tree for the menu? Is there a C# type (Collection?) I can already use or should I roll my own? How to store the values? I can see me wanting int, float, string, bool and maybe Vector3. Is there anything like boost::any in C#? If not does a struct with one of each type and a flag of which type it is sound right? How could I connect the values to the classes that use them? Currently I'm thinking about having the main DebugMenu class static and having each class add their options in their constructor along with a reference to the variable it points to. Any other options I should think about? I'd also like to support calling methods as well as changing values, for example a "ResetLevel" node would call World.Reset(). I've been reading about Delegates and this seems like a good place to use them I think? Thanks for reading.

summaky

May 28, 2009 at 6:32 AM

I can't help you with the C# code, being a C++ programmer myself, but from what I could understand from your idea's description you basically want a Property Grid -- the control you use to set properties for form controls in Visual Studio -- in your XNA game.

I would try to mimic the behavior of the Property Grid in your debug menu and use introspection, attributes, and C# properties to get and set the values in your game's classes.

Sorry for not being more useful.

MJP

May 28, 2009 at 5:11 PM

Yeah PropertyGrid sounds exactly like what you want...except the problem is that you can't use it on the 360 since it's a WinForms control. Duplicating it on the 360 would probably require a lot of work.

An alternative would be to have the 360 game connect to some debug utility running on the PC. The utility would send commands over the network to the 360, which would then interpret them and set appropriate values (this is pretty easy to do with Reflection). Then the utility could use the PropertyGrid and whatever other WinForms stuff you want. You could also let it have a "console" like in Quake or Crysis, where you just manually type out the command.

JPatrick

May 29, 2009 at 1:55 AM

As others have mentioned, System.Reflection will provide you with the facilities you need to programmatically manipulate arbitrary types at runtime; the hardest part being constructing the actual UI for it on the 360, since XNA provides none out of the box.

I just thought I'd address your question about storage. If you're relatively new to C#, I strongly encourage you to read up on Data Types and their semantics. Primarily the difference between reference and value types, and value type boxing. A "reference" in C# is not the same thing as it is in C++. Boxing is also particularly important since you're targetting the 360, and it can have a non-trivial performance impact there if it occurs too often.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.