Scrolling Game Development Kit Forum
SGDK Version 2 => Help, Errors, FAQ => Topic started by: dutch_619 on 2008-11-18, 06:49:37 PM
-
I have had a few issues with importing audio from the FX library. I get an error message stating that SGDK2 failed to decapsulate info from the fmod.cs package. Is this a common error? Or perhaps I did something stupid...
I finally went back an finished a game I started oh so long ago and decided to do something new.
-
Hmm, seem to have gotten the problem more or less resolved. Still won't import, but was able to edit and add what I needed (and a little judicious copy and pasting helped).
-
Is there not a file "fmod.cs" in the directory with the SGDK2 file from which you are trying to import the sound? What version are you using?
-
It seems that I had some leftover files from a beta release of SGDK2 that caused an issue. After a complete uninstall and a clean install it ran quite smoothly. From there I just added the correct files and imported the audio (as described in the tutorial).
I am quite happy with the C# implementation too. I finally got an old old game to run, but it was ugly due to my inexperience with VB.
-
I'll try posting from my PSP. So you're saying you remade an SGDK 1.4 game in SGDK 2.0? From scratch? Any comments on how the 2 compare?
-
No, it was an alpha release of SGDK2 (I used the Beta name mistakenly). I did finish a game started in SGDK1.4 (at long last) which is how I started using SGDK2. I imported tilesets from the 1.4 rev as well as much of the various sprite behaviors. I did write the sprite behaviors in C# directly rather than using the rules creator. This was done as the alpha had some... issues.
As far as comparing the two, I find SGDK2 both much harder to use as the learning curve is steeper and at that same time a bit more intuitive. I find it easier to write/script behavior for a sprite in C# than it was in VB.
The released version of SGDK2 is much more polished than the earlier version with MUCH more functionality. While I still have issues with the graphics editor, the ability to export a sheet, then to re-import it with graphics added externally allows me to bypass this.
-
i say that SGDK1 is easier for beginners and SGDK2 for anyone with some game development skill
-
I guess I have a hard time picking up on the details when reading messages on that little PSP screen :-[. I see now you were talking about SGDK2.
Back on topic, I understand that importing audio would be more difficult than it was in 1.4. Are there other areas that are harder to use in 2.0?
-
Well, part of the problem may be in how poorly I described my problems :whistle:
The things I have found more difficult for the most part have had to do with the rulesets for sprites. A template of basic sprite behaviors as was available in SGDK1 might be a worthwhile thing. Just a very basic set of rules to import for left/right and 360 sprites would be nice to have.
A timer function might be nice to have as well. I have one built using the framerate limiter and a counter linked to it to let me do a "pause" in a map. This lets me play a movie clip on its own map and then jump to the next map.
-
Ah yes, the plan was to have an importable sprite template for each useful sprite type that SGDK 1 implemented. So far you have, left/right flat, left/right jump and left/right slopes, 360-degree car (new), 360-degree spaceship, platform (single-state), cannon (new) and a player sprite. Are there any other basic sprite types from SGDK1 that you found useful that you think should be made into SGDK2 templates? Were you aware of these sprite templates serving as the replacement for the basic SGDK 1 sprite types? (Are they fulfilling their purpose?)
-
Ah... didn't see know they were there in the source folder... I have been using the help file as I go, but haven't run through the tutorial project. I was attempting to have my sprite do the basic left/right + jumping left/right as well as an attacking left/right by using a rule-set to change the sprites state rather than switching to another sprite doing that action. I think I might need to do it via different sprites however, as my rule-set is already HUGE.
I did storyboard the entire game first this time however. This has proven to be very helpful! My previous tries with SGDK1 were frustrating due to this lack of forethought.
-
I think Tanja had a similar problem of the rules getting too complex to manage, and converted it to C# code instead. Maybe I should add a command to "Convert To Function" that would take all the rules in the current tree (or the selected branch) and generate a function from them which you could call with one rule. Then you could edit the rules in C# code and keep the rule tree simple. Maybe this would also address the other issue of displaying the C# code for the rules too. Thoughts?
-
I think that perhaps a set of modules to be called would be a good idea. Instead of importing a ruleset for a sprite, you could call a c# module of the basic sprite type. Then the rule tree could be used for any additional behavior beyond the basic sprite control. Perhaps have a basic value for gravity, inertia etc. set that would be edited to fit the users need.
So, perhaps a left/right and jumping sprite module and a 360 module to start? This would allow the user to have a ready to run basic sprite with only rules for attacks or special functions needed. Maybe a menu sprite as well? Something that simply snaps up or down based on the up oe down key to allow text to be highlighted.
-
The problem with delivering the pre-defined templates as "modules" is that makes the sprite less customizable and flexible. One of the goals of SGDK2 is to separate the features/framework into layers so that the user is free to customize the code at a level/layer they're comfortable with. In version 1.x, you only had 2 choices: use a pre-defined sprite type or script all of your sprite's behavior manually. SGDK2 creates a new layer of "Rules" that expose behaviors in a format that's (intended to be) simpler to use, but not as complex as coding, and more flexible but not as straightforward as simply selecting a template. And yet it keeps both other options open. You can still simply select a template, and you can still totally customize everything at the code level. If I were to convert all the templates into modules, it would defeat the purpose of having this intermediate layer where the user could perform relatively simple customizations to the sprites' behaviors because the rules would no longer be exposed. There are too many variables about a sprite's behavior (even those exposed in version 1.x); they just couldn't all be exposed by a single rule function without giving the user the opportunity to control them. In version 1.x you can control the gravity, inertia, input source and jump height (among other things). That alone represents too many parameters to pass to a rule function. To it seems to make sense to split it up a bit more as I have tried to do in 2.0 so that you have high-level functions controlling the sprites behavior at a level somewhere near the midpoint between manually coding everything and simply selecting a template. Ant the goal of limiting the number of parameters in a rule function to 3 is to help enforce the idea that these rule functions should be simple and easy to create. If there are more than 3 variables affecting a rule, the rule should be split into multiple rules to make more of it visible as separate components in the tree (or parameters tab) instead of having it all collapsed into a single tree node.
The reason I suggest having an option to convert a set of rules into a single function for non-template sprites is because you have the opportunity to customize those rules in the rule editor before converting them into a function. Also, the delivered templates are relatively short and don't need to be converted into functions. The number of rules on most of the templates is quite manageable. But I imagine that often times you can end up with some pretty complex sets of rules for sprites while incorporating or manipulating them for a specific project, unlike the templates which are just a simple framework for sprite behavior.
Does that make sense?
-
I believe you may be correct in thinking that a template "module" would reduce flexibility; at least as far as more complex sprite behavior goes. The importable templates are simple enough as you stated to remain in the rules editor. With that being said, I don't believe what I'm doing now is even possible in SGDK1 without a massive amount of scripting.
I think my main issue at this point is that I'm becoming a wee bit overwhelmed with the size of my rule-set tree. It's a bit intimidating. All in all I think SGDK2 is much more flexible than SGDK1 due to the changes in sprite behavior alone. I ended up having to use Visio to develop a flow chart to visualize what I needed to do.
-
Part of the problem may be how importing works. It's not immediately obvious to somebody who's used SGDK 1 how to create a left-right walking sprite. You say New Sprite, and you get this vast blank canvas which is not a step in the right direction. If there were a way to show the sprites in the library in a dropdown to select from when creating a new sprite (or able to select <Blank>) that might make things simpler, similar to how new projects are made from the file menu.
-
Now that would shorten the learning curve quite a bit, just by being able to see how a simple sprites rule-set should look. All that blank space is intimidating after SGDK1 as you said!
-
Good point. Also, I noticed last night that I should make all the generated and intrinsic source code come in the form of "partial" classes, so that custom code can extend these classes in independent files, allowing the code generator and the "reset code" command to overwrite the delivered code without interfering with the extensions. Then I can convert groups of rules to a partial class custom code file. So I will try adding that and also adding something to make the sprite templates much more visible.
-
I have updated SGDK 2.1 to allow the user to select a sprite template to import from a pop-up menu off the "New" command, which seems to work nicely. And I am partly done implementing a function to allow you to convert a set of rules to a function. I have it to the point where all the rules can be converted to code. Now I need to figure our the best way(s) for the user to specify which rules to convert, and whether/how they are deleted and replaced with a call to the new function. Then I'll probably compile and post a new beta release.
-
Sweet! I'll be sure to migrate to SGDK2.1 upon the Beta release of the update!
-
There you go... it's ready. You can also convert rules to functions.