Correct me if I'm wrong...

[TheLaw]

I'm on day 3 with the kit, and I'm loving what I see. But I've fighting the plan/rule maker dialog every step of the way. I feel an urge to break into pure c# code. I have been under the assumption the the rule dialog box has been writting the c# code for me behind the scenes, but I can't seem to locate it. I feel I'll never be at peace with this kit until I figure out how it works under the hood. Perhaps a debugger would allow me to step thru and see what's happening. Can I grab a free JIT debugger somewhere, or will I have to install C# 2008 express.

So 1) Where's my plan code going and? 2) What's the best way to debug this puppy?

[bluemonkmn]

Alright, you're my kind of developer -- interested in the details.  Well, you're right.  It is generating C# code for you.  The sprite rules go into a file whose filename matches that of the sprite (with a .cs extension, of course), and can be found in the "Sprites" folder where all the project's generated source code is output when you compile (you can't see it in the IDE, but if you use Windows Explorer, you can find a "Sprites" folder among all the other source files in your project's folder after you compile the project, if you don't tell SGDK2 to delete the intermediate files).  The code for the actual rules is in a function called "ExecuteRules" at the end of the file.

And the plan rules can be found in the MAPNAME_Map.cs file (a sibling of the Sprites folder) where MAPNAME is the name of the map containing the layer that contains your plan that contains your rules *whew!*.  You may find multiple implementations of "ExecuteRules" in each of these files, depending on how many plans and layers you have in your map.  That's where the plan rules go (I assume you can work out how to find which ExecuteRules goes with which plan based on the parent class names, but let me know if you need more help there).

To debug it, I suggest getting Visual C# Express 2008 from Microsoft's site.  This is what I'm actually using to develop SGDK2 itself too these days (just to make sure anybody has equal ability to compile, develop and debug all SGDK2 code).  Once you have that installed, you should be able to load the GAME.csproj file in your project folder (generated when you compile the project) and compile and run the project with Visual C# instead of SGDK2.  Then you should also be able to set breakpoints and debug it.  I'm not aware of a debugger-only installation.  But you may find other features of Visual C# Express 2008 handy if you're considering writing your own custom code for SGDK2 projects.  Despite my efforts to make a nice text editor built into SGDK2, Microsoft's IDE still blows it out of the water with features like Intellisense.  Then you can just use the IDE to paste your code into the project and view it in pretty colors (maybe make some minor adjustments) .  BTW, you can edit any code you like in the C# IDE, but SGDK2 will only allow you to update code in the source code folder of the project.  It doesn't provide any means for you to "paste" in updated versions of generated code or anything like that.

I hope you continue to find SGDK2 interesting and entertaining.  We need more people interested in SGDK2 at your level to contribute content (games, templates, ideas, etc)!

[durnurd]

As far as fighting with the rule maker dialogs:  If you have particularly complex logic you need to design, putting everything into a custom code object and just making a single call to it is often a cleaner solution than trying to make all the predefined rules work together.  Or, of course, you can mix the two together, using the standard rules for normal movement and collision, putting in special calls where necessary.  I some times find it easier to just map one sprite to one function that handles it each frame, which then does allow me to just copy/paste changes to the sprite rules between the C# IDE and SGDK2IDE.

[TheLaw]

Cool! Thanks to both of you! I don't plan on bypassing the rule dialogs completely, I just want to know how everything works and where to park my custom code. And of course, writing custom code requires a pretty thourough understanding of the  whole system. I noticed when I added the weather effects, all the useful routines/data magically appeared in the list boxes. So this thing not only writes code for you, but it reads it to! That really excited me. I can go low and write core routines in pure c# and kick back and relax and use them in the rules dialog. Awesome stuff! I'm finding this kit even better looking on the inside. I just wish I had more time to spend with it. Oh, and more tuts would be good too. If the spirit moves me might hack something up as I learn.

One quick feature request: How 'bout showing the line of c# code somewhere on the rules dialog as its being built (or probably easier: after it's built). It might give real coders a better relationship with the rule system. Sometimes I find my self struggling to see exactly what a rule does, and I know if the c# code was there I could just go: "oh!"!!!

Thanks again,
Lawrence

[bluemonkmn]

Do you mean something like this: you select a function for the current rule, and then the file and line of code where that function is implemented is displayed somewhere on the dialog?
Or when you select a rule, show the file and line of code where the rule (will be) generated?  I suspect you mean the latter, which would be kind of a mess to implement because the code isn't generated yet and doesn't exist on disk until you compile.

Another reason I would be hesitant to implement this is because it might be too much information for some users, and would just contribute to their confusion.  And even for those who are interested in this level of information, although I suspect that it would be a nice way to learn about where the code is going, it probably isn't necessary or particularly helpful after you fully understand it.

It might make sense, however, to give more information about the build process as the project is compiling.  For instance, I could show progress information that includes the name of the sprite and the name of the corresponding file being generated for each sprite.  Then I could do the same for each map, and maybe all the other generated files.

BTW, have you checked out the help file?  The root page of the coding reference (in 2.1 Beta 1) indicates where the code is generated for sprites and plans.  I believe the same page and information exists in 2.0, but I don't remember where it appears in the table of contents.  But it's the page the introduces you to SGDK2 coding and shows an example of a sprite rule and a plan rule and the corresponding generated code.  It also gives lots of details on what each rule does, which might be helpful too.

[durnurd]

I got the impression that he was asking for what the line of code would actually look like, for example, if you choose:

Do
AlterYVelocity
-5

it would output the line of code that that maps to.  Of course, the mapping is somewhat straightforward:

this.AlterYVelocity(-5);

 so maybe I'm wrong.  Unless he thought it was more complicated than that, but it's really not.

[TheLaw]

Yeah, durmurd sorta got it. Maybe it's just me, but I can read and understand "this.AlterVelocity(-5);" much faster than reading the settings from each of the drop downs. To me it's a faster alternative to understanding what a rule does - especially when you haven't seen it in a while. I also feel newbies who haven't written source code before might start catching on after a while. Now that I think of it, the code wouldn't HAVE to be a legit line of c#; pseudo code of some sort would work for me. It's just a quick way to read what a rule does when your browsing thru them. Not sure where to put the code, perhaps right beside the rule name in the rules tab...?

Just a thought. Thanks for your time guys,
Lawrence

[Tanja]

this is a good idea. i would like to see the code like this too.

[Jam0864]

Good idea - The 'knowing what rules do easier' part doesn't apply to me so much, but the

I also feel newbies who haven't written source code before might start catching on after a while.

part certainly does. You would need an option to switch it on or off in my opinion.

Perhaps when you highlight the drop down box with a chosen rule in it the code would come up next to your cursor in that little white box, until you move your cursor off of it. Not sure what it's called, but if you highlight the smiley buttons when your posting it has the effect I'm talking about.

[TheLaw]

Hummn, I agree with turning it off and on 'cause it may confuse/annoy some.  But I envisioned having it (optionally) permanently placed along side the rules some how... Not sure. Perhaps after work I'll hack up a screen shot of my vision - just a first rough draft, and we can pick it apart.

[TheLaw]

Well here's a couple drafts of what it could look like. You'll notice the code is in different spots in each.  This is because I like the placement better in the first one (SGDKWC1.BMP), but then I looked thru some of the other rules and noticed that the lines can become rather long. That's when I came up with the second one which gives more room for long lines.  Again, you don't really use the source code unless your searching thru the rules or more importantly - debugging them. In the second one the code is outta sight and outta mind until you want to look down at it, so I don't believe that turning it off is a concern. It's only a first draft, and is open for suggestions. ...Of course we still need our wonderful developer to say yes the whole idea too!  :yes:

Edit: Yikes 192k upload size? Well, here's the first one?...

[TheLaw]

And here's the second one?...

[bluemonkmn]

It may not be easy to generate single lines of code.  The code generator (built into the .NET framework) is more statement oriented and would want to include all the contents of the if block as part of the if statement.  But I'll mull it over and see if I think of anything.  Dang, I'm never going to get to create a game of my own .