Scrolling Game Development Kit Forum
SGDK Version 2 => General Discussion => Topic started by: billybob884 on 2007-01-29, 07:19:56 PM
-
Hey, i actually had a few questions as to what's in-store in terms of features for sgdk2.
the biggest question on my mind is this, will there be a way to make the player "hug" the ground (slopes) without having to pump up the gravity? like one of the most annoying things (for me, at least) in sgdk1 was that when u were walking down hill, u really couldn't jump, u had to stop walking before you could do so. i was hoping there would be some support for this in 2.0
another, albeit less important, question is, in sgdk you could make falling platforms, but if i remember right, it was tedious, and you had to setup the paths for each individual tile that would fall. will there be an easier way to do this and similarly repetitive things?
-
All that can be done in the alpha, I think. If you look closely at the rules in the player sprite, I think you will find one called something like "Snap to Ground", which forces the player sprite to touch the ground if it's within 2 pixels of it (or however many pixels you specify in the parameter). I hope this accomplishes the desired effect. I suppose it depends on where that rule is relative to the jumping rules as to whether you will be able to jump while going downhill. (If you snap to the ground first, and then check for jumping, it should work.)
Falling platforms should also be possible using logic similar to the floating scores that appear when you pick up a piece of fruit in the sample game (ie., when you pick up a cherry "100" floats up from it). Notice that the fruit simply consists of tiles. So if there's a way to make a "points" sprite float upward from a fruit tile when it disappears, surely there's a way to make a "falling platform" sprite float downward from a breaking bridge tile when it disappears.
If you investigate the rules on the sprites and plans, and look at the code in the source code folder, you might be surprised at how flexible SGDK2 games are compared to version 1.x games. All the solidity handling is in customizable code now. All the sprite movement is in customizable code too. Every rule you see in the sprite definition editor and the plan editor represents a function defined in the source code folder that can easily be customized by changing the code, and it is saved with your project so you don't have to rely on the right version of the engine to have your rules up-to-date. These "Rules" are kind of like special functions from 1.x, and the functions they call are kind of like the special function types (switch to map, etc), and the best part is now you can make up your own function types by adding a new function to the SpriteBase class or the PlanBase class, and it will look and work exactly like the default set of functions delivered with the basic installation. And all that without requiring changes to SGDK2 itself. You can even provide your own documentation for the function that will appear on the sprite definition screen when the function is selected. So I hope to see some other interesting project templates that people will provide with lots of new and interesting rule types added.
-
Ok, another question. i've poked around your demo a little, though not enough to say i have any semblance of a good understanding of it, so with that in mind, how heavily based upon actual scripting are games made with this engine going to be? because what ive realized i liked most about sgdk1 was that you really didnt have to have any programing knowledge to be able to make a game; once you understood the basic format of the special functions and tile interactions, you were good to go unless you wanted something complex.
as im sure you (or durnurd) remembers, i have virtually no scripting knowledge, so you can probably understand my concern. for example, you stated in a previous post (in this thread?) that not even the arrow keys are hard coded in. heh, i guess with the recent thought ive been giving to making a sequel, i'm just getting a little jumpy as to how complicated this may be.
-
The intention is that people still be able to make games without writing any code. So tell me if you consider this simple enough to be similar to version 1's functions (that you say you like) and not similar to scripting -- change the key that is used to jump by following these steps:
1) Going to the Sprite Definitions folder
2) Opening the "Player" sprite
3) Go to the Rules tab
4) Expand "If Climbing"
5) Expand "Else (not climbing) if trying to climb up"
6) Expand "Else (not trying to climb) if standing on solid"
7) Select "And pressing button 1"
8) Drop down the list for the "Input" parameter
9) Select InputBits.Up to make the sprite jump when up is pressed instead of button 1.
All the rules on that sprite might scare you right now, like "I have to make all these rules every time I want to add a sprite!?" but don't worry. First of all, the player sprite is much more complicated than the average sprite. And second, you don't have to define these sprites from scratch if you don't want to. The player sprite in that project, for example, was imported from the sprite library, and there will hopefully be many more sprites in the library in the final release so that every useful sprite type supported by version 1 will have an example sprite template that you can import to use as-is or build from. The cool part is now you can make your own sprite types with whatever states and rules you want if you have an idea that doesn't match any of the delivered sprite types (assuming you aren't scared of the rule system, which is hopefully still quite a bit easier than coding/scripting). Whereas version 1 was limited to "Single State", "Left/Right", "8-State" and "36-State" , now you can make up your own types, and many more types will be available in the library.
The hope is that the names of the rules (like "Else (not trying to climb) if standing on solid" and "And pressing button 1" are plain-English enough that someone who doesn't know how to code will be able to find the rules they want to fiddle with and make changes that might get them what they want. The hope is that this rule system is about as simple as the special function system, but much more powerful. Let me know how successful that was :). Documentation might make a big difference here, so if you find anything particularly confusing here, let me know, and I'll try to remember when writing the documentation to make a note of it and go into more detail in that area.
-
Oh, that reminds me, I think the indentation should be a bit more like programming in that tree, where you can see the ELSEs and the END IFs even if the IF isn't expanded (on the same level) so you know the general outline of the code, even if it's completely unexpanded.
-
Oh, that reminds me, I think the indentation should be a bit more like programming in that tree, where you can see the ELSEs and the END IFs even if the IF isn't expanded (on the same level) so you know the general outline of the code, even if it's completely unexpanded.
So did I, but that doesn't work out very cleanly, unfortunately. It's weird to have a node that doesn't have any data... you click on it and what happens to the pane with all the data... just disabled? A number of things get more complicated if I try to do that, unfortunately. I suppose I could try again, but I was hoping people wouldn't mind the current structure in which every tree node maps to exactly one real rule... err... except for the Ends ;D.
The current structure is just more straightforward internally because the "else" and everything in it are still subordinate to the whole condition statement.
-
oh, well that doesnt sound too bad. im sure its just like anything else that'll take a little practice and maybe a tutorial to get used to. just at first seeing all the code u had written in the scripting folder got me a bit jittery ;)
-
All the code in the Source Code is there for customization, but it's all generated when you make any new project by default.
-
how about sprite collisions in sgdk2? like the 2 main things i can think of is, say for example, you have an enemy with spikes on the top of it, and you only want it to hurt you if you touch the spikes on top. will you be able to do something like that? or again where it may be even a little more complex, like having a pillar slamming up and down from the ceiling, you want it to kill you if it comes down on you, but not if you run into the side.
-
What, sort of like hitpoints? That would be really cool.
-
Yea basically, the only example I can think of off hand is in Mario when you have to jump on the little mushroom guys. I know that someone was able to do something like this in sgdk1, except that you had to have 2 separate sprites right next to each other and a bunch of special functions. It wasn't that hard, it was just annoying to do ;)
Actually, another question (lol, I may as well just ask now). I've actually been brainstorming a little about how I would go about making another game.., and my question is this. How customizable will player sprites be? Because I've been thinking about how I'd like to be able to set it up.
The concept isn't too bad. It would basically be three 'states'; a 'normal' state, a 'hurt' state, and an 'invincible' state. The way I would like to do it is each state would have only a left/right for each 'position', a stading left/right, a walking left/right, a jumping left/right (a rising and falling for facing each way, so 4 total for this one), a crouching left/right, and a crawling left/right. The only catch is each position's tiles would be different in each of the three states.
:) I hope I'm not explaining this too poorly. Like, the normal state would look like all the original animations in my first game, but then the hurt ones would be flashing, and maybe like a color change for the invincible ones, or something. I don't think that I could have done this in sgdk1 because I would have had to have 5 sprites for each state, and there would be a problem with switching to the right state's position. How feasible does something like this sound? Would it be ridiculously hard to implement, or would it be doable?
-
how about sprite collisions in sgdk2? like the 2 main things i can think of is, say for example, you have an enemy with spikes on the top of it, and you only want it to hurt you if you touch the spikes on top. will you be able to do something like that?
There are three ways I can think of to deal with this in SGDK2, and the best is to create a sub-framed sprite. Each sprite definition has a number of states, and each state has a number of animation frames. Because you may want collisions to be handled differently depending on what the sprite currently looks like, each frame in each state has its own collision mask (based on which pixels of the frame are beyond a certain opacity level). This achieves the same effect you got in version 1 with sprite collisions being based on non-transparent pixels overlapping. SGDK2 goes a step farther when it allows each frame to be composed of sub-frames (frames whose delay is 0, meaning they get merged with the next frame). You can set the collision mask for each sub-frame separately too. So you could put the spikes in one sub-frame and set its mask to pixels with an alpha level of 127 or higher, then put the rest of the creature in another sub-frame and set its mask to empty (alpha greater than 255, which is impossible).
or again where it may be even a little more complex, like having a pillar slamming up and down from the ceiling, you want it to kill you if it comes down on you, but not if you run into the side.
This might be more challenging if you want collisions with different parts of the same sprite to be handled differently (one collision stops the player from moving farther into the pillar, and another hurts the player). This one would probably require multiple sprites and the use of a function (already delivered in the default source code, I think) that sets the position of a sprite relative to the position of another sprite.
The concept isn't too bad. It would basically be three 'states'; a 'normal' state, a 'hurt' state, and an 'invincible' state. The way I would like to do it is each state would have only a left/right for each 'position', a stading left/right, a walking left/right, a jumping left/right (a rising and falling for facing each way, so 4 total for this one), a crouching left/right, and a crawling left/right. The only catch is each position's tiles would be different in each of the three states.
Invincible and hurt wouldn't necessarily need to be states. They could be counters that affect the player's color. That's relatively easy to do with a call to modulate a color channel on the sprite based on a counter value or a sprite parameter value (you can have a rule that, when the "hurt" parameter is 1, toggles another counter between 127 and 0, and sets the alpha channel to match in order to make the player flash translucently). But if you want to use separate graphics for all those states, that's possible too. It just gets a little more difficult to manage. But there's no trick to it really. It's all quite straightforward. You just create a state for each of the states you mentioned above, define the frames in the states, and then define the rules that determine when the player switches to those states in the Rules tab. Defining the rules would probably be the most tedious part because you would have to, for example, define a separate rule for switching from left normal to left hurt and one for switching from right normal to right hurt if you want to really use separate states for normal and hurt. Anyway, it's much more practical than it was in version 1.
-
Invincible and hurt wouldn't necessarily need to be states. They could be counters that affect the player's color. That's relatively easy to do with a call to modulate a color channel on the sprite based on a counter value or a sprite parameter value (you can have a rule that, when the "hurt" parameter is 1, toggles another counter between 127 and 0, and sets the alpha channel to match in order to make the player flash translucently).
yes, either flashing transparency, or maybe flashing red. either way, thats exactly what i want for the 'hurt state'. the reason why i think the 'invincible state' will need its own sprite is because i will probably want it to be consistent with the first game, and in the invincible state, you were 'powered up', u ran faster, jumped higher, etc.
-
Those could all be dealt with in counters as well. Just have the jump height be a counter that's normally set to 10, when they're invincible, set it to 15 or something. Same with speed.
-
One thing you may not have realized is that states are not tightly integrated with rules, so creating a new state in itself doesn't make the sprite behave according to a new set of rules. Switching the sprite to a new state would only do that if you create the rules such that the sprite behaves differently when it's in that state. You may have noticed that the states defined for a sprite don't have that much information associated with them. And in fact that is the extent of a state. All it has is the appearance of the sprite, the collision masks for that state, and the solid size of the sprite when it's in that state. The rest is all rules. So if you want the sprite to behave differently for some reason, that can all go into the rules. The only time you need to create a new state is if you want the solid size of the sprite to change, when you want it to collide differently, or when you want the sprite to look different in a way that can't be accomplished by modulating colors/alpha on an existing state. Even changing the solidity definition that a sprite uses is done on the sprite instance with SetSolidity (or something similar -- can't remember exactly), and is not hard-wired to the state.
-
I was wondering if solidity is done by the sprites tile or the non-transparent pixels.
-
The interaction between a sprite and a tile is calculated by comparing the solid area of the sprite (a rectangle defined by the sprite's solid width and solid height) against the shape of the tile (which can be all the shapes from GameDev 1.x plus a few more, and you can define your own too). The collision between two sprites can be based either on the solid rectangle of the sprites or on pixels of the sprites beyond a specified alpha level (up to the user).
-
I just tried editing the SHFL example project. This is really cool! ;D Ladders and springs were placed by putting down a tile. :) This is much easier than in SGDK1, where you'd need a lot of special functions and a sprite for each ladder or spring. I expanded the map and added a few extra spots to go. ;) I tried changing the scrolling parameters for the map. Much better than before, you could change individual scrolling parameters for each side of the screen. I did some other stuff too but they were little things and I can't really remember them. Nice work this is looking really good. :D
-
Glad that you're getting a chance to play around with it, and that it's working out well for you. There is indeed a lot of new stuff to explore. If you're feeling adventurous, you could start looking into the rule systems (Sprite Definitions and Plans) and maybe even the source code to see what adjustments, modifications, or even new developments you can come up with there. Springs work by a bit of custom code. Obviously not every game in going to have springs in it, and there is no intrinsic support for springs in SGDK2, but if you look at (I think) the source code objects, you will find the custom code that was added to this project in particular to make specific tiles behave like springs. But you can still have plenty of fun without getting into the source code, too.
-
Yeh, I plan on trying to make something with SGDK2 in the near-future. I've got a question. Will it be possible to play an SGDK2 game in an internet browser?
-
SGDK2 cannot currently play in a browser as far as I know. However, the architecture is such that it should be possible because its games are .NET programs in a single file, which would work well for a download-able component in a browser, but there appear to be security issues related to accessing DirectX and/or some other activities that the generated games perform. If someone wants to investigate what would be necessary (what would need to change) to make the games playable in a browser, I would be interested in collaborating on implementing features to support this, though.
-
There are ways to compile a .NET project as a COM-visible DLL, which can then be used as an ActiveX object in an <object> tag in a web page with classid="Filename.dll#namespace.classname". It would take a bit of reworking of the underlying code for the Project and the GameWindow especially. But it can be done, I think. It would only work for Internet Explorer, since Firefox doesn't support ActiveX controls, but it's a start. Because there are also ways to embed COM components within Java programs, which Firefox is able to run. So you could use the Java framework to allow Firefox to access the .NET framework to get something up and running in most browsers. Maybe. I'm not sure of how the DirectX would behave.
-
I think the security issues with COM are worse than those of .NET. If you want to just ignore security, there are probably better ways to do that without resorting to COM. I'd hate to resort to the quagmire of COM for such a nice, clean application.
-
Well, it's the only (well, first) thing I can think of to embed it into an HTML file. And it's not really COM, it's just COM-visible, but the security is still based on the .NET execution permissions. I got a simple app to work earlier today, and I just had to add http://(domain.tld)/* to the .NET permissions to get it to work.
Of course, it would be annoying if everybody had to do that just to play the game.
-
What if you add the URL to your trusted sites? If that's not enough, what if you then add a permission to allow .NET code from trusted sites to run with more permission (which I believe is one of the rule types you can set up in the .NET configuration)?
-
I added the URL to trusted sites, which was already in the .NET permissions list with "Internet" permissions, which is not enough to run SGDK2, I'm betting. It came up with the usual security error. Changing the Trusted Sites permissions to full-trust worked, but then somebody still has to change .NET permissions.
-
I would do this myself, but I'm working on many other things of course, so I'll pass the question along to you again in case you have an interest in looking into it further :)
By compiling it in debug mode (or through any other means you can think of) can you determine why it's complaining? What causes the security exception?
Are you trying to run SGDK2 itself or a generated project. I'm thinking a generated project would be a good thing to try.
-
Oh, yeah, I was trying SHFL at the time, not SGDK2. Details:
The action that failed was:
InheritanceDemand
The type of the first permission that failed was:
System.Security.Permissions.SecurityPermission
The Zone of the assembly that failed was:
Trusted
I have also found that turning the GameForm into a user control instead of a Windows Form presents some problems with specifically the keyboard.SetCooperationLevel, among other things. When commenting out the keyboard line, the other main problem is that when adding a GameForm to a Windows form, the Windows form doesn't even show up. I've only tried a few quick hacks to get it to work so far, but nothing has worked yet.
-
Durnurd, do you have internet explorer 6 or 7? It might have a different result.
-
Strange. Well, keep hacking if you have the time. It'd be interesting to know how close we are to allowing SGDK2 projects to run on the web. Also, do you know if .NET controls can be embedded in FireFox?
-
I have IE 7, just for fun. I know that .NET controls cannot be embedded in Firefox directly, but they can be used in Java via COM, which can then be embedded in Firefox. I haven't tried it, so I don't know how well that would work.
-
Good news, in some sense. I hacked together a working example of making it work, somehow. Only the menu works. It crashes as soon as you select "Start a new game". On my local web server, the error comes from .NET, saying that it can't find the assembly SHFL when trying to deserialize in the GameLoad function. Online, the error comes from Internet Explorer crashing.
It takes several seconds to download the entire thing before you can play it (~500KB), and even then, you can still only get the menu to work. Better than nothing, though!
Oh, and one more thing. You need to give full permissions to the running assembly, either by zone or by URL. Here's the sample:
http://www.beardedchild.com/files/ActiveXTest
(Remember, it only works in IE7, and it will crash if you select anything from the menu)
-
No more progress yet. If anybody wants to try their own hand at it, I can upload the source files to download. The good thing to note is that it does work as a COM control in itself rather than a form, so that it can be put in any form (from a different programming language, for example).
-
I've got it working locally now without sound. I found several people who had almost exactly the same problem I've been having, and that is that the deserialization of the SaveUnit was trying to load the SHFL assembly, and it wasn't finding it, because it was looking in the wrong locations. I used one of the solutions in This Thread (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=888375&SiteID=1&PageID=1) in the LoadGame function which remedies the problem.
In short, I can now play the game in Internet Explorer!
Unfortunately, as I anticipated, loading fmodex.dll is presenting some problems. I'll look into that next. But if you aren't using any sound (or other external files) then it should work just fine!
The solution I see right now is embedding the DLL into the game and loading it dynamically from a stream rather than a filename. Unfortunately, I don't know if that's possible with an unmanaged DLL. It might be possible to write out the dll to the application data directory from within the program just before using it and then referencing it. I'll keep this thread updated on my progress.
-
Okay, so it's a hacked together example, BUT:
A fully-functional example (WITH sound) of Super Happy Funland, as playable in Internet Explorer 7. It works by checking to see if fmodex.dll exists in the current directory (which happens to be my desktop when I try from IE), and if not, writes it out from an embedded resource during project initialization. It makes SHFL significantly larger, and it's rather conspicuous on the desktop, but hey, I got a fully-functional SGDK2 game to work in an internet browser!
Link: http://www.beardedchild.com/files/ActiveXTest/
The only downside I see right now is that there appears to be no way to close the browser without closing the process from the task manager or navigating away. I don't know why. And navigating away continues the music playing in the background. I imagine it most likely has something to do with the fact that I had to get rid of the Close event when I turned the GameWindow into a UserControl. Anywho, let me know if the example works for you.
-
Well, I can't get around the security problem. I went to .NET configuration and set trusted sites to have full trust, and still got the exception. Oh... I guess that's because I only have .NET framework configuration for .NET 1.1.
So here it is for anyone else who wants to try modifying their permissions to allow this to run. Go to Windows\Microsoft.NET\Framework\v2.0.50727 and type the following:
To check your current permissions:
caspol -m -lg
To add Full Trust to sizes in the trusted zone:
caspol -m -cg Trusted_Zone FullTrust
After doing this, however, I got an error at a familiar place you mentioned:
Microsoft.DirectX.DirectInput.Device.SetCooperativeLevel(IntPtr hwnd, CooperativeLevelFlags flags)
So Durnurd, is it possible to make all the changes by just modifying code that's editable in the project, or would you have to modify the code generator?
-
Hmm, I thought commented that line out. Checking... checking...yes, I did indeed.
Oh, that was only for the keyboard. You have a gamepad. I didn't comment that out.
I can make almost every change without the need to change the code generator. The only problem that arises is project.cs. It creates a New GameForm and sets its Game property to it, and that, in the end, is what runs the project. However, when turning the project into a runnable control, it's looking for a Control to call a constructor on rather than a Main() method. So it would call the constructor on the GameForm, which I could modify to do everything except set the project's Game property. The way I got around it was by changing the void Main in the project to a project.Init() call, which I called from a wrapper class which is the one that you embed in the web page. I changed the GameForm into a Singleton and just called the GameForm.Instance() and changed the project.Init() to set its Game to GameForm.Instance() as well.
So I would need to be able to edit Project.cs as far as I can tell.
Unless... if I changed GameForm into a wrapper class for the instance variable of the Game (GameControl, for example) by just copying GameForm and only doing a call to all of the functions directly. It seems like a lot of work though. But it would be possible.
So it's possible to make all of the changes without changing the code generator. But I think having access to the Main() method or Project.cs would make it easier.
I updated the sample project so that it will run with a gamepad now. I also changed it to an .EXE so it's executable as either a game in itself or as a control in another program (like IE7). Try it now:
Link: http://www.beardedchild.com/files/ActiveXTest/
-
Wow! Nice work! So I should probably pull out the pieces of Project.cs that are generated and make Project.cs visible as a Source Code file and have only the few generated pieces in a generated file of their own. Oh if only I were using .NET 2.0 I could use partial classes. But I think I'll still hold off until a later release to upgrade to 2.0.
So this was pure .NET with no ActiveX, right? I think people will be quite impressed if I can tell them that SGDK2 supports games embedded in web pages (with just a couple modifications to the client's security settings ;) ). Next question, I guess, is if there's any way to run without needing the extra security. If DirectX is insecure, there must be some technology that SGDK2 can target that IE/.NET won't be quite so paranoid about -- Flash perhaps? Whatever it is, it would have to be able to integrate with a .NET application's UI.
-
There was no ActiveX involved, correct. I just made changes to the .NET code, and included an object in an HTML file from the created assembly.
As for the security permissions, I don't even know how to look into that. Those confuse me way too much. I'll leave that up to somebody else for now. And that somebody else might also want to look into other ways of using fmodex.dll also :)
-
I'm trying it right now. ;) My internet real slow, I passed the monthly download limit, internet now goes 36kb/sec and compared to the normal speed of 100MB/sec for my internet, it seems extremely slow. :-[ This could take a while. :(
-
Ok, this is taking too long. I'll wait until March when my broadband is back.
-
normal speed of 100MB/sec for my internet
Woah. 100 MB/sec? Could you seriously normally download a whole CD in 7 seconds?
-
That would make sense, but I doubt it. Web pages usually load in 1 second or less, but saving a file to your computer off the internet is slower for some reason.
-
Looks like DirectX needs FullTrust to run. I asked about it on the MSDN forums. Here's what they had to say:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1269780&SiteID=1
-
Hmm... This WPF stuff looks promising. I might just have to jump straight to .NET 3.0 if it means SGDK2 games could run in a browser without security issues. Wikipedia seems to have some good info: http://en.wikipedia.org/wiki/Windows_Presentation_Foundation (http://en.wikipedia.org/wiki/Windows_Presentation_Foundation)
-
Ok, I just downloaded alpha 2. (I'm the first person yay! ;D) I like the new UI in the frameset editor. :)Haven't tried the writing functions yet, but plan to. ;)
-
Can SGDK2 play MIDI's?
-
Yes, the same way as any other sound file, but it doesn't sound as good on high-end sound cards if you play it that way because in the interest of cross-platform consistency, FMOD has elected to re-implement its own internal MIDI syntheizer without using the sound card's sound table. Really you can use anything you want to play back sound files, but FMOD is the only sound library that I'm delivering with SGDK2 right now. I don't know if there is a good way to stream MIDI files from memory through other mechanisms, which is what SGDK2 "wants" to do. But any mechanism could be added to a project as a customization to allow you to play MIDI files either from disk or from a resource embedded in the EXE file.