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.

> C3 is not FREE. That is the only "problem".

>

> No amount of clever marketing, learning material or whatever you can think about can get around that.

Honestly, I don't get why the trial version of C3 is as limited as it is. There's a ton of great features that you can't even access from the trial version and the tiny limit on events doesn't make sense from my POV.

Yeah, imo this is a poor decision. 50 events is stupid small. 2 layers is stupid small. No families is basically broken. Canʻt even try javacript... As you said, limits on everything.

Can anyone think of a single other subscription based engine that doesn't have a fully featured free version?

Nope. I happily bought c2. I would have happily bought c3. But I will not happily shell out money on a monthly basis for a tool, especially when I donʻt use it every month.

Its for kids because that is the priority scirra has taken with their product.

Scalability issues and failure to add features for fear beginners would find it complicated... these are major barriers in my mind to any serious look at construct.

Construct is great, so long as you are either making something simple or a prototype. But if you want to practice SOLID, you canʻt. If you code, you know, if you donʻt, you probably wonʻt.

But anybody coming from unity to c2 is probably lacking a skill. Or they have the skills and want a speedier work environment for 2d, but then... enter point #1. If you canʻt scale, slapping down a lot of progress on day one is useless if you are having growing pains already on day 5.

Every dev cycle I come back to construct, It has a nice IDE, and making games in it is fun... but each time I leave to finish in unity, frustrated with lack of event reusability, better abstract coding, efficient functions, etc...

The moment you find yourself creating a tool to edit project files so you can more efficiently delete or copy variables... well...

Also, and most importantly, if you are visual, but want to write good events, you need to use families... families all have the same icon in the event sheet, so now, that whole visual nature of events goes out the window..

To append to my previous statement, I have plenty of experience working within construct 2, less so c3. I used Tiled to create levels in c2 and Unity.

If you are still looking, what is your time frame and scope? I have 2 more websites to build in the near future but after that I have availability. The bulk of my experience is as an artist, but I've done my fair share of level decoration.

If you are okay working with an experienced programmer/artist, but a minimally experienced level decorator, let me know.

There's a C3 version in that link; I've been using it for a few months and it's been great!

Check out page 10 in the thread for the most recent version

SOWEET. Thanks, i missed it. Gonna give it a go!

try making your own pathfinding with events !! You'll gain lots of experience and improve your skills !

I mean... I can already tell you it will probably perform very poorly built on top of the event system (unless maps are really small or agents limited), will be a headache to scale, will be hard to move to other projects, etc...

Code is fast, flexible, and elegant. Construct events are... well... nice for easy tie things together, but not searching a graph tree.

Don't get me wrong, I like events, there is a good reason why I always try to circle back to construct every so often... but I learned along time ago that if the tools out of the box don't have what you need, you are much better off spending your time in an environment focused on the code (Unity, Unreal, Mono, Phaser, take your pick).

It would be a good challenge for someone not familiar with events/coding or pathfinding algorithms, or just someone wanting to say they did... But none of those apply to me and would take longer than just coding it. I'm looking for easy here, not because I lack skills but because I lack time. Which is why, like I said I always come back to construct. It has the allure of promised fast prototyping, a more simple workflow, better asset pipeline for 2d... I use construct when it can do the job more easily than other tools.

There is an addon for pathfinding on a tilemap called EasyStarJS. Not only it's much faster, it has tons of features and allows to mark specific tiles as obstacles, change their cost etc.

This is for c2 yeah? I remember using it. There isn't one for c3 is there? I already switched back over to unity for the project so its semi moot at this point though.

I needed oneway, modifiable pathcosts per unit, etc... Creating a whole behavior in c3 when I can do faster in unity just made it a no brainer.

Okay, I wasn't using this right either. I find bugs as soon as I moved the 3d camera. I've searched around for other answers and found one from newt that said to simply use mouse.x and mouse.y position. That also seems to not work. I'm using the ghost racer example and spawning a flash object where my mouse position is, just that it only works when the camera isn't moved and left at default.