Construct 2 - feature poll

This forum is currently in read-only mode.
0 favourites
From the Asset Store
Casino? money? who knows? but the target is the same!
  • Ah, I see what you mean by "Event-written behaviors/plugins/modules" now.

    Thanks guys.

    I've now used my 3rd vote for that feature, as it sounds very powerful.

    Having looked at the results again now that more people have voted, I'm a bit concerned that gamepad support has dropped down the list.

    For me, this is THE most important aspect of playing a game, and we shouldn't expect users of our games to have to install 3rd party utilities like joy2key just to play them with a gamepad.

    I think that gamepad support should be in there 100%, regardless of other features, especially if Construct 2 is going to be a commercial product.

    Krush.

  • Mac support would be nice but - Xbox360 support would be something else, would make Construct super popular.

    Another side request I thought of is being able to tweak things during runtime, stuff like jump strength in the platform behaviour.

    My biggest thing is audio support though - easy functions for fading/cross-fading sounds, Doppler effects and being able to attach the sine behaviour to the volume of a sound.

  • Ashley how long can we still vote? I hope you will not close this topic to soon....

  • I hope the fact that this poll doesn't have "full unicode support" means that it's already planned and listed as an absolute must feature.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Yes, full unicode support is planned. Also, I don't plan on closing this topic - you can vote as long as you like. I'll check it from time to time to see if anything has changed.

  • Hey ash, what you said about the feasibility of alternate runtimes in this thread.

    Does that mean the extensibility and flexibility to port to multiple runtimes you originally thought is not possible afterall, or do you just mean the differing featuresets of different platforms will make impossible for perfect alternate runtimes?

    Its probably a bit premature to speculate on everything, but I had assumed that once a sprite plugin was made for whichever platform, the behaviors would transfer fairly universally for new runtimes, and little else. Do you still think its possible for user created runtimes for platforms as diverse as android, ps3, etc?

  • It's possible to support many runtimes. I'm not sure what you mean by "transferring behaviors universally to new runtimes". Traditionally porting the runtime to a new platform involves writing a new runtime, a new plugin architecture, and a whole set of plugins which are functionally equivalent to another platform - all in all, a lot of work. I don't anticipate that we will have the resources or volunteer interest to complete more than two platforms in the forseeable future. Long term, this may change though, and by designing in a flexible architecture that anticipates multiple platforms, this can be made much easier when the time does (eventually) come.

  • "Event-written behaviors/plugins/modules"<-- Best feature

    Some more features(just suggesting) -

    C# for plugin development

    Support for other IDE's like DevC++, C-Free etc.

    More programming Languages support like C# or C++ (i think David is working on a Lua Plugin)

    Change the UI, rip off that ribbon

  • I'm not sure a C# plugin engine is a good idea - what's the install base of the latest .NET framework? If games won't run on Windows XP without a .NET framework upgrade then we'll have a very similar problem to the D3DX update problem: a lot of people either won't bother and not play the game at all, or will come to the forum confused as to why it doesn't work.

  • It's possible to support many runtimes. I'm not sure what you mean by "transferring behaviors universally to new runtimes". Traditionally porting the runtime to a new platform involves writing a new runtime, a new plugin architecture, and a whole set of plugins which are functionally equivalent to another platform - all in all, a lot of work. I don't anticipate that we will have the resources or volunteer interest to complete more than two platforms in the forseeable future. Long term, this may change though, and by designing in a flexible architecture that anticipates multiple platforms, this can be made much easier when the time does (eventually) come.

    I see. I thought part of the extensibility would be one more layer of abstraction, so all behaviors at least would work with at most a recompile on anything that supports c++

    So the plugin source for a c2 plugin might say something like:

    setobjectXY(objectname,50,100)

    And the definition for setobjectXY wouldn't actually move the object, it would serve as an interface that would merely pass on the information to the appropriate runtime implementation of setobjectxy

    Runtimes would be required to have a certain set of object position,dimension,orientation,destruction,and creation callback functions that would do the actual movement, and the same behaviors could be used for all runtimes

    Is something like this possible, I know at least dx,mac,linux,android,and xbox can use compiled c++

  • Oh yes, it's possible especially for behaviors and simple plugins that consist purely of logic, to compile for multiple platforms for one C++ source. C2 will have better abstractions across its SDKs so that kind of thing is easier too. There may be an issue keeping the SDK in sync if multiple runtimes are being developed by different people, but at least then that would mean multiple runtimes are in development!

    It also doesn't help with platforms which you can't use C++ on like the web - you simply are forced to write a plugin twice. However if the SDKs are as similar as possible that should be pretty straightforward.

  • Man, gamepad support shouldn't even be on the list. That is such a must yet I feel compelled to use a vote on it. Gamepad support should be a 'for sure' feature. Then I could pick something else for my 3rd choice!

  • Same here, gamepad should be a given just as unicode (any language, any gamepad!).

    So yeah, the vote I used in gamepad I wanted to use in event-based behaviors. But I see that's quite up the list anyway so it's okay

    I worry about developing with a team bigger than ONE PERSON though. Currently it's almost impossible.

    Oh and online because uh... it's shiny.

  • I'm not sure a C# plugin engine is a good idea - what's the install base of the latest .NET framework? If games won't run on Windows XP without a .NET framework upgrade then we'll have a very similar problem to the D3DX update problem: a lot of people either won't bother and not play the game at all, or will come to the forum confused as to why it doesn't work.

    it's ok, but how much knowledge of C++ is required to make a plugin??

    and what about support for other IDE's like DevC++?? nothing in this world can make a install that VC++ express and download that WinSDK.

  • For some reason I can't vote... so I pick:

    • Multiplayer support
    • Event made plugins,effects,etc
    • Muti-platform suport

    ~Sol

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)