Thread: [Super-tux-devel] Level packs?
Brought to you by:
wkendrick
From: Nathan M. <zr...@gm...> - 2004-08-02 16:48:47
|
I was just thinking it would be really nice if there was some sort of "level pack" format (.stlp?) that would be installable by Supertux in such a way that it could include new tiles, graphics, particle effects (where are these defined?), and possibly even enemies, without risk of conflicting with other levels' already-defined things. This would likely require a move to a more modular scriptable format for stuff, which I believe was considered by many to be a bad idea when it was brought up earlier... I really like the idea of letting level designers create completely new things without needing to patch Supertux's source or tileset file, though. |
From: Marek <wa...@gm...> - 2004-08-02 21:14:10
|
Nathan McCoy wrote: >I really like the idea of letting level >designers create completely new things without needing to patch >Supertux's source or tileset file, though. > > I agree. Especially that tileset resource file is a major pain in the butt. One of the milestone 2 goals should be to clean up this mess and create an easily expandable, user-friendly level- and resource management system. This will be a time-consuming task as we need to give it a lot of careful thought not only about how to manage the current resources, but also about what future versions should be capable of. If we are going to create a flexible SuperTux library, a good resource management will be essential. For example, maybe we can think of a way to set tile id's automatically, that'd make things a lot easier. If we are going to support level packs, we could create a Quake3-engine-like system where everyone can add a package containing their own levels, textures, shader scripts etc. which will then be put together by the game. (Or by us, should we decide to take, for example, a contributed package over into the official one.) Just a few quick thoughts. Marek |
From: Nathan M. <zr...@gm...> - 2004-08-03 01:09:23
|
On Mon, 02 Aug 2004 23:14:13 +0200, Marek <wa...@gm...> wrote: > Nathan McCoy wrote: > > >I really like the idea of letting level > >designers create completely new things without needing to patch > >Supertux's source or tileset file, though. > > > > > I agree. Especially that tileset resource file is a major pain in the > butt. One of the milestone 2 goals should be to clean up this mess and > create an easily expandable, user-friendly level- and resource > management system. This will be a time-consuming task as we need to give > it a lot of careful thought not only about how to manage the current > resources, but also about what future versions should be capable of. If > we are going to create a flexible SuperTux library, a good resource > management will be essential. For example, maybe we can think of a way > to set tile id's automatically, that'd make things a lot easier. If we > are going to support level packs, we could create a Quake3-engine-like > system where everyone can add a package containing their own levels, > textures, shader scripts etc. which will then be put together by the > game. (Or by us, should we decide to take, for example, a contributed > package over into the official one.) > Just a few quick thoughts. That's a great example. I think that working on developing Supertux as a game in itself is a good goal, but ideally it should also be an excellent open-source game engine that other games can be built on. Someone should eventually be able to take Supertux and make a Metroid game with it while modifying very little if any source code. Look at the "total conversion" mods they have out there for some ideas of what can be possible with a well-designed game and level system. |
From: C R. <zra...@mi...> - 2004-08-04 17:48:29
|
On Aug 2, 2004, at 8:09 PM, Nathan McCoy wrote: > On Mon, 02 Aug 2004 23:14:13 +0200, Marek <wa...@gm...> wrote: >> Nathan McCoy wrote: >> >>> I really like the idea of letting level >>> designers create completely new things without needing to patch >>> Supertux's source or tileset file, though. >>> >>> >> I agree. Especially that tileset resource file is a major pain in the >> butt. One of the milestone 2 goals should be to clean up this mess and >> create an easily expandable, user-friendly level- and resource >> management system. This will be a time-consuming task as we need to >> give >> it a lot of careful thought not only about how to manage the current >> resources, but also about what future versions should be capable of. >> If >> we are going to create a flexible SuperTux library, a good resource >> management will be essential. For example, maybe we can think of a way >> to set tile id's automatically, that'd make things a lot easier. If we >> are going to support level packs, we could create a Quake3-engine-like >> system where everyone can add a package containing their own levels, >> textures, shader scripts etc. which will then be put together by the >> game. (Or by us, should we decide to take, for example, a contributed >> package over into the official one.) >> Just a few quick thoughts. > That's a great example. I think that working on developing Supertux as > a game in itself is a good goal, but ideally it should also be an > excellent open-source game engine that other games can be built on. > Someone should eventually be able to take Supertux and make a Metroid > game with it while modifying very little if any source code. Look at > the "total conversion" mods they have out there for some ideas of what > can be possible with a well-designed game and level system. On this note I already have plans for at least one good total conversion mod ;) > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source > Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Super-tux-devel mailing list > Sup...@li... > https://lists.sourceforge.net/lists/listinfo/super-tux-devel > > --- From Ratchet (Mikey Lubker) Lead Coordinator of the IGDA Indie SIG: http://igda.org/indie Check out my projects: http://sf.net/users/ratchet Are YOU a Good Person? Go here: http://www.wayofthemaster.com/wotm_flash.html |
From: Marek <wa...@gm...> - 2004-08-04 18:03:37
|
> > On this note I already have plans for at least one good total > conversion mod ;) > Tell us about it. :) Marek |
From: C R. <zra...@mi...> - 2004-08-04 19:09:03
|
It'll of course be under GPL to me ;) It'll be a "extreme sport" postman game. You are either a mail delivery guy (or girl - character option ;) ) or a mechanic at the post office, and must either deliver mail or fix machines while riding a unicycle. And you'll have to learn moves as you go thru the levels. ;) If anyone's interested in helping, please mail me. ;) Ratchet On Aug 4, 2004, at 1:03 PM, Marek wrote: > >> >> On this note I already have plans for at least one good total >> conversion mod ;) >> > Tell us about it. :) > > Marek > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source > Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Super-tux-devel mailing list > Sup...@li... > https://lists.sourceforge.net/lists/listinfo/super-tux-devel > > --- From Ratchet (Mikey Lubker) Lead Coordinator of the IGDA Indie SIG: http://igda.org/indie Check out my projects: http://sf.net/users/ratchet Are YOU a Good Person? Go here: http://www.wayofthemaster.com/wotm_flash.html |
From: Ingo R. <gr...@gm...> - 2004-08-04 18:55:43
|
Nathan McCoy <zr...@gm...> writes: > That's a great example. I think that working on developing Supertux > as a game in itself is a good goal, but ideally it should also be an > excellent open-source game engine that other games can be built on. It should first and for most be a good GAME, not an ENGINE. The game should always get 100% priority, if an engine pops out while working on the game, good, if not, nobody will miss it. If free software world needs something it are good games, not good engines, we already have enough of them. > Someone should eventually be able to take Supertux and make a > Metroid game with it while modifying very little if any source code. Hint, Hint! -> http://www.nongnu.org/windstille/ > Look at the "total conversion" mods they have out there for some > ideas of what can be possible with a well-designed game and level > system. Try to find a whole bunch of artist first before you start to go all for 'total conversion', currently SuperTux as only a freaking single tile-theme, thats not even enough for half a game. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
From: Ryan F. <rf...@gm...> - 2004-08-04 19:26:02
|
On Wed, 04 Aug 2004 20:55:35 +0200, Ingo Ruhnke <gr...@gm...> wrote: > Nathan McCoy <zr...@gm...> writes: > > > That's a great example. I think that working on developing Supertux > > as a game in itself is a good goal, but ideally it should also be an > > excellent open-source game engine that other games can be built on. > > It should first and for most be a good GAME, not an ENGINE. The game > should always get 100% priority, if an engine pops out while working > on the game, good, if not, nobody will miss it. If free software world > needs something it are good games, not good engines, we already have > enough of them. I agree. SuperTux may eventually become almost totally data driven (at which point it would become an engine). But like you said, our goal first and foremost should be to make a good game, with this good game possibly having a great engine that could be used by other projects (if they desire). We won't make a big jump towards the engine, but it will probably evolve that way over time. > > Someone should eventually be able to take Supertux and make a > > Metroid game with it while modifying very little if any source code. > > Hint, Hint! -> http://www.nongnu.org/windstille/ I had a feeling you'd eventually bring that up when I originally read the grandparent :P > > Look at the "total conversion" mods they have out there for some > > ideas of what can be possible with a well-designed game and level > > system. > > Try to find a whole bunch of artist first before you start to go all > for 'total conversion', currently SuperTux as only a freaking single > tile-theme, thats not even enough for half a game. Yep, no point in starting TC's before SuperTux itself has something to convert from. -- Ryan |
From: Marek <wa...@gm...> - 2004-08-04 19:44:17
|
>It should first and for most be a good GAME, not an ENGINE. The game >should always get 100% priority, if an engine pops out while working >on the game, good, if not, nobody will miss it. If free software world >needs something it are good games, not good engines, we already have >enough of them. > > You are right there, but these ideas of ours are future visions, not actual plans. At least that's how I see it. :) By the way, how's Windstille coming along? Marek |
From: Ryan F. <rf...@gm...> - 2004-08-03 03:09:02
|
On Mon, 02 Aug 2004 23:14:13 +0200, Marek <wa...@gm...> wrote: > Nathan McCoy wrote: > > >I really like the idea of letting level > >designers create completely new things without needing to patch > >Supertux's source or tileset file, though. > > > > > I agree. Especially that tileset resource file is a major pain in the > butt. One of the milestone 2 goals should be to clean up this mess and > create an easily expandable, user-friendly level- and resource > management system. This will be a time-consuming task as we need to give > it a lot of careful thought not only about how to manage the current > resources, but also about what future versions should be capable of. If > we are going to create a flexible SuperTux library, a good resource > management will be essential. For example, maybe we can think of a way > to set tile id's automatically, that'd make things a lot easier. If we > are going to support level packs, we could create a Quake3-engine-like > system where everyone can add a package containing their own levels, > textures, shader scripts etc. which will then be put together by the > game. (Or by us, should we decide to take, for example, a contributed > package over into the official one.) > Just a few quick thoughts. I agree with the agreement :) In the long term (as in LOOONG, with 2-3 O's) SuperTux could be entirely data-driven. The engine would read the datafiles and be able to construct menu's, maps, etc. Like I said: long term. -- Ryan |
From: Ricardo C. <ri...@ae...> - 2004-08-03 18:02:51
|
Em Ter=E7a, 3 de Agosto de 2004 04:08, o Ryan Flegel escreveu: > On Mon, 02 Aug 2004 23:14:13 +0200, Marek <wa...@gm...> wrote: > > Nathan McCoy wrote: > > >I really like the idea of letting level > > >designers create completely new things without needing to patch > > >Supertux's source or tileset file, though. > > > > I agree. Especially that tileset resource file is a major pain in the > > butt. One of the milestone 2 goals should be to clean up this mess and > > create an easily expandable, user-friendly level- and resource > > management system. This will be a time-consuming task as we need to give > > it a lot of careful thought not only about how to manage the current > > resources, but also about what future versions should be capable of. If > > we are going to create a flexible SuperTux library, a good resource > > management will be essential. For example, maybe we can think of a way > > to set tile id's automatically, that'd make things a lot easier. If we > > are going to support level packs, we could create a Quake3-engine-like > > system where everyone can add a package containing their own levels, > > textures, shader scripts etc. which will then be put together by the > > game. (Or by us, should we decide to take, for example, a contributed > > package over into the official one.) > > Just a few quick thoughts. > > I agree with the agreement :) In the long term (as in LOOONG, with 2-3 > O's) SuperTux could be entirely data-driven. The engine would read the > datafiles and be able to construct menu's, maps, etc. > > Like I said: long term. Oh, my god! That sounds cool, but in practice I don't think it would work= =20 that well for a game. The thing is that parsing a text file and then apply = it=20 and all that stuff can be slow. Besides, games need a lot of flexible that= =20 data files may not provide or, even if they do, they can get easily bloated. Anyway, it is a thing to think about. Tell that to Tobias, I'm sure he wou= ld=20 be delighted for that idea. ;) About the bad guys data files you mentioned in another mail, I would like = to=20 work that after Septmember. It is something that, in my opinion, is really= =20 important to boost bad guys development. Cheers, Ricardo =2D-=20 He who is known as an early riser need not get up until noon. |
From: Ryan F. <rf...@gm...> - 2004-08-03 03:06:08
|
On Mon, 2 Aug 2004 09:48:45 -0700, Nathan McCoy <zr...@gm...> wrote: > I was just thinking it would be really nice if there was some sort of > "level pack" format (.stlp?) that would be installable by Supertux in > such a way that it could include new tiles, graphics, particle effects > (where are these defined?), and possibly even enemies, without risk of > conflicting with other levels' already-defined things. This would > likely require a move to a more modular scriptable format for stuff, > which I believe was considered by many to be a bad idea when it was > brought up earlier... I really like the idea of letting level > designers create completely new things without needing to patch > Supertux's source or tileset file, though. There was quite a bit of discussion on it, but I believe it was finally decided to be a good thing :) To start off with the script format would be really simple (to get the framework in place) and later we might eventually move over to python scripts (or similar). And yeah, making more stuff a lot more modular would be great. One example that comes to mind is all the hardcoded badguy types. This should all be handled by datafiles. If you wanna start work on it, go ahead :) I'm pretty busy right now with classes but may have a little time free near the end of the month.. after that.. we'll see. -- Ryan |
From: Ingo R. <gr...@gm...> - 2004-08-04 18:50:44
|
Marek <wa...@gm...> writes: > I agree. Especially that tileset resource file is a major pain in the > butt. One of the milestone 2 goals should be to clean up this mess and > create an easily expandable, user-friendly level- and resource > management system. This will be a time-consuming task as we need to > give it a lot of careful thought not only about how to manage the > current resources, but also about what future versions should be > capable of. Whats the problem with the current resource and tile loading stuff? The only bad thing I see at the moment is that the tile-resource file doesn't use the sprite-tag which the sprite-resource file provides, thus duplicating a handfull of lines code unnecesarily, but beside that I don't see much that could be done a lot better. > For example, maybe we can think of a way to set tile id's > automatically, that'd make things a lot easier. That will just make sure that the next change to the tile-file surely f***-up all the current levels. The whole point of having the id's hardcoded is that they never ever need to be changed for a given tile. > If we are going to support level packs, we could create a > Quake3-engine-like system where everyone can add a package > containing their own levels, textures, shader scripts etc. which > will then be put together by the game. Thats basically what phyfs provides. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
From: Ricardo C. <ri...@ae...> - 2004-08-04 19:35:26
|
I have to say I agree with Ingo. That could become really hard to manage. It would be better to just agree in something (like someone suggested) is having numbers reserved for some tiles, this way it would always be portable. 0 - 100 - green stuff 101 - 200 - red stuff 201 - 300 - slopes We would just need to port current levels, not that hard using a file replacement utility. After that, it would be portable for pretty much time. A part from this, work that tiles need, in the code, I mean (in the order that they came to my mind): - using Sprites might be a valuable thing; - improve collisions, so that we can have not only square tiles, but also different shapes. For instance, supporting slopes; - map might be a worth consideration for use instead of the vector. It is kinda of ugly having empty items; - add more flexibility to tiles. Allowing them to have bad guys, for instance. Cheers, Ricardo Em Quarta, 4 de Agosto de 2004 19:50, o Ingo Ruhnke escreveu: > Marek <wa...@gm...> writes: > > I agree. Especially that tileset resource file is a major pain in the > > butt. One of the milestone 2 goals should be to clean up this mess and > > create an easily expandable, user-friendly level- and resource > > management system. This will be a time-consuming task as we need to > > give it a lot of careful thought not only about how to manage the > > current resources, but also about what future versions should be > > capable of. > > Whats the problem with the current resource and tile loading stuff? > The only bad thing I see at the moment is that the tile-resource file > doesn't use the sprite-tag which the sprite-resource file provides, > thus duplicating a handfull of lines code unnecesarily, but beside > that I don't see much that could be done a lot better. > > > For example, maybe we can think of a way to set tile id's > > automatically, that'd make things a lot easier. > > That will just make sure that the next change to the tile-file surely > f***-up all the current levels. The whole point of having the id's > hardcoded is that they never ever need to be changed for a given tile. > > > If we are going to support level packs, we could create a > > Quake3-engine-like system where everyone can add a package > > containing their own levels, textures, shader scripts etc. which > > will then be put together by the game. > > Thats basically what phyfs provides. -- "There's always been Tower of Babel sort of bickering inside Unix, but this is the most extreme form ever. This means at least several years of confusion." -- Bill Gates, founder and chairman of Microsoft, about the Open Systems Foundation |
From: Ryan F. <rf...@gm...> - 2004-08-04 20:00:43
|
On Wed, 4 Aug 2004 20:36:15 +0100, Ricardo Cruz <ri...@ae...> wrote: > > I have to say I agree with Ingo. > That could become really hard to manage. It would be better to just agree in > something (like someone suggested) is having numbers reserved for some tiles, > this way it would always be portable. > 0 - 100 - green stuff > 101 - 200 - red stuff > 201 - 300 - slopes That would just break current stuff and doesn't really solve anything. We already have tilegroups to group things, we don't need to designate number ranges. -- Ryan |
From: Demon N. <dem...@ya...> - 2004-08-05 15:00:39
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Mi=E9rcoles, 4 de Agosto de 2004 21:36, Ricardo Cruz escribi=F3: > A part from this, work that tiles need, in the code, I mean (in the order > that they came to my mind): We can make the tiles like vectors: (tile (id 1) (solid 0,0 0,32 32,32 32,0) (file "grass.png")) This is like (solid#t) (This is only a example, in this case I prefer solid= #t) (tile (id 1) (solid 0,0 0,10 32,10 32,0) (file "grass.png")) Height: 10 px (tile (id 1) (solid 0,0 0,20 32,10 32,0) (file "grass.png")) Tile with inclination (tile (id 1) (solid 0,0 16,32 32,0) (file "grass.png")) Triangle =2E.. The tile-file implementation is easy, but the code to make that it work=20 correctly... =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBEkuPHo4XwRDcj7QRAlVtAKCCT2XLDH0Xrt8fvYzxTCjKoFb3+wCfTTEH GYuYdX4qwXWQAzi6x5z/lb8=3D =3DeDok =2D----END PGP SIGNATURE----- |
From: Ricardo C. <ri...@ae...> - 2004-08-05 17:04:52
|
I don't have know why I have added that (solid) field. This was just to ma= ke=20 my point about the ids subject. Anyway, about that, maybe something like the following would be better: (shape "square"), (shape "triangle-left"), (shape "whatever"). Since then we could make specific code for each one that would be obviousl= y=20 better for performance reasons. Anyway, we could, of course, have a custom shape. Em Quinta, 5 de Agosto de 2004 16:00, o Demon Night escreveu: > El Mi=E9rcoles, 4 de Agosto de 2004 21:36, Ricardo Cruz escribi=F3: > > A part from this, work that tiles need, in the code, I mean (in the > > order that they came to my mind): > > We can make the tiles like vectors: > (tile (id 1) (solid 0,0 0,32 32,32 32,0) (file "grass.png")) > This is like (solid#t) (This is only a example, in this case I prefer > solid#t) (tile (id 1) (solid 0,0 0,10 32,10 32,0) (file "grass.png")) > Height: 10 px > (tile (id 1) (solid 0,0 0,20 32,10 32,0) (file "grass.png")) > Tile with inclination > (tile (id 1) (solid 0,0 16,32 32,0) (file "grass.png")) > Triangle > ... > > The tile-file implementation is easy, but the code to make that it work > correctly... > > =2D-=20 I'd rather laugh with the sinners, Than cry with the saints, The sinners are much more fun! -- Billy Joel, "Only The Good Die Young" |
From: Ricardo C. <ri...@ae...> - 2004-08-05 11:02:10
|
Em Quarta, 4 de Agosto de 2004 21:00, o Ryan Flegel escreveu: > On Wed, 4 Aug 2004 20:36:15 +0100, Ricardo Cruz <ri...@ae...> wrote: > > I have to say I agree with Ingo. > > That could become really hard to manage. It would be better to just > > agree in something (like someone suggested) is having numbers reserved > > for some tiles, this way it would always be portable. > > 0 - 100 - green stuff > > 101 - 200 - red stuff > > 201 - 300 - slopes > > That would just break current stuff and doesn't really solve anything. > We already have tilegroups to group things, we don't need to designate > number ranges. Have you ever tried to add a new tile? It is a hell because you have to check it around who has the highest number to add that. And a few times, bugs were introduced because of repeated numbers. Yes, it would break current levels (nothing that a file replace utility wouldn't solve easily), but it would make tiles configuration much pleasent. Cheers, Ricardo -- Nothing is faster than the speed of light ... To prove this to yourself, try opening the refrigerator door before the light comes on. |
From: Ryan F. <rf...@gm...> - 2004-08-05 11:23:03
|
On Thu, 5 Aug 2004 12:09:24 +0100, Ricardo Cruz <ri...@ae...> wrote: > Em Quarta, 4 de Agosto de 2004 21:00, o Ryan Flegel escreveu: > > > > On Wed, 4 Aug 2004 20:36:15 +0100, Ricardo Cruz <ri...@ae...> wrote: > > > I have to say I agree with Ingo. > > > That could become really hard to manage. It would be better to just > > > agree in something (like someone suggested) is having numbers reserved > > > for some tiles, this way it would always be portable. > > > 0 - 100 - green stuff > > > 101 - 200 - red stuff > > > 201 - 300 - slopes > > > > That would just break current stuff and doesn't really solve anything. > > We already have tilegroups to group things, we don't need to designate > > number ranges. > > Have you ever tried to add a new tile? > It is a hell because you have to check it around who has the highest number > to add that. And a few times, bugs were introduced because of repeated > numbers. > > Yes, it would break current levels (nothing that a file replace utility > wouldn't solve easily), but it would make tiles configuration much pleasent. Perhaps. Maybe we should have some utility to add new tiles (without overlapping). Would probably be simpler than a util to reformat the levels (and we wouldn't break levels for future releases). On the other hand, now would be the time to break level file format (since it's already much different than in 0.1.x). However, I think that even in predefining ranges we will run into the same problems with repeating numbers, etc, especially if we have more than 100 tiles of a same general group. I dunno.. just playing devil's advocate. -- Ryan |
From: Ricardo C. <ri...@ae...> - 2004-08-05 12:21:56
|
Em Quinta, 5 de Agosto de 2004 12:23, o Ryan Flegel escreveu: > On Thu, 5 Aug 2004 12:09:24 +0100, Ricardo Cruz <ri...@ae...> wrote: > > Em Quarta, 4 de Agosto de 2004 21:00, o Ryan Flegel escreveu: > > > On Wed, 4 Aug 2004 20:36:15 +0100, Ricardo Cruz <ri...@ae...> wrote: > > > > I have to say I agree with Ingo. > > > > That could become really hard to manage. It would be better to just > > > > agree in something (like someone suggested) is having numbers > > > > reserved for some tiles, this way it would always be portable. > > > > 0 - 100 - green stuff > > > > 101 - 200 - red stuff > > > > 201 - 300 - slopes > > > > > > That would just break current stuff and doesn't really solve anything. > > > We already have tilegroups to group things, we don't need to designate > > > number ranges. > > > > Have you ever tried to add a new tile? > > It is a hell because you have to check it around who has the highest > > number to add that. And a few times, bugs were introduced because of > > repeated numbers. > > > > Yes, it would break current levels (nothing that a file replace utility > > wouldn't solve easily), but it would make tiles configuration much > > pleasent. > > Perhaps. Maybe we should have some utility to add new tiles (without > overlapping). Would probably be simpler than a util to reformat the > levels (and we wouldn't break levels for future releases). On the > other hand, now would be the time to break level file format (since > it's already much different than in 0.1.x). > No, there would be not the need to a tool to reformat the level format. It would only be done once! Of course, it would then be impossible to play 0.1.1 levels from the head. Anyway, better to break to completely break it than having it half broken, due to the change of some tiles ids. > However, I think that even in predefining ranges we will run into the > same problems with repeating numbers, etc, especially if we have more > than 100 tiles of a same general group. > It wouldn't still be a problem. Imagine this case: ; Green tiles 1-100 (tile (id 1) (solid#t) (file "grass.png")) (...) (tile (id 100) (solid#t) (file "pieceofgreen.png")) ; Swap tiles - 101-200 (tile (id 101) (solid#t) (file "discusting_water.png")) (tile (id 102) (solid#f) (file "i_will_not_drink_this.png") Okay, green tiles are full. The developer would only need to add a: ; Green tile 201-300 (extended from 1-100) (tile (id 201) (solid #t) (file "another_green_tile.png")) And now, other developers that want to add more Green Tiles would just see the first was full and add to this extended, and so on. ----- // ----- This is what is currently being done: ; Green tiles (tile (id 1) (solid#t) (file "grass.png")) (...) (tile (id 100) (solid#t) (file "pieceofgreen.png")) ; Swap tiles (tile (id 101) (solid#t) (file "discusting_water.png")) (tile (id 102) (solid#f) (file "i_will_not_drink_this.png") Then, a developer would want to add a new green tile and what it does is: ; Another green tile (tile (id 103) (solid #t) (file "another_green_tile.png")) Then, another swap is needed to be added, so a new line is created: ; Another swap tile (tile (id 104) (solid #t) (file "another_swap_tile.png")) Then, if another green tile is needed, the developer would have to go around (in the mess that the file is) and look for the highest number, or just add a big number. Anyway, bugs like this could (and already) happen: (tile (id 104) (solid #f) (file "yet_another_green_tile.png")) Same as the "Another swap tile"! Arghh! It is just a mess! We just need some organization, no need for a new implementation, this is just fine. Cheers, Ricardo > I dunno.. just playing devil's advocate. -- Q: Why is it that Mexico isn't sending anyone to the '84 summer games? A: Anyone in Mexico who can run, swim or jump is already in LA. |
From: Ingo R. <gr...@gm...> - 2004-08-05 17:27:06
|
Ricardo Cruz <ri...@ae...> writes: > Have you ever tried to add a new tile? Yes, lots and lots of tiles. > It is a hell because you have to check it around who has the > highest number to add that. And a few times, bugs were introduced > because of repeated numbers. You have to check at *EXACTLY ONE* place in the file, the end. Use (last-tile-id + 1) and the job is done. If somebody messed up the tile file and randomly added new tiles in the middle of it you should go and punch him. Adding some sanity checking into SuperTux for the right tileid order might of course be a good thing to avoid accidental copy&paste errors. > Yes, it would break current levels (nothing that a file replace > utility wouldn't solve easily), but it would make tiles > configuration much pleasent. No, it would actually cause your currently non-existing problem, to get much much worse. Think of the tile-id as a completly random handle thing, it has ZERO meaning in itself, the only properties that it must have is that it should be uniq and never change, its value can be completly random. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
From: Ricardo C. <ri...@ae...> - 2004-08-05 17:44:19
|
Em Quinta, 5 de Agosto de 2004 18:26, o Ingo Ruhnke escreveu: > Ricardo Cruz <ri...@ae...> writes: > > Have you ever tried to add a new tile? > > Yes, lots and lots of tiles. > At first, I believe it was pretty simple. But as the file keeps growing, it gets a hell to add one to it. > > It is a hell because you have to check it around who has the > > highest number to add that. And a few times, bugs were introduced > > because of repeated numbers. > > You have to check at *EXACTLY ONE* place in the file, the end. Use > (last-tile-id + 1) and the job is done. If somebody messed up the tile > file and randomly added new tiles in the middle of it you should go > and punch him. Adding some sanity checking into SuperTux for the right > tileid order might of course be a good thing to avoid accidental > copy&paste errors. > Then, there would be no organization. Tiles from the same tile groups should stay together, making them to be listed together in the level editor is reason enough. > > Yes, it would break current levels (nothing that a file replace > > utility wouldn't solve easily), but it would make tiles > > configuration much pleasent. > > No, it would actually cause your currently non-existing problem, to > get much much worse. > If there were no problems, our level designer wouldn't complain about it and start this discussion. That, as a matter of fact, is the second time it happens. > Think of the tile-id as a completly random handle thing, it has ZERO > meaning in itself, the only properties that it must have is that it > should be uniq and never change, its value can be completly random. Yep, and since it never changes, I suggest to start a fresh organization of the tiles file. I can do that myself, no need to complain about it. Anyway, would be better to wait for the 0.1.2. Cheers, Ricardo -- I can't decide whether to commit suicide or go bowling. -- Florence Henderson |
From: Ingo R. <gr...@gm...> - 2004-08-05 18:04:09
|
Ricardo Cruz <ri...@ae...> writes: > Em Quinta, 5 de Agosto de 2004 18:26, o Ingo Ruhnke escreveu: >> Ricardo Cruz <ri...@ae...> writes: >> > Have you ever tried to add a new tile? >> >> Yes, lots and lots of tiles. >> > At first, I believe it was pretty simple. Actually, it started out rather complicated with two groups of tiles, the old and the new ones, serving more or less the same purpose. Due to the way the ids are, that situation could be painlessly solved and both tile sortiments could be used in parallel and thus providing an easy migration. > But as the file keeps growing, it gets a hell to add one to it. The file has still exactly one end, and thats still the only place at which you have to look. It doesn't get any more complicated, no matter if you have 10 tiles or 10000 tiles, just look at the end, (last_id+1), done. If somebody fucked up the file and inserted numbers in random order, then one should better sort the files after their id (trivial with a few lines of scheme). > Then, there would be no organization. Yes, thats exactly the point, the tile-id's MUST NOT be used for organisation, tile-groups must be used for that, since they can be painlessly reordered at any point in time, tile-id's must stay forever. > Tiles from the same tile groups should stay together, making them to > be listed together in the level editor is reason enough. That what tile-groups are for. >> No, it would actually cause your currently non-existing problem, to >> get much much worse. > If there were no problems, our level designer wouldn't complain > about it and start this discussion. That, as a matter of fact, is > the second time it happens. Then people are doing something fundamentaly wrong, if you just add last_id+1 there is NOTHING that can go wrong, the only point where it ever can go wrong is if too people at the same time add new tiles, but then, no matter what system, you get conflicts which you have to resolve. >> Think of the tile-id as a completly random handle thing, it has >> ZERO meaning in itself, the only properties that it must have is >> that it should be uniq and never change, its value can be completly >> random. > > Yep, and since it never changes, I suggest to start a fresh > organization of the tiles file. Why that? Its completly useless, tile-groups to the same and do it a million times more flexible, you can even have overlapping tile-groups if needed. > I can do that myself, no need to complain about it. Anyway, would > be better to wait for the 0.1.2. It would be MUCH MUCH better to let everything as it is and just fill the tilegroups with meaning full content. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
From: Nathan M. <zr...@gm...> - 2004-08-05 18:32:15
|
What's the maximum tile-ID number? Probably the best solution is to let each level-designer apply a unique 3-digit prefix to their tile ids, and have a wiki page or something where people can put their number so it's easy to tell if the prefix you have in mind is taken already. Once you have one, you can easily create a stand-alone level pack without woory of stepping on anyone's toes. (For example, if I wanted to create new tiles, I could use tile-ids 113000, 113001, 113002, and so on. Nobody else would create tiles starting with 113, and I'd have 1000 tiles of space to work with.) In addition to this, we should allow for multiple tile-definition files (perhaps put them all in a directory that supertux checks for tile definitions) so that the end-users wouldn't have to worry about editing files - they just unzip a level pack to their Supertux directory and play. (Or have a simple installer - look at Stepmania's "smzip" format, which are really just zip files that are designed to be unzipped in a certain location, but you can have a simple program to handle that file type that does the unzipping for you in the right place automatically. Anyone care to grab their source and change one line to make an "stzip" installer?) |
From: Ingo R. <gr...@gm...> - 2004-08-05 19:19:07
|
Nathan McCoy <zr...@gm...> writes: > What's the maximum tile-ID number? MAX_INT currently, which means some rather huge number, more realistically is probally 65536. > Probably the best solution is to let each level-designer apply a > unique 3-digit prefix to their tile ids, and have a wiki page or > something where people can put their number so it's easy to tell if > the prefix you have in mind is taken already. Yep, that would be some poor-mans namespaces, might be needed if there is a huge number of more or less independet tile creators, but as it stands now with just not even a handfull of people, its easier if they just dump their stuff directly into CVS, so it gets instantly available for everyone. > they just unzip a level pack to their Supertux directory and play. Actually they shouldn't even need to unzip the zip if physfs is used, the game could just 'mount' the zip transparently. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |