Stuff I want to see in the next patch

[budgiedood]

Wahoo thanks Alex, what will you be able to do with the editor? 2player vs modes?  2player co-op modes? or just 1player levels?
thanx
Oli

[c-b]

Does that mean it'll be released on monday? Ack I cant wait to make my own X-7 levels (You know, the chase/race levels with vehicles and such). Not to mention play with ropes and chains.

Although I really should be working on my other maps.

[Chronic Logic - Alex]

You will be able to make single and multiplayer levels, you won't be able to create new versus modes though, those are hard-coded.

[ExplodingCabbage]

This is a list of stuff I'd like to see in Gish 1.3 (excluding bugfixes)

* Ability to play warp zones that you have already discovered from the single level option.
* A way to turn off turbo mode  http://www.pontifex2.com/iB_html/non-cgi/emoticons/tounge.gif" border="0" valign="absmiddle" alt=':p'>
* Ability to play the campaign from a certain level, rather than just playing that certain level. I would suggest that this replaces the 'single level' option, as then the player would be able to just choose 'exit' rather than 'continue' if he just wanted to play one level
* If the above doesn't happen, it would be good to have the option of playing the right music for single levels, rather than just a random track
* Not crucial, since the plot isn't the most intellectually stimulating and deep anyway, but fixing some of the grammar errors in the dialogue wouldn't go amiss.

OK, the editor. What I'd like to see in it...

* Levels are made by laying down blocks of any size or shape. Then, each block can be selected and have its properties changed - these would be Friction, Strength (0 would be default, and make the object invincible), Whether it can move, Weight.
* Ability to add lava, water, spikes, ropes, buttons. Ropes would have a strength rating, buttons a resistance rating, spikes a damage per second rating.
* A trigger editor, ala most strategy games. This, I believe, would be the simplest and most intuitive way to do the complex stuff. Basically, every trigger has:
  Events - the thing that starts the trigger off. It could be the start of the level, pressing a button, or gish moving into a certain area
  Actions - what happens. It could be a dialogue running, a door opening, or the end of the level
  Conditions - when an event occurs, these conditions are checked. If they are false, the triggers actions are not fired. For example, suppose you have an automatic door in your level that opens when gish comes within a certain distance of it and closes when he leaves... but the player has to turn it on before it will function, by pressing a button. The event would be 'Gish comes within x distance of door y', the condition would be 'Button z is pressed', and the action would be 'Door y opens'

For the trigger editor to work, it should be possible to add objects to the trigger just by clicking on them - for instance, if the action was 'Door moves', you would type in a distance, the choose a direction, then click on the door in the level. Everything is easy this way, and there's no programming code.

Thats about it. Hi all, btw - I'm new here.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/cool.gif" border="0" valign="absmiddle" alt=':cool:'>

[budgiedood]

I think i'll add my thoughts-
A way to turn of SUPERSUZE MODE  http://www.pontifex2.com/iB_html/non-cgi/emoticons/tounge.gif" border="0" valign="absmiddle" alt=':p'> !
Co-operative story mode.
co-operative and vs triggers in the mapmaker.
A fix to tarball mating!

All i can think of at the moment.
Oli

[Jacius]

I mean no offense to you, ExplodingCabbage, but the design of the level editor should, and most likely will, reflect the design of the game's existing levels. There is a pretty clearly defined format for the levels (as shown by the fact that there *are* levels), and I imagine that Chronic Logic has an editor that they use internally (although it may not be bug-free or easy to use, and thus not suitable for release to the public).

I definitely would like to see the ability to play already-found secret levels from the level select, and for the level select to allow you to beat levels and play the next one. A cooperative mode would be great; hopefully some newly designed levels which require two Gishs to get through.

The biggest change that I think Gish needs is a new model for damaging Gish (and Hera/Gray). I have three major peeves with the current model:

First, spikes are not realistic. That is, Gish is damaged by merely being in contact with the spikes, rather than the sharp, pointed shape of the spike piercing Gish and thus causing damage. This is not a very big deal, because you are supposed to avoid the spikes anyway.

Second, Gish often gets caught at the edges of elevators and "sucked under" resulting in immediate death by pinching. Many of these elevators are secret, and you cannot even see where Gish is, so it is impossible to try to avoid the edges. Even if you avoid dying, many of the elevators will not come down again, and thus you are stuck in a secret chamber and have to restart the level.

The biggest problem is that Gish is an imposter! Yes, I know he is supposed to be a tarball, or at least a life-form that resembles a ball of tar, but this is not how he is modeled. That is to say, Gish is modeled as a ring with partially-rigid connecting spokes going through his middle (or something similar to that). Gish's mass is thus largely located on his perimeter, rather than his center, with the result being that he is prone to collapse in on himself or be inverted.

One of two things should be done: either his physical model should be altered to fit his damage model, or his damage model should be altered to fit his physical model. I personally think his damage model should be changed so that if too many of his "bones" break (that is, undergo too much pressure), then he would be damaged.

Alternatively, he could be made more liquide-like. For example, his face would 'slosh' arount inside of him, and only his head would take damage from pinching.

-Jacius

[weeble]

Hmm... I wrote a reply, but either I forgot to post it or it got moderated away. I'm going to assume it was my ineptness, since I don't think I said anything untoward.

I think Jacius said much the same thing - the level editor's features will doubtless reflect the existing structure of levels. So far as I can tell, that's a few layers of square grids of tiles, plus a whole bunch of special objects, like light-sources, ropes, movable blocks and enemies. My point is, the features of the level editor will be determined by the features of the game, not vice-versa.

[ExplodingCabbage]

Weeble, Jacius - sorry, but I don't really see your point. All my ideas for the editor were ways that I think the editor would be made easiest to use and least convoluted. How does my editor not 'reflect the design of the game's existing levels'?

Jacius - I completely agree with you about the damage system though. The spikes struck me as pretty lame at first, and I've died at the hands of elevators an uncomfortable number of times, but I really don't see how this can be changed. One thing I can think of about the spikes is that the damage taken by them would depend upon the momentum with which gish/grey is moving into them. One quirk with damage I would add to the list though: ability to damage self doing nothing but jumping up and down on a flat surface. Again, though - hard to fix. I would suggest that the degree of damage from flatness should depend upon the forces applied to gish... but then we'd be getting into large-scale game changes.

[weeble]

Ach, since you insist:
* Levels are made by laying down blocks of any size or shape. Then, each block can be selected and have its properties changed - these would be Friction, Strength (0 would be default, and make the object invincible), Whether it can move, Weight.
There appear to be two main classes of blocks in the game: those that can be any size, which can move and deform; and those that are fixed in a static grid, that can be broken. Off-hand I can recall no movable, breakable blocks. I would expect that these different classes of block will require different treatment in an editor.
* A trigger editor, ala most strategy games. This, I believe, would be the simplest and most intuitive way to do the complex stuff. Basically, every trigger has:
  Events - the thing that starts the trigger off. It could be the start of the level, pressing a button, or gish moving into a certain area
  Actions - what happens. It could be a dialogue running, a door opening, or the end of the level
  Conditions - when an event occurs, these conditions are checked. If they are false, the triggers actions are not fired. For example, suppose you have an automatic door in your level that opens when gish comes within a certain distance of it and closes when he leaves... but the player has to turn it on before it will function, by pressing a button. The event would be 'Gish comes within x distance of door y', the condition would be 'Button z is pressed', and the action would be 'Door y opens'
I really think this requires new code in the game and not just the editor. For example, dialogs always happen at the start of a level - it's quite possible that it isn't currently possible to trigger them from a switch or whatever. Also, I don't recall observing any conditions in the sense you describe. There are no buttons that enable other actions. It looks more like there is just one trigger - "object in area", and one action - "move object". I might be wrong - it's possible that the game has a more high-level understanding of buttons and switches, but I don't see why it would need one. There's also no guarantee that the level ending conditions are flexible - these could be hard-coded for all we know.

Also, you've missed out one of the most important features needed to make levels - object constraints. Various objects are fixed to each other or to points in space throughout the game. Without a means to edit this you'd not be able to make drawbridges, mining carts, rope-bridges, swings and most of the other interesting features in the game.

I still don't think I have close to a complete understanding of the simulation. I think that it's pretty pointless for us to suggest how a level editor should function when we don't know what capabilities exist for it to access.

Still, you have some good points - it should be easy to make doors with switches and stuff like that, without having to manually specify all the objects, joints and whatnot that go into them. Hopefully there will be some kind of prefab system. If they're nice they'll even let us make our own prefab contraptions.

If you're going for usability, I'd suggest you probably want to avoid making the user "type in a distance" when this kind of thing can be more naturally measured by having a resizeable vector appear on-screen.

[Jonathan_NL]

I think these are the layers:

Fixed background texture:	the texture you see when you can look through all layers in front of it.
Background layer:	The tile-based background.
Static interactive layer:	Fixed tiles you can't go through. Used at the edges of 'walled' areas. These are lit.
Interactive layer:	Gish, enemies, vehicles, moving platforms, etc. Simply where everything happens. Also lit.
Front layer:	Stuff in front of you. Used for decoration (like tubes at the Sewer), to fill 'walled' areas, for some tunnels and to hide secrets.

About custom objects: I know about something that allows you to create your own objects (only graphical), with this syntax (you can use whitespace in numerous ways, but this is the cleanest without without a fixed width font and assumed tab size):

Code Sample

texture_name // the name of the texture you want to use tri x y z x y x y z x y x y z x y shade_smooth polygon 5 x y z x y x y z x y x y z x y x y z x y x y z x y shade_flat quad x y z x y x y z x y x y z x y x y z x y quad_strip 8 // multiple quads in a row x y z x y x y z x y x y z x y x y z x y x y z x y x y z x y x y z x y x y z x y quad_strip 10 // if you want to create the sides of a cube -1.0 -1.0 -1.0 0.0 0.0 -1.0 1.0 -1.0 0.0 1.0 1.0 -1.0 -1.0 0.25 0.0 1.0 1.0 -1.0 0.25 1.0 1.0 -1.0 1.0 0.5 0.0 1.0 1.0 1.0 0.5 1.0 -1.0 -1.0 1.0 0.75 0.0 -1.0 1.0 1.0 0.75 1.0 -1.0 -1.0 -1.0 1.0 0.0 -1.0 1.0 -1.0 1.0 1.0 // close the 'path' end here nothing is parsed note that there are many more, mostly game-specific things

If you know vertices you can probably decode this. http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>

[ExplodingCabbage]

Weeble -
There appear to be two main classes of blocks in the game: those that can be any size, which can move and deform; and those that are fixed in a static grid, that can be broken. Off-hand I can recall no movable, breakable blocks. I would expect that these different classes of block will require different treatment in an editor.
Um... you seem to have missed out the ones that can't move or be broken. http://www.pontifex2.com/iB_html/non-cgi/emoticons/tounge.gif" border="0" valign="absmiddle" alt=':p'> But nvm - I see your point about the movable, breakable blocks. I guess you'd need to make it so that if you checked 'breakable' it would automatically uncheck 'can move', and vica-versa.

I really think this requires new code in the game and not just the editor. For example, dialogs always happen at the start of a level - it's quite possible that it isn't currently possible to trigger them from a switch or whatever. Also, I don't recall observing any conditions in the sense you describe. There are no buttons that enable other actions. It looks more like there is just one trigger - "object in area", and one action - "move object". I might be wrong - it's possible that the game has a more high-level understanding of buttons and switches, but I don't see why it would need one. There's also no guarantee that the level ending conditions are flexible - these could be hard-coded for all we know.

Good points - I think I agree now that the trigger editor wouldn't work, although I do think that it would kinda suck if dialogue had to be at level start, and it would be weird for this to be hard-coded. Still, there are a few factual flaws here that I shall correct:
There are conditions... sort of. I'm thinking about vs. levels and most boss fights. On the other hand, if level ends are worked separately from triggers, you're right - conditions don't exist. Doesn't matter much anyway - they'd rarely be used and could be 'faked' if necessary, so I'll yield on that matter.
About 'only one trigger' - what about collection and pit-fight levels? They have other triggers.
'Only one event' I disagree with, also. There are triggers that make ropes break, objects rotate and objects appear, to name a few, as well as the 'X wins' and 'new round' triggers.
About level endings, I actually seriously doubt they are hard-coded. Think about the number the game already has - enemies destroyed, gish in area, time up, all amber collected. It wouldn't make sense for them to have been hard-coded. On the other hand, I have a fear that they may have been hard-coded, since versus levels... strangely don't ever... end...

You're right that I should have gone into more detail about ropes and chains. I guess the best thing would be to set a point on any layer for each end where it is attached, and then select the length of the rope. You would also have a tickbox in most objects saying whether they can bump into ropes (for stuff like the weird vehicles in 2-7) As for ropes that start off wrapped around something... I dunno about that one.


I still don't think I have close to a complete understanding of the simulation. I think that it's pretty pointless for us to suggest how a level editor should function when we don't know what capabilities exist for it to access.

True. I assumed a lot of stuff would be possible that might not. It would be a shame if the engine really is limited purely to what we've already seen in the campaign in the way of stuff like warp zones, dialogue, complex triggers and level ends - there would be a lot more potential in the editor if it allowed more complex triggers, however it allowed them.

Still, you have some good points - it should be easy to make doors with switches and stuff like that, without having to manually specify all the objects, joints and whatnot that go into them. Hopefully there will be some kind of prefab system. If they're nice they'll even let us make our own prefab contraptions.

Prefabs would be good, especially for vehicles, but I have a fear that we might be limited to prefabs, at least in the way of doors, vehicles, buttons etc. That would kill off much of the editors potential. http://www.pontifex2.com/iB_html/non-cgi/emoticons/sad.gif" border="0" valign="absmiddle" alt=':('>

If you're going for usability, I'd suggest you probably want to avoid making the user "type in a distance" when this kind of thing can be more naturally measured by having a resizeable vector appear on-screen.
True. I was kind of focusing on the bit about selecting the block, and missed that I had just provided a perfect example of how to disobey my own advice.

Johnatan_NL -
Fixed background texture: the texture you see when you can look through all layers in front of it.
Background layer: The tile-based background.
Static interactive layer: Fixed tiles you can't go through. Used at the edges of 'walled' areas. These are lit.
Interactive layer: Gish, enemies, vehicles, moving platforms, etc. Simply where everything happens. Also lit.
Front layer: Stuff in front of you. Used for decoration (like tubes at the Sewer), to fill 'walled' areas, for some tunnels and to hide secrets.

OK, I understand that bit and it's sensible. But... all the code below was scary. I hope modders won't have to understand any that to make custom objects, when all that is really needed (as far as my puny brain, unaugmented by the wonders of a detailed understanding of programming and clever stuff, can understand) is to draw something as a jpg. and import it to a pallette in the editor. More complex stuff could be done from there by inserting the object to a layer, and if it is interactive setting all the variables I have already brought up, as well as sticking together objects with different properties.

[Jonathan_NL]

Gish uses targa.tga textures, not jpeg.jpg.

Everything in my example is just vertices and keywords declaring them and a few other things (like shading). You have probably noticed x y z x y. The first x y z are the coordinates in 3D space, and the second x y the coordinates of a place on the texture. Everything is in triangles, but the format of my example also accepts other shapes. It does that like this:
http://home.filternet.nl/~eo000199/jonathan/trianglebased.png">
The quad_strip here is the one in my example, but unfolded to 2D.

Of course it is possible to use a graphical editor, and the format I described doesn't need to be used. Btw, the BCS object format (I thought it was the format of some 3D program, ask Josiah) is binary, not really readable by human. http://www.pontifex2.com/iB_html/non-cgi/emoticons/wink.gif" border="0" valign="absmiddle" alt='::'>