Feature Idea
objectantics
Member Posts: 8
Hi GS, oA Games here, new to GS Scene.
So we are learning GS and its capabilities.
While in discovery I had an idea...
When an object is "renamed", "automatically" add it to a list between Standard, and Custom, call it AllMyGameCode, or "My Game Logic".
This will build in the "DRY" principal into GS, fostering quick and easy reuse of Game Logic.
It seams reasonable to create "Logic" objects as generics so that an inheritance model could be used on Logic. So a "Logic Object" could be prototyped much like an "Actor" (which has both Asset and Logic, i know).
It could be unlocked to create an instance specific version. Just like we handle actors now.
Just an idea.
Thanks,
James Beine
oA Games
So we are learning GS and its capabilities.
While in discovery I had an idea...
When an object is "renamed", "automatically" add it to a list between Standard, and Custom, call it AllMyGameCode, or "My Game Logic".
This will build in the "DRY" principal into GS, fostering quick and easy reuse of Game Logic.
It seams reasonable to create "Logic" objects as generics so that an inheritance model could be used on Logic. So a "Logic Object" could be prototyped much like an "Actor" (which has both Asset and Logic, i know).
It could be unlocked to create an instance specific version. Just like we handle actors now.
Just an idea.
Thanks,
James Beine
oA Games
Comments
@objectantics
Hi James, and welcome to GameSalad! Best of luck and success with all your future projects.
It's really good that you're thinking of ideas while using GSC that'd make using it simpler; although your idea here isn't needed in my opinion, sorry to tell you.
As you've discovered, if you put your Rules and Behaviours into a Prototype actor, then you can drag as many of these into your scenes as you want; as well as unlock any of them to amend/add the rules there. That is, in effect, your "logic object" which doesn't need to be listed anywhere, as they are in the Inspector ready for use at any time. And for your logic object groups of rules and behaviours that you'd want to list, the custom behaviours can be used; and although these groups of behaviours and rules aren't linked with a specific actor, they don't have to be.
Hopefully my answer hasn't dampened your enthusiasm for thinking about any other GSC GUI ideas though...
Edit: everyone works slightly differently I guess, so if you needed this feature, then just add to the title of the custom behaviour the name of the actor it came from...
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Okay, not to be argumentative, thats not the intent, but to better explain the benefits of the proposed idea...
So the existing manually created list, could be renamed "Favorites" established by "adding a star" to a "logic object".
The new list, "my game code", is system generated, it is just a "set" that a dev could browse through easily, and use a project management hierarchy.
A view to the game development process, not the game itself.
It's a quasi navigation tool, with management features. It might even be useful for a future "refactoring" feature set.
Your feedback inspired another idea too. The new "auto generated list of object should contain a sublist of actors using the logic (with indicators for "unmodified" or "modified", i.e. unlocked)
As a project matures the logic is contextually dispersed and assigned to actors as you go.
If you are working ad-hoc as is the nature of GS, your not really documenting as you go.
This would create a "map" if you will of your game.
Other contexts could be over-layed onto this list concept.
Scenes, Levels, Goals, Features
Even "project management" data. (this actor is complete) (this actor is incomplete) with respect to the intended design.
I know I'm all over the board here, don't take it wrong, I'm more than a little inspired as you can see.
I'll just keep sending until you guys shut me off. Use what works, disregard the rest/ No harm no foul.
Best regards,
James Beine
oA Games
Hi again James, interesting thinking. :-) Really, no worries at all of you being shut off! (Providing you're not rude, aggressive, etc., etc) Fire away with as many ideas/questions/answers/thoughts as you like! (providing they are relevant to any particular Forum of course... ;-) If by a custom saved object you mean a Prototype actor, there is a warning already if that actor is being used: "Confirm Delete", etc. But you're right about deleting Custom Behaviours; it'd be useful to have a warning there or an Undo at least; good one.
OK, your auto-generated/populated list you suggest I can understand where you're coming from, but still I can't see the point. In a "real-world" situation where you're creating an app, you/we know where all the Rules and behaviours are pertinent to each actor in the main; the same with attributes already listed in GSC in several places as well as well-named custom behaviours;by using the Group and Notes behaviours, as well as clearly titling your behaviours or sub-groups as you want....
Basically, what I'm saying is, I can see you're coming from a programmer's perspective and you'd like to pull out all the equivalent of code (already made for us in Rules and behaviours) for ease of access... but I'll say again, there really is no need! It's all there, each chunk of Rules/behaviours neatly in each actor, accessed by their Editor windows; or chunks in Custom Behaviours....
Things like Scenes, Levels, Goal and Features can be all done outside of GSC in the planning stage, in fact I'd go as far to say should be done outside, otherwise we'd all get into a right old tangle....
To try to reduce an unbloated and logical system (and I'd add an elegant system), which uses main features based on object-oriented programming, is retrograde; I know your not suggesting that, but by adding lists of actors, lists of Rules and behaviours used, and by which actors, etc; would do the same thing - it would confuse the whole system. Less is more and all that...
A few more of your ideas:
"As a project matures the logic is contextually dispersed and assigned to actors as you go."
This really can't be automated; and if you didn't mean that, again I'll say, isn't necessary: you can "assign logic" to other actors by clearly marking your Custom Behaviours and dragging the Rules/behaviours into another actor; or simply drag out another prototype; then unlock it to make it an instance if you need to amend/change the Rules/Behviours.
By the sound of some of your other ideas, "Other contexts could be over-layed onto this list concept" for instance, you'd be in your element using a Mind-Mapping piece of software – http://en.wikipedia.org/wiki/Mind_mapping which could satisfy most of what you want, I'm thinking; used before and while you're using GSC.
I admire you for your programmer's logic, if I can put it that way, but I think that the more you get into a working pattern with the way GSC is structured, you'll see it's "all there" for you; all easily found, and there's not the need to "tangle" it unnecessarily.....
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Hi @Orbz I'm not understanding; I'd be grateful for an explanation...
As much as I know, arguments in the coding sense (and pertaining to behaviours and expressions in GSC) are surely the attributes, which can already be used, of course, after the custom behaviour has been dragged out into another actor and changes made with additional or existing arguments in its edit section.... again perhaps I'm missing the point here...
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
They need a container that can mask the inner workings of the custom behavior so that we can create our own behaviors that are black-boxes that accept arguments and thus the ability to set parameters on them.
For example: Look at the way the "Accelerate" behavior works, it has arguments. It's not a block of code that you have to then tweak.
Custom behaviors - as they are now - is just a fancy clipboard.
We need the ability to create a block of reusable code, and the only way to make it truly reusable is to have the code block accept arguments so that it can not be tied to actor specific or global variables. Think of the way a function call works in any other programming language.
A custom behavior would have a name, argument list, and execution logic and the contents of the execution logic would be hidden in your code. That way you can edit the custom behavior "template" and it updates everywhere it's been used. As it is now if you have a "custom behavior" and you want to change the logic of it, you have to go find every occurance of it, update all the code, it's a friggin mess. Also, updating variables is a nightmare. It's not re-usable. Any programming 101 instructor will tell you that code-duplication leads to bugs.
Hmm, still not getting it; "container" could be a custom set of behaviours; our own behaviours (like wiggle for instance) can already be made with the existing behaviours, expressions, attributes and rules and contained in a group behaviour; and they can accept arguments (after the event, as it were) when dragged out and amended in the edit section.....
As for custom behaviours just being a fancy clipboard, I'd prefer that any day than copy and paste!!
I doubt we'll ever have the useage of blocks of actual code: that's programming territory, which is, as you know, going against one of the a main selling points of GSC, i.e no programming....but it'll be interesting to see any developments there in the future...
In the meantime, the equivalent of function calls will still have to be made with concatenated expressions and attributes, I guess...
I'm sure there'd be no bad feeling just because I disagree with you, @Orbz so I'd like to say I hope any true coding of any sort doesn't ever make it into GSC... the complete opposite of what you want....
But hey, let me me buy this round.... ;-)
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Please explain to me how you use the current implementation of custom behaviors to do the following:
Implement a custom "wiggle" behavior
Insert that behavior into 10 different Actor Prototypes
Update the wiggle behavior to be different in some fashion, give it an extra rule that says only-wiggle if the screen is not pressed, for example.
Now, how the heck do you get those 10 different Actor Prototypes to reflect the change without going into each one and making the change in 10 different locations?? You better pray you didn't miss one or make a mistake.
Re-usable code is just that, you change it in one place and it updates everywhere. Think of it like code-prototypes.
The only way to do that is to have parameters to the behavior.
Also, dropping a custom behavior and then tweaking all the variables is a chore that would be gone with parameters... aka, arguments.
As a programmer for over 20 years I can say without a doubt that GS is 100% programming it's just masked in pretty GUI and a very nice 2D runtime engine. I still have to think like a programmer. If you want to see an example of true non-programming look at Kismet for the Unreal Engine. That is a true VPL http://www.unrealengine.com/features/kismet/
You've changed your post after I wrote my last comment:
A custom behaviour already can have a name, it is, in itself an argument list or the list of arguments can be seen as the list of attributes used, the execution logic is already there, built into the behaviours, thanks to those excellent programmers at GS HQ, etc.
Anyhow, I agreee it's a right pain to update every occurrence of a set of behaviours you've saved as a custom behaviour, but I guess that's all the more reason to put all rules and behaviours in a Group behaviour before dragging it to Custom.... at least that way it's just one click to delete it, one drag to drag out the updated version....
I've not encountered much friggin mess personally , but I've been exasperated, for sure.
Why is updating variables a nightmare; and "not re-usable"? Variables are the attributes; I know you know that. There's no problem about updating attributes...
I really don't know why you seem to be "muddying clear water"...
Anyhow, I'll just say we'll beg to differ and leave it at that.
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Its the same diff between an actor prototype and unlocked actors. think "behavior prototypes" and you get the idea. write once, use many places. even in diff projects.
I don't know what sort of parameters you'd add that would automatically update custom behaviours throughout a game file; but anyway, surely an update button could be added next to each custom behaviour name? But even then sometimes a custom behaviour dragged out into another actor might have been amended differently from others; you might want to update only four out of five copies, etc... all in all, I'd far prefer to do it all by hand.
I could say, because I started learning BASIC on the Commodore 64 as well as an Atari ST back in the 80's, (Lingo in the 90's within Macromind Director, etc) that I've been programming on and off (to be fair tho', much more "off" than "on") in four or five variations of BASIC for just over 40 years, but even if I hadn't, it would be easy to agree with you that GSC is programming; of course it is, with those neat code packages called Behaviours and Rules; and I agree you do have to think like a programmer because GSC is structured around a high-end programming language form, object oriented. I've never said GSC doesn't involve programming. I've said it doesn't involve coding, despite the insistence of some other members that it does; (the closest to coding in GSC is using the expressions, as you know, but that's about it).
And I think to get too close to tinkering with the coding if it was possible would spoil GSC; you and a lot of other people have done some marvellous things with it without resorting to code; and the incredible amount of things that can be done with GSC already without resorting to that too....
And if you did want to get under the hood more, then I guess there's always the competitor to try out.... ........
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Fair enough, but the start of this thread was about "Future Ideas" so along those lines sticking with the current system doesn't make sense when there are obviously far superior methods.
You even said you "don't mind" clicking on all your behaviors to update them when you make a modification. But good design says you shouldn't have to. All I am saying is this:
You'll note that I specifically used the elipsis selector instead of the 'e' expression selector. This is because you are passing a reference to your game's attribute that may be modified inside the code block. In this way you can pass in a variable from your project and the custom behavior can modify the variable directly instead of only modifying a copy of the value of the attribute. In essence the params of the custom behavior become pointers to the attributes that they are set to when the behavior is used. This makes the code blocks re-usable across projects. Really fancy code blocks could be sold on the marketplace. Of course, there may be a need for 'e' or '...', perhaps a toggle switch in the behavior definition next to the argument? I'll leave that up to the GS devs to decide.
PS, I too had a C64, but I wouldn't say I actually started coding as a day job until about 20 years ago.
The two additional windows you've added to your example, top left and bottom, are the same information, albeit used in different places, so surely one is redundant; then leaving the top left, we have attributes already listed in an actor's attributes if made via a Prototype; or in the game and scene attribute lists..... and ok, for those, we have to change window, back I find that absolutely no hassle whatsoever to do (go to another window to change an attribute's name or value); and I'd even go so far as to say I wouldn't want it any other way, because for me, it is truly part of that indefinable "zen" of using GSC ehich I find so enjoyable.
The top right, being the group of rules and behaviours saved as a custom, can be edited by dragging it out into a new nlank actor really easily, and using that actor's edit window...
All in all, anything which can be done in your example can already be done without too much extra hassle and so to add this particular example would just add bloat to GSC, in my 'umble opinion.
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
I really don't think you understand what I made there.
I'm not arguing that what I made can't already be done. What i've made is EASIER and FASTER than what is currently possible. Aren't you a fan of less work and less bugs?
Suppose you find a bug in your current custom behavior? You then have to go fix it everywhere it's used! That's a royal pain in the butt and leads to all kinds of problems.
Suppose you find a faster way to implement something? You just change the definition of a single behavior and POOF every actor that depends on it is instantly sped up! This is programming 101, this is good design 101. This makes everyone's life easier. I really don't understand what you have to disagree with? Everything you are saying is just that you don't like change and that you like things the way they are. But I'm offering you an easier way to do exactly the same thing you are doing now. Less work, less bugs, more productive, faster! Why not?
What I made is basically what @objectantics was saying originally... more or less, not exactly the same, but along the same lines of DRY except without a full blown inheritance model as that can be a bit overwhelming for non-programmers. Everyone is already familiar with behaviors though, it's not a big leap to let them have Behavior Prototypes that can be reused in the exact same way that Actor Prototypes can be reused.
OK, of course I would want any change to a system that makes work easier and/or faster but not at the detriment of the workflow (by adding addtional features which are a duplicate of what's already there). I mean that, personally, this particular example which might save a couple of minutes, (by changing something in a custom behaviour then deleting and replacing throughout a game file) is adding bloat in as much as it can all be done relatively quickly already, when needed... having another window dedicated to groups of rules and behaviours, then duplicating all attributes used in that group as yet another list just seems too much for such a relatively straightforward task, which isn't even a task which is needed to be done that often anyway.... once you've got a group of rules and behaviours working as you want, what else might be changed other than the attribute values or names? And these are already changed/amended automatically throughout already....
I'm getting fed up with myself explaining this and feeling a bit of a stick-in-the-mud.......
But really, I would welcome improvements on workflow speed and way of use if they were really needed - of course I would - but which didn't "rock the boat" too drastically with the way GSC works (and looks) now; and didn't add unnecessary ways of doing things that may be a faster time of doing things but at the detriment of the "clean-ness" of GSC; i.e too many different ways of doing the same thing.
I know I might be in the minority here (or even all alone... boo hoo....
Hey, @Orbz you still haven't told me what you're drinking... when you do, I'll order... L-)
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Ok, well. I guess without using it you wouldn't understand the benefits. Have you done any programming? If so what I am describing is the same thing as creating a subroutine or function. It's a re-usable bit of code.
I have run into many many situations in my projects where I waste hours of time changing some logic around in multiple locations because there is no way for me to cleanly separate logic out of the actor and make it available to other actors.
Are you on skype? I'll show you an example in my current project of how this would be incredibly useful.
I drink absinth.
Also, I too am a fan of the Mac, what I am talking about is very Mac friendly. Actually, it's neutral. It's a concept that GS started with the Actor Prototypes and should extend to the Behavior Prototypes.
Oops, wrong thread.
My GameSalad Academy Courses! ◦ Check out my quality templates! ◦ Add me on Skype: braydon_sfx
lol, what's your contact info?
My GameSalad Academy Courses! ◦ Check out my quality templates! ◦ Add me on Skype: braydon_sfx
oh, duh... sent you an invite
My GameSalad Academy Courses! ◦ Check out my quality templates! ◦ Add me on Skype: braydon_sfx
I'll nip in here while @Braydon_SFX is waiting for Skype...
@Orbz I'm not on Skype and every time I'm asked I'll say " I really must do that..." but never get around to it.... I really should.... Your last para; I don't know what you mean by a Behaviour Prototype; I guess you mean a Custom Behaviour...
We'll be going round in circles again if I explained what I've already explained with regards to amending a custom behaviour, and replacing it in the custom list... all I need is it in a group behaviour when it's first made, so I can delete the lot with one click in an actor, and drag out the amended one in its place; possibly five or six times over but takes about a minute which I'm not worried about.... etc....etc
And yes, I have done some programming as I mentioned in one of my comments (which you might have missed because you were writing a reply at the time); in more detail then: in the '80's I taught myself BASIC on the Commodore 64 and wrote some primitive games on it; learned the variation of BASIC on an Atari STFM, did a few programs that involved simple music applications; in the 90's used Macromind Director (as it was called then) utilising their programming environment called Lingo, made some presentations, applications and games; then in the '00's used Runtime Revolution's RunRev extensively (now called LiveCode) making and starting quite a few applications... though none got as far as being commercially available....
I dabbled in Fortran for a while many moons ago, and have tried to learn C, C+, C++ as well as – eventually – Objective-C, all of which did my head in and I realised I haven't enough brain cells to understand them. (Although to put this into a little bit of perspective, when I was at school, computers were, of course, unknown to us, and it was at least another 12 years after leaving school that I saw my first computer (ZX Spectrum? Can't remember what came first.....)
For all these, (apart from when trying to learn Objective-C): no programmer 101 or whatever it is you said; no internet, just teaching myself by trial and error; the occasional application help file and from a few dusty books I could find/afford at the time.
So I do understand about things like sub-routines and functions.
And that's already catered for in its own way in GSC, "translated" like this....
A group of rules and behaviours can be the equivalent of a sub-routine, the group behaviour surrounding them given a title .... collapse it down and there's the function name...
If you need that "function" drag it out of the custom behaviour library... if you want to call it, trigger it with an attribute... providing you've dragged it into the rules of course...
OK, time out, I've bought you your absinth... here ya go.... ~O) yes, I know they've put it in a teacup – and for some reason is steaming – sorry about that...
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
I am the programmer dipped in chocolate, I can use both sides of my brain.
I am both creative, and a designer, and a coder. I do all well but I am not "the one".
The "ORACLE" told me so. Love this.
The programmer in me fighting for supremacy loves "tools", but not at the expense of elegance, design, or performance.
Cheers,
James Beine
oA Games
GSC is not a programming language. Parameters and Return Values would essentially make the behaviors system a "Language", and language means "Syntax", and that kind of defeats the purpose.
Correct me if I am missing something here.
Perhaps a "public" attribute.
someActor.someAttribute should be "gettable" and "settable";
This would solve the above, and make the behaviors system more programmer friendly.
IMHO,
James Beine
oA Games
I have been writing code.
Now I code less. I design more.
Loving it.
Abstraction is nothing more that programming at a higher level.
Is GSC the highest level of "programming" available? I suggest it is.
James Beine
oA Games