Closed datahead8888 closed 8 years ago
Sounds like a nice task for @sydneyjd. Do you want to give it a try?
Vale, Quintus
Sure i can give it a shot. What does the original one look like @datahead8888 ?
Sydney
What does the original one look like @datahead8888 ?
These are the images, though they are all the same size in the actual game. The first step would be to come up with a concept - how will we change it?
Also, "Pow" itself is a term used in the Mario games. We might either consider "Switch" or some other name.
Here are the SVGs: https://github.com/Secretchronicles/TSC/tree/v2.0.0-beta7/drafts/game/pipgirl/pow
Valete, Quintus
I know it doesn't look the best (yet) But what do you think of the overall switch idea? @datahead8888 @Quintus @Bugsbane
Nice. The idea is good. The top part can even be colored differently.
Now apply a gradient to make it look round.
Vale, Quintus
Does the red part slide into the black part, sort of like a big button that is pressed down? I was thinking if we might shape the bottom black part a little differently, but it depends on what we're trying to do.
You also might try a little different color for the very top rectangle (at least another shade of red) so that it stands out against the main body.
Yes, it will need shading, but that will probably come after the initial shape is decided.
Does the red part slide into the black part, sort of like a big button that is pressed down?
I would say so.
Vale, Quintus
@Quintus @datahead8888 @Bugsbane Opinions? Any ideas on bottom of switch improvement?
Red and black together, traditionally signifies danger, rather than opportunity.
Currently it looks somewhat like a pipe, especially the black part. Might I suggest we try a switch instead?
Red and black together, traditionally signifies danger, rather than opportunity.
I was imagining we would have several colours for the top part. The old pow switches are also available in three colours, and depending on the situation, the level designer should be able to pick the switch with the colour he finds to fit best.
Valete, Quintus
@Bugsbane @Quintus @datahead8888 How do i change the bottom to look more "button like"?
I'll try and run up a draft tomorrow (Monday)
I honestly have a little trouble seeing black for the color of the base. Gray might be an option.
At this point, I'd like to defer further suggestions about the shape and other color choices to Bugsbane.
@Bugsbane, do you think you might be able to draw a really quick sketch of your thoughts so that Sydney can see what you had in mind?
I'm thinking something a little more along these lines (shading on the base still needs work):
Notable changes include:
I also generally favor avoiding letters anywhere given the many different languages spoken by our players.
Changing it to green (generally in most games, pushing a button is more likely to do something good than bad)
I still think we should have switches with different colors. They can be used where they fit, or a creative level designer could use the color codes for something. You could have blocks of the same color appear/disappear, or red switches generally spawn enemies in the level, etc.
I also generally favor avoiding letters anywhere given the many different languages spoken by our players.
I agree with this, but where was the suggestion made to use letters?
Valete, Quintus
I still think we should have switches with different colors
Agreed.
where was the suggestion made to use letters?
The current original image uses the letter "P". I brought it up in reference to that.
The current original image uses the letter "P". I brought it up in reference to that.
Ah ok. I think the P was only there because the original Mario switches also had it.
Btw @Bugsbane, why don’t join us in IRC at #secretchronicles
on chat.freenode.net? datahead and me are hanging around there quite often, and sydney is there all the time. Would be nice to see you there from time to time.
Vale, Quintus
Honestly, I immediately mistook it for a Mario pipe when I saw the green color. It could just be me, though, since we've been talking about pipes recently. We could also try another shade / color for the very top tip section to differentiate it from the middle section below it. Good work :)
We also ought to get Sydney's thoughts on this and probably should allow him to make any other changes if they are made.
Btw @Bugsbane, why don’t join us in IRC at #secretchronicles on chat.freenode.net? datahead and me are hanging around there quite often, and sydney is there all the time. Would be nice to see you there from time to time.
Yes, we'd definitely be up for having you in IRC with us :) I tend to be in and out of IRC quite a bit myself.
I still think we should have switches with different colors....
This is a good idea. The question of level consistency is going to eventually come up. I'm wanting to publish some thoughts on world/level consistency later. I don't want to be overbearing with rules on how levels are made, but there are some things that need to thought about across all levels. Consistency, consistency, consistency, consistency...
@Bugsbane I really like your switch. Are we pushing for this in release in 2.0.0? We culd do the pipe tops fliped over like bugsbane used up there. That would alow them to match with existing pipes. Any thoughts?
Honestly, I immediately mistook it for a Mario pipe when I saw the green color. It could just be me, though,
I don’t think that this looks like a Mario pipe, even with the green color.
Are we pushing for this in release in 2.0.0?
Not without the SVGs and not without a licensing confirmation. We have had this once, that’s enough :-)
Also, we’d need a graphic for the activated state of it.
Vale, Quintus
there are some things that need to thought about across all levels. Consistency, consistency, consistency, consistency...
This.
Not without the SVGs
Is there somewhere SVG's can be uploaded more easily than comitting to GIT on a regular basis? GitHub issues are a pain, as they allow uploading of PNG's / JPG's but not SVG. This is what often leads to me uploading png's and then never getting around to sharing the SVG. Git might be easy for dev's, but this kind of thing usually ends up taking me 1/2 an hour to figure out, which is time I'd much rather spend making art. Something like a TSC ownCloud instance with a folder structure mimicing the TSC data/bitmaps folder would be great, as it's super easy to just turn into another folder in the file manager via webdav. If we had something like this I'd save all my drafts in there by default instead of having to hunt around for them, upload them somewhere else etc.
and not without a licensing confirmation.
Can we save time here and just have me state for the record that:
"I give full permission for the secret Chronicles project, as found at http://GitHub.com/Secretchronicles to use any artwork (png's/jpg's/sketches/.svg files) created by me, that I post on this projects sub pages (issues, files area etc.), past, present and future until further notice, under a creative commons CC-BY 4.0 license."
? Because if that's ok, then I verify the statement above in quotation marks to be accurate and true. :) Once again, while I understand, accept and appreciate the need for covering legal bases, I'd like to spend less time doing this, and more time doing art, where possible.
Is there somewhere SVG's can be uploaded more easily than comitting to GIT on a regular basis?
Currently, there are 3 possibilities:
http://team.secretchronicles.de/~<username>
everything you like. I use it to dump everything TSC-related somewhere onto the web (link). I’d just have to create an account for you, then you can use any SFTP program like FileZilla to upload files.Can we save time here
The forum and mailinglist both have rules that automatically license everything 4.0 that you post there. GitHub doesn’t allow us to enforce people to check an "I accept this" option, so it doesn’t work on GitHub. datahead has pointed out that we could have this when we self-host the tracker after the 2.0.0 release.
just have me state for the record that:
That’d work for GitHub for now, yes.
Vale, Quintus
We still need the SVG from Bugsbane if we use his version and need to be sure everyone is in agreement as to which version we use. Thus no one needs to be assigned to this task for now. We should discuss this in our next team meeting, unless we reach Bugsbane before then and come to a decision through the tracker.
Sorry I don't have time for much more right now:
"I give full permission for the secret Chronicles project, as found at http://GitHub.com/Secretchronicles to use any artwork (png's/jpg's/sketches/.svg files) created by me (including the SVG file linked to below), that I post on this projects sub pages (issues, files area etc.), past, present and future until further notice, under a creative commons CC-BY 4.0 license."
http://duruz.com/green-button.svg
This is a temporary link. Please download the SVG and add to the git repo.
I stored it on alexandria: http://team.secretchronicles.de/~quintus/store/green-button.svg
Thank you for your hard and patient work for the game. It is great to have a skilled artist like you :-)
Vale, Quintus
Do we need frames for it being pushed down, or will that be done in code? Using frames is probably quicker to do, but you could have it looking a lot smoother is there was code along the lines off "Lower button if it has a weighted object on it, otherwise make it slowly rise again." By "the button" I'm referring to only the green part, not the metal base. I can easily group the button and the base, or separate them into separate PNG's if it will help. This would take all of about 20 seconds.
There’s no C++ code for the switches. They’re entirely controlled by scripting, including change of the graphic when stumped on. TSC provides a rudimentary default implementation in the SSL (http://www.secretchronicles.de/docs/2.0.0-beta8/ssl/Std/Switch.html), but a level writer is free to code all the logic himself instead. Thus, no changes in C++ code are required. The SSL implementation however can surely be improved.
Here’s the implementation in the SSL: https://github.com/Secretchronicles/TSC/blob/9ad35b29688159edb0250f74e29618dae0106517/tsc/data/scripting/std/switch.rb
As you can see, rather simple. By employing a quickly executing periodic timer, it’d be possible to create a smooth animation if desired (again, without touching the C++ code). Same goes for the button reacting on objects on it. In any case, the scripter will need frames to display, so they’re definitely needed :-)
Vale, Quintus
TSC provides a rudimentary default implementation in the SSL (http://www.secretchronicles.de/docs/2.0.0-beta8/ssl/Std/Switch.html), but a level writer is free to code all the logic himself instead. Thus, no changes in C++ code are required. The SSL implementation however can surely be improved. Here’s the implementation in the SSL: https://github.com/Secretchronicles/TSC/blob/9ad35b29688159edb0250f74e29618dae0106517/tsc/data/scripting/std/switch.rb
You just made my head explode.
As you can see, rather simple.
Ahhhh.... no.
By employing a quickly executing periodic timer, it’d be possible to
Is it possible that my head could have exploded a second time?
so they’re definitely needed :-)
This part I get. So how many frames do you need? Just up and down, or multiple inbetween frames (how many)? Given that each one is just moving an object and re exporting, each frame should only take me a few seconds extra.
@Bugsbane You don't know Ruby, do you? :)
@kirbyfan64 Sure! That's those red rocks that come out of the ground, right? Why do you ask? ;P
@Bugsbane You don't know Ruby, do you
I'm a programmer, and I don't really know Ruby very well either :)
@Quintus, if we add more frames, yes, it could be done through scripting now, but it might make sense to add some sort of C++ support eventually.
Up and down frames as well as the SVG: At this link.
I give full permission for the secret Chronicles project, as found at http://GitHub.com/Secretchronicles to use any artwork (png's/jpg's/sketches/.svg files) created by me (including the SVG and PNG files in the .tar.gz file linked to above), that I post on this projects sub pages (issues, files area etc.), past, present and future until further notice, under a creative commons CC-BY 4.0 license.
Bugsbane notifications@github.com writes:
You just made my head explode.
Fairly enough :-). Okay, from the beginning: TSC comes with a scripting engine that allows the level author to diverge from the standard TSC gameplay. datahead used this to create a draw bridge, and I often use it for switches. If you play the tutorial level, you’ll see sauer2 used it for showing messages to the user. In one of the new “quintus_*” levels I dynamically create platforms when all red gems have been collected by the player. The enemy pit level I posted in the forums generates lots of enemies dynamically.
Or in short: Any dynamic content in TSC is done by scripting. The main documentation on scripting is here:
http://www.secretchronicles.de/docs/2.0.0-beta8/core/
That’ſ the so-called “core” documentation. Any of the things documented there are implemented in C++, but are accessible to the level writer at runtime by using Ruby. Additionally, this facility was used to provide a set of simple Ruby scripts that we ship with the game, the “Standard Scripting Library”, or SSL for short. This way a level writer doesn’t have to reinvent everything, but can just use the Ruby code that was written on top of the Core API. The SSL is documented here:
http://www.secretchronicles.de/docs/2.0.0-beta8/ssl/
Switches are implemented this way. The “switch” standard library takes the facilities from the Core API that allow to control the appearance and collision behaviour of a sprite and uses them for making the switch work. It first attaches to the static switch sprite by listening for a “touch” event on its UID. The event handler, when executed, changes the switch’s sprite to the pressed one and additionally performs some action the level author defined in his script code.
That is, the current implementation uses two sprites, the normal sprite, and the sprite for the pressed button. You can supply any amount of sprites that you deem useful, and it should be easy to adapt the switch’s implementation by just changing some lines of Ruby code.
By employing a quickly executing periodic timer, it’d be possible to Is it possible that my head could have exploded a second time?
Forget about the timers, it’s an implementation detail only relevant for coding. The one who is going to adapt the switch.rb file will appreciate that I made a recommendation on a possible way to implement it.
This part I get. SO how many frames do you need? Just up and down, or multiple inbetween frames (how many)?
Supply as many as you deem required. Whether we show 3, 4, or 10 does not really matter as the amount of code needed to make it work is the same.
Valete, Quintus
Seems to me that if there's no need of any specific number, that two, just like what we already had, is probably simplest. If we don't actually need more, then we can just close this with the two frames I've already posted.
Okay. Then I’ll add your button when I find time again.
Vale, Quintus
Quintus, are you still working on this task? Will it likely be deferred until the SFML port (major priority) is completed?
datahead8888 notifications@github.com writes:
Quintus, are you still working on this task? Will it likely be deferred until the SFML port (major priority) is completed?
It is likely that I focus on the SFML stuff exclusively first. However, adding this graphic should really not be difficult. Feel free to unassign me.
Vale, Quintus
@Bugsbane can we have blue and red versions of the switch as well so we can directly replace all switches in this directory?
Vale, Quintus
Also, please export at a larger size, like 128x128px like the blue pow switch we currently have.
Here’s how it looks in-game, with the old blue switch on the right side:
What does everyone think?
Valete, Quintus
Looks pretty good! However, are you sure everyone would recognize this as switch at once? It doesn't stand out that much...
Am 07.10.2015 um 09:36 schrieb Marvin Gülker:
Also, please export at a larger size, like 128x128px like the blue pow switch we currently have.
Here’s how it looks in-game, with the old blue switch on the right side:
5 https://cloud.githubusercontent.com/assets/156358/10331587/d4930752-6cd6-11e5-8d57-0b52513517dc.png
What does everyone think?
Valete, Quintus
— Reply to this email directly or view it on GitHub https://github.com/Secretchronicles/TSC/issues/337#issuecomment-146101941.
It doesn't stand out that much...
In the image above I think this is a result of the green background behind the green switch. You’d probably use another color in that situation; also I think there’s a switch in the tutorial level that makes people familiar with its functionality (if there isn’t, please add one :-)).
Vale, Quintus
Sounds reasonable.
Unless someone changed the tutorial, the switch should be still in there.
Am 07.10.2015 um 14:07 schrieb Marvin Gülker:
It doesn't stand out that much...
In the image above I think this is a result of the green background behind the green switch. You’d probably use another color in that situation; also I think there’s a switch in the tutorial level that makes people familiar with its functionality (if there isn’t, please add one :-)).
Vale, Quintus
— Reply to this email directly or view it on GitHub https://github.com/Secretchronicles/TSC/issues/337#issuecomment-146177678.
It doesn't stand out that much
the image above I think this is a result of the green background behind the green switch.
I agree with both statements. Maybe offering a couple of different colors (red, yellow, blue) may help. It would be quick and easy enough to do. Possibly, the "off" switch could be made a bit taller, too...
Maybe offering a couple of different colors (red, yellow, blue) may help
Take a look at what I wrote above — I asked you for exactly these :-)
Possibly, the "off" switch could be made a bit taller, too...
Beware that it needs to be distinguishable from the "on" switch. You’d then have to make that one taller also (maybe try to match the dimensions of the existing pow switch?).
Vale, Quintus
Yes, I'm just talking about making the taller image, taller again, so it would actually be more distinguishable. Actually, if we wanted to mark junior jobs for artists, making this taller and changing colors would definitely be one, otherwise I can just do it.
Actually, if we wanted to mark junior jobs for artists, making this taller and changing colors would definitely be one
I’d be fine with this. Sounds like something for @sydneyjd then :-)
Vale, Quintus
Hi, this is my idea of a switch. Colors can be changed. =D
@JohnTheTreeman - the main characteristic of the Nintendo-like switches is the letter P. I think we'd be best off not having any letter on the switch. We've gone through enormous efforts to stop being a Mario-NIntendo clone, so I don't think letters are worth the risk.
Multiple types of switches might be an interesting idea to discuss, but if they require programming changes, they will have to wait until the SFML port is done.
datahead8888 notifications@github.com writes:
Multiple types of switches might be an interesting idea to discuss, but if they require programming changes, they will have to wait until the SFML port is done.
Since all switches are scripted, and script is written by the level writer, no C++ code changes are necessary.
Vale, Quintus
The Pow Switch looks just like the P-Switches from some Mario games. We probably need to replace it with a bit different image (at least with a letter other than P).