Feature Request for C3 - Enemy Behaviour Editor

I hate when i have to code again and again the enemy behaviours for different projects having similar issues and wasting the time fixing again or searching the project in wich i solved the problem, and after that i can't copy/paste because uses different instances, names or associated plugins with other things so i have to code again looking the old code.

So i made a mockup that something that will be great have in C3, i used the colors of the new website .

The idea is save the enemy behaviours(Or hero, etc...) we create as presets to be used in next games with a few clicks.

So, we select the enemy, add the "Enemy behaviour" with a button to open the editor and setup the objects of our game and load the desired behaviour and ready.

Obviously for more complex and extense behaviour use the events, the idea is setup/preset the most used features.

As adition the idea is have some mini-preview on we can drag&drop the Player and the enemy/enemies and create some basic level using tiles to have an idea how the behaviours will work, instead of run again and again the game to test it.

For Yes/No and Enabled/Disabled options i did a separate tab on you can see all them without large scrolls and with only one click instead of now that you have to click first in the arrow to appear the two options to choose and another click to select.

What you think Ashley , Tom ? Something like this can be done in C3 ?

I like this idea <3

I think this is a variant on the "modular events" idea, am I right? You want to package up a series of existing behaviors and events and use them as your own new behavior?

That's a good idea, but to me this UI just raises an endless list of questions: how does the editor know what to list under "General"? Why is the Properties Bar duplicated to a new place in the UI? How does the editor know what to list there? Why are only "platform" and "top-down" tabs available? Is it a cookie-cutter feature where no other kinds of games supported? How does it determine the color scheme key used in the preview? That preview would probably require some significant rearchitecting as well. Where do the instructions for controls come from? Where does it find what to list in those capabilities in the bottom-right? Why is only "On collision" listed underneath that and how does the editor know to show that and not a different trigger? How will the user configure all of these aspects and what will the UI for that look like? Will this general UI layout apply to general-purpose games for entirely different mechanisms or is it too specifically designed for just your specific use-case?

This is often a problem I have interpreting user feature requests - you can show something that looks cool and everyone piles in to say "great idea!", but when you are actually responsible for implementing it, there are a wide range of questions to which the answer seems to be "it just somehow happens by magic". I do think it's interesting and worthwhile to explore feature ideas and make mockups like this, but you have to appreciate the deep and far-reaching implications of actually implementing software, and try to cover that in your ideas, otherwise... it's just a nice screenshot.

Users cannot cover the full execution of an idea.

We dont know the full picture of the software.

I have been programming with construct for 2 years full time and i still strugle implementing basic design patterns.

By making c3 a subscription module, your target audiance is more pro game studios that needs more tools.

(Some of my issues: no namespace for functions, family with sprite and sprite font, no api, no .dll)

I think this is a variant on the "modular events" idea, am I right?

Since you mentioned, I'd like to ask: Are you planning on bringing the "modular events" idea to life in the future? I know it has been asked several times for C2, but can we expect this functionality for C3 later down the line?

Ashley I know what you mean, this is a mockup/concept that how aproach to the problem. As you said lots of questions and things i not had in mind and will be difficult if not possible to do with the actual or new construct engine.

I'm going to reply the questions i can with the idea:

General tab

I don't know if i understand what you mean. When you click to "choose" the idea is open the same tab that on editor to pick one of the objects in your project. But i guess maybe this is not possible and this have to appear in the events editor?.

Duplicate properties tab

No duplicate tab, i copied the same style for fast concept, but in the left tab of construct will appear only an editor button to open that dialog and an empty box to set which enemy behaviour use like "Enemy_Test1" used in the concept. No more things and the left tab keeps clean.

Why are only "platform" and "top-down" tabs available?

At first was only a general features to use in any type of game but i added at the end the top-down because depending of what type of game you are doing you will need one or other properties. So maybe will be better a list or other way to show the properties for all the style games we want to add. I set this ones because Construct2 comes with that plugins: Platform and 8-Movement(Platform and Top-Down).

About the color scheme in the preview

Not can be changed, the idea is use something that can works=be readable. At the end you only need to see well where is the player, the enemy, the collisions and how the enemy moves to see if do what you want.

Why is only "On collision" listed underneath that and how does the editor know to show that and not a different trigger?

The idea is add the most common features and for more complex behaviours use the event editor. I guess better some kind of list or way to choose the action.

Will this general UI layout apply to general-purpose games

Thats the idea, some movement behaviour editor on you can save the presets to use in any kind of future game, Platform, Top-Down, Space, RPG-Adventure,etc... and not code again the same behaviour with different hero, enemy or whatever, thats the main idea of do this.

Overall questions about how the editor know what to list

I don't know if i understand this. The idea of this "Movement behavior editor" is give you something to start, a basic setup. If you add or modify something in the event sheet that changes their behaviour only will be displayed in the Runtime not in the Movement Behaviour Editor properties or preview. Save the basic events to use the event sheet only for the game special features.

---

The first thing i'm gonna do on C3 is prepare my game template and design the possible tools for request or hire somebody for behaviours/plugins/effects to make all more One Click=Basic Setup, Starting with my "friends" the Arrays XD. I wasted two days trying to configure them to use as inventory list to add the picked object after the last item or when one is removed order again without empty blocks with for each, CurlX,etc... and finally leave it .

So this request may be more easy to achieve, Can be possible add a preferences/basic setup icon on the "Array Editor" with this two actions:

On new Element: Do nothing / Add First / Add Last

On Delete Element: Do nothing / Order

I mean, this is an example but can be better ways, but the point is some way that automatically on you set the event add/remove an element on the array do this things, that will save a lot of work, frustrations and again will keep the event sheet more clean. Or even a simply actions in the event sheet that can do this will work for me. Is possible?

Modular events, and an editor sdk.

I could see having a preview window that when you click on an instance the image, and collision polygon are displayed.

Press a play button to cycle its frame as well as poly's.

Modular events: import project(merge project), make plugin/behavior by events -- they might be similar (but not the same)

General tab

I don't know if i understand what you mean. When you click to "choose" the idea is open the same tab that on editor to pick one of the objects in your project. But i guess maybe this is not possible and this have to appear in the events editor?.

My main question was: it shows "select target object", "select collision object" etc - how does the editor know to put those there? Presumably the user has to select what to put there - how does that work? How does it integrate with events? What's the workflow?

[quote:3asddiy9]Duplicate properties tab

No duplicate tab, i copied the same style for fast concept

This makes it pretty confusing to interpret your concept: you made it look like a dialog, but significant features of it are not meant to be in that dialog? Communicating the idea clearly is difficult, but necessary to get the right idea across.

[quote:3asddiy9]Why are only "platform" and "top-down" tabs available?

At first was only a general features to use in any type of game but i added at the end the top-down because depending of what type of game you are doing you will need one or other properties. So maybe will be better a list or other way to show the properties for all the style games we want to add.

This sounds like steps towards either god-behaviors which try to do everything, rather than small independent behaviors targeted for specific uses, which I think is a better approach to focus on.

[quote:3asddiy9] Why is only "On collision" listed underneath that and how does the editor know to show that and not a different trigger?

The idea is add the most common features and for more complex behaviours use the event editor. I guess better some kind of list or way to choose the action.

So this duplicates part of the event sheet? I really don't think it's a good idea to duplicate existing parts of the editor, it makes more sense to me to keep everything in one place. And again, who chooses what appears there, and how?

[quote:3asddiy9]Overall questions about how the editor know what to list

I don't know if i understand this.

My point is: where does the information come from? For example your mockup appears to mix both the Platform and Bullet behaviors, and the cells in the bottom-right appear focused on the platform behavior. Why those properties? Do we hard-code those in to the engine, or are they user-configurable? How does the user configure them? How does the user define what "One touch = kill" does? There are just so many questions about how this would actually work in practice that I would say you've shown a concept for maybe 10% of the idea.

We've been doing Construct a long time and we also have a good sense of what confuses new users, what annoys experienced users, etc. I'm not trying to rip apart your idea because I don't like it, it's just this is exactly what we do internally when approaching a new feature. There are a great many angles on it, ranging from user experience, to the performance overhead in the engine. If you can go through a similar process when coming up with feature ideas, it's much easier to actually consider it, and that would help you convince us to do what you want.

[quote:3asddiy9]The first thing i'm gonna do on C3 is prepare my game template and design the possible tools for request or hire somebody for behaviours/plugins/effects to make all more One Click=Basic Setup

I suspect if you hire someone to do this, they will ask many of the same questions. "Wait, how exactly do you want this to work, in detail?"

I see what you mean, this mockup not pretends to serve as guide to build a plugin/behaviour exactly like that. Simply show some possible feature to save behaviours as presets to be used in any game without code again the same thing with different objects. Maybe a real one will have an oposite aproach, as i said i don't know if some things can be done like the preview gameplay and if other can even be possible.

For that the idea to find somebody with experience in javascript or hire to explain the ideas and give me what options i have to do that with the SDK plugins tools and which ways to develop it. Starting as i mentioned with small behaviours/plugins or edits like the Arrays thing(That you not mentioned, is not possible?), some small actions that can save infinite work, and grow to more complex stuff at the time i know what things can be done and how with the SDK.

Because after years using C2 i learned i can't do the big games/projects i want because always there is some point i waste days trying to add some feature and get frustrated/demotivated, that with one or two actions in the plugin/behaviours will be solved in minutes and is what i want to solve for C3 for a large project i have in mind.

> General tab

> I don't know if i understand what you mean. When you click to "choose" the idea is open the same tab that on editor to pick one of the objects in your project. But i guess maybe this is not possible and this have to appear in the events editor?.

>

My main question was: it shows "select target object", "select collision object" etc - how does the editor know to put those there? Presumably the user has to select what to put there - how does that work? How does it integrate with events? What's the workflow?

[quote:fyzpzlvt]Duplicate properties tab

No duplicate tab, i copied the same style for fast concept

This makes it pretty confusing to interpret your concept: you made it look like a dialog, but significant features of it are not meant to be in that dialog? Communicating the idea clearly is difficult, but necessary to get the right idea across.

[quote:fyzpzlvt]Why are only "platform" and "top-down" tabs available?

At first was only a general features to use in any type of game but i added at the end the top-down because depending of what type of game you are doing you will need one or other properties. So maybe will be better a list or other way to show the properties for all the style games we want to add.

This sounds like steps towards either god-behaviors which try to do everything, rather than small independent behaviors targeted for specific uses, which I think is a better approach to focus on.

[quote:fyzpzlvt] Why is only "On collision" listed underneath that and how does the editor know to show that and not a different trigger?

The idea is add the most common features and for more complex behaviours use the event editor. I guess better some kind of list or way to choose the action.

So this duplicates part of the event sheet? I really don't think it's a good idea to duplicate existing parts of the editor, it makes more sense to me to keep everything in one place. And again, who chooses what appears there, and how?

[quote:fyzpzlvt]Overall questions about how the editor know what to list

I don't know if i understand this.

My point is: where does the information come from? For example your mockup appears to mix both the Platform and Bullet behaviors, and the cells in the bottom-right appear focused on the platform behavior. Why those properties? Do we hard-code those in to the engine, or are they user-configurable? How does the user configure them? How does the user define what "One touch = kill" does? There are just so many questions about how this would actually work in practice that I would say you've shown a concept for maybe 10% of the idea.

We've been doing Construct a long time and we also have a good sense of what confuses new users, what annoys experienced users, etc. I'm not trying to rip apart your idea because I don't like it, it's just this is exactly what we do internally when approaching a new feature. There are a great many angles on it, ranging from user experience, to the performance overhead in the engine. If you can go through a similar process when coming up with feature ideas, it's much easier to actually consider it, and that would help you convince us to do what you want.

This could become a sticky or tutorial titled: you have a feature request? Read this first

The main issue Ashley seems to have with this is specifics, ie: it's specifically only useful for enemies and wouldn't have any other abstract uses. Well, what's a platform behaviour do, other than platform movements?

The main issue Ashley seems to have with this is specifics, ie: it's specifically only useful for enemies and wouldn't have any other abstract uses. Well, what's a platform behaviour do, other than platform movements?

Platform is for platform games.

Enemies can be in every genre and type of games. So it needs to be more abstract I think.

Wouldn't just being able to copy a Group from one project into another carrying all referenced/dependant, variables, functions, sprites and other plugins with their behaviours, layers referenced, with all appropriate settings etc from within that Group...solve the same issue and be wider in scope?

It wouldn’t guarantee that the pasted group would function properly straight away but you would be a lot closer a lot faster than picking through events line by line copying variables and other objects referenced, then finally copying the events.

I assume this is something similar to the modular system you guys are talking about. If I’m totally off subject please ignore me I’m a little groggy this morning….

> The main issue Ashley seems to have with this is specifics, ie: it's specifically only useful for enemies and wouldn't have any other abstract uses. Well, what's a platform behaviour do, other than platform movements?

>

Platform is for platform games.

Enemies can be in every genre and type of games. So it needs to be more abstract I think.

True, but the species of an enemy will always relate to an enemy, regardless of genre, and therefore should be universal to any game type really.