Scrolling Game Development Kit Forum
SGDK Version 2 => General Discussion => Topic started by: durnurd on 2010-03-27, 10:00:37 AM
-
It would be great if we could specify the superclass of specific Plans and specific Sprite Definitions. The options would be from a list of abstract classes that extend from PlanBase and SpriteBase (presumably that do not implement the ExecuteRules method, although this point is contestable).
This way, if some sprites or plans share functionality, it can be in a shared superclass, but not in the base class because not all sprites need it. It is also possible to override methods in this way, for certain sprites or plans.
My reason for this mainly is that I want a plan that does something exactly once, and if I plan on having an arbitrary number of these, I can't count on map flags to be plentiful enough. It's easy enough to do, by just adding a boolean to PlanBase, but for two reasons I don't want to. First, if I put it in PlanBase, I can't reset source code without losing it. I could put it in a partial class for PlanBase, but PlanBase is not a partial class itself, which means after I reset the source code, I have to go in and redeclare it as a partial class. Second, the extra boolean would not be needed for other plans, only those that are to be activated once.
-
PlanBase is a partial class. If it's not, then your project's source code must be old. I can do this in a separate file with the current SGDK2:
abstract public partial class PlanBase
{
bool done = false;
}
Sadly, I can't do this because plans are hard-coded to inherit from PlanBase:
abstract public partial class RunOncePlan : PlanBase
{
bool done = false;
}
public partial class Level_1_Map
{
public partial class Main_Lyr
{
public partial class Door_Left : RunOncePlan
{
}
public partial class Door_Right : RunOncePlan
{
}
}
}
However, this might be a good alternative. You can create a class that generically handles any customizations you want to make to any plans:
abstract public partial class PlanBase
{
protected CustomPlanInfo cust;
bool IsPlanActive()
{
return cust.IsPlanActive(this);
}
public Coordinate GetCoordinate(int index)
{
return Coordinates[index];
}
public virtual void CustomInitialize() {}
}
abstract public partial class CustomPlanInfo
{
public abstract bool IsPlanActive(PlanBase plan);
}
public partial class RunOncePlanInfo : CustomPlanInfo
{
bool done = false;
public override bool IsPlanActive(PlanBase plan)
{
return done == false;
}
}
public partial class ActiveWhenVisiblePlan : CustomPlanInfo
{
public override bool IsPlanActive(PlanBase plan)
{
return (plan.ParentLayer.CurrentPosition.X + 800 > plan.GetCoordinate(0).x)
&& (plan.ParentLayer.CurrentPosition.X < plan.GetCoordinate(0).x)
&& (plan.ParentLayer.CurrentPosition.Y + 600 > plan.GetCoordinate(0).y)
&& (plan.ParentLayer.CurrentPosition.Y < plan.GetCoordinate(0).y);
}
}
public partial class Level_1_Map
{
public partial class Main_Lyr
{
public partial class Door_Left
{
public override void CustomInitialize()
{
cust = new ActiveWhenVisiblePlan();
}
}
}
}
-
Two things:
first: I had reset the source code, but apparently files that are currently open in the editor are not reset, so because I had that file open, it was not reset.
second: Hard coded how? My suggestion is some dropdown list in the plan editor or the map editor that changes the base class for that plan for when code generation happens. Would that not work?
-
second: Hard coded how? My suggestion is some dropdown list in the plan editor or the map editor that changes the base class for that plan for when code generation happens. Would that not work?
I was talking about the current SGDK2 implementation. SGDK2 doesn't let you specify the base class -- it's hard coded to always inherit from PlanBase. The above code shows you what you can do without changing any SGDK2 code. Of course, if I changed SGDK2, it wouldn't be hard-coded any more. But my assumption is that if I don't release another update soon, you'd still be interested in some way to accomplish this with the current SGDK2 code.
I know that if one file doesn't specify a base class for class A, then another file with a partial class for class A can specify a base class. So I thought that we would be able to specify a base class for plans in a partial class. But I forgot that SGDK2 does specify a base class, so we can't do it that way.
-
I am going to re-implement the default framework code and SGDK2 code generator so that every ExecuteRules function generated by SGDK2 is implemented as "ExecuteRulesInternal" instead. Then I'm going to make an override-able (virtual) function in the base class called ExecuteRules whose default implementation is simply to call ExecuteRulesInternal. That way, every place that the generated code calls ExecuteRules, you have a chance to override what executes by overriding ExecuteRules in a partial class for the derived class. For example:
PlanBase.cs will now implement
public virtual void ExecuteRules() { ExecuteRulesInternal(); }
And then you can add code in a separate file
public partial class Level_1_Map
{
public partial class Main_Lyr
{
public partial class Door_Left
{
public override void ExecuteRules()
{
if (isPlanActive) // You could, for example, only execute plan rules under certain conditions.
ExecuteGlobalPlanRules(); // You could, for example, run some code before any other plan rules.
base.ExecuteRules();
}
}
}
}
I am doing something similar for map ExecuteRules, so you should be able to put in a LimitFrameRate call in a map ExecuteRules customization too.
Of course, now it would be even more nice to be able to specify the base class for a plan, sprite, layer or map so that you didn't have to create a partial class for each individual object that wants to customize the ExecuteRules behavior.
Think this too is helpful?
-
Yesterday I managed to implement the "BaseClass" property for a Plan in the map editor. Now you can see a dropdown list of other abstract classes that inherit from PlanBase. When you select one, and then re-select the plan, you will see any public properties specific to that base class appear as properties in the property grid so you can initialize their values. I have yet to implement BaseClass in the plan editor. And I have yet to implement it for sprite definitions.
-
I meant to reply yesterday to your previous comment about ExecuteRulesInternal, but my tubes were down.
So if you combine the ability to change the base class with the execute rules internal, then you basically get something where you don't have to put an If rule at the beginning of every plan rule set (for example). By itself, it doesn't seem to helpful, because all your example does is the same an extra if and an extra Do would do in the rule set. But if you could have it be for every plan of that base type, it would be much more helpful.
-
Another comment about plans: Is there a way to move them around at runtime or a reason not to have one? Things like offsetting, scaling, and even rotating if the box bit doesn't matter.
And another one: Would it be possible to make paths with non-rectangular bounding areas? That is, have plans with more than two points that can still check to see if things are inside of them. I know there are algorithms to do it, at this point I'm just talking about the map editor GUI for displaying them.
-
It seems to me that there's little point in making the map editor display that. The reasons I can think of are:
1. To demonstrate, "hey, guess what you could do if you wanted to".
2. To help the user remember which side of the line is the inside (There's only one that makes sense once the path is implicitly or explicitly closed).
The reason for doing the rectangles was to help visualize all sides and corners, but that's not necessary when all sides are already drawn.
-
1. To demonstrate, "hey, guess what you could do if you wanted to".
Yeah, but I totally want to!
Anyway, how about built-in algorithms for checking insideyness?
-
That could be fun to work on. Do you think that's the most important thing after base classes for plans?
-
Well, I don't know what else there is to work on, so I've no idea. My real need was to be able to move plans around, and the other ideas came after that as things that seem like they should exist, but aren't necessary for what I'm doing right now.
-
I implemented a function to check whether a sprite is within the polygon formed by a plan's coordinates. I checked everything into SVN so you can test all this base class and polygon stuff. Wanna try it? If it looks good, maybe SGDK2 is ready for another release.
-
I did an update, and found that either two files are missing or they're supposed to be generated somehow. When I opened the project, it couldn't find the .config files for opentk.dll and fmod.dll. When I deleted the references to them in the project I was able to run the application. Will let you know more once I try it out
-
Some more points: One reason I wanted to make subclasses was so I could override functions like reactToSolid in the subclass. There are plenty of ways to handle this, but it seems like the cleanest would be to have a subclass in between SpriteBase and the specific classes that use the overridden reactToSolid method. The problem is that reactToSolid is not marked virtual and is in an abstract class, which means it can't be overridden properly. I can use 'new' instead of 'override', but I'm not sure what the difference is, and if it would be a problem.
The OTHER problem is that reactToSolid needs to be able to access m_solidity and layer, which are declared private in the base class and there's no getter for m_solidity. As it stands, I can get away with making the one change to SpriteBase to declare m_solidity as protected after resetting the source code and everything still works, so that's definitely a giant leap forward.
-
I noticed a few more things:
There's still nothing stopping me from putting illegal characters in a plan's name on the map editor.
- If I specify a SpriteBase variable in a subclass of PlanBase, I can use the dropdown combo box to edit its value in the map editor (although it sometimes takes a few clicks to get it to refresh and show it), but I can't access that sprite in the plan editor.
- If I specify a subclass of SpriteBase as a variable in a subclass of PlanBase, I cannot use the dropdown combo box to edit its value in the map editor. I can still type in values as text.
Trying to run the game when an instance of it is already running crashes SGDK2 - If a sprite is riding a platform, and the platform becomes deactivated, the app crashes in debug mode, because the rider tries to update the platform manually before doing its own reactToPlatform, which then calls the assert(IsActive).
- Similar to the SpriteBase thing, if I specify a LayerBase as a variable of a SpriteBase, I cannot use the dropdown combo box to edit its value in the map editor. In fact, I cannot even see the property in the list in the map editor (I've tried setting using the [Description("")] tag to no avail). I can still set its value in the rules editor using, in my case:
m_ParentLayer.m_Builder_2.LockLayer = ((Map01_Map)m_ParentLayer.ParentMap).Locked_Tiles- When using CheckNextCoordinate in FollowPath, the check for reaching the target point uses < TargetDistance, meaning having a TargetDistance of 0 will never move on to the second point in the path. If the TargetDistance is 1 instead, an L-shaped path will cause the sprite to have a slight grade while going from the second to the third point, because it will never have reached the exact middle point of the L.
-
Thanks. Just like at my job, I'm glad to have someone else with the time to test my work more thoroughly so I can just focus on fixing the things that people care about, rather than spending all my time testing, and then not knowing if anybody even cares about what I tested :).
Looks like I've set expectations pretty high with some of my helpfulness in the map editor. You want a drop-down list of all the sprites of a particular derived SpriteBase type to be available when editing a plan's property values in the map editor when a plan has a variable of that derived SpriteBase type? That's pretty fancy, isn't it? :) (Although, I guess it shouldn't be much different than what I've already done.)
Question about your experience with CheckNextCoordinate: do you think "<= 0" would fix the problem? You say that using "1" didn't work, which implies that your sprite had some landing points between 0 and 1 pixels from its destination, which suggests to me that it's unlikely your sprite would end up exactly at 0 pixels from its destination within a reasonable amount of time. Or do you have it running at a constant 0.5 pixels per frame or something like that?
-
The sprite is always running at 1 px per frame at orthogonal angles. The reason I care so much is because as soon as it reaches the last point in its path, it deactivates itself, and whenever it's directly overlapping a tile, it changes that tile, so if it deactivates itself before it reaches the end, it won't change the last tile unless I extend the path 1 px extra.
I got around that issue, I think, by limiting the velocity to 1 px per frame before moving, then resetting velocity to 0 for the next call to FollowPath. Then, on the very last point, I put a weight of 1 so that it will wait there 1 frame before starting to move back towards its original point (which is how it determines if it should deactivate itself). There's probably something else I did as well, but I don't remember it.
-
Some more points: One reason I wanted to make subclasses was so I could override functions like reactToSolid in the subclass. There are plenty of ways to handle this, but it seems like the cleanest would be to have a subclass in between SpriteBase and the specific classes that use the overridden reactToSolid method. The problem is that reactToSolid is not marked virtual and is in an abstract class, which means it can't be overridden properly. I can use 'new' instead of 'override', but I'm not sure what the difference is, and if it would be a problem.
I don't understand why you would want to override ReactToSolid instead of just implementing your own ReactToSolid. Should many other functions be overridable too?
-
Well, I don't really know the difference between creating a New ReactToSolid method vs an overridden ReactToSolid method. I know what overriding the function does, so that's what I assumed would be the best option.
-
I wouldn't name it "ReactToSolid" because that would be confusing if you're implementing a new function. But the real reason you'd need to override a function instead of implement a new one is if you need polymorphism. So the question is, do you need to be able to call ReactToSolid on the base type and have it execute the actual derived ReactToSolid code depending on the actual sprite type?
-
Well, okay. Probably not, in this case. But would it make sense to just have SpriteBase not be an abstract class in any way? It would fix this issue for any subclass for any method (I think) and all you'd have to do is have an empty ExecuteRules method. Not sure if it's the best way to do it though...
-
I don't think I'm understanding you correctly.
Are you suggesting that it would make sense to make the sprites not abstract -- not have any inheritance? That would imply that either:
1. All sprites share the same class, or
2. Every sprite is its own class.
#1 would be problematic because the sprite parameters, states, and sizes are all implemented in the derived sprite classes. The states and sizes could maybe be implemented generically in the base class somehow, but the sprite parameters would have to be drastically different (well, at least until I start using/requiring .NET 4.0, where you can dynamically add properties to an object, at least with VB.NET). It's nice to have parameters so directly correspond to variables defined in the derived sprite class. Also, eliminating object inheritance seems to be a step in the wrong direction with OOP, where right now you can define a base class and take advantage of the fact that your derived class inherits all the base class functions, and can add new functions and variables only applicable to this specific new type of sprite.
#2 would be problematic because the framework code needs to be able (among other things) to determine the position of a sprite generically. And that would also mean a lot of overhead if every sprite type had to totally rewrite all those SpriteBase functions.
OR are you suggesting that SpriteBase should be abstract (asking the question "would it make sense to just have SpriteBase not be an abstract class" suggesting a "no" as the right answer)?
To that I say, SpriteBase already is abstract in some ways. All these members are abstract and must be overridden by the derived sprite generated by SGDK2:
- SolidWidth and SolidHeight
- SpriteState
- ExecuteRules
- ClearParameters
- RemoveFromCategories
Also, the framework takes advantage of the ability to refer to and interact with sprites generically in a number of ways as indicated above (sprite position, size and appearance).
But if you are saying that SpriteBase should be more abstract, I am undecided. I started adding "virtual" to many of the functions implemented in SpriteBase until I stopped and asked the question, "how am I deciding what makes sense as virtual and what doesn't?" and I didn't know the answer. Under what circumstances will you need to override a function? Was I correct to begin with in having only those members that the framework cares about be abstract? So maybe you are suggesting that nothing more than the framework's minimum requirements should be abstract, and things are OK as they were?
Edit: Oh, also Processrules is virtual and can be overridden, but is not abstract because it has a default implementation.
-
After reading up more on C# (I haven't used it enough lately) I'll retract my main comment, which was essentially to just remove the 'abstract' keyword from SpriteBase and provide default implementations that would always be overridden.
However, having most methods be marked virtual makes sense in the sense that subclasses can then change them generically without having to change the base class (and lose those changes upon resetting the source code), so that two sprites can interact in a generic way without needing to know each others' types.
-
Ah, so you think functions that sprites and plans might want to call on each other would make sense as virtual functions because they might want to perform the operation on a SpriteBase. So that would probably be all public functions and properties then?
-
I did an update, and found that either two files are missing or they're supposed to be generated somehow. When I opened the project, it couldn't find the .config files for opentk.dll and fmod.dll. When I deleted the references to them in the project I was able to run the application. Will let you know more once I try it out
I don't see any reference to an fmod.config in my SGDK2.csproj. Are you sure fmod.dll.config was one of the files?
-
If I specify a SpriteBase variable in a subclass of PlanBase, I can use the dropdown combo box to edit its value in the map editor (although it sometimes takes a few clicks to get it to refresh and show it), but I can't access that sprite in the plan editor.
This is a bigger change than I want to make now. The plan editor is designed mainly for editing rules/details of a plan. If you want to edit the design of a plan (its coordinates and parameter values) that's done in the map editor. If I were to implement the ability to change parameters in the plan editor, I'd need a whole new page because there is no page for editing plan parameters.
-
I don't want to change the variable, I just want access to it. If I select a rule like "FollowPath" I want it to show up in the list of sprites. So I can create a PlanBase subclass with a Sprite variable spriteToFollowPath defined that I can set at design time, then in the FollowPath action, use that sprite instead of one of the specific sprites from the map.
-
I don't see any reference to an fmod.config in my SGDK2.csproj. Are you sure fmod.dll.config was one of the files?
The files that are actually missing are OpenTK.dll.config and libfmodex-4.22.01.so
-
Since libfmodex-4.22.01.so isn't source code nor is it my own (like OpenTK.dll) you are expected to pick that one up from the Linux support package or exclude it from the project.
-
I fixed most of the issues you brought up, and maybe now it's ready for release:
- Improve error handling when attempting to run the project if it is already running.
- Fix an error that prevented multiple displays from being open simultaneously.
- Allow a layer to be created with a null tileset to represent the designer background layer (allow user-created layer to refer to no tileset).
- Prevent the user from creating a layer with zero tiles.
- When resetting source code to a template that imports decapsulated source code files, be sure to import the referenced code because the project into which the code is being imported will not know how to find the template's decapsulated files.
- Implement the ability to sort sprites in the map editor.
- Add OpenTK.dll.config to source control.
- If a plan contains a SpriteBase-derived member, show a drop-down list of the appropriate sprites in the map editor when this plan is selected.
- Prevent invalid sprite and plan names from being specified in the map editor.
- Change most SpriteBase and PlanBase members to be protected instead of private.
- Change most SpriteBase and PlanBase members to be virtual so they can be overridden by an intermediate base class.
- Change CheckNextCoordinate to proceed to the next target if the distance from the current target exactly matches the target distance.
- Prevent debug-mode errors when a platform is deactivated and a sprite is riding on it.
- Stop riding on a platform if it is deactivated while riding it.
- Change SpriteBase.TouchTiles to return a strongly typed collection of results.
I also finally merged the SGDK 2.1 branch back into the trunk (over SGDK2.0) so anybody retrieving source code without knowing what's where is most likely to get the latest code now (well... until I start making modifications in the trunk and they think the latest would be in the 2.1 branch... hmm...).
How's it look?
-
When I opened the project in the trunk, it couldn't find OpenTK.dll and OpenTK.GLControl.dll. Once I manually added them from the branch, it built and ran and everything works! I particularly like the part where it doesn't crash when I open two map editor windows :)
-
Yeah, the OpenTK dlls too are not my own and are not source source code so I didn't check those in either. You said you picked them up from the branch, but you must mean that you picked them up from where you had the branch in your local workspace because they're not checked into the trunk or the branch (right?).
-
Is there some readme somewhere in the repository saying that these files need to be downloaded and where to find them?
-
I don't think so. I figure anyone who is up for compiling source code is likely to know that they can get the binary files from the installed image if nothing else.