Plugin development is anarchy.

Lol, well, alrighty then. Guess Iʻll get my cowboy hat on and get to work/

R0J0hound Do you tend to mix all abilities in the same conditional tree, or do you keep seperate trees for non-intersecting behaviors? For simple things, I totally agree, abstraction can be an added difficulty that solves no issue, but... for slightly more complicated issues...

For example, if pressing down normally causes a character to duck while on ground, but a digger upgraded character digs into the ground, and perhaps another ability causes some jump activated power to charge.... would you simply prefer to have those all under the condition tree as such, or do I misunderstand? For example:

	if (onGround) {
		if (isFirstTickonGround) {
			if(isRecoveringFromSpecial) //Do special landing thing
			elseif (hasJumpAbility & 
				input.jumpLastpressedTime < forgivness)
				//Do regular jump

		}
		
		elseif (input.down) {
			if(hasChargeAbility) //do charge stuff;
			if(hasDigUpgrade) //do dig stuff;
			else //do normal duck;
		}
		elseif (input.jump) {
			if (hasChargeAbility & isChargeComplete) //Do Special
			elseif (hasJumpAbility) //Do Regular Jump;
		}
		
		
	}

	//Somewhere else in the tree
	if(isInWater)
		if(isRecoveringFromSpecial) //do specialstuff
		else etc... // do water stuff
	

	//in class for ability dig

	CanDig() { return this.state.OnGround & this.input.down }
	DoDig() {
		//Code for digging behavior
	}

	//in class for Charge Ability

	CanCharge() { return this.state.OnGround & this.input.down }
	DoCharge() { //code for handling the charging }

	CanDoSpecial {return this.state.OnGround & this.input.Onjump }
	DoSpecial() { //code for special charge ability }

	//in class for jump ability

	CanJump() {
		return
			this.state.ground & this.input.Onjump ||
			this.state.ground & this.input.lastJumpPressedtime< f||
			this.state.lastexitgroundTime < f & input.OnJump }
	doJump() { //Code for handling jump }

	
	//Somewhere else in characterHandler
	if (noActiveAbility) {
		//iterate through dynamic list of registered "CanChecks()"
		//Compare priorities and set Active ability to the ability
		if non, set to default
	}
	DoActivateAbility();
	

Aloha,

In the past, if I found myself repeating events, I would create a behavior to encapsulate that functionality. For example, common math functions such as vector.dot, etc...

I have picked up alot of particular habits associated with c# in monogame and unity, and for lack of knowing any better, I find myself implementing them here. In the past 8 years, I have primarily used construct as a prototyping tool, and didn't concern myself with the architecture concerns.

The question I have, is it better to break behaviors down into the smallest possible functional bits in accordance with SOLID, or is it better to group common behaviors into a singular behavior. If Scirra built behaviors are any example, then they choose to make behaviors have more than a Single responsibility (platformer behavior handles input/commands -> objectHandler -> stateManagement -> collision response), but this is possible they chose that route for beginner ease, not because its the best way to manage projects.

For example, for an input/command behavior, I could create a behavior that tracks commands (up,down,left,right,jump) and maintains a record of them several frames back. If I had an object that only needed left and right, using such a behavior would break SOLID principles (bloating an object with features it won't use). As would the platformer object for an object that never needs to jump.

At the moment, the only way I can figure how to avoid the above is to create a simple behavior for tracking a singular command, and then simply adding it to an object as many times as you have distinct commands. Adding a further command is as easy as adding the behavior again, rather than editing the behavior itself to add something most objects wouldn't need.

But then, lets say I have a platformer handler, I don't see a way to force the object to have the prerequisite behaviors installed, and would have no way of teing them neatly together in a way that wouldn't result in even more work. I could also implement the ability to dynamically add commands to a single behavior via a dictionary, but then I'm recreating functionality that already exists in other behaviors.

The issue here is that my mind in firmly in a unity paradigm and I am treating behaviors as I would object scripts in unity. I never repeat myself, but I'm finding it hard in construct. Am I thinking about things wrongly?

The goal is to have neat, reusable code, that I can efficiently maintain, scale, add to, but the net result should be less work, not more.

Eren Awesome! Good to know, I never considered checking there for errors.

Missing language string. Which... is lame. I don't need a personal plugin to have a translation lol. Thanks construct.

Heyo,

Dumb question here: I made a super simple behavior but when I install it as an add-on, it never shows up. I get no errors or anything. Installs but never shows up in the list and isn't available in the project.

I've never had this happen before, so forgive me if this is a noob question, but what could be happening.

If it makes a difference, I used c3IDE to generate the addon, so the issue may be there.

Thanks!

I don't touch project files, dats scary. Maybe it's fine, I don't know.

Meh, if make backup what could possibly go wrong? Its actually quite human readable. You can do all sorts of tricks in the project folder; Anything from adding extra data, to automating art asset overhaul.

if by standalone app you mean the old nw.js one, it's a really bad idea to use it at all since its last update predates extinction of dinosaurs and creation of universe itself. it uses an old chromium version and you should not run construct on anything else but latest.

No, sorry, I mean the construct editor that you can download and install and use apart from a browser.

Hey all,

I know this is a topic that I have brought up before, but I wanted some recent input on design. Consider the topic of creating a platformer project, like mario, but where mario's abilities and behaviors are dynamically altered based on various factors, such as equipment.

For those who program, (For me, c# in unity or monogame), I would typically create a character handler that would handle states and delegate which particular behavior should have control over the character (run, walk, jumping, moving in air, wall sliding, etc...). When a a new ability is added to the character, it would register its various functions on actions/callbacks that are triggered by the handler. Some people use state machines to handle the transitions, but I preffered a softer machine where multiple states run at the same time and can share control (for example, sometimes you want the "horizontal movement" ability to execute while "rocket jump" is executing.

Its nice, because then adding a "power jump that charges while ducking" allows the code for that ability to live in one place, instead of having to be distributed around a giant if/else tree in various locations. You just register into the appropriate action/callback. In this case, the handler would call any ability that has registered with the particular input/state conditions that result in duck being true, and the power jump would charge.

Ideally, these abilities all inherit from some base class that handles the boilerplate registration and callbacks. This is easier to manage with polymorphism and class imo, but I suspect there is an elegant way to handle this in c3.

Elegance = Easily scalable, maintainable, and changeable code that is the easiest to read and work with.

Building such a system out with c3 function maps doesn't seem the right way to go, as it clutters the global name space (Not ELEGANTO!) and has some performance issues. Custom actions is a better solution, but without dynamic routing, you have to wrap up abilities in objects. So even though you have a mario characterHandler object, his jump logic is actually being processed by a custom action on a "BehaviorJump" object that is in a family of CharacterAbilities. The CharacterHandler familily handles a list of UIDs to its abilities , and simply calls the type of action wanted.

This current solution has got a lot of UID picking, and is verbose. Alot of boilerplate. But it is as elegant as I can imagine atm.

You can easily build up a giant spaghetti mess of character abilities all being togled on and off by boolean trees, but that gets to be a nightmare once you start trying to add dynamic abilities that can be picked up with an item or activated in specific situations. I know some famous gamemakers have said, screw it, and then just made a mess (celeste's character controler is a grand example of this), but the fact is, a working mess is only a problem if you have to go in and change things.

AND the whole point of the project is to provide a reference for design patterns for those building projects along SOLID principles, so the matter is somewhat academic.

Well it's been a day you could've done it by now ? You make a Family with the same variables with an extra character to differentiate, then the events that use the old object, you change the variable to the new one because since that object is now in the Family it will adopt the new variable, then you right-click replace object with Family.

I mean... I did do it, but the json way as I mentioned. Its way better.

Open the objecttype json.txt file in the project folder. copy variables, open familytype json.txt file and paste. Takes like a simple 2 minutes, regardless of how many variables.

Could be useful, suggest as an improvement. If names are clear though it should be fine to use many Families.

I agree... names are super important. Probably the most important thing about any type of coding, but a custom made icon would really help make it "pop" - text really isn't that visual.