Ruskul's Forum Posts

  • Overall I think most of the issues people have been complaining can be solved by Brackeys type community members teaching people about the software and writing tools to cover more and more blind spots.

    I agree with the above point - construct lacks people like brackeys and codemonkey, but I also think the few out there making tutorials dont have a large enough audience to justify making tutorials. Its a chicken egg thing. Well made videos are a TON of work and you need enough users to care... I keep thinking of giving it a go (mostly on SOLID principles and how they apply to construct), but...

    Alot of what makes good coding practices good are difficult to apply to construct. Which is my biggest trouble with it for larger games and why i only really prototype concepts. I must admit, I've been using custom plugins for variables since a month after starting to use construct and globals 2.0 is great. Managing scope in c3 compared to c# is night and day though. I can write code quite easily that I never have to look at again in unity. Making abstract complex framworks is cumbersome, especially when you can't prevent their misuse in the future if you forgot what variables and functions are for what.

  • dop2000

    Thanks for confirming. I ran a sample project testing different ways of picking sheep, just for fun.

    I tried the method I mentioned in OP, using overlap, then using a for each. I also created a variant using a script.

    Alternatively,

    Using an array attached to each field to maintain UID of sheep in the field, looping through each field, picking the ascociated array by uid, then looping through each element in the array, picking the sheep from the array value,and addings its worth to the field.

    This was the best solution and hadnles large numbers of fields and sheeps much better than the simple overlap.

  • It is interesting to repeat some mechanics using video as an example.

    A text assignment can always be understood in different ways.

    But so long as it follows the letter, its all good. Usually though, you define the inputs that need to be handled and then define acceptable solutions. So if I give you a problem with an input and define acceptable outputs, so long as the output meets the criteria, is all good.

    The toolkit should be complete, what you write without using behaviors turns the challenge into a programming competition. Competitive olympiad solutions are very rarely used in practice.

    I mean, challenges are about, the challenge... so yeah... I agree, some challenges should use the whole toolkit, but the challenge still needs to be quantifiable.

    Of the second point, Okay, I disagree - knowing how to recreate the wheel is important and applicable... what of when the provided tools fail. Pathfinding doesn't allow you to iterate through the mesh yourself. The platformer behavior solves collisions in a very particular way that doesn't work with "soft ejection" found in most retro games. To build a clone of mario3, using the the built in platformer behavior won't help you. It solves the collisions all wrong and you won't be able to truly recreate how Mario interacts with solids. Every built in behavior will fail if you have specific needs it doesn't cover.

    I read your example assignment and realized that I am not interested in this kind of work at all.

    What types of challenges would you find enjoyable if you were participating?

  • I'll have to dig into the way you suggested doing. So far my approach looks totally different and I am interested to compare performance. I think off the top of my head, there are some issues with the strings as it can more easily lead to soft bugs.

    Does creating a function with a return value not take care of this?

    It does but then you have to make your own system of overriding functions. Custom actions can be overridden by family members, which is real nice and starts to tap into the sweet sweet polymorphism.

    For example, in general you don't want to pollute the global space, but what advantage is it if all Construct objects were NOT in the global space?

    If I was programming in monogame/c#, I would explicitly dictate what scope var, classes, structs, etc... are in. Then, I have the advantage of controlling access to only the places where those objects are needed, useful, etc... It also makes it super easier to work with collaborators, as they don't need to about the 100 private instance variables you use to make collisions work. They only care about the publicly exposed methods... such as "OnCollision".

    I think the thing I like the most about using Construct (non-scripting) is the syntax check. It will prevent you on the spot from using a variable that isn't declared or missing a comma or period somewhere. It's not really even a pain point in my normal dev/day job, but its just nice that when you build your project to preview your game, you don't have everything breaking because of a typo.

    This is why when I have to start scripting in construct, I usually move over to a game engine that has a better environment for it. Strict and autocomplete is a must and a lifesaver for me. But I'm biased. I started with pascal and moved to c++. Python and javascript drive me bonkers. I get the appeal where it has advantages, but honestly... I really, really like c#.

  • Lets say we have Field and Sheep.

    Sheep have a instance variable "value", and fields have variable "value"

    If I want to calculate the total value of sheep in a particular field:

    1st: set Field.value = 0

    2nd: Field overlaps Sheep -> Field Add sheep.value to field.value

    ...But the above only adds the value of the first picked sheep, not all picked sheep. Is there a way to add the value of all picked sheep?

    I was trying to avoid for each loops, for academic reasons :D

  • Jase00

    ... if fields overlap but are spread across the map, then collisions get managed pretty well.

    In comparison to gamemaker/unity, how hard is this example to do, like what would be the quick rundown of what you'd do in those applications?

    In Unity... It would be very similar to construct at the abstract level. The difference is that functionality can be expressly written into a class while you would do it with events and picking in construct. The harder part with construct is creating a robust system that can easily allow for additions and subtractions of items at the design level. In unity You would add a collider component to the field and characters for hadling entering and exiting feilds. You would also create a class for effects, and a class for the affected. You then write a class for fields where they store a reference to an effect. Any effect would have base behaviors and derived effects would describe specific functionality. When a character enters a field (using inbuilt collision system), it would store a copy of the reference to the effect. When the effect updates, it would callback to the character to do a thing (like subtract health, etc...).

    A basic system like this is pretty fast to program (you COULD even do it in javascript for c3) but Iʻm trying to do this with events.

    The bigger dif is that unity uses component architecture and classes can inherit from classes to n depth... Construct only allows one level of depth to inheritance with its families. While you can add an object to as many families as you want (mimicking components) you donʻt have a good way to extend them to provide further functionality.

    Iʻll have a capx to share maybe in a bit. I donʻt think the collisions are an issue at all unless you are dealing with RTS level scope and every unit attack creates a field. Even then, construct does a pretty good job with collisions. The bigger issue is that construct

  • igortyhon

    If you are strong in programming, you can use JavaScript and all its power.

    You can... but that isnʻt the point here. "without coding" is kinda both constructs claim to fame and one of its pros. The moment you have to start authoring behaviors or plugins, you may as well be in unreal/unity/monogme/gamemaker - but that is a different video :D. c3

    Maybe you just don't know how to use this tool.

    Lol Maybe... do you?

    Typical. The one person on this thread with the fewest years experience is the only one to share this profound nugget of wisdom. Everything makes so much sense now, canʻt believe I never thought of that. Please, elaborate, so much insight.

    Do you have successful games or do you just like to compare and test?

    Even more irrelevant... Maybe. Do you?

  • Jase00

    Scenario 1 - dictionaries everywhere, put dictionaries into containers with objects, then you can definite as many bits of data as required. Or just use instance variables. Then lots of comparisons for whatever is needed.

    Yes, but instance variables are out. You canʻt dynaically add more at run time - so it is arrays and dictionaires all the way. You canʻt use containers because they donʻt work with families. So you need dictionaires, picking, functions, custom actions, etc... And all this is much more cumbersome than a simple script. Once you are scripting in c3, you are acknowledging the limitations of events and you could be coding in any environment where coding is better supported.

    For the the pure implementation comparison videos, I typically get the logic figured out ahead of time, practice the solution and then do several time runs. Right now, Iʻm investigating the best way to build this using construct events (no scripting atm). I use as many hotkeys are available to me, and memorize any script calls I need, and make and use a cheat sheet. Itʻs just measuring the flow of the tool and the ease of adding on.

  • —

    TLDR: you said use scripting. I agree, but then the benifits of the event system and constructʻs core strengths (speed and ease) start to diminish.

    With the examples in the original post, I think it would make more sense to provide your solution in other engines/languages and the problem you forsee implementing in Construct since your claim is that Construct causes difficulties.

    In a component based engine where classes are components, example of one class:

    //Add to any object that needs inventory

    //Overide to add specific functionality

    Class HasInventory {

    List<Items> inventory = new List<Items>();

    public void AddItem (Item item) {

    Items.Add(item);

    item.OnPickup(this)

    }

    public void DroppItem (Item item) {

    //check if item can be dropped and is in inventory

    ...

    item.Ondrop( this );

    Items.Remove(item);

    }

    }

    Class ExampleItemHealthSucker : Item {

    private HasHealth heldBy

    Public void OnPickup(HasInventory temp) {

    heldBy = temp.getcomponent<hasHealth>();

    Public Update() {

    //do a thing to the holder

    if (heldBy!=null)

    heldby.modifyHealth(-1);

    Public void OnDrop(HasInventory temp) { destroy(this.gameobject) }

    }

    Take the above code, slap an inventory component on any object that needs it, and add item to any object that can be collected. You need alot more to make this water tight and dummy proof, but that isnʻt the point.

    Any additional behavior and you can inherit from either class. Maybe a thief picking up a wallet always removes the money from it and adds it to his own pocket. Maybe the vampire medalian only remove health from its owner if a silver cross is also in the inventory. Maybe the bomb explodes and kills the owner and all inventory both up and down the chain. Maybe many things, but all things can be handled by a script attached to the object handling it.

    I do agree that sometimes I find myself wishing I could quickly use a .map() to achieve something - and yes, you can use JavaScript in Construct. As others have said, it is preference.

    I agree, this is something javascript should be used for. But... then the strength of construct, no longer applies. If I am authoring plugins/behaviors and scripting... VS/C# and unity wins almost everytime. Simply on grounds of performance, scale, ability to keep projects SOLID, etc...

    Construct has some major +++s but right now, the scripting environment isnʻt as good as other tools.

    But with events, I don't see why you couldn't achieve either of those with mostly instance variables and functions.

    Because the number of effects, items, types, etc... isnʻt known. if you know a character will only have two stats, you can hard code it. Easy, happy to do that in construct- If you know there is only water and fire effects, you can hard code it. But creating a system to handle nTypes, nEffects, etc... Not so easy. You need arrays or dictionaires for tabbing UIDs of objects, you have to iterate through those objects. Callbacks in the form of strings used to invoke functions are needed - and probably some scripting so you can avoid the silly function maps.

    I prob would recommend JavaScript.

    Me too, but then, what advantage does c3 then have over unity? or monogame for that matter?

    My point is that these are the same tools you would use to achieve your functionality in any programming language. It does seem a bit awkward at times, but that is because Construct was originally built as a no-code engine. So there are some trade-offs there - think target audience. However, I'm a programmer and still enjoy using Construct. I'm not actually sure why, but I do!

    Agreed. All points. I keep coming back to construct over and over again.

    > but with constructs current limitations . . . to avoid c3 limitations in functions and custom actions.

    What are the limitations? Can you elaborate?

    Encapsulation, private properties, custom actions canʻt return a value, functions are always in the global space, all objects are in the global space, you canʻt attach functionality to objects through events (you can make behaviors though).... Like you said, construct is swift in the right circumstances... but at scale, it can be unweildy if you donʻt build your own pluggins and behaviors

    Also, I'm not sure who said it, but I don't think it is fair to say a lot of loops or for eachs would kill performance. Of course a certain amount of loops will kill performance - anywhere, any engine, platform - but I've seen people act like adding a couple of "for loops" into their project is the end of the world. I'm just saying, test it to see if it actually does, especially if you are making a video comparing engines, ha.

    Foreach and function call events have performance overheads that are significant depending on the gameʻs scope. The more you do in a funciton, the less the overhead matters, but if you have routing functions only to do a single action, you are adding alot of overhead to that single action. Obviously, this will matter only in some types of games.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • For the record, we want to do both: an easy-to-use tool for beginners, and also a capable tool to build and publish a full game. So we need both features that help absolute beginners get started (like guided tours), and help advanced users go further (like JavaScript coding).

    Ashley

    The javascript is essentially what allows nearly unlimited potential with c3 and is a great addition. But, there is a big * there. The problem is that leveraging constructs advanced capabilities invalidates its major appeal (fast and easy), in some cases. It can do it all, but it easnʻt as easy at that point as other tools.

    The sdk, though well documented, lacks of recipes and examples, c3 behaviors arenʻt available to reference, and the included template does basically nothing and needs comments, etc., and authoring behaviors and plugins is cumbersome and verbose (even after coming to grips with them), even to make a simple behavior that simply holds variables, you still need a bunch of different files. So at its most basic level, creating a plugin or behavior has a huge overhead. In construct 2, I could even dig in and take a look at parts of the engine.

    I have authored my own custom platformers and other controllers as behaviors, (and even did my own box2d import) in c2 but each time I did, I could recreate the same thing in unity or gamemaker in much less time -

    I learned construct 2 and the its sdk before ever even touching unity, but learning unityʻs code and workflow was much easier than learning to make behaviors and plugins for construct. I kept bouncing back to construct though and still do. Construct gets alot of things right. In a blank project, I can create an custom astroids like movement controller in like 5 minutes. If I use javascrpt lines in the editor, I can do it slightly faster. I can do it in 8 minutes in gamemaker, and I can do it in 7 minutes in unity. Construct is also faster to load projects, start new ones, and launch the game. Game maker and unity drag their feet on compiling assemblies each time you hit play. So construct really shines, then you hit that "need to code some plugins" and its hard to justify.

    So I love testing ideas and building prototypes in construct. But... then scale happens. To build SOLID oriented games, that can flex as the design changes and grows, you need to be authoring plugins and behaviors - With lack of object oriented events, events can become brittle and forcing them to be OOP or component focused is cumbersome and introduces huge performance losses if using events. Even taking an object and making a family out of it is tedious.

    If construct could get to the point where it had a tool to help author behaviors and plugins...So at least you could just write 1 file, and all you had to do was fill in the actual script functions (like tick), life would be much better. Sure you need to define ACEs, but doing them accross multiple files is a pita.

  • Hey everyone,

    I thought, it could be fun to host a type of Olympics for construct 3. Like gamejams, but focused on very specific topics. In order to score, you simply have create a solution that solves the "problem". The solutions are then graded on performance, time to complete, and other merits.

    Example: (without using any behaviors) - Create an object, "A", that has the drag/drop behavior made through events. Create another object "B". Object B should accelerate towards object A on update, and then decelerate in order to arrive at A without overshooting it. Object B should use the following variables for acceleration, max speed, and deceleration - the contents of which must be loaded from a project file "ObjectBDictionary.json" (see format below)

    Anyone have any interest in participating?

  • Simple example and implementation:

    A field object.

    A family of characters.

    A family of functionality card.

    When a character enters the field, the field stores a reference to the character and hands a function card to the character. When the character leaves the field, the field removes the function card from the character. Fields can overlap and characters can hold multiple functions. The function card dictates what happens to the holder of the card.

    Simply tracking "On collision exit" becomes a bit of a pain, much less adding refferences to arrays and dictionaries that should be in a container, but can't because families. So instead is back to picking by uid and alot of for each conditions which kill performance at scale.

  • I'm currently working on a video series comparing gamemaker/construct 3/unity across a variety of challenges - from speed of workflow, to engine specific challenges. Currently I'm working on SOLID comparisons. I've worked ALOT with construct in the past, but I've never found a good way to deal with the following types of scenarios. It is the primary reason I hate working with construct and is the one thing holding it back in my mind.

    Here are 2 simple scenario that are very easy to program in a conventional language but are a nightmare in construct events. Performance can also take a huge hit depending on how you implement it. I'm curious to know how others have structured projects to deal with these problems but also retain maintainability and allow for easy additions.

    OKAY, here we go:

    Garages hold buses. A bus can pick up people, people have pockets, those pockets can hold anything but for now we care about wallets and keys. The keys unlock gates, the wallets hold money, coupons, access cards, and credit cards. We need to be able to add and remove people to the bus, items to people's pockets, items to people's wallets, etc. When a bus arrives at a gate it needs to know if any of the people onboard have a key to the gate. At any moment, we need to know the total money on board the bus. The bus has to pay tolls, but each type of bus determines how to take money from people on the bus. People can trade items(including money) while on the bus. Some bills are fake.

    The complexity arises when we begin to add more functionality to items. Perhaps people now carry gems, and the bus is gem powered and each type of gem on board affects the performance of the bus. Blue gyms allow the bus to travel on water, green gyms save gas, etc... Perhaps garages behavior is modified by buses and their contents as well. Perhaps people now have stats and they are happier based on how much money they carry (fake or not- unless they are bankers and then no amount of money satisfies them)

    What if after all that I want some people to carry bombs, and some people to carry guns, and some people to have driving skills...

    There is clean, SOLID ways to code this. But using events... eek.

    Scenario two:

    Characters have stats. They can carry gear. Gear can affect stats while being carried. Gear can be assigned to active slots and add functionality to the character. Not all characters have all stats and only have the stats they need. Gear can add additional stat categories. Attacks can modify, buff, or otherwise change stats. Field of effects can alter stats while in the effect but are removed once leaving the field.

    Stats can be modified by addition, % change, etc... but those also should be ordered (for example a shield could double base defense, not modified defense, while a defense charm could double total defense including all gear etc...). In addition, some effects may only take place if certain gear is present. For example, fluff armor may add the stat "flammability" to a character. A fireball spell may add the effect "burn" to the character. During update, the burn effect compounds based on flammability. Other effects may not change stats, but simply cause the player to smoke, flash, jitter, etc...Some effects may remove other effectors (water removes all effectors caused by fire damage...)

    Effects are unlimited and a character could have 100s of active buffs, mods, etc.

    This type of dynamic buff system combined with inventory is a complex problem, but with constructs current limitations, you will quickly drown in complex workarounds to avoid c3 limitations in functions and custom actions.

    Any useful paradigms for this within the constraints of c3?

  • Also people calling Construct "for kids" is silly, that's like saying pencils are for kids and "real artists" use wacom tablets. I don't mind a small community as long as this is enough for Construct to be developed further, but I can see that a big community has its benefits.

    It isn't silly when the primary target of c3 is kids. The engine is explicitly made for beginners and Ashley has explicitly argued against rising complexity in the form of features that would aid power users and enhance scalability, on the grounds that beginners would be turned off.

    He isn't wrong, he knows his market, but construct is for kids. Its also for hobbyists and a few professionals too, but even though construct is touring complete, that doesn't mean its the right tool for the job. You CAN build a skyscraper without power tools, but that doesn't mean its going to be easy.

  • I can't believe what Unity is doing. Charging $0.20 per install, and its applied to past games too.

    It isn't charging for past installs. It only charges for installs after the new pricing begins in 2024. It will only charge if you the game has been BOTH installed 200,000 times AND you have made x amount of money.

    As stated a number of times, 90% of unity users won't pay a cent. There are issues with this model especially in the mobile market, but unity is also responding to feedback, so there is that. Construct 3, on the other hand, charges whether or not you are successful and refused to listen to the community on the pricing model.