Scrolling Game Development Kit Forum
SGDK Version 2 => News and Announcements => Topic started by: bluemonkmn on 2007-12-13, 06:30:22 AM
-
I posted a new release this morning that may represent the functionality of the official release. A few problems from the last beta were fixed, and judging by the number and severity of fixes going into the product now, I think it's safe to think about releasing this so I can get started on version 2.1!
The following fixes are included in RC1:
- When importing a source code object, make sure that any existing window containing source by the same name is closed before importing so that further editing in that window does not cause the import operation to be effectively undone.
- In the plan editor and sprite rule editors, display the status and type of each rule with an icon in front of the tree item in order to more clearly distinguish the types of rules and whether or not they are suspended.
- Add a command to the plan and sprite rule editors to suspend the selected rule as well as all of its children.
- Fix the layout of the sound preview window launched from the Source Code editor so that the volume slider does not overlap the buttons.
- Fix an error in resizing the map editor.
- Implement command in code editor to export embedded data to a file.
- Document "Export to File" command in source code editor.
- Document "Toggle Suspend for This and Child Rules" command in plan and sprite rule editors.
- Add tutorial for importing sprites.
- Fix bug in frame remapping wizard that caused an error when appending frames to an empty frameset.
- Change about dialog to indicate "Release Candidate 1"
-
good job. ^^
-
awesome, nice work bluemonkmn.
-
I think I'll let this go for a week or two and if nothing critical comes up, do the actual release. Still just a release candidate at the moment. Let me know if you find any problems.
-
one thing sgdk2 needs is publicity. :( It is most definantly better than game maker, and game maker is popular because everyone knows about it. :/
So... I shall post links in IRC and on forums :) If others could 'advertise' as well, then SGDK2 could be very successful. :D
SGDK2 deserves to be well known, with heaps of people to enjoy it. :)
-
good idea jam, too bad that i am not in the homebrew scene. :(
-
but i will sgdk2 give a lot of credit whenever i show my game (presentation at the uni, portfolio, pixelart-sites when the style is still pixelart then, sites for downloading free games) ^^
-
I've been holding back a bit on the publicity during pre-release stages of SGDK2 because it would probably be a big mistake to go hype something that doesn't work right and turn people off because then they think SGDK2 is a program that doesn't work (and won't try it again when it does). But I think it's ready now.
I suspect that publicity isn't the only difference between Game Maker and SGDK2, though (it'd be cool if it were). It's like the PS3 versus the Wii. The PS3 is technically superior, but the Wii appeals to a wider audience. Although SGDK2 may be technically superior in some regards, I think Game Maker might know better how to appeal to a "lower common denominator" by being more visual and covering a broader range of game types. (It seems that the author is now working for a company that is supporting the product full time now, so it could be hard to compete with that, except for the fact that SGDK2 is totally free and open with no registration or restrictions involved.)
What SGDK2 really needs is some big flashy games that demonstrate the power that it has that no other program has... what you can do with SGDK2 that you can't do nearly as easily with anything else. People who are looking around for a game creator don't have time to do a full investigation, but I think if they saw the games that a particular engine could create, they could be heavily swayed. I believe they call this the "Killer App (http://en.wikipedia.org/wiki/Killer_application)". SGDK2 could really use a Killer App. And I think SGDK2's killer app would be a huge epic platform game (that also includes some mini games and other non-side-scrolling views for parts) that's really fun to play ... so fun that people are dying to add their own levels to it or edit the existing levels. Maybe it would include a feature that seamlessly links to levels that are downloaded at runtime so the game is always changing or different every time you play.
But until this killer app exists, we'll just have to try recruiting people with old fashioned publicity. I'll begin that publicity myself when I do the official release, but you're welcome to get started early.
-
is downloading and playing of maps from the internet possible yet? that sounds really good...
-
Possible, yes. Not easy, but possible. You'd have to write a lot of custom code. The things that are readily available to do in SGDK2 do not define its limits. The custom code objects folder expands the possibilities greatly. You could write a pixel shader to apply to the screen, or you could completely rewrite the display engine to draw objects with dynamic shadows. The possibilities are really much larger than what is built in.
-
I just wanted to add that BlueMonkMN is awsome
-
Downloading maps could be easier than you might think. .NET has framework objects to access data over the web, so all you'd need to do is use one of these and download the data into a memory object that you could then use with (for example) the LoadGame function. If the data that you stored was in the right format, you could be loading games over the web. I haven't tried it myself, but it'd be cool to try someday.
And I must comment that acbf7wx is pretty remarkable herself :)
I hope that game she's been working on becomes available for all to see someday.
-
couldnt u just download expansion packs for games, and have them all programmed into the game beforehand, if it doesnt find a map, instead of returning an error and crashing, it could just force u to play another level that that expansion pack wasn't needed for? (two that's = confusing, hope everyone understood lol)
-
You could, yes, but I think the idea is that you can generate new maps even after the game is out, i.e. any user can make levels for your game and allow anybody to play them.
-
i suggest to add a "relative position"-parameter to the "follow plan"-method. like it was possible with version 1.
and a "match a sprites position relative"-method. so when a sprite is attached to another sprite, one can still change the position of the child at will. the child will follow all moves of the parent sprite at its own position.
one more suggestion: i know your sprite definitions are quite short, guessing from looking at the sample sprites. but me, i am not so good/effective at scripting, and like mentioned in the thread about the air stream tiles, i have a very long sprite definition. at my 1280 screen, i have to scroll now to see the bottom. it is sometimes hard to keep track of all functions. i figured out how to use suspended rules as "comments".
i suggest the following:
the introduction of "code blocks/boxes". this means i can collect a bunch of rules in something like a box, which is displayed in the rule editor. i can open and close this boxes just like an if-rule. every box could has a description text on it, just like naming the rules. what do you think?
-
It would be simple enough to do this by creating an "If" rule that is suspended and give it whatever name you want as description.
-
yes. but i don't like to write senseless functions, and it would be user/newbie-friendly.
-
Why don't you like "senseless functions"? Either way, it must take a row in the tree view, and either way, it will not affect the generated code, and either way it will show whatever comment you want for the block. I think you could even put "CommentBlock" (or whatever you want) as the name of the rule function to call to indicate that this rule is just a block header.
But I should also point out, the rule system is intended to be a very high level designer that chooses which behaviors a sprite or plan will use, not define every detail. So if you are getting too many rules to manage, I think it's an indication that you should move the code into a custom object or add some code to SpriteBase.cs to simplify the rule definitions for the sprite. My original thought was that a sprite could maybe even have just a single rule like this:
FollowFloor
Then all the details of that behavior would be in code. But I decided to not be quite so high-level because you should be able to customize it a little. Is there any way you can simplify the rules that define your sprite's behavior by moving more into the source code? (You remember that you can just copy the code generated by compiling the project into a function, right?)
-
i remember this. ;D maybe i will try it some day (i am little bit scared of it and have only time for the most important things now... time is running out for me)