Fimbul's Forum Posts

  • Are 16 exporters not enough?

    Might want to hire someone to crank out exporters 24/7

    </sarcasm>

  • Problem Description

    Picking an object inside a function via the "pick overlapping point" system condition doesn't work, unless you have a breakpoint set somehwere.

    Description of Capx

    There is a function, called at the beginning of the layout, that destroys an object overlapping a point.

    There is also a breakpoint in the event that calls the function.

    Steps to Reproduce Bug

    • Run the project normally
    • The blue sprite remains
    • Run the project in debug mode
    • Press "continue"
    • The blue sprite is destroyed

    Observed Result

    The blue object remains if the project is ran normally.

    However, in debug mode, the breakpoint "pauses" the project. When you press continue, the object is destroyed.

    Expected Result

    The object should be destroyed regardless of whether you have a breakpoint or not.

    Workaround

    Add a "Wait 0 seconds" system function above the function calling event.

    Affected Browsers

    • Chrome: YES
    • FireFox: YES
    • Internet Explorer: As if I would run this thing...

    Operating System and Service Pack

    Windows 7 x64

    Construct 2 Version ID

    Release 165 (64-bit) checked

  • Ok. What about instance variables, though? There are no groups there, and no way to "hide" them by using different sheets. IMHO a simple collapsible optgroup list would suffice.

  • I just wanted to pop in and say I would also love a dialogue engine.

    The main point is that, while I want a dialogue engine, I don't want Ashley to be the one to do it.

    There are many great dialogue editors already out there, some even including support for localization. All we need is an official way to integrate them (rather than the current unofficial/unsupported/unstable method of editing the XML).

    I updated my second post (back in the first page) with a list of cool middleware, check it out.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ashley: But can't we have a simple cosmetic solution for global/local/instance variables, like the current "folders" for objects (which don't actually do anything)?

    Also, if possible, could we have this:

    ?

  • Fimbul

    In regards to levels. R0j0hound made a plugin that does a good job of saving a Layout's object. While C2 can export a scene to JSON I found the result file to overkill. So using R0j0 plugin you can use C2 as a level edit, run the level, and get the the plugin string export to save to file.

    Aphrodite also has a good solution too. Also if your using Tiles you can use Tiled. The SDK isn't impenatrble. I've used to make a photon multoplayer client.

    I consider those to be mere "workarounds": if you use R0j0's plugin, or even tiled, you end up making your game using some other IDE, outside construct. The construct "layout" ends up being a giant black canvas with random objects littered just outside it, since your map "loading" is being done externally.

    I have in the past created applications to facilitate map-making and stuff like that. My point is, it would be great if I could remain in C2 all the time. If I could hook into c2's interface I could create a rudimentary "tiled" clone that allowed me to place quick-backdrop/sprite tiles in the editor(since I don't like using the tilemap object), while at the same time populating arrays/defining obstacles/editing NPCs and stuff like that.

  • Meanwhile, your best bet is to code it manually using construct 2's events.

    Ashley

    I expect this sort of thing to come up all the time. Can we get some solution to facilitate reusing/customizing this sort of custom-coded UI widget?

  • Ashley:

    Interesting to see how the discourse changed over the years.

    Now people are complaining about "unplayable framerates" with 1000 sprites, webGL effects and physics enabled on two year old phones.

    Used to be that the mobile situation was:

    and those limits counted even for state-of-the art phones

    I for one am glad no time was wasted making native exporters.

    Edit: changed "don't use webGL" to "no mobiles support WebGL yet"

  • The title of this post is a bit misleading:

    What I think you mean is: "should I use install creator to create an installer for my node-webkit exported game?"

    The answer is "probably not", install creator is very outdated. I would look elsewhere, though I'm hesitant to offer alternatives since the best ones are paid.

  • However I gotta say you need to pull up your sleeves and do some work. many of your requests require code writing programmers to do all the time, often with no benefit. All they have are lines of code and then they have to compile and execute. There are no visual tools and inspectors. In fact C2 has probably the most robust API of any game language ever. And yet there is complaint that it doesn't do AI, Isometric so on so forth. Fimbul most API's don't do what C2 does at all. they are first and foremost renderers and 3d/2d mathematical apis.

    Whiteclaws and jayderyu:

    I'm not saying Ashley should create a build-your-own-ai interface. I'm saying the plugin SDK should be good enough for me to create that myself.

    Check out Three.js, jaws.js, Pixl.js, Craft.js, Unity API, not a single one of these game engines can hold a match to C2 inferno in comparison of API. If you want to look at extensions done by other people then that's another matter, but that same principle applies here. Some one has done AI works, Isometric tiles and more. These other groups have produced massive games from rudimentary api's that have zero to no game logic and still pull of games like World of Warcraft.

    These other frameworks are flexible enough to allow you to use your own formats, and allow you to build your own tools - what is called a "pipeline". Do you think WOW programmers did everything in code? No! They obviously built their own map editors, dialogue editors, and everything else they needed to make a game.

    My point is that C2 is very impenetrable if you want to build your own tools to help you make your game - right now the only option is to crack open the XML files it generates and hope you didn't have a syntax error somewhere. I want ashley to make an IDE SDK so that I can make my own integrated editors to use inside C2.

    Most of C2's limitations aren't limitations to the majority of gaming industry. Because once they get to work they aren't waiting on Ashley to do the grunt work for them.

    Yes! Yes a thousand times this!

    The problem with C2 is that, often, when you run into a problem, you have to wait for Ashley to fix it. There are no official ways to fix things yourself. It's too focused on beginners, and advanced users (those who know javascript, even if just a little) are left wanting.

    Now you may ask, "hey, fimbul, why don't you use pixi.js instead?". I could do that - I know programming enough that I'm confident I could code an engine in pixi. However, I like the eventing system, I like the webgl effects, I like being able to easily change properties of my project, and have minification and png-compression. I like having Ashley focusing on performance while I cruise by.

    Look at how powerful unity's extensions are: you could implement construct 2 as a unity plugin if you wanted! Now look at how pitiful c2's plugin SDK is.

    Here are my main requests

    Functions and Array as primitives like the Number/String

    Modularity through Groups

    Asset store

    C2 IDE inherently group development tool.

    We are in agreement. Also agree with your proposal for how function syntax should work. I also want to add that, since arrays are primitives, you'd be able to pass arrays as parameters to functions - that would rock!

  • As long as everything's running in javascript, the performance is never going to be as good as it could be, javascript is simply much slower than any native C++ code and theres nothing that can change that.

    This is not the case at all. Yes, interpreted javascript is slower than C++, but that means nothing.

    There are JIT compilers, for instance, and nothing prevents a native compilation from javascript to raw x86 code, generating equivalent performance to C++. The only limit is how "clever" the compiler is.

    If you really want performance, the argument never ends: why not create the entire engine in C, which is much faster than C++? Why not create the engine in assembly? Why not create the engine in x86 instructions? There's no limit to how deep the rabbit hole goes - it's always a tradeoff.

    Thing is, if you want to create a tool that is easy to program and can make use of the best (and bleeding edge) technology available, javascript is your best bet. Server side, there is very little that can go faster than javascript (node.js is way faster than .net, for instance). Desktop wise, we're playing catch-up, but we're almost there. Mobile, we still have a ways to go, but it will get there. The latest devices are already good enough, it's just a waiting game now, before they're widespread.

  • A lot of people, i'd even say the majority, use tools like construct/gamemaker/multimedia-fusion etc. because they want to make their "dream" game, not because they want to make their game as marketable and cross platform as possible. It's a hobby, and i think enabling people to make their game as big and complicated as they want within the scope of current hardware, rather than force them into cutting back so many features modern hardware would allow, makes C2 a lot less appealing to a lot of users.

    am very, very confused with your post. You said "enabling people to make their game as big and complicated as they want [...] makes C2 a lot less appealing to a lot of users", which makes no sense.

    Then you said

    A lot of people didn't leave because we got tired and stopped using the software

    ait, what? You're saying people got tired and stopped using the software, and for that reason, they didn't leave?

    I think I agree with what you said, or maybe I agree with the opposite of what you said? I can't be certain.

  • I gotta agree with almost everything here. Except the arrays and dictionaries, I have extensive systems that use arrays that would be far more complicated otherwise.

    I'm not saying arrays should be abolished, I'm saying they should be more integrated

    Right now, we have two types of variables, string and number. I want more:

    • String
    • Number
    • Boolean
    • Array
    • Dictionary
    • Object (yes I know you can do this with IID pointers, but it's clumsy - besides, why not implement it natively?)

    This way you can have an array of numbers and text, just like you do now, but it will also be possible to have an array of objects (a preselected objects list, or pSOL, for advanced users).

    Example:

    With a dictionary of arrays of text as an instance variable of an object, the syntax would be object.dictionary["key"].array[position]. This looks way more complicated than it is. Look how easy making an inventory would be:

    • player.inventory["name"].slot[0] ? get the name of the item in the first slot of the inventory
    • player.inventory["quantity"].slot[3] ? get the quantity of items in the fourth slot (not third, since it starts at zero) item in the inventory
    • player.inventory["id"].slot.Width() ? get the number of slots in the inventory

  • Sure, why not? Construct's price has been steadily rising as you surely know (since you're an early adopter). Also, there's no reason why the business edition can't be more powerful than the standard edition (collaboration features look like a nice fit there).

  • Solutions:

    Keep in mind most of the following solutions have been requested or mentioned many times already:

    [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16]

    So, in the last post I detailed the problems we face with trying to create big games in C2, now let's talk about solutions that can be implemented without taking the next 10 years:

    Widgets:

    We need some way to simplify object management, and I think a good place to start is to allow better object grouping. I know we have families, and those allow things like placing a head onto a body, or a healthbar onto a target, but we need to go deeper. We need widgets!

    • More layers of object-nesting: We can have multi-part objects, but why not have those multi-part objects also be parts of other objects? Say you have a complex gun made of several sprites, particle emitters, webGL effects, and you want to use that gun on a spriter character with independent limbs?
    • Functions as part of objects: Instead of coding things as a series of instructions in line, you can "group" related functions together, and fire them using a function! An enemy needs to reload? Regardless of his race, weapon or current animation, just use the action "reload" on that enemy!
    • Variable grouping and variable nesting: See this post
    • Deprecate the array and dictionary objects: We have strings. We have numbers. And then we have the array, which is just a numbered container for strings and numbers, and the dictionary, which is a string-coded container for strings and numbers. Those shouldn't be objects, they should be variable types (for global/local variables and for instance variables). If you want to know the name of the third item in your player's inventory, just do player.inventory[3].name (this example is 1-based, but the final result should probably be zero based) - no need for a separate array object! Want to know the score of a player named Fimbul? Just read Scores["Fimbul"] - no need for a separate dictionary object!

    More powerful SDK:

    This one is for plugin/behavior developers: How about more controls? Dynamic properties based on user input? Sliders? Checkboxes? Radio buttons?

    Many of the more advanced recent plugins have special interfaces inside the editor - tilemap and spriter are two examples. Well I want to have my own interface too!

    What if I want to create a dialogue editor, or a state machine, or a map editor? Right now, I would have to create my own editor to manipulate XML files and save them again. With an IDE SDK, we could create interfaces that do complex things automatically!

    Better project management:

    We need ways to simplify project management. We currently don't have ways of collaborating - only one programmer can work at a time. That single programmer is also responsible for updating graphics and tweaking effects, music and sounds, story, balance the game (change health/damage values, etc). While this is fine for a small product, if construct wants to see serious use, it's going to have to learn to play in a team, with multiple people working on the same project at once.

    Middlewares:

    We already have some middleware integrated with construct, but we could always use more! Right now, the problem is that integrating middleware with construct 2 is a task that can only be accomplished by Ashley - if we had an API to communicate with construct, we could hook the tools ourselves!

    Here is a list of some tools, I included spriter and tiled (both already integrated) to show that C2 is no stranger to using external tools.