Author Topic: SGDK 2.0 Status  (Read 301809 times)

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
SGDK 2.0 Status
« 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.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #1 on: 2006-01-03, 08:06:01 AM »
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.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #2 on: 2006-01-03, 10:57:41 PM »
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.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #3 on: 2006-01-07, 12:05:40 PM »
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.

billybob884

  • Contributor
  • Fanatic
  • **
  • Posts: 355
    • AOL Instant Messenger - billybob884
    • View Profile
Re: SGDK 2.0 Status
« Reply #4 on: 2006-01-07, 11:07:03 PM »
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.
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." :: Hitchhiker's Guide to the Galaxy

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: SGDK 2.0 Status
« Reply #5 on: 2006-01-08, 07:49:50 AM »
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.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #6 on: 2006-01-09, 09:33:02 PM »
I think I've finished the sprite state editing tab of the Sprite Definition window now.
« Last Edit: 2006-01-09, 09:38:30 PM by bluemonkmn »

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #7 on: 2006-01-10, 07:22:32 PM »
I started working on the Sprite Parameters tab this morning, a very simple tab.

GameDeveloper

  • Guest
Re: SGDK 2.0 Status
« Reply #8 on: 2006-01-14, 11:12:59 AM »
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]

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #9 on: 2006-01-15, 08:39:04 AM »
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.

GameDeveloper

  • Guest
Re: SGDK 2.0 Status
« Reply #10 on: 2006-01-15, 02:22:40 PM »
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.

billybob884

  • Contributor
  • Fanatic
  • **
  • Posts: 355
    • AOL Instant Messenger - billybob884
    • View Profile
Re: SGDK 2.0 Status
« Reply #11 on: 2006-01-15, 04:53:45 PM »
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
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." :: Hitchhiker's Guide to the Galaxy

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK 2.0 Status
« Reply #12 on: 2006-01-15, 06:54:25 PM »
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.

GameDeveloper

  • Guest
Re: SGDK 2.0 Status
« Reply #13 on: 2006-01-15, 06:59:12 PM »
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.

billybob884

  • Contributor
  • Fanatic
  • **
  • Posts: 355
    • AOL Instant Messenger - billybob884
    • View Profile
Re: SGDK 2.0 Status
« Reply #14 on: 2006-01-15, 07:03:06 PM »
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.
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." :: Hitchhiker's Guide to the Galaxy