Scrolling Game Development Kit Forum
SGDK Version 2 => News and Announcements => Topic started by: bluemonkmn on 2006-01-02, 09:51:54 PM
-
I think I am going to start trying to post information about the current SGDK 2.0 status here, kind of like a blog. We'll see how long I manage to keep up with it.
Since the pre-alpha demo I have fixed some minor synchronization issues and errors. I also filled out the XML dataset so that project schema is now prepared to contain a number of other kinds of data (I don't remember if any of this went into the pre-alpha demo or not) Anyway, the most recent pieces of data that I have added to the schema are:
1. Sprite Definition (a root level object -- can be used on any map -- YAY!)
1.1. Sprite State (child of Sprite Definition)
1.1.1. Sprite Frame (child of Sprite State)
1.2. Sprite Rule (contains kind of "script" code for each sprite; child of Sprite Definition)
1.3. Sprite Parameter (allows an arbitrary number of different named parameters for each kind of sprite; child of Sprite Definition)
2. Sprite Category (Categorizes sprite definitions; replaces collision classes)
2.1 Sprite Category Sprite (assigns any number of sprites to any number of categories)
3. Sprite (Represents a sprite instance; child of layer; related to Sprite Definition)
3.1 Parameter Value (each sprite instance has a value for each Sprite Parameter in the Sprite Definition)
4. Coordinate Path (Path that a sprite can follow; child of layer)
4.1 Coordinate.
5. Category (Used to group tiles into categories)
5.1 Category Tile (Specifies which tiles are in the category)
5.1.1 Category Frame (Limits which frames of the tile are included in the category if limited)
6. Solidity (Defines a global set of rules for determining tile shapes; multiple named rule sets can exist)
6.1 SolidityShape (Associates a category of tiles from a tileset with a Tile Shape)
7. Tile Shape (Creates a named tile shape based on a mathematical formula; for example "y >= x" represents a downhill shape)
Every child (an item numbered with multiple numbers) represents a 1-to-many relationship. Any object that is a child of another object represents a piece of data on the parent of which the parent can own any number. (A sprite definition can have any number of sprite parameters, for example.) Every item with only a single-component number above represents a root-level object. Root level objects generally represent a global list of named objects that will appear at the top level of the tree.
This is just a quick summary of what I'm preparing to implement. I haven't described in detail how all the objects relate to each other and all their properties, but I do have all that laid out in the schema right now. If you're interested in more details on any particular aspect, feel free to ask. I have only listed new objects (objects that were not already included in the pre-alpha demo).
Current status: I'm now working on a UI to add "SolidityShape" data... in other words, a window where you define which tile categories map to which tile shapes. I have already completed the window that allows you to define arbitrary tile shapes based on a formula and preview them. I have also completed the window that allows you to categorize tiles and optionally include only a limited subset of frames from multi-frame tiles. (If you fo not limit the frames, then all frames are included by default.)
My most recent challenge was figuring out how to embed a combo box in a data grid column, but I think I have that figured out now.
-
This morning I verified that the SolidityShape grid seems to be working, and filtered the category column based on which tileset was selected. The grid has 3 columns: Tileset, Category and Shape. When you select a Tileset in the first column, the "Category" column's combo box will be populated with all the categories defined for that tileset. Then you can select a category and specify a shape for all the tiles in that category.
On my way in to work, however, I realized that there's probably an issue with the timing on when the category combo box is populated. It is populated when the value in the Tileset combo box changes. But what if you select "Tileset 1" on row 1 of the grid and select "T1C1" for the category, then you select "Tileset 2" on row 2 of the grid and select "T2C1" for the category, then click on the category cell for row 1? I suspect it will still be showing the categories for Tileset 2 because each column uses the same combo box for the whole column. So at my next opportunity I will test that and probably have to refresh the category combo box whenever the current cell changes based on the Tileset value for the cell's row.
-
I tested and confirmed that the suspected problem was indeed a problem and fixed it. In the process I discovered that I had neglected to set up a relationship in the schema between the Solidity table and the SolidityShape table. This was the cause of a problem I ran into a couple days ago that forced me to manually specify the value of the "SolidityName" column in the Solidity table when the grid added a new row. It was really bugging me that it wasn't doing that automatically and I couldn't figure out why so I finally gave up and did it manually when a new row was added. I'm so glad I found the right/easy way to make this work. I like deleting unnecessary code. Of course it's always preferrable to get it right in the first place, but at least when you're deleting code, you know you're headed toward more simplicity and in the right direction. The good news is, there's a whole lot of "simplicity" going on in this project so far. A lot of it just feels right.
For those who may be interested, the thing I have discovered about Microsoft's XML schema generator and the way that Visual Studio generates code from it, there are interesting ways that nested parent-child relationships need to be set up. I tried a number of things and finally finally found the "simple" solution there too a while back:
1. If you create a parent table and a child table without making the child table an element in the parent (without nesting them) you can set up a relationship in the schema between the tables, and you will get nice functions for retrieving related records generated for you. However, when the XML data is written to a file, the data is not nested. It comes out just as two flat lists of data, and every child item has to include and repeat all the parent value keys in each record in order to maintain the relationship.
2. If you nest one table as an element in the other, then you can get the nice relationships in the XML -- it's all hierarchical like XML should be and the child elements don't have to explicitly show the values of the parent keys because they are implied by the nesting. However, then you run into a problem in the generated code where there's an implicit relatipnship that is maintained entirely separately from the explicitly listed columns. So, for example, my "Solidity" table has a "Name" column, and my SolidityShape child table has a "SolidityName" column that related each child record to the parent Solidity record. But now the code generator will generate an implicit "Name" column on the SolidityShape table to relate it to the parent Solidity records (when it sees that it is a nested element)... Agh!
3. Finally I discovered that if you nest the child table as an element in the parent table and also set up a relationship based on the parent table's primary key (and set the relationship's "nested" property to true), then the code generator appears to utilize this relationship to consolidate it's understanding of the relationship into a simpler entity... so that both the XML generation and the generated columns and methods all come out just like you want them. You have generated methods that will return a child record's parent, to return the parent record's children, and all the columns are set up just once and, apparently, the framework code that wants to use the schema to create new rows now knows how to automatically relate child records to their proper parents.
Whew! And so I forgot this one relationship and I didn't notice that it was missing when I started seeing these problems until I was testing this other problem. But I'm glad it made itself noticed to I could delete some unnecessary code! It looks like the Solidity definition UI is working nicely now. It's not very keyboard accessible yet (almost have to use the mouse), but I'll leave that for another day... it's late.
-
After taking a couple days out to review and post a couple GameDev 1.x games, I'm moving on to SGDK 2.0 sprite definitions. I've just started laying out the UI. And then the first thing I did was realize that sprite states should be named and not numbered, so I went back to the schema and changed "StateIndex" to "SpriteName". I think it will be nicer to refer to the "Jump Right" state rather than state #3 or whatever.
I'm excided about moving on to this area of work. Sprites are the real guts of where all the work happens in SGDK. I think the SGDK 2.0 sprite system will be a significant improvement over 1.x. I don't know all the details about how it will work yet, but the schema is set up to be pretty flexible. Sprites will have built-in little "scripts" that will get compiled into the generated EXE when you compile an SGDK 2.0 project (actually they're just rules that get converted to code and compiled -- not script). So they will be very flexible. What I have left to work out is what kind of wizards/templates to offer to help users create sprites with as much ease as 1.x, while still offering all the new flexibility.
One step at a time. First I have to get the basic state/frame definition implemented. Then implement the ability to define arbitrary parameters. Then I can finally move on to defining rules for how to use the parameters and code to switch between states and animate the sprite.
-
hey, i have a Q, is sgdk2 going to be purely isometric? or is it still teh same side scrolling as the current one? for some reason i remember the first one looking like 'age of empires'-styled, and im too tired right now to go looking for the screenshot.
-
The isometric view is just one thing you can do with SGDK2. It was more of a trick than reality. The map tiles are still based on straight square tiles. It was just the way the frameset was defined that made the isometric look possible. However, SGDK2 is still heavily based on Side-scrolling.
-
I think I've finished the sprite state editing tab of the Sprite Definition window now.
-
I started working on the Sprite Parameters tab this morning, a very simple tab.
-
I have a question about SGDK2.0. Is it possible for you to just implement a 2-Player choice into this engine? I was just thinking about it the other day, and was wondering if this could be part of the engines architechture, rather then just a script. A script, to me is just fine, but it could be so much better implemented into SGDk2. Normally, I wouldn't complain about this, because I could just use the aforementioned script, but I was thinking that if it was put into the engine, you might be able to have a choice of which map could be two player enabled. Then, maybe, our games could have a co-op mode, and a single player mode or a single player mode and a multiplayer mode. This would really make games more interesting.
The now script makes it so that on every map, there are two players, rather then just having a choice. Sorry for butting into your 'blog' here, but This was just bothering me. :) [I sure hope this made sense]
-
I'm hoping that the "sprite rule" system and the "global rule" system that will be introduced into SGDK2 will be flexible enough to handle that. Some of you may be familiar with how a script normally simply calls "Play" after defining all the events to start playing the game. Well, "Play" is a hard-coded function in GameDev 1.x that runs the game and manages the player and scrolling and everything. And although I think it's possible to NOT call play, and to instead manage all that in script yourself, nobody has done that yet, probably because it's a big step up in complexity to re-write all that code in script instead of just calling Play. (Play is also the function that GameDev calls on itself if you don't have a script.)
Well in SGDK2, I am planning for the global rule system to expose the whole "Play" function to the user. So you won't be restricted to a specific pre-set function that manages the player and everything. You will be able to generate the code based on some template (like a 1-player auto-scroll template or a 1-player sprite-scroll template or whatever). Then instead of writing external event handlers to customize it, you will be able to edit the generated code directly and have the customizations compiled directly into the game. (Similarly in the sprite rile system, you could define sprite rules for a second player that determine which sprites move in response to another set of inputs rather than those used for player 1.) This makes it easier for either users or myself to create/provide "2-player dual-view", "2-player sprite scroll" and "2-player auto-scroll" templates. The templates would probably go through wizards to ask how to find the player sprite on each map or something. I haven't worked out the details yet.
I haven't had much time to work on SGDK2 lately, but yesterday I did finish the sprite parameters tab. It was incredibly simply. It's just a single-column grid automatically bound to the SpriteParameters table. All you do it type in the names of parameters that this kind of sprite can specify. I might have to add a data type column. Sprites will probably have to be able to have parameters that connect them to paths or to other sprites.
Now comes the real challenge -- the Sprite Rule system.
-
I did want to ask one more thing. Is it possible, if special functions are returning, to maybe implement 'switches' or triggers, that can be set by a special function? I know items work like this, but it would be nice to have a special function not nessecarily 'work', or it's switch is off, and when it is turned on, THEN it requires an item to proceed with the function.
This is just a suggestion/question. Agian, sorry about butting in.
-
sorry for the request, but would it be possible to make a slight change to the create sprite function? where you can specify relative to: 'absolute', 'player', or 'trigger', how about one thats like 'specify sprite' (which would make available a drop down menu of all the sprites on the current map), and have it create the sprite next to all instances of that sprite, if any exist within the current display
-
Those issues are a little to specific to be thinking about yet, but I'll try to remember to check back and think about them again when I design the new rule system (which will be the replacement for special functions). The new system will probably be almost unrecognizable compared to the old one, but I can probably at least verify that you'd be able to do something similar to what you want in the new system. The only thing I know about special functions so far is that they will be partially based on trigger areas. The function itself will be separated from its trigger area (they are kind of tied together in 1.x). In 2.0 special functions will be more widespread and equally connected to different kinds of triggers rather than being primarily triggered by an area on the map. But I'm not clear on the details yet.
I'm a bit unclear on the general usefullness of the other request. Wouldn't it be better to just create a sprite relative to a specific instance of another sprite rather than all instances? Every sprite instance will be named in SGDK2, so that would be possible. Though once again, I haven't gotten to the specifics there yet either.
-
I understand. I can't wait for the new kit, and all of these new things you speak of all sound like a welcome break from what we have to use in the now version. I'll make sure to hold off on the questions until it's a good time to start requesting. Maybe even post them in a more appropriate thread? ;)
Thanks for listening.
-
yea, by my post i just meant that youd be able to have a function create a sprite (SpriteB) relative to SpriteA without requiring SpriteA to be in a collision or at a specific location (i.e. absolute). i can't think of any perticular examples right now, i just know that ive thought of a few things before that this would have made simpler.
-
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?
-
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. :)
-
Idea/suggestion about paths.
-
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.
-
I think I am in a position to allow control over the order of priority of the sprites.
-
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)
-
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 :-X ;)
]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. 8)
-
Hmmm... you make some interesting points. Heh... sorry I just had to say that :P.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
"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.
-
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.
-
OK, I think I got most of the runtime code worked out for everything that I've developed so far except for sprites and categories. I am able to generate the project source code for a project and then I can relatively easily incorporate that into a Visual Studio project and compile it. I can see a compiled project scroll through a bit of a map now, which is cool. I've been spending the past couple days trying to optimize the DirectX Display object. Performance isn't quite as good as I hoped it'd be. I am only getting about 60 FPS with just 2 simple layers. As I write, however, I did a new test where I include all my layers in a single batch instead of doing one batch per layer and was pleasantly surprised to see my FPS hit 75 FPS, which is my refresh rate. Maybe there's no problem here after all. I will formalize that optimization and do a little more work with the way I am handling textures, and then I hope to be ready to go back to designing/implementing sprites.
-
I have been working on allowing the user to place sprites in the map editor, and things have been working out great. This interface is a world better than the GameDev 1.x interface when it comes to adding sprites to a map. No flipping back and forth between a full screen display, path editing and sprite editing. Now you have all your sprites in the toolbox just like tiles, and you can select one, set it's properties right there on the side of the map editor and then add it to the map. You can switch to sprite selection mode and when you click a sprite it's properties will show up in the same grid where a new sprites properties are edited. The properties include all the intrinsic properties and the user-defined properties, which can all be edited on the fly. I haven't implemented coordinate paths yet or "sprite plan". The foundation is there, but there's no way to create an actual plan or a path or link it to a sprite yet. The nice thing is that you won't have to have a path just to have a sprite any more. I'm not entirely sure how sprite plans and coordinate paths will be related to each other and to sprites yet. I suspect a plan will be a set of rules that can operate on either a single sprite or on all sprites in a category. It will be used for things like making a sprite follow a coordinate path (a rule within the plan will reference both the sprite and the path to do this) and causing a sprite to teleport (for example the plan would contain a rule "if a sprite in the player category enters the area determined by the first two coordinates in path X, then teleport to the third coordinate in path X.") I will have to make this simple for the user so they can easily (without a lot of extra thinking and steps) create a teleporter/door by just indicating the transport area and the destination and which category of sprites are affected. Internally it will be stored in more general structures though (the aforementioned coordinate paths and plan rules). In a sense, it will be like the graphics editor where you have various tools to achieve certain effects, but then you can get down to the detail level (graphics editor has pixels, plan editor has points and rules) and touch things up.
I still have a but more work to do on manipulating sprite instances in the map editor, and then I will probably move on either to this coordinate path / sprite plan work, or back to the code generator to see how sprites come out in the runtime code. I have modified the display class and the layer class a bit in the process of implementing sprites. For one thing, there is now a "priority" property on both the sprite instance and the layer -- when the priority of the sprite is the same as the priority of the layer, the sprite draws between the rows of tiles like you'd want to see for an isometric-style map. If it is greater, then it draws in front of the layer, and the order of the sprites' drawings are determined purely by priority. So now it's really easy to determine which sprites draw on top of which other sprites. I hope nobody minds that it's a static setting and can't be changed at runtime, but I think that will help optimize performance. And if you really want a sprite to move to a different priority, there's the option of creating an identical sprite with a different priority, deactiviting the old sprite and activating the new sprite to make it look like it changed priority. If changeable priority is a big issue, though, I could consider the possibility of allowing priority to be swapped with another sprite's -- it's probably not a big deal to implement. As I was saying, I modified the classes a bit and need to incorporate similar changes into the runtime copies of some of this code.
-
The ease with which one may place a sprite makes me salivate... aaaaggghhh...
-
<homer simpson>Mmmmmm, Spriiiiite.... *gurgle gurgle gurgle gurgle*</homer simpson>
-
I've been deeply embedded in the code generation for a number of days now. I'm developing code to generate code for storing and rendering sprites and tile categories and tile shapes among other things. In thinking about tile shapes/solidity, however, I get a stronger impression every time I think about it that the current tile shape mechanism, although cool (with its preview feature), is not the best design. I think the tile shapes should be "hard coded" into the source code section of the project data instead of being a dialog of its own. That way people who know what they are doing can still define new tile shapes for their particular project (or copy them from somewhere). But for the majority of people who can live with a preset set of shapes (like GameDev 1.x did), I don't have to make a mess of the code by allowing custom shapes and allow the possible confusion that only convex shapes may be handled entirely correctly, even though the current dialog allows you to define all kinds of wacky shapes. I think the code will be a lot cleaner if I skip the step of pre-processing these shapes into arrays of numbers that define the boundaries and just have functions that calculate the boundaries in real time -- I don't think the math for calculating the boundaries of the intrinsic set of basic shapes will be any more complicated than the formula for locating a piece of data in the pre-processed array, so I could certainly save some time and space. So when I get time, I'll probably remove the tile shape dialog and just hard code the same shapes that GameDev 1.x had. I might also add shapes that TechnoVenture had (Slow Uphill 1st half, Slow Uphill 2nd half, Slow downhill first half, Slow Downhill 2nd half... and maybe similar ceilings).
But first I have to get through this whole Code Generator mess. Every line of code I write seems to require me to implement another whole feature first and this results in a whole lot of loose ends to come back and clean up later. I hope I don't miss any.
-
I've gotten back to a state where I can generate a project that compiles and now I can see sprites being drawn on the map.
-
I think I'm on a path that leads to a reasonable solution now. The map editor will allow you to define coordinates for a plan (points in paths or corners for rectangles) and store them all in the same kinds of generic "plan" objects. But it will not try to allow you to define all the rules associated with a "plan" on the same screen. I will leave the specific rules to another screen. I have the map editor allowing me to display and add coordinates to paths. Now I am proceeding to complete that work, allowing coordinates to be selected and moved, etc.
-
I got the path and coordinate editing working reasonably well now, but haven't gotten into the Rule editing for the paths yet. As I was adding the paths to the main project tree, something occurred to me about the way I was handling data in memory. First of all there were some problems/errors in the way I was detecting changes, so I fixed those. But I also realized that I can use the .NET DataSet object to track all changes that have occurred since the file was loaded. But in order to do that I have to eliminate some of the "AcceptChanges" calls I am doing throughout the code, which makes the changes permanent in memory and discards the information about where changes have been made. If I can manage to keep that change information around, then I could allow multiple people to be working on different areas on the same file at the same time, and when they save, their changes could be merged if they don't conflict with each other. So I'm currently trying to eliminate by extra "AcceptChanges" calls so that I can use the .NET data change tracking information for something useful.
-
Rule editing for sprite plans works at a basic level now. Eventually I'll have to fill it out by adding more functions, but that's just adding code to the PlanBase base class (which any user can do at runtime). The framework is there. Oh, I'll also have to add support for listing more parameter types. Right now all it will help you with is a parameter that accepts a sprite (it will list all the sprites on the layer) and a parameter that accepts a point (it will list all 1-coordinate Sprite Plans on the layer). I will also want to be able to list sprite categories and other Sprite Plans. And eventually I'll want to add a wizard to help ease the process of creating common plan types. Right now the parameters are a bit cryptic because they list the values in the form that the actual generated code will represent them. The name of the target object is contained in there, but it might be nice to have a wizard to combine a number of steps into a simpler process with simplified object names. Also, I'm not sure yet how to handle integer parameters since there are so many in a project. I don't want to list every parameter of every sprite. So I'll either need to work that into the wizard somehow or make a "sub-wizard" that can be launched for each integer parameter. Or maybe the dropdown lists can be smart enough to only show parameters of sprites that are passed in one of the other parameters.
So the next step, now that sprite plans are basically functional, is to go back to sprite definitions and make the rule system for sprite definitions work. What are these Sprite Plans and Sprite Definitions you ask?
1) Sprite Definition: Contains all the information about a type of sprite. This includes the user-defined parameters that this type of sprite can have (sprites that follow paths defined in plans will probably need a user-defined parameter to store the index of which point in the path they are currently heading toward). It includes a list of all the states that the sprite can be in. It includes the list of frames in each state. And finally, it includes the list of rules that determine how a sprite moves and transitions from one state to another based on varying input and conditions.
2) Sprite Plan: These are layer-specific rules that determine what can happen to individual sprite instances on a particular map. Every sprite plan can include a series of coordinates, a set of rules, or both. It's kind of like a combined GameDev 1.x Path and Special Function merged into one. These rules don't have to refer to a sprite at all (I use the term "Sprite Plan" loosely, and often just refer to these as "Plans"). I expect that these plans could also control things like the current scroll position of the map, regardless of any sprites. There is currently no association between a plan and a sprite except that most rules that a sprite plan can use will accept a sprite or sprite category as a parameter, which determines which sprite(s) the plan affects. Sprite plans can be edited in the map editor by adding coordinates to the plan and chaging their name. They can also be edited independently to set the rules for the plans and create plans that don't have coordinates.
Now, if SourceForge would stop having random service outages I could continue :-\. I must just be unlucky in my timing: a few days ago I tried to use the SourceForge secure shell service to upload screenshots for the first time in a couple months, and it happened to be the day that SSH service was out. Then yesterday I tried to update the SGDK2 source code in SourceForge's Subversion service (for the first time in a few weeks), and it happened to have just gone down yesterday.
-
I reached a kind of exciting milestone tonight. I was finally able to compile and run a simple project in SGDK2 without any help from the Visual Studio IDE or manual steps. SGDK2 can now generate, compile and run a game without any outside help. All the project did was sit there showing a still map, but I think this was an important step.
-
Well, I am now starting to get sprites moving around inside the layers of a map and react to the shapes of the tiles. Solid tiles and sloped tiles going rightwards are working so far. I haven't fully tested it yet, though. I'm not sure how well it will work when the sprite's position suddenly becomes a non-integer (right now I'm only dealing with whole numbers). I look forward to testing the new half-slope ("y=x/2") tile shapes and a new even more cool shape that I realized was possible in talking to durnurd. I think we finally have an easy way to support tiles that are solid only when standing on them, and you can jump up through them and land on them! There are a lot of similar possibilities for other 1-way tiles too. Can't wait to try them out. One thing I was impressed with was that the solidity of animated tiles worked as desired on the first try. I had an animated tile that was designed to be solid when it was showing a visible frame and act as empty when it was showing an empty frame, and right off the bat I was standing on it when it was visible and falling through it when it wasn't.
I've been using some of the Super Happy Funland graphics for testing in a new project. I finally implemented the import feature in the graphics editor to be able to import all those graphics into SGDK2. Of course they don't take advantage of translucency, but they're good for testing. They make for quite a nice test project without me having to spend hours developing test graphics.
Anybody hungry for another pre-alpha release so they can see what it's like so far?
-
me hungry...mmmmmm....pre-alpha release... :)
-
I've been neglecting this thread. Obviously I have released another pre-alpha demo since I last wrote (pre-alpha 5). It demonstrates, among other things, how you can have *tiles* now (not just sprites) that you can jump up through and land on. Since then I have managed to implement a function to help sprites follow paths defined in plans.
I'm currently working on collision detection. I have added an "alpha" parameter associated with each sprite frame (next to the "repeat count" or "delay" or whatever I called it). This allows you to specify how a specific sub-frame contributes to the shape of the overall frame within each sprite state's series of frames. Let me (re-?) clarify the terminology I've been using since I may have extended it a bit by now:
1) Sprite Definition - Defines the general behavior of the sprite that applies to all maps
2) Sprite Instance - Many sprite instances can exist per sprite definition. Each instance represents a specific sprite on a specific map and follows the rules defined by the sprite definition as well as the rules defined "plans" in the layer
3) Sprite State - A number of states can be defined in each sprite definition. A sprite instance knows what state a sprite is currently in, but the definition is the one who defines what that state does/means.
4) Sprite Frame - Within each state are a series of frames that determine how the sprite animates when it's in that state. Each sprite instance knows what frame its on within the state too. Each frame has a "delay" or "repeat count" that determines how long that frame will be displayed before moving on to the next frame in the state.
5) Sub-Frame - When a frame sets a "repeat count" or "delay" of zero, it is merged with the next frame. I have been using the term "Sub-frame" to distinguish these. Multiple sub-frames come together to forma single frame which is what you see when the game is running (a combination of multiple sub-frames are drawn all at once in a single frame to represent the sprite at that instant).
The alpha level is a number between 0 and 255 and can be read as "pixels above this alpha level in the image should be considered solid for the purpose of collision detection". A low alpha level (low threshhold) means more solid pixels and a high alpha level means fewer solid pixels (if you have semi-transparent pixels in your frame). An alpha level of 0 will indicate that a sprite does not have a collision mask and will just perform rectangular collision detection. An alpha level of 255 will indicate that there are no solid pixels in this (sub-)frame so it does not contribute to the shape of the overall frame.
I've got all the code written. Now I just have to test it and presumably fix it.
-
I'm still making good progress on SGDK2. I noticed that the last pre-alpha (6) that I posted had a problem when riding a platform upwards. I have fixed that locally by switching the order of the "ProcessRules" call within the ReactToPlatform function (it should be called before checking to see if the sprite has stopped riding the platform instead of after IIRC). But unfortunately you can't fix that locally unless you directly edit the SGDK2 file in notepad because there's also a problem with the source code editor that limits the number of characters you can enter into the textbox to 32767. I have remedied these problems locally and am currently working on syntax highlighting in the code editor. It's looking good.
-
I'm starting to work on some of the wizards now. I have a wizard to help calculate the map scrolling size based on the size and position of the layers in the map. I also have a wizard to set every property of a layer with some more graphical interaction and detailed help. It too will look at the scrolling size of the map to help calculate a reasonable size for a layer based on its scroll rate and offset.
I'm also working on supporting ladders. I added some new sprite rule functions to help determine what state the sprite is in and switch states. I also added one to check what tile is on the layer at the position where the sprite is. Combining these it is possible to define rules that allow the player to be in a "climbing" state when there is a ladder behind the player (and automatically switch back to a normal state if they leave the ladder). Then when I started thinking about how to incorporate that into a wizard I realized that checking the tile number in a sprite rule could be problematic. What if the sprite is sometimes on a layer that uses tileset "Main", and other times on a different map's layer that uses tileset "Alternate"? What if tile #100 on layer Main represents a ladder, but tile #100 on tileset "Alternate" is something completely different. Defining a rule that allows the player to climb on tile #100 would be a problem in that case. Then I noticed the same problem might exist with tile categories. A tile is in a category based on the index of the tile in it's tileset... what happens if you use the same category on a different tileset? Maybe it would work correctly, but it wasn't clear to me the way things were designed.
So yesterday I spent a few hours doing a little bit of re-work in the framework. Now a tile category can include tiles from multiple tilesets in a smart way. As it turns out, the runtime/generated code didn't really change, just the design time interface. Categories are relatively simple at runtime (they have to be to be fast). Allowing the category to be aware of tiles in multiple tilesets allows me to create a function that takes a category of ladder tiles and return true if the player is on one or false if not. The category can include ladder tiles from all tilesets so it doesn't have to worry about the sprite being on different layers with different tilesets. Other good things that came out of this:
* You don't have to re-create the same categories for multiple tilesets, and make multiple sets of rules if you want your sprite to interact with the same kinds of tiles from multiple tilesets.
* Solidity doesn't have to be defined by tileset because now when you reference a tile category from your solidity definition, it applies to a category that can encompass all tilesets. So solidity definitions are simplified.
-
sounds like a good solution. I like the idea of keeping more stuff global instead of properties of a tilsets/layers/maps.
You going to stay with 256 tiles per tileset or up the maximum to 65536? (or somewhere in between)
-
sounds like a good solution. I like the idea of keeping more stuff global instead of properties of a tilsets/layers/maps.
Oh, you're gonna love it. The best part is that sprite definitions are global, so you can use the same type of sprite on any map and layer without having to re-define it on each map. But you probably already read about that. And sprite categories are global, so collision tests and platform interactions can be defined globally. There's also a "Global Map" which you can use as your inventory display -- it gets drawn in front of whatever map you're playing on and allows you to create "rules" (and draw graphics) that are applied regardless of which map you're currently playing on.
You going to stay with 256 tiles per tileset or up the maximum to 65536? (or somewhere in between)
No more 256 limit; if you look at the pre-alpha demos going all the way back, there's a "Bytes Per Tile" setting on each layer that allows you to determine how many bytes each tile takes on that layer. If your bytes per tile setting is 1, then yes, you will be limited to using the first 256 tiles in the layer's tileset. But you can also set it to 2 bytes (which I think gets you 32768 because I think it's using a signed integer) or 4 bytes (which gets you over 2 billion, but I don't know who'd need this).
On to new developments:
I just finished my initial pass at a Sprite Import wizard. I think this will be the primary means of creating sprites in a user friendly way. Before I had this idea, I was trying to work out various kinds of wizards for various kinds of sprites and then remembered/realized my plan of using templates to create sprites. So now there is an "Export sprite template" command on the sprite definitions window. Anyone can use this to create a file that contains just the data needed by the current sprite definition. That is:
- Sprite Definition itself (the name)
- Sprite States
- Frames in each state
- Sprite Parameters (just names again)
- Sprite Rules
- Frameset(s) referenced by all sprite states in the sprite
- Graphic Sheet(s) referenced by those frameset(s)
So only that data is included in an exported sprite definition. And when it is exported it is actually in exactly the same format as a regular SGDK2 project. That means it will be possible to import sprites (and eventually other data) from sources that are created in 3 ways (which all happen to use the exact same format):
- Exported sprite template files created by the user.
- Sprite template files delivered with the application.
- Arbitrary SGDK2 project files.
Furthermore, you can load a template file as if it were a project and edit it. Using datasets has been wonderful in providing lots of extra features in an easy-to-implement way, and this is just one more example -- transferring data from one project to another and making the file format universal has been so much easier as a result of storing all the SGDK2 project data in a dataset.
As you import sprite definition(s), you can select one or more sprite definitions you are going to import from a single file, and specify alternate names to use for them within your project. This allows you to import the same definition multiple times and specify alternate names for each definition. (This is less necessary now that sprite definitions are global to all maps, but I'm sure it will still be a handy feature for different kinds of sprites that follow similar rules.) Then, if you already have framesets and graphic sheets in the project that use the same name as those that you are importing, you will be prompted with the option to either import the frameset or graphic sheet with a new name (as a new object) or to assume that the already existing object is the same and make the sprite definition use the existing frameset(s) and graphic sheet(s) instead of importing new copies.
The nice thing about this design is that I don't necessarily have to have wizards to create 36-state sprites out of existing graphics. I can create a single template file that has a 36-state rotating sprite and *includes* its frameset and graphic sheet. When you import that, it all comes along (if you like) and then all you have to do is edit the graphic sheet to alter the graphic cell to your liking. (a 36-state sprite will likely be based on a graphic sheet with just one cell which gets rotated into 36 frames by a frameset at runtime). So you just change the one graphic cell and your whole rotated sprite is already ready to use. I'm not sure how changing the size of the cells will affect the transforms in the frameset. I might have to make templates for different sizes in order to get the rotations to center properly. But I think once again a single relatively simple solution covers a whole lot of use cases... this allows me not only to deliver a wide range of pre-defined sprite types, but anyone can create new types to be used in any other project. The primary limitations are that any rules referenced by the sprite definition must be compatible between the template and the target project, and you may have to create sprite categories or tile categories with specific names if the template refers to specific tile category names (like "Ladders") or sprite category names (like "Platforms"). But you can put as much or as little as you like into the template as far as rules go. You can pre-define the sprite to climb ladders in a particular tile category, or you can leave that out and expect the user to define those rules after importing.
-
I'm in the process of implementing support for sound effects now. Since sound effects and other media can come in such a variety of formats, I decided to implement sound/media and other custom code as a general purpose extension. Instead of building hard-coded support for sound into SGDK2, I am adding a new concept of "Custom Objects". A custom object is something that is added to the "Source Code" folder. It can be imported from a template (such as an "MP3 File" template) or manually coded into the project. A custom object can consist of a block of source code and/or a block of binary data, which can be imported into the project from any type of file (and will be saved embedded in the SGDK2 project file). A special type of "custom object" will be added if you end the name with ".dll". This type of custom object represents a reference to a .NET assembly and cannot contain any code or data. This allows one to reference, for example, Microsoft.DirectX.DirectSound.dll if they want to use Microsoft's DirectSound framework for playing sound effects. (Of course there will be a template that includes a reference to this for playing some types of sound effects.)
Custom objects can have dependencies on each other. For example, the "Example WAV File" custom object might have a dependency on a "WAV File" custom object that knows how to play WAV sound effects. That, in turn, might have a dependency on Microsoft.DirectX.DirectSound.dll. Importing custom objects (such as sound effects) will work similarly to importing sprites. When you import "Example WAV File" from the template, it would also import all the dependencies of that object, and merge them into the project. If they are already there, they will be ignored. If not, they will be imported.
Custom Objects could conceivably be used for much more than sound effects. I forsee these as possibly becoming the replacement for GameDev 1.x's scripted event handlers that you'd find in a VBS file. Sprite Definition rules and Sprite Plan rules will be able to interact with these custom objects by using interfaces defined in the rule source code files. For example, if you want to create a new type of custom object "Message" that would display a message on the screen while you play, you might take these steps:
- Create an interface in PlanBase.cs (the file that defines what rules you can use in Sprite Plans) called "IMessage".
- Define a method "Draw" on this interface that takes a Point as a parameter.
- Create a function "DrawMessage" in PlanBase.cs (that's a custom code file that is embedded in the project) that accepts an "IMessage" for the first parameter.
- Create a custom object "Message" that inherits from (implements) the IMessage interface.
- In the constructor of this object, load the embedded resource named this.GetType().Name + ".bin" using a .NET ResourceManager (SGDK2 will always compile the binary resources associated with a custom object into the EXE using the name of the custom object followed by ".bin"). This resource could be a string or a bitmap or whatever you want to store your message as. Loading the resources in this way allows you to load the data associated with any derived object (based on the derived object's type name).
- Create a function "Draw" that implements the Draw method of the IMessage interface by retrieving the Display object from the global GameForm object and making the appropriate DirectX calls to draw text (or bitmap) directly on to the display at the coordinate specified by the parameter. Use the data that was loaded in the constructor.
- In the code for the DrawMessage function in PlanBase, call the Draw method on the IMessage parameter, passing the current plan's first coordinate as the Point parameter. (This will cause the message to be drawn at the coordinate of the first point in the plan.)
- Create any number of dependent objects that derive from Draw and specify their own unique messages. Each of these objects will expose only one member: a static read-only property that returns a global instance of itself (the instance would be created in a static constructor for the class so that each class has exactly one global instance always available). So the code is very simple -- all the work is done in the base class. Associate a binary resource (string or bitmap) with each of these objects.
- Now you can use the the DrawMessage function on any plan you like. The dropdown list will display all static functions that it can find in the custom object that return an object of type IMessage. So that's how you easily get a list of all your available messages whenever you choose to use the DrawMessage function.
Drawing a message may be a silly thing to do using custom objects unless you want your message to be represented by bitmaps instead of strings. But this is a nice example of the flexibility of this system. And if people (especially me) start creating lots of custom object templates, I think it will be quite a user-friendly system too -- you want this feature? Import this custom object into your project and you've got easy access to it.
-
I have started to look into integrating the FMOD Ex API (http://www.fmod.org/) into SGDK2. Looks like sound support could be really easy from my end -- FMOD has already done most of the work (and even provides a handy C# wrapper). Anybody out there familiar with FMOD? It looks like they also have a designer API. I haven't had time to research yet -- does that mean that I could also integrate some sort of music composing interface into SGDK2 if I wanted to?
-
I don't think the designer api is meant for composing. It's meant for a sound designer who already has all of the sound assets and needs to mix them and apply effects based on game mechanics during the game. Basically you just define an event and then take the sounds you have and mix them how you want to in the designer api, then give the sounds and event list to the programmer who implements it in the game.
The designing of the actual sound elements is done elsewhere.
As for licensing, it is obvious that SGDK2 is free and therefore does not require a license to be purchased by anybody. However, if somebody does want to sell their game, does this mean they would have to buy the hobbyist $100 single-product license first?
-
Well, sound support with DirectSound and FMOD templates is reasonably well wrapped up (choose the template for whichever framework/technology you want your game to use, or both). I don't actually have the templates yet, but the test project I have been working on has the code which I can export into templates, and the IDE framework is in place to allow FMODEX.DLL to be referenced/copied/generated from wherever it resides (DLL files can be embedded in the project, or left as files in the project directory or the directory where SGDK2IDE.exe resides, in which case the project file only stores the name of the DLL).
The latest thing I've been working on is Save/Load game support. It's working out beautifully. I marked every class whose data needs to be save-able as "Serializable", and then I just use .NET's built-in serialize feature to save the game to a byte array. There were a couple tricks I used in the process. For example, the DirectX display object referenced by some objects can't be serialized. But I used a combination of implementing the ISerializable interface and creating a separate class that implements IObjectReference and ISerializable to stand-in for that object during serialization. This allows me to override the serialization process for a class to the extent that I needed. For the display object, I override the GetObjectData method to tell it to use a DisplayRef "stand-in" object during serialization instead of trying to serialize the Display object itself. The DisplayRef stand-in simply returns the global display instance during de-serialization instead of trying to store anything to the byte array. I used similar techniques for serializing Tilesets, Framesets and other objects that should not be changing at game runtime (which also reduces the size of the save file, of course). They just refer to the static instances instead of trying to save their data.
The next thing I did was create a "SaveUnit" class whose purpose is to accumulate information about which information you want to save during your next call to a Save function. Currently, you can choose to independently include
1) All maps
2) Any counters (you can add all counters and then remove some from the save unit or just selectively add individual counters)
3) An indicator of which map is currently being played
No more do you have to do an all-or-none save/load operation. You can choose to do a Mario-style save by just saving all the counters and the current map indicator, without saving the state of any maps, for example. I have not yet determined what kind of individual map selection should be allowed, but I might also allow specific maps to be included in the save unit instead of having to choose all maps or no maps (you might want to save the world map without saving any level maps, for example).
So far it appears to work great and the load/save functions operate instantly (at least in my little test project). Oh, and another new feature is the ability to save to memory slots. I actually haven't implenented the ability to save to file yet (I will be doing that shortly). Right now, the functions are just saving to "memory slots". A memory slot is simply represented by an integer. You can save to as many separate numbered "slots" as available memory allows. So if you want to use the save feature simply to help reset to a prior state, you don't have to be writing files to disk. Also, you don't need to save a map in order to reset it. Each map always knows how to reset to its initial state, and you can unload a map at any time which will force it to be re-created in its initial state next time you visit it.
-
When I said that load/save operates instantly, I hadn't realized just how instantly. I can hold down the "L" key (which, in my test project, triggers the load function) and it will load the game every frame without affecting the frame rate. That's a fast load! :)
Anyway, I'm on to the recently suggested additions to the graphics editor. I'm going to try the random fill first. Instead of implementing a new "fill" command, I figure I will implement it the way the GIMP does: as a filter. I intend to create a tool or command that will simulate the behavior of the RGB Noise filter in the GIMP. This appears to add a random value to the R, G and B component of each pixel (the value is the same for each of the R, G and B components, but a different value is chosen for each pixel). I'm not sure how important it is to allow the user to specify how much this value can vary. I would like to just pick some reasonable value and hard code the tool at that value instead of creating a whole new UI just to allow the user to specify the range for the RGB noise. Maybe I'll make it a custom tool. Oh... or maybe it would make sense to vary the value based on the currently selected alpha level... that kinda makes sense. If you have a lot of alpha, the noise will affect the image a lot (lots of variation). Small alpha will only affect the image a little (small variation). I think I'll do that.
Another thing I was thinking about was making the custom tool code be something that can be updated and re-compiled at runtime, instead of having to download the source code and recompile all of SGDK2. Then I could create RGB Noise (or anything else) as a custom tool, and if you wanted more or less noise, you just go to the custom tool code and change a number. I'll have to try that... would be much more convenient than having to recompile SGDK2.
-
I had a productive evening yesterday. I managed to implement both the "Add Noise" feature and the "Remap Hues" feature. Both are working well. Looks like I forgot about the hotkeys -- that should be the easy part. Then maybe I'll move on to implementing more export/import support for graphics/tilesets. You can already import and export graphics as PNG, but I think I still need to allow import/export between projects/templates.
-
I think I've finished implementing multi-player support, at least to the extent that I'm going to implement it for the initial release of 2.0. I added a menu bar to the run-time form where the game is played. So in windowed mode, you can access the menu to customize the controls for up to 4 players. Each player can use either the keyboard or any gamepad or joystick that Windows knows about. And if they use the keyboard, of course you can customize the keys. This is a step better than 1.x in which you had to define the keys at design time and there was no standard multi-player support (you had to write a script and handle everything about the second player manually).
In the project settings window at design time, there are two new settings: Maximum Players and Maximum Views. Maximum Players determines how many players are in the dropdown list on the Options dialog at runtime (and that's all it affects. Most of the multi-player support is handled by what rules you choose to create in your game). Maximum Views determines how many different views there are for each map. For example, in a 4-player game you can have all players in one view, and make sure none of them can leave that view, or the view can be divided into 4 areas, one for each player. (Or you can have 2 views each with 2 players; arrange it however you want). The maximum number of views just lets the template code know how many views to manage for each map. Then you can define your rules to select any of these views as the current view to perform scrolling on it. Furthermore, at runtime, your rules determine how the views are laid out. You can have 1 single view, 2 side-by-side views, a top and bottom view, or 4 quadrants.
Implementing the subdividing of the views complicated the scrolling a bit because when the view is smaller, it turns out, a layer that scrolls at a rate of 2 can show slightly more tiles than it can in a larger view. But I think I did the best I could in the wizards and I adjusted the way that the map's scroll width and scroll height are defined. So now for the most part it should behave pretty well with respect to making layers the right size to fill the map or finding the right scroll size for the map in order to reach the edges of the layers (these are functions of the wizards).
I updated the sample project I decided to try a split top and bottom view with two similar sprites in the top view (forced to remain within one screen of each other) and a ship in the bottom view. I can press 1 to switch to single-view 1 player mode, 2 to switch into single-view 2 player mode (the two similar sprites), and 3 to switch to split screen 3 player mode. Things seem to be working reasonably well. The bottom half is scrolling independently from teh top half, and as I switch between the number of players (all determined by the way I defined my rules -- not hard coded) I see the screen re-arrange itself and sprites get removed or added for the extra players.
I'm not planning to support network play in the initial release of 2.0, but I expect it would be easier to make a networked game in 2.0 than it was in 1.x (and there was a demo of a network game in 1.x). Could it be as simple as creating a new kind of player besides keyboard and joystick? If you don't mind the possibility of synchronization problems (both players picking up the same item at the same time), maybe. And I suspect it's all possible just by changing the custom code embedded in the project. No need to change the SGDK2 IDE code. I'm pleased that so many of the features are so largely contained in the customizable project code. It means that projects in SGDK2 will be very flexible.
There are just a few details to clean up on multi-player support and then I move on to other clean-up and testing. I have to improve the default keyboard settings when you switch a player from joystick to keyboard control. Right now they all just default to settings similar to those in version 1.x, but I should make each player default to their own set of keys. (Right now, BTW, player 1 defaults to keyboard, and player 2 through 4 default to whatever game controllers are available, all to the same one if only 1 is available. If none are available they default to 4 different keyboard layouts.) Then I have to make it possible to save the player settings when the game is saved.
-
With SGDK, would Game Developing be easier, or harder. And would it be more easier to use for beginners? ???
-
You mean comparing SGDK2 to version 1.x? I don't think creating a simple game will be much easier, but a few things will be easier, and much more will be possible without extra work. For example, it will be much easier to create a 2-to-4 player game in SGDK2 than it was in version 1.x (I just finished the features to support that). Creating a game with a complex set of sprite definitions shared accross maps will be much easier in SGDK2 because you won't have to re-create them for each map like you did before. It will also be much easier to place new sprite instances and edit existing sprite instances on the map because you don't have to switch between the map editor and the sprite editor to do it, and you don't have to have a path for every sprite. You just click a sprite on to the map like you do with a tile. And some things that you can to with SGDK2 were just completely impossible/impractical in version 1.x: translucent sprites, real-time sprite color adjustment, compiling the game to machine code instead of intepreted code (optimization/speed enhancement), the ability to write custom code in C# and directly access DirectX instead of being restricted to VBScript (now you could draw arbitrary shapes on the display, or maybe even indroduce some 3D models into the display), .
In the end it will be up to users to tell me what's hard and what's easy, though. As the developer, it can be hard for me to see SGDK2 with an inexperienced eye, and hard to see how hard and easy certain tasks are to learn. What I can tell you is that many of the tedious tasks for an experienced user of version 1.x will be simplified for an experienced SGDK2 user.
-
How much of the program is done? (Percentage) :)
-
I'd guess about 90% now, but it's hard to say. I'm about ready to switch the current status of the project to "alpha" instead of "pre-alpha" indicating that the main coding is mostly done any my primary focus now is testing and developing samples, templates, art libraries and help content. Of course, I may still do some more coding as problems and ideas come up during testing. But the program is pretty much in a state where developing games is possible now, I think. Of course I haven't developed any complete games with it yet, and I'm sure I'll come up with some more coding as I test developing my first real project with it. The 90% figure might be a good estimate on design and coding, but that may only be about 60% of the overall work because there is going to be a lot of effort put into developing help content, graphics and sounds libraries and template/sample projects. But I hope to get some help in this last phase, especially from Orion Pax (hint, hint :)).
-
I've come up with an interesting term for a new feature I added over the weekend to help improve code reuse in templates. The term is "decapsulation". I have this file "fmod.cs" embedded in the sound library projects that has a couple hundred KB of code for wrapping the functions provided by fmodex.dll (the sound framework provided by FMOD). And I want to use the functions in that file from every template in the sound library without having to create separate copies of it in each one. So what I ended up doing was allowing the file to be "decapsulated" into a separate file called (for example) fmod.cs outside the SGDK2 file. Then the code of the "fmod.cs" file that is embedded into the SGDK2 file simply reads:
~import "fmod.cs"
(you can also use relative paths -- relative to the SGDK2 file). This causes SGDK2 to read the contents of an external file whenever the fmod.cs dependency is imported. The final project (result of importing from templates) will still be entirely encapsulated because the file is embedded into the SGDK2 project as it is imported, but now the templates have the ability to share objects. I did a similar thing for graphic sheets in case there are (for example) a number of sprite library templates that want to share the same graphic images. There is a "decapsulate" button on the Graphic Sheet manager that prompts for a relative path to an external file. If it already exists, it will delete the internal graphics and refer to the external file (which must be .PNG). If it doesn't exist, the file will be exported and then the internal graphics will be deleted and replaced with a reference to the external file.
Currently those are the only two objects that support decapsulation. Those seem like the biggest kinds of components with the most need for "decapsulation".
The creation of the sound/music library is going well. Now I have to wait for SourceForge to respond to my support request. It seems they have recently broken the ability to rename items in the Subversion tree, and I really need to rename my "Music" library to "Sound" since I am going to put a sound effects library in a single file in there too.
Oh, I also haven't mentioned yet that I have a feature that automatically imports the credits from a template (such as a music library) into the project when you import any item from the template. That's why decapsulation was important. I didn't want to just create one huge music library file because I wanted to provide separate credits for each library. When you import a piece of music by "Ceekayed", only Ceekayed's name should automatically be added to the project's credits and not the name of every composer in the music library. Of course the credits are editable so you can fine tune them, but I wanted some automatic system so that even those who aren't paying attention are giving proper credit where it's due by default.
-
i know you cant really say for sure, but how long will it be till its done? i have a really good idea for a game but i dont know if i should wait till sgdk2 comes out.
-
Well, I hope there will be an alpha release this month, but it will not be thoroughly tested and there won't be any documentation, so I'm not sure how usable it will be. But I will be using the pre-alpha and alpha releases to make sample/demo projects and templates, so it should be *possible* to use if not easy. And it would be great to have someone eager like yourself out there to help with the testing process when the alpha is released so that when the beta and final releases come along, they're more thoroughly tested. So if you want to try using the alpha release to work on your project, I'd be happy to hear your feedback and help you out where I can in understanding how to use it (that may also help me in knowing what I need to focus on in the documentation).
-
ive got a question on compatibility. i know that in title this is sgdk 2, but will it be able to work on sgdk1 projects? or will there be some sort of importer?
-
There will be no compatibility whatsoever. These two projects are completely separate, and there is no way to import or work on SGDK games in SGDK2
-
You could import your tilesets, and media content (WMV, MP3) into SGDK2 without too much difficulty, but beyond that, there probably won't be much more you could import. If people find it useful, I could pretty easily write something to allow you to import map layers -- just the tiles without functions or sprites -- but I'm not sure how much that'd help.
-
I just added some documentation for the graphics editor -- it's viewable at http://sgdk2.sourceforge.net/Documentation/GfxEdit.htm (http://sgdk2.sourceforge.net/Documentation/GfxEdit.htm).
-
I think if you do a find/replace on your area map to add a Title attribute set to the same as the Alt in each area tag, then hovering over each area with the mouse will show a tooltip of what that area is. This works in Firefox and IE.
Checking... yes. Yes it does do this. (Also, maybe add a borderwidth=0 to the img)
Oh, also, you might want to add a little bit of this, so it's clear what you're supposed to be looking at, once you get near the bottom, and it doesn't automatically scroll the selected item to the top of the page:
function highlight (id) {
var elems = document.getElementsByTagName("a");
for (var i = 0; i < elems.length; i++)
if (elems[i].href == "")
elems[i].style.backColor = "#ffffff";
document.getElementById(id).style.backgroundColor = "#00ccff";
}
-
I'm still making progress, slowly but surely, on SGDK2. One of the latest changes that has gone in is the ability to see a frame in the background of the frame editor while editing a frame's transformation so you can see how it looks overlaid on/next to an existing frame. Another is the ability to customize the mapping of buttons between a joystick input device and the player's buttons. I've also added a new tutorial for converting the sample 2-player project into a 3-player project to help people understand multi-player projects. And I plan to add a tutorial for creating some new tiles and tile shapes. Are there any other critical tutorials people can think of that I should include in the initial release? Something that would help you get started with SGDK2 that's not there already?
Currently I'm in the process of colorizing the updated icons that OrionPax gave me half a year ago or so. I have not been able to get a hold of OrionPax for many months, so I'm having to start working on the graphics myself and make due with what he left me with many months ago. I'm planning on changing the development status to Beta soon, and I'd like to have the final graphics in the program for that.
-
Oh crap, forgot about the graphics I said I was gonna make... lol Well they appear to be done, the sample project died, because I had to reformat the computer...(damn viruses) I already had the graphics uploaded on box.net, so I just downloaded them to see if everything was included. They seem to be done, I might touch them up a bit in photoshop first though.
-
Today I made a number of changes according to recent comments in the forums:
1) Limit the size of tiles displayed in the tileset editor's dropdown list to 128x64 pixels.
2) Limit the number of tiles in the list to 8.
3) Allow the tile animation preview to work as a tile preview if you leave it up:
3a) Display the selected background color even for non-animated tiles.
3b) Re-draw the display as it is resized.
3c) Re-sync the most recently opened animation preview to the currently selected tile when a new tile is selected.
4) Add a rule and plan function called "SelectLastCreatedSprite" so you can use SetTargetParameter to set parameters on the last created sprite.
5) Add "lastCreatedSprite" to the dropdown list for rule parameters that expect sprites.
Soon I'll look through the list of suggestions again (I don't have a list, I have to just look at recent forum postings) and if there's nothing else quick and critical to get in, I think I'll try to do another beta release so everybody can get the most recent fixes.
-
fine. i would appreciate more entries for the help files.
how to import sprite definitions from the library, how to use the music and special effects libs, how to add properly a dynamic sprite...
i would seriously like to have some tuts to show how to script various enemy behaviours.
-
You're not the first to request a tutorial on using/importing sounds, so I'm starting with that. It might take a few weeks to finish writing the suggested tutorials, so this will delay an updated beta release. Meanwhile, can you describe in more detail what you'd expect from the enemy sprite tutorial? There are already sprite templates to demonstrate the following enemy behaviors:
- Shoot a cannon ball in the currently aimed direction when triggered.
- Walk back and forth on flat ground.
- Walk back and forth, following slopes in the ground.
- Walk back and forth, and jump when a gap is encountered.
- Follow a path.
Do you want tutorials explaining these already-implemented behaviors, or do you want tutorials about different behaviors? Are you sure you want a tutorial instead of just a better selection of importable sprite templates (tutorials are much harder to write)? What information should be included in a tutorial that you can't easily learn by looking at sample code (whether it's new sample code that I could add or some that already exists)? If a tutorial is necessary, since I can't write a tutorial for every type of enemy sprite behavior, which type of sprite should I write a tutorial about?
-
huh, a lot of questions.
durnurd has shown me how to import the sprites you mentioned. these are quite cool. i don't think this possibility was mentioned in the help files, so it would be very good if you could update the help on this topic.
i don't need a tut which explains this behaviours, because the rules are easy to read and are as good as a tut.
i am happy that you are willing to write further tutorials, even if it takes you a few weeks. but the semester ends late january, so i would be more happy if there were more script code to examine. i agree with you that i can learn faster from existing scripts. what's more, if writing tuts is all what you keeps from releasing a new beta, then i would prefer to have the beta first without the tuts.
if you ask me, put your time into development of enemies instead of tutorials teaching the same, but do cost you much more time.
i can imagine monster birds, which are fluttering around at one point till the player is near, and then do a nose dive to attack him. the same with some animals which are grazing on the ground.
as i tried out the cannons, i saw they do fire when the game starts. as a scripting newbie i realized that there is a parameter called fire, but failed to make the cannon fire whenever the player gets near. (actually, i thougt about this problem, but didn't made an attempt to solve it and kept it for future spare time)
i could imagine these script examples:
- fire a few times one after another, pause a few seconds, repeat
- only fire if the player is near (specified range)
- cannon changes its state by itself towards the player (f. e. a cannon on the plain ground runs through the stats left, upleft, up, upright and right, when the player is flying from left to right over the screen. astriction: the cannon is not allowed to run through all states. some are always blocked from solid which the cannon stays on. exept it's a space cannon flying freely through space.)
- combination of cannonball and other enemy: the cannonball/enemy is fired, then lands somewhere because of the gravity. at this place it proceeds its normal enemy behaviour.
and now.... i tell you what i have imagined and dreamed of since i thougth about to start this project. it is sure very complex. it is also not necessary for my project. look at the pics.
the guys with the ball chain-like neck and legs can move really cool around, since these chains are a good method to enlarge a sprite, its outreach, and smooth its movements.
the dragon tank is made of several elements. you have to defeat each of them all to win. with these two techniques one could make so large and distinctive enemies, it would be... so amazing.
-
I think I will finish the tutorial about sounds that I am writing, then release a new beta, then work on some more sprite templates. Of course it's impossible to create every sprite type that anyone would want. Even with just the cannon sprite, you have listed 4 behaviors that could combine to produce at least 16 different kinds of cannon sprites. So I think I have to focus on more general sprite variations and let the user customize the sprite to their liking. However, cannon-like sprites are a very common and useful kind of "enemy" sprite so I should maybe provide some more options and variations on that one like those you have mentioned.
-
I think I'm done writing the new tutorial. Would anyone care to help me test it? It's at http://sgdk2.sf.net/Documentation/Tutorial4.html (http://sgdk2.sf.net/Documentation/Tutorial4.html) for the moment. I haven't proofread it, so it still needs a final review before re-compiling beta 2.
-
It looks good to me (minus a few spelling errors), but then, I already know what I'm doing.
I took the liberty of making something a bit more visual. I made three different types of walkthroughs for the three different parts of the sound tutorial using screen capture programs, and I'm curious as to which people like the most? Find them here:
http://www.findmyed.com/files/SGDK2Tutorials/Tutorial4-1.htm
http://www.findmyed.com/files/SGDK2Tutorials/Tutorial4-2.htm
http://www.findmyed.com/files/SGDK2Tutorials/Tutorial4-3.wmv
-
ok, i'll test it. i found some mistakes in your tut, bluemonk.
for the part "playing background music" the user shall change the "signal94" into "tropical fun". alright then.
then there is the part where it reads: "Next we will try to play different music on level 1 that we had on the menu map."
4. Select TropicalFun as the first parameter. This will cause TropicalFun to be the sound that is stopped by this rule.
7. Leave the rule type as "Do" and select "CustomObjects.FMODBase.StopSound" as the rule function.
8. Select the Signal95 music for the first parameter. (it has to read Signal94)
if the user run the game now, for the menu is music, but for the game not. this comes because in the player rules, the "continue music" rule is playing "tropical fun", the next rule is stopping that sound.
-------------------------------------------------------
the rest of the tut is fine to me, all the things worked. it is indeed very easy to use sounds, but the way how to i would have never figured out without help.
as for the video tuts of durnurd: generally i like video tuts very much, because it is faster to assimilate the information.
for the first video part i wonder why it is so short.
for the second part: it is the best, but it ends with "open the sprite definitions folder". but the rest remains unshown, there is no connection the the third.
third part: way to fast. but the important things are shown. the only thing i miss is, when you copy and insert the code of "boing". please don't use a shortcut the viewer can't see.
what i like so much for the written tutorial is there is plenty of background information besides the how-to.
what i generally dislike for the written tuts: it is a huge mass of plain text. sometimes it is very hard for me to do one step at the devkit, than return to the tut and find the right sentence where i was. the sound tut is not very long. but the others are. maybe you could insert more spacing between paragraphs, use colored headlines or a screenshot.
thank you both very much for the tutorials.
-
The problem is that there is no way to copy or paste code with a visual shortcut. You have to use Ctrl+c and Ctrl+v to copy and paste text in the code editor. Something that should probably be put into the edit menu.
The second tutorial quickly runs through how to do the part shown in Tutorial one, then you have to take over manually once it starts telling you what to do (Open the sprite definitions folder).
-
then pardon me, durnurd, i didn't know that.
at a situation like this, where something isn't clear, there could be a hint, like in the first video part with the "speech bubbles".
maybe the videos could be inserted in the tut at the right place or something. it is a good idea to make them, since the other tutorials are very long.
-
I like the first one best -- I think it's the most effective in helping the user remember/understand because it not only goes at the pace the user is reading, but also forces them to trigger the actions as they actually would.