SGDK 2.0 Status

[bluemonkmn]

I got a good chunk of time to work on SGDK2 last night.  I started out by staring at the screen and other forms of "thinking" (and resting -- I was tired) for about an hour.  Finally I started putting controls on the Rules tab of the Sprite Definition form.
Some of the questions/challenges/thoughts I am faced with in designing this portion:
1. I would like to keep all sprite parameters as simple integers.  It makes maintaining them at design time so much easier.  I went back and forth a number of times, wondering if I should allow parameters of type "Sprite" and of type "Path".  On the one hand, allowing this flexibility increases the power and flexibility of the sprite rule system.  A sprite could refer to any number of other sprites and paths for any purpose.  On the other hand, it also significantly increases the complexity of the rule system and the design time sprite editing.  I might have to figure out a way at design time to allow you to specify a value for each of these parameters, and figure out how to convert that into runtime data when the project is compiled.  But I've ended up sticking with the idea of parameters being simple integers for now.
2. I am realizing more and more how different the design-time and run-time environment of an SGDK2 game will be.  At design time, a reference to a sprite consists of a map name, a layer name and a sprite name.  At runtime, a reference to a sprite is probably just a variable of type Sprite (and the variable name will be the sprite name).  But then when it gets saved (assuming that I will support saved games) I may have to convert it back to names.  Or maybe I can just use the built-in .NET serialization and it will automatically save an object and everything connected to it in a binary file -- but that would be too easy... and what happens when it gets to the DirectX display object -- does it try to save my video card to a file?
3. There are three considerations that I have encountered so far in designing a sprite and its rules in relation to its parameters.  The first is how do I remember which platform a sprite is riding.  The second is how to I remember which path a sprite is following (and be able to specify it at design time).  The third is how do I keep track of which sprite this sprite has collided with during a collision test.  Those can't be stored in user-defined parameters, but I am thinking that I don't need an unlimited number of these, so I could hard code two sprite references and a path reference into the generic "Sprite" object.  Then any sprite can refer to a platform, a collided sprite, and a path.  The platform and the path could be set at design time so you can initially set a sprite instance to be riding a platform and following a particular path without having to hard-code that into the sprite definition.  Then when you are defining rules, and you use a rule that needs a sprite-type parameter you will be able to pick from any of the sprite instances (on any map?) or the current sprite's platform or collision sprite.
4. Creating sprite definitions global to the whole project is presenting its own challenges.  The sprite definition system can no longer assume that a particular sprite definition will only be dealing with objects on a partucular layer any more.  It has to be prepared, for example, to have a rule that checks for collisions with a sprite on any layer of any map.  It's hard to make myself remember, when I think of what kinds of conditions and actions a rule can have, it has to be structured to be useful in a generic way that can apply to all instances on all maps.  I have a condition planned that allows you to define a rule to check for collision with a specific sprite.  But that's probably useless to the point that I should eliminate that condition altogether.  How many types of sprites want to be checking for collision with a particular sprite instance on a particular map?  I also have a condition to check for collisions with sprites in a particular sprite category.  But this morning I realized that categories are too broad.  If I have a sprite category of all the bullet sprites, I don't want to be searching through all the bullet sprites on all maps to check for collisions with a player sprite instance when the player sprite is only on one map at a time.  But it also doesn't make sense to try to make sprite categories only contain sprites on a single map either.  The category applies to the sprite definition no matter which map its instances are on.  So I think the design-time category associated with sprite definitions needs to implicitly create some run-time categories of sprite instances (just for the current layer) if I want to be efficient about things.
5. One thought that I came up with this morning that I thought was useful, but realized just now was incomplete: If I allow sprite definitions to be sorted within a category, then I can refer to sprites by index within a category and the integer sprite parameters become useful for referencing sprites.  The problem with that idea is that, at design time, you are categorizing sprite definitions, not sprite instances.  Referring to a sprite definition from a sprite rule is not helpful.  I thought I could use this to do things like: a. Create 5 bubble sprites based on the same sprite definition b. Create category "SpawnedBubbles" containing these 5 sprites c. Create rule "CreateNextSpriteInCategory" that allows you to activate the first non-active instance of a bubble in the "SpawnedBubbles" category.  This would achieve the effect of creating a new bubble sprite each time the rule runs (up to 5).  I guess that much would still work (if I limited it to sprites within the current layer -- use the run-time category), but now if you want to refer to a specific bubble sprite by index, it doesn't help to have the "Bubble" sprite definition be "number 1" (the only sprite definition) in its category.  I would need to number the sprite instances, not the definitions.

Fortunately I haven't written any code behind this UI yet.  And all I've done as far as defining specific rules is make a list of rule names that I might want to implement.  I will have to go through this list again with a clearer mind, considering the differences between design-time and run-time, and considering the differences between a sprite definition and a sprite instance.  This certainly won't be the WYSIWYG editor GameDev 1.x was, but if I can get it right, the power will definitley be worth it.  WYSIWYG is only useful to a certain point in a game editor anyway, right?

[cbass]

I like to see you're putting a lot of thought into the sprite system to balance ease/speed of design and how much power/options to give the designer

I tried thinking up solutions or idea for some of your problems mentioned above but I'm kinda stumped on some of them too.  But I did come up with a couple ideas to throw out about the new sprites system.

Idea/suggestion about paths.  Since in 1.x they are a series of points, then you added in delays (integer).  Maybe could could add in references to rules/(special functions) at points in a path (again could be integers referencing a rule index).  It could be like adding in delays now except you would select from one of 2 drop downs, for global rules and for definition specific rules, or type in the number manually.
The rules could do stuff just like special functions act in 1.x.  Create sprites, delete sprites, play media, etc.  You could even do stuff not possible in 1.x: change sprites maximum speed, jump to a different point in the path, create if-then-else statement like commands that can give the sprites "intelligence" rather than just following a simple path.
This could make it easier for the intermediate designer to make smarter and more advanced sprites.  In 1.x it can be frustrating that non-player sprites can never activate functions except on collisions, this could solve that.

I like how you absorbed the 1.x version of templates into 2.x definitions to make things simpler.  I do however like the idea of keeping something like templates but only as a design time element, to speed up sprite creation.  Since it looks like you are creating more options for definitions, maybe you should allow the designer to save pieces of a definition, say the states/graphics/frames, some or all of the rules or parameters, path, as a template.  Then at any time during designing a new or editing an old definition, the designer can load data from a list of templates that only affect whatever is stored in the template.  Example, when making a new sprite they can load the rules and some parameters from the "enemy1" or "bullet" or "platform" template and grab the graphics from a different one, then load the movement parameters from the "top down" template, and finally select the path themselves.  I was thinking of this as an optional advanced option, but it could possibly be of benefit of those new to the kit by pre-loading many of these templates into either a new project or keeping the SGDK global and have templates like "Platform", "Left bullet", "right bullet", "Player".  So the new designer could just load up these pre-made templates, add in the graphics and starting path and be done with a sprite without having to fill in every advanced option him/her self.


Now that definitions are global, there will be a lot to keep organized, it would be nice to add in ways to sort them by different properties.  Trying to select from a small list box that you can only see a few of the definitions in and not even be able to read the full name really is tough.  I  see that the current version has an expandable window size which is nice, I just hope you aren't designing the interfaces with lower resolutions in mind   If you are, i envision something like a button that opens a new window that has basically a spreadsheet of all the definitions that can be sorted by any reasonable property.  Double clicking on one would load that sprite def into the main window.  Another cool option would be selecting multiple definitions and batch changing properties/setting for all of them at once.  Examples: (up all the sprite movement speeds 1 or 2 steps to speed up the action), (after finishing a top down map, select all the definitions used in that map and put gravity to "0")


I'm sure some of this stuff you are implementing in another way, but I just thought I would get these ideas out there if you haven't thought of them yet.

[bluemonkmn]

Idea/suggestion about paths.

[Orion Pax]

Maybe this is a bit off topic but will their be a sprite priority system (sprites on the same layer)? such as: Sprite A is always infront of sprite B and always behind sprite C / inless ( add contitions for changing priority). In 1.4 if this is a concern you end up having to reinitate a lot of sprites in the prefered order if you have done something that alters the order (delete/create new sprite, etc) which can come up quite frequently.

There was mention of ui organization/sortment of sprites and such... even if there are less entries to worry about with global sprites it could still get to be a long list and being able to sort and organize that data is important. Most things in 1.4 are on a first come first serve basis so you have to export to xml to reorganize. The gui itself is limited by frames/boxes not being resizable - names getting clipped off... This can be a huge hassle though I doubt it will be an issue in 2.0

Anyway I think I got most of whats been said here but I'll have to see it in action. I certianlly have my own ideas on how to do things but I'm no programmer so I'll take a wait an see approach for now =]

btw: is there a thread for thoughts/questions on sgdk 2.0? I'd say alot more but its really not in sync with the on going status portion at this time.  I'm adamant about some features and I'll haunt you to the grave if they aren't included =P

Tiny minor note to cbass: are you forgetting EOP (end of path) in 1.4? you menionend only on collisions to trigger functions for nonplayer sprites. With eop_ you can do alot of things... I wouldn't call it a 'smart' sprite but you can still get some complex behavior if desired.

[bluemonkmn]

I think I am in a position to allow control over the order of priority of the sprites.

[bluemonkmn]

I'm in the process of making a couple changes/decisions based on recent discussion.  Not sure if they'll stick, but here they are:

1) I am changing the name of the "CoordinatePath" object which was going to be used to define paths for sprites to follow to "SpritePlan".  This more general name/object will encompass not just points on a path that a sprite might follow, but can also contain custom rules that might apply to a specific instance of a sprite (as opposed to all sprites of the same type), and (for example) a reference to another sprite that this sprite (any sprite following this plan) might follow.

2) I added a "Type" column to the sprite definition's parameter list, with the thought that maybe I will allow multiple types of parameters after all.  For the moment, I expect a parameter to be one of the following types:
int (integer)
sprite
spriteplan
area (a rectangular area on the layer, like the rectangle for a GameDev 1.x special function)

[cbass]

Orion, yes I did forget about that while writing that post.  I have used it quite a bit.  One problem I ran into with it though is when I want to delete the sprite and activate and EOP function it won't quite behave how I wanted, my EOP function activates a series, one of which is a "delete sprite" but deletes the last one made not the one that is at the end of its path. (any way around this, i cant think of one).  Also, I wish the was a OSR_[SpriteName] (On sprite remove) which activates a functions of that name just before a sprite is removed no matter what the reason for the removal.  I think i mentioned this in another post, and this is the SGDK2 thread so Ill quit talking about it 

]Every sprite instance that can exist must be defined at design time.  You can't create an unlimited number of a certain type of sprite.  (However, you will be able to "Activate next inactive sprite in category" to achieve a similar effect)

Right now I am working on a game that has 1 "Initial instance" spite, the player.  All other sprites are created by tile interactions and special functions, and those with paths are always "follow path relative to starting point".   This is mainly to make sprite creation as easy as tile placement (looks like your doing this "out of the box" in SGDK 2.  Would be nice to have an options for when to activate sprites: "When playersprite comes within 500 pixels", "At beginning of Map", "When player collides with sprite", "On Rule ACT_[SpriteDef]*"

Anyways, I can see how dynamic sprites would still be possible with the system you described in the quote above, but will we still have as much freedom with dynamic sprites?  Can we still change properties of sprites or definitions at run-time via "Script" or otherwise? (I like to change anything and everything at run-time, Especially graphics)


And on Paths.  I have an idea just come to me, take it or leave it.  Since you will have path points, special functions, Sprite Instance starting points, and now areas.  Maybe to make map creation easier you should just allow the creation of "Points" in the Map GUI.  They would have names, and an X and Y and be indexed by the layer.  They could be used for anything: Path Points, Special function corners, Sprite instance start positions, and area corners.  When making them in the map editor you could type the name and start clicking and it would auto-update the name for you at each point "EnemyPath00,EnemyPath01...."  You could also have buttons to "Create Path from last points of same name", Create Area from last 2 points", etc, that would either auto-create or open the appropriate dialog so you could edit the newly created object.

Some benefits of this method include: The ability to edit individual path points easier and append path points, the ability to edit locations of areas easier, easier way to select destination of "teleport player" special function, easier way to implement "move tiles" special functions

The real benefit would come for being able to select these points "by name" from any other dialog where appropriate: Sprite Instance/Definition for rules or path locations, Special function/Rule/Area for areas of functions or targets (Transport, move tiles, etc).  They could also be used for easy map navigation in the design GUI, have drop-box "Scroll to Point...."

A huge list of points could become unruly and difficult to navigate so you could "hide" points after you make the appropriate path, area, etc.  So the list only contains what you want it to contain (the stuff you are working on, the most recent stuff" with an options to "view hidden points" available.
Another problem might be for novices that want to make paths and area "the old fashion way", but you could still keep those options available, an just auto-name and auto-hide the points of paths and areas made in this manner.

Also, I'm not sure how you would implement it, but having "relative points" might be a good idea as well.  "Left of, Right of, Ballistic projectile series01, Ballistic projectile series02, TopLeft of screen. etc"  These would all be useful for things like shooting players, shooting enemies.  Some of these could be pre-defined as well.  Might make things easier to select points by name rather than having to worry about coordinates at every level of design (especially for those new to the kit )"

...Steps off soapbox. 

Also, thanks for keeping us involved in this process.  Hopefully we all get a better engine and development environment out of it. 

[bluemonkmn]

Hmmm... you make some interesting points.  Heh... sorry I just had to say that .

It's too late in the evening for me to make any important decisions now, but I'll sleep on it.  Right now I'm leaning toward leaving some of those kinds of things for SGDK 2.1 or something, if I can figure out a way to leave that option open in my initial implementation.  I suspect (as of just now) that I will want SGDK 2.0 to be relatively bare and just implement the critical framework (and some of the alluring features that will draw attention to the new version), and then build on that after getting SGDK 2.0 out so that people can start using it.  If I bite off too much, SGDK 2.0 could get unnecessarily delayed in the sense that I won't have anything really usable for a longer period of time.

[cbass]

Good point.

I agree with getting a complete working version up and running as soon as possible.  One thing I hope you do, however, is have a long running beta, call it a beta so you don't always have to worry about backwords compatibility (keeping old projects working on the new version)   when adding features and changing stuff.  (i imagine this could be a time consuming  problem, but maybe you have a simple way of doing it)

I'd hate to get stuck with something that everyone agrees is less than what it can be, but noone wants to change since they don't want to go through the hassle of manually updating their current project.

[bluemonkmn]

I got a bit of time to work on SGDK2 tonight.  I put in a combo box for the new "Type" column on the sprite parameters tab.  So now you can specify the data type of various sprite parameters.  Then I started writing code to spell out all the different kinds of rules there would be.  I started one list of conditions and one list of actions (those are the two components of rules).  Each type of condition has a name, a description, and two parameters (each with a name and a type).  The parameters used in the rules are more specific than the sprite parameter types.  For example, one of the rule parameter types is "OutputSpriteParam" which indicates that one of the function parameters is designed to be the location where the rule will output a sprite.  I used this in a "HitSpriteInCategory" rule.  That rule will check to see if the current sprite is hitting any sprite in a particular category, and if it is, it will put a reference to that sprite into the sprite parameter indicated by the second rule parameter.

An action is slightly different that a condition -- it will accept 3 parameters and supply a return value (which will probably have to be associated with a sprite parameter since you can't really do anything else with output values at this point).  There are other differences between conditions and actions too.  Up to 3 conditions can be joined with "And" or "Or" and each component can be preceeded by a "Not".  But each component of the condition conforms to the types of available conditions (one name and two parameters).  I'm concerned that 2 parameters won't be enough someday, but that's all there was room for on the UI if I wanted to fit 3 conditions onto it (each with 2 parameters).  Sure I could probably support an unlimited number of parameters and/or conditions in a single rule, but I thought it might keep the UI simpler to impose some sensible limits.  I might revisit this in a future version -- the data structure is open to more if the UI can figure out a better way to handle it.  It is possible to nest conditions to an unlimited depth (which is similar to performing an And) but only 3 can be combined into a single rule and given a single name.  That means only 3 can be ORed together.

So after I finished defining some condition types I moved on to defining some Action types and realized I had a potential problem.  In GameDev 1.x I had to be careful to process all the platforms sprites before processing all the sprites that might be riding on the platforms because I didn't want to have the rider position itself above the platform and then move the platform.  And I don't think my current sprite definition design will support this.  So I might have to think on that a while.  Right now each sprite definition has its own rule system, but there's nothing controlling the order in which each sprite definition's rules get processed.  Also, I wonder if some sprite definitions will want to have processing at multiple points.  Perhaps I need to introduce multiple-phase sprite rules.  Some rules execute during phase 1, others during phase 2.  It occurs to me as I write this, however, that GameDev 1.x did not need multiple phases, and simply being able to control the order in which the sprites process their rules was adequate.  I haven't gotten to the point where I determine which order the sprites get processed in yet, so this might be a non-issue.  But now I have presented the idea of multiple-phase rules, which might be useful.  So I may think on that a bit before locking myself into an implementation.

[bluemonkmn]

The mechanisms I'm putting in place for managing parameters and rules and their interactions are just not working out well and seem to be making a mess of an otherwise clean design.  So I am re-thinking how to manage parameters/variables in the sprite rule system.  After backing up a bit and thinking, I am considering a new possible solution.  Instead the rules requiring that all affected variables/parameters be supplied as inputs, I think I will explore the idea of having the rules impose a set of implicit parameters into the sprite.  So, for example, if a sprite definition ever uses a rule related to riding on a platform, this rule carries along with it 2 variables: a "Platform" sprite reference and a "PlatformOffset" floating point number variable.  These two variables will implicitly become members of this sprite definition (and thus every sprite using this definition) to support this rule.  This will greatly simplify the user's task because they won't have to go back and forth adding parameters to support every rule they use.  Now the trick is how to implement it and how to detect if there's a conflict if I want to support user-defined rules (whose parameter names might conflict).  In some cases rules need to be able to share the same parameters (the LandOnPlatform rule, which initializes a sprite's riding on a platform, needs to share parameters with the ReactToPlatform rule, which uses parameters initialized during LandOnPlatform).

Perhaps it's time I try to further abstract the rule system.  It'd really like to be able to implement all this complexity only once and then re-use it for sprite rules and global rules and whatever other rules might come along.  It looks like I need a rule definition system, and then I need to be able to use these rules within a sprite.  I wonder if I even need parameters directly on the sprite definition any more.  I'll have to think on this some more.

[bluemonkmn]

Well, I tried using Microsoft's classes for parsing C# code at runtime to provide a friendly interface to define rules based on customized code.  Then I found out that Microsoft didn't implement and logic in their class for parsing C# or in their class for parsing VB.NET code.  I guess the class is just there for other people to inherit from and provide their own implementations.  So rather than parsing the code to get information about what you can do with a sprite, I has to compile it into a little DLL and then ask the DLL what it could do.  That's working so far.  I've added a new folder to the root of the project for "Source Code".  You can't add or delete source code, but you can change the default source code.  There will be a preset set of customizable source code with each project.  This is analogous to the source code for GDPlay.exe in GameDev 1.x.  The cool thing is that you'll be able to customize the source code for each project and save it with your GDP file rather than having everybody agree on one standard set of runtime code.  Of course there are limitations: the source code must conform to some standards that allow the other objects defined in the UI to extend/interact with it.  But I think this will be a very powerful solution.  Each new project will come with a default set of source code, but within the context of an individual project, you can make significant customizations to the code.  And yet, you don't even need to look at the Source Code folder if you don't want to.

So far, all I have the are the beginnings of some (run time) default source code for a SpriteBase blass (the class from which all Sprite Definitions will derive).  But I am able to compile it to a temporary file to get the information about what kinds of rules/actions you can apply to a sprite.  This is where I'd forsee the ability to perform time-based movement instead of frame-based movement -- customize the SpriteBase class to move a sprite based on DX,DY and how much time has passed instead of just DX,DY.  I suppose multiple sets of default code could be provided for different projects too, so maybe I could provide a time-based project template that would include that automatically.

[bluemonkmn]

I finally got a chance to work a little more in the sprite rules code.  It can now return a list of functions that the custom code provides/implements and the names and types of the parameters for each function.  I'm in the process of returning information about the enumerated value names for parameters that are of an enum type.  This all has to be done accross AppDomain boundaries in order to make it possible to unload and delete the temporary compiled DLL, so it's a little complicated, but I'm getting used to that kind of thing now.  I did waste an hour or two researching it again even though I had researched it before because I gotta believe there's another way to make a call accross AppDomain boundaries without having to reference an external Assembly from the temporary assembly.  But I gave up once again and just allowed the temporary assembly to reference SGDK2IDE.exe.  They need to be using a common interface in order to transfer control accross the boundary, and the interface has to come from a single reference point, and the assembly containing that reference point will be loaded into both AppDomains (will not be able to unload until both other assemblies unload).

I was thinking more about this SpriteBase code that defined all the operations that can be done on a sprite within the scopr of a whole project.  It occurred to be that I could maybe at some point allow multiple versions of this class within a single project.  I could have other base classes derive from SpriteBase so that you wouldn't have to keep the same set of data and functions for every type of sprite in your project.  But for the first release, I'll probably just stick with one because I don't think it will be hard to add this feature later, and it might work out better when I have a better understanding of how the overall design will turn out.

[bluemonkmn]

"Fortunately" I sprained my ankle Saturday so I had good reason to stay home today and managed to get some good work done on SGDK2.

[bluemonkmn]

My focus is now more on figuring out what the runtime code will look like than on any design-time aspect of SGDK2.  It got to the point where I really couldn't make much progress without filling out most of the runtime code.  So I am leaving the details of sprite definitions aside for now and writing the code that will write the code for the game based on the project data.  I haven't committed any changes to subversion yet.  Hopefully I can get to a point where it is testable again and then I can commit some of the changes.