Dealing with item tied functionality is a nightmare in c3.

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?

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 kind of agree that the scenarios described are kind of a nightmare to do with events... which is why I use javascript for that stuff. I'm not sure how that could even be reasonably implemented via eventsheets without being cumbersome.

And I don't think it needs to be implemented via eventsheet. If you're a beginner, you're probably not gonna go ahead and attempt to create complex systems like that. If you are not a beginner, time to step it up and jump into javascript.

When picking becomes a problem I try to do things in a way that does less picking that looks cleaner if possible. One idea is to make getter/setter functions with uids. Another is to use one data structure object such as json to store all the data.

JavaScript works too but it has its own set of annoyances so pick your poison I guess.

I’m always trying to find ways to do stuff in simpler, cleaner ways, and some kind of system on top of events to abstract away complexities often come up.

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.

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.

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

Picking in events is essentially filtering, which can be done on instance variables. Functions can have return values - if you want to break out complex logic into re-usable bits. tokenAt and tokenCount can be used if you want an instance variable as an array. If you need an array of objects, you can use tokenAt and uids. If you want an array of custom objects, as opposed to instances, I prob would recommend JavaScript.

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!

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

What are the limitations? Can you elaborate?

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.

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

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

Thanks for writing out the logic of how you would achieve that elsewhere. My brain is a bit foggy today and I'm not in a good spot to write out all of the logic, but let me tell you how I would get started.

This is a non-scripting approach, as I agree, the scripting side of Construct removes a lot of the advantages of Construct.

Create a Family. I'll call it inventoryFamily for now.

Think of the Family as the equivalent of a class. Of course a lot of differences though. Adding sprites to this family will add all the behaviors, effects, and instance variables to the sprite.

To start, will add a string instance variable to the inventoryFamily. I'd just call it inventory.

Create a function for addToInventory. One param will be uid, which first condition will be to select inventoryFamily by UID.

Now you are sure you have the instance you want. Another param can be the inventory item to add, whether it is a word or a reference number. Adding would set inventory = inventory & "," & param (if inventory has value). You can also use scripting in an event, if you want to make use of like .split(',') .push and .join(',').

If another action needs to be taken I'd make another function for that. Sometimes I'll make a function for each different action and other times I'll make one function and pass a param for the different actions. Of course the latter turns into a long event of elses, but if it is only a few actions for each sometimes I'd prefer that to keep them organized and not pollute the function namespace.

This also isn't my favorite, but I'd probably do call function by name. That way, the name of the follow-up action (removeMoney, modifyHealth) could be stored wherever you need it (with the item type; if action from the carrier, would create an instanceVariable on the inventoryFamily of pickupItemAction; or pass the param into the function).

It would be great to be able to attach a function to an object such as a method, but the functions that first grab the instance by UID achieve the same thing.

custom actions canʻt return a value

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

As for some of the other limitations you mentioned - let me remind you my brain is foggy and also mention you prob know more than I do, so this isn't disputing what you say - but I'm not sure about some of the direct downsides or limitations. 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?

I kind of suggested using scripting because it sounded like you wanted to adhere to common programming practices. I almost always use events, unless I want to hit an API or its code I want to use elsewhere.

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.

I know that didn't address everything, but maybe it's all I got, ha!

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