C3 Architect Request list

Being able to add curve paths during edit time (if possible dynamically be able to create paths at run time as well!) and making the sprites move along the curved paths is definitely on my wish list. Without such a functionality, its very complicated (with several trade-offs ) to build games like Zuma.

True

kmsravindra

I am also working on a second game that makes heavy use of Spline paths for pathfinding and movement. So I'm so totally into your request. I made a path node capx, but without the edit time tools for easy creation it's a pain to work with. I have a runt time editor that make it's easy, but integration into existing capx is not very fun.

Infact, I had to ask my client to look away from Construct 2 to build a game like Zuma for performance reasons

-Building games as exes.

kmsravindra

I have not have had a performance issue with C2 on mobile as of yet. However I have seen many projects developed poorly; including in ways that would hit Unity. However to be fair the intuitive way C2 promotes development is poor performance. That's why a number of suggestions in the C3 architecture offer a different development model that would allow for easier to development good performance apps.

Azu

Sorry. The doc isn't a feature request list. it's a low level architecture request. Suggestions and design models that would allow for improvement in game development; not so much exporting. that's why the request is for custom primitive objects and not for the curve object itself.

[quote:377f8yqv]Modularity

The ability to create re-usable objects and associated ES code between projects. These can be helpful to one self and the community. They are easy to use and shareable. overall increasing the development of all projects without going through redundancy or trying to copy over complex other projects into a complex project.

I don't know if you're talking about something similiar, or if it's even the same...

So just in case

-------------------

Create Custom Modular Objects

What i mean is (for example)

You've created a monster. This monster isn't just one simple sprite, it may be linked with several other objects together, using custom parameters etc... (additional hit boxes, single arm objects, angle object, and a lot of custom code)

Now, it would be awesome to simply SAVE this specific model you've created as one single "Object".

This "Modular Object" could then be shared throughout your other projects or wherever you might need it.

So if you're going to create a second monster, you can simply get this modular object out of the library (new)!

Set a new name on it, and it's already in your game. (Event Code will accordingly be adjusted to the new given name)

From this point it will be really easy to change just a few parameters, replace animations to create a complete new monster.

If you're creating an army of such monsters, it would be finished in just a few minutes.

All you would have to do would be changing the animations and maybe some parameters afterwards.

(Event code could be associated with these objects)

This could be used across near anything.

Your custom walls, doors, any characters. Just everything that's complex.

This should be right inside the interface, and it should give you the option upon using an object from your library to either duplicate specific objects, or use existing ones and bind them together. (for example use the same hit boxes, arms etc which were attached to this object using the container, but create a duplicate of the main sprite)

Having this right inside the interface would speed up your workflow dramaticaly.

You could create your own library of complicated modular objects, or share them with other developers (maybe through the market).

Imagine if you've finished your game, and released it to the public already.

You recieve great feedback and you decide to create a sequel.

Just create a new project, use your library and you can use the same assets and customize them just like that!

Keep in mind

[quote:377f8yqv]Our goal is to make Construct 3 the best game making editor ever.

That's what they said

Everade

That's in the documentation as a Prefab, it's the only Unity term used. It's also appropriate as it's the for word for "Prefabrication".

Prefabs are a wanted feature, and personally I feel better than just Adding more Sprite types.

I know what Ashley says, but there are two key points

1. The core run time is going to remain the same. So limitations in the rumtime will effect final features.

2. Best is subjective to what Ashley sees as the best and right way to game design. However some times those views aren't industry standards, and inefficient game design. As examples, Sprite Object instead of Sprite Behavior(which uses image atlases). Behaviors attached to every single instance of type, where as behaviors are best attached on a per game object.

So all we can do is see how C3 turns out. I'm hoping for the best, and I'm hoping C3 will be the best. But that requires flexibility and responsibility for the SDK community developers, rather than Scirra determining the best way to handle everything.

I think that would be great if you will take a look of other engines like Unreal Engine, CryEngine, Unity and see what features they have and try to even simplify and integrate some of them in the 2D/3D world of Construct 3. I recently seen a presentation of the making of Rayman Legends and I think they have a nice engine (for a 2d platformer).

anty21ro

It would be easy to just throw in other ideas from other engines. That wasn't really the goal to remake another engine. The idea is to get to the founding root of the IDE so that people can make any tools they need. If these tools 1:1 reflect other engines such as UDK then that's fantastic. We know the core design can do what's wanted. The industry has refined a lot of tools at this point.

However saying that there are a few features that are insanely good for work flow that are from other engines. Such as file journaling for auto updating, prefabs which focuses on maintaning good design optmizations and allows complex objects and others from both UDK, Anarchy and Unity. However they are far and few between. Mostly was to keep to the current C2 architect and re-work the design system to make making games easier, and easier to maintain higher performance games rather than falling into the massive, but invisible poor performance pits(ie every enemy type has it's sprite, every button is it's own sprite, every bullet is ist's own sprite.....).

As for Legends, that's a lot of custom tools at UbiSoft. And the idea is to allow C3 users to create tools as such, not for Scirra to make the tools themselves.

Don't know if this was brought up already, but some sort of simple but intuitive text editor for txt objects. For example, one in Rpg Maker was quite all right. It could also store the text automatically in a txt sheet of your choosing and remember which lines of text belong where. Also txt object could have some reprogrammed functionality from the start, such as text display and scrolling type.

If there are customizable windows, and associated actions. Then the architecture can already support the request down the road. Either by Scirra or some one else.

If there are customizable windows, and associated actions. Then the architecture can already support the request down the road. Either by Scirra or some one else.

Extensions are great and all, but I want the main software to function well from the get go. I'm already going trough nightmare of custom extensions in other software I'm using, and I don't C2 to be this way.

I understand, but this thread is about architecture. The current issue your having is architecture, if your having nightmare issues that's because of limits in the base foundation. With C2 there are limitations in C2 that developers can't get around, including making making easy to use tools. So some of the best development flow tools can't work well with C2 without Ashley making custom code to the IDE, and that custom code never passes on to developers(ie Spriter custom code for importing). Where as a good architecture would allow a tool like Spriter to seamlessly work with C2 without constantly re-importing.

If you want straight out of the door requests. I suggest looking for a straight out the door request thread. However I do take suggestions and evaluate them to make sure that the C3 can handle all requests effectively rather than limited.

Though I do need to go over some of the items in the document and find ways to break them down to their architect basics rather than the results.

It looks like we have a troll

http://i.imgur.com/BAsp1pv.png

It looks like we have a troll

http://i.imgur.com/BAsp1pv.png

Would it sound jaded if I were to be surprised that it took this long... <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing"> <img src="{SMILIES_PATH}/icon_rolleyes.gif" alt=":roll:" title="Rolling Eyes">

jayderyu:

You can roll back, right?

> If there are customizable windows, and associated actions. Then the architecture can already support the request down the road. Either by Scirra or some one else.

>

Extensions are great and all, but I want the main software to function well from the get go. I'm already going trough nightmare of custom extensions in other software I'm using, and I don't C2 to be this way.

This +1000.

I know the whole point of this thread is to articulate how C3 should be more open to tinkering and third-party-extensions, but megatronx makes a really good point: we need basic functionality that works. I just don't want to see C3 typified by this response from Ashley (and/or other devs, if there ever are other C2 devs):

"Yeah, that's a good idea, and it's on the todo list, but you know, you can just add it yourself with the sdk."

Also, while I can think of all sorts of awesomeness that could come from custom IDE elements, such a feature must be designed so that extensions can be rolled into a capx on export (hopefully such a feature can be extended to plugs/behaviors/effects too).

Otherwise, we are going to be looking at an expansion of the dependency-hell that already affects many C2 projects due to third party plugins/behaviors/effects.

Anyway, don't mind me, just being the devil's advocate. Now, where's another parade I can piss on... <img src="{SMILIES_PATH}/icon_twisted.gif" alt=":twisted:" title="Twisted Evil">