Ruskul's Recent Forum Activity

  • 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
    	
    

    Basically, the logic for the special gets mixed in various places under various input or state conditions. Do you find it difficult to maintain such code into the future; Removing, or adding abilities, etc, forgettign how many different places the special charge ability touches? I have found such trees are easy to make initially, and the process is quite organic. When making a game like mario, where mario is the most complicated character, but has a limited and static set of behaviors, and most enemies are simplified subsets of mario abilities, I think the ease of a conditional trees is probably the best approach. But I canʻt see how this wouldnt become a tangled nightmare for a game where abilities are dynamically added and removed in any combination, or where all characters are more complicated than mario but at the same time use his behavior as a base framework to overide.

    As opposed to something more like:

    	//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();
    	
    

    In the above, the code itself is more cleanly contained imo, but there isnʻt a good way to acomplish this on construct as far as I have found. Not easily, or performantly. Which I think we can all agree, trading 1 problem for 2 more is particularly elegant lol.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • @Overboy , I was curious. I have been using dictionary behaviors and came across and interesting use case where it would be very advantageous to have multiple dictionaries on an object. Is there any reason why the behavior can only be added once?

    So sorry, I somehow failed to see that it was possible before writing you. Great job on all your tools btw. They are very useful.

  • 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.

  • Aloha,

    I am getting a crashes while working in the c3 editor once every few hours. No error reports, just "awe snap, something went wrong : reload page?". I have also had a few hangups while in the sprite editor, where when I click to close, the loading the wheel pops up and just keeps on spinning and the project is frozen. Obviously all progress is lost since the last save.

    I know these details won't be helpful for diagnosing the problem, but I was wondering if others have other similar issues. I have only had a few crashes while working in the editor on the browser, and all of those were reproducible, provided error reports, etc... but as a standalone app, the crashes have been getting on my nerves. So far, I have been able to reproduce nothing. The projects aren't complicated either, just basic templates projects that have minimal stuff in them.

    I'm going to keep to the app to see if I can't spot the reason for the failures and just exercise using the save button more frequently.

  • 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.

Ruskul's avatar

Ruskul

Member since 23 Nov, 2013

Twitter
Ruskul has 2 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • x6
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

18/44
How to earn trophies