Mich's Wish List

#21 @Conor -

Quote:since I am the coder/designer/artist on my games I don't need user-friendly behavior tabs in the editor. Anything that can be done with behaviors can already be done with script so they seem a little redundant in my situation.

In some ways, you are correct. There are several different ways to apply logic. Using your example, I could take it one step further and say "I don't need scripting. I can just use C++." Where I disagree with you is how you consider behaviors only useful for designers/artists to use in the editor. I believe they have a lot more use than that, especially when you add a signal system. It allows me to write more modular code that I can share between projects, as well as create a cleaner messaging system between game play objects.

Take this example. I have an object which I want to go up in levels when it gains experience. So I code ExperienceBehavior:

%template = new BehaviorTemplate(ExperienceBehavior);

%template.addField(experience, "Tracks current experience", int, 0);

%template.addOutput(onLevelUp, "On Level Up output signal");

function ExperienceBehavior::addExperience(%this, %exp)
{
   %this.experience = %exp;

   // If it is greater than 100, go to the next level
   if (%this.experience > 100)
      %this.Signal("onLevelUp");

   %this.experience = 0;
}

I can add that behavior to an object so it can go up in levels. Now, I can write whatever behaviors I want to respond to onLevelUp, without ever knowing if onLevelUp exists. Rather than hard-coding behaviors to check for "onLevelUp" or putting all my logic in addExperience, I could just connect them.

Pulse Behavior

%newTemplate = BehaviorTemplate(PulseBehavior);

%newTemplate.addField(pulseIntensity, "How quickly it pulses");
%newTemplate.addInput(startPulse);
%newTemplate.addInput(stopPulse);

function PulseBehavior::startPulse(%this)
{
   // Start pulse effect
}

function PulseBehavior::stopPulse(%this)
{
   /// Stop pulse effect
}

Sound Effect Behavior

%soundTemplate = new BehaviorTemplate(PlayEffectBehavior);

%soundTemplate.addField(audioProfile, "What sound to play");
%soundTemplate.addInput(playSound, "Input signal to play sound");

function PlayEffectBehavior::playSound(%this)
{
   // Play sound effect here
}

With improvements to the behavior system, like the signals I am referring to, I have a lot more flexibility with my code. I can write more modular and generic behaviors, then glue them together however I want. Sure, artists and designers are going to get a lot of benefit from this by having the ability to visually connect behaviors. Believe me, this is still also useful for someone writing the actual game logic.

#22 If you really want some rapid prototyping power, imagine a GUI that would allow the following before you ever touch code:

* Quickly build BehaviorTemplate shells
* Execute them without shutting down the editor
* Piece together new behaviors in the rollout using signals

The logic still has to be written, but all the signals and fields are ready to be used. You just have to fill in the blank spots. All of this still has a spot on my wish list. I am also the artist/designer/coder on my game project. I don't have access to the same resources as I do at the GG office. The ability to prototype and spiral through development is crucial for me.

#23 Like Conor, I don't use bahaviors. Actually, I've never used them. In part, because I come from T3D, and I have my own torquescript practices around scriptObjects.

But what you're describing here as use cases look quite interesting. Having no experience with behaviors though, makes me wonder where in you above description you're speaking of actual functionality, and where you are describing desired future features?

I definitively have to check out behaviors.

#24 Never used behaviors too, mostly cause their want to be benefit has always been buried due to some seriously annoying missbehaviors and troubles that made them barely unusable for 'combined effects'. The lack of proper OO in TorqueScript definitely did its best in a negative way too.

But if thats meant to change to become a true, proper, clean, performant and documented component pattern system for functionality I'm all in for the idea :)

#25 Fancy GUIs are nice to have because they attract new users. GG always need new customers. But they don't just look good - they're adding functionality. The mess that is the current editor GUI needed changing to fit the new features in. I don't mind them changing the look a little, since we DO have certain shapes that we're going to recognise the meaning of no matter what the colour is. Having seen bits of the new GUI (I think there are some teasers by Mich on the forum too), I don't think I can find anything to complain about other than wanting more of it.

Behaviours are very nice to use for all sorts of little things. Movement behaviour - slap it on the screen object you want, no need to rename or change the class or any of that. Let TWO objects share a movement/input behaviour if you want, and let the gamepad number be a configurable setting in the editor, which can then of course be configured from script if you want to.

I'm guessing most of you are one-man shows, and do your own level work/use other methods than the level editor. When you're working in a team it's very nice to allow the artist-level designer to stick the functionality he wants on various objects without having to know how to code it up, and ask the coder for a behaviour with more functions as needed. But that's just the basic use. They help my workflow. I've used them for level defaults and audio management to extend the editor.

#26 @Novack - What I was describing with signals is a future improvement. The idea of behaviors communicating with each other can be done with the current implementation, but you end up creating dependencies. What I'm suggesting with signals avoids creating dependencies, allowing you to plug & play behaviors.

#27

Quote:@Johnny - I have been stockpiling several conversations and e-mails between Melv and I. I think they would make really good blogs. Once I can get the 1.5.1 preview out the door, I can actually start posting then each Friday.

I have enough to probably last about a month or two. They are all very tech heavy (obviously), but is that something you would like to see each week?

Yes! I would love to hear about that... also would love to get an update on your game that you were working on.

#28 Yes to Fancy GUI.

Are You Quick Enough 2 heavily uses GUI for all menu stuff. It really saved me a lot of time.

#29 @Johnny - Great. I'll talk to David about picking a specific day each week, other than Friday. Maybe "2D Tuesdays", where I post blogs and resources for T2D/iT2D =)

Quote:also would love to get an update on your game that you were working on.

Oh, well I've been keeping very quiet about it for a while. I created a "first playable", which was really a proof of concept. Not very deep, but it demonstrates the base game play. It was surprisingly fun. Family life caused me to miss my deadline last year and has slowed the project to a crawl. Having a kid apparently does that =/

#30 @Michael - 2D Tuesdays, or any day for that matter, sounds great! I know a lot of effort goes into a blog so I hope it doesn't take up too much your time.

#31 @David - Blogging definitely takes effort and time. Like I said, I have archives of discussions. Since they will not be marketing blogs, I don't have to fancy them up or send it up the food chain. It's pure tech talk, so I can mostly just copy and paste. I'll just put a little "editor note" at the top of the blog to provide context and change the perspective.

#32 Mich - those behavior examples look useful alright. However the only case I can think of where different classes would use the same behaviors is for something simple like fade-out or scaling. For example, if I used the above 'gain experience' behavior for my player character, it would have to be more detailed to also trigger sounds, particles, adding score, changing inventory settings, stats etc... all of which would be different for something else gaining experience (such as an NPC or enemy or a player in a different game). I'd effectively have to write separate behaviors for every class, or have a giant switch$(%this.owner.class) in the behavior, which means I'm not simplifying anything at all.

In the case where objects really do have a common behavior, such as multiple enemies of different classes, all of which explode - I already have the superClass for those and can write a common enemySuperClass::explode function so I don't need a behavior there.

Even in the very simple case of fading out a sprite (bring the blendAlpha gradually to zero) I currently need different scripts for different classes - different things happen when an enemy fades out (because it has died) or the cross-fader covering the whole screen fades out (starting the level) or a score text pop-up fades out. The addition of a signal such as %this.signal("fadeComplete") would allow me to integrate all these into one behavior, but honestly it's not a huge saving. It's pretty quick to copy and paste a something::fade or something::scale function and customize it.

The best place for behaviors is in 3-Step-Studio where their visual interface will benefit beginners. In the world of complex, commercial game development you can't just take a 'player-movement' behavior and drop it on your player. The touch controls script in DroneSwarm Command is 700 lines long and it's deeply integrated into the specifics of the gameplay and the UI. Packing this into a behavior wouldn't help this project, and wouldn't be useful to me in future projects.

I feel a bit bad for arguing against a feature that you clearly consider useful, but I really don't see that behaviors provide any significant benefit - they are merely replicating existing functionality with a different interface. Whereas Box2D or working text would provide enormous instant benefits so I think the team's efforts would be better placed in those areas.

#33 My love of behaviors is that they make it much easier for me to offload level design/simple mechanic tweak features for games to the creative types.

#34 @Conor - No worries. Don't feel bad at all. I always value your input. It's obvious I tend to use them more than you might in your game, which is why they ended up on my wish list. I use behaviors and datablocks more than I use script classes. If I were to make my game moddable, which I plan on, behaviors are going to make it a lot easier to extend once the game is live.

#35 Behaviours are really close to how Unity 3D works at the core, but the additions Mich is talking about would make them one step awesomer than the competition. The 2D product has been called a game BUILDER for a long time, and a few hundred standard components to drop in and modify as/if needed would certainly make that promise come true.

It's better to make a post about features you want than making long posts about how much you hate a feature being implemented ;)

If you've already spent many hours writing classes, keep using them. Nobody's forcing you to change them over to behaviours. But for new users I recommend looking into them first. Old people can't change their ways anyway >:)

#36 I also find behaviors and datablocks very useful! Please keep improving them.

#37 Alright everyone. I've been given the green light to start "2D Tuesdays". The first will start this Tuesday (6/5).

#38 Yes! Finally a good reason to visit the frontpage.

#39 @Johnny - I agree. I see behaviors used a lot more, but I don't think enough developers use datablocks. I use them to handle all of my static data and have the behavior manage dynamic data.

#40 @Michael - You're right. I only used datablocks once in Twistum, but I think it's a feature with a lot of potentials. I think we should encourage great tech in it2d that makes our lives easier.

But if I had to pick between datablocks or behaviors - it would definitely be behaviors.