Fimbul's Forum Posts

  • I've been sitting on this post for a long time, and was waiting for the multiplayer feature to be released before posting it. I'm releasing it now before the next big project is attempted.

    Many people are always complaining about the lack of big, serious projects in Construct 2, and I agree! All that we see right now, at least in terms of released content, are small webgames/freegames/mobile titles. Now, when I talk about big games, I'm not talking in terms of hours - the engine is already capable of delivering experiences such as spelunky, super meat boy or even mark of the ninja (which only recently became possible due to spriter). If you understand construct eventing enough, you can even succeed pulling off titles like Braid.

    So, this leaves construct in a very nice position regarding some genres (keep in mind we're talking about the desktop):

    • Platformers ✓ Levels can share a common event sheet ✓ Cutscenes can be done in different layouts ✓ Spriter enables powerful animation features ✓ Most stuff can be tracked using global variables (stats, combos, achievements)
    • Point-and-click adventures ✓ Levels can be done in different layouts/sheets ✓ WebGL allows for stunning scenes ✗ Branching narrative gets confusing very quickly
    • Racing games ✓ Plenty of third-party plugins and behaviors allow for cool movement ✓ Particles and physics allow for dynamic tracks ✓ Automatic layout memory management allows for BIG tracks and lots of AI players ✗ Upgrades that cause complex interactions get unwieldy quickly
    • Vertical/Horizontal Shooters
    • Physics-based puzzles

    Some genres, however, still remain remarkably difficult to attempt with construct. You may notice that the genres C2 has difficulty with are the most ambitious genres - this is the type of stuff people attempt with unity or write custom engines, but I don't see why that has to be the case. I would like to, for once, see a big, complex, ambitious project succeed:

    • RPG (à la RPG maker) ✓ Dialogues can be easily tied to NPCs via the use of families, and downloaded individually ✗ Tilemap object is very deficient: can't add properties to individual tiles, no multi-tile entities, can't apply shading to single tiles, collision mapping must be done with separate object, tile placement is cumbersome, "open-world" layouts eat lots of memory (there's no option to only load visible tiles) ✗ Can't do isometric (yes I know you technically "can", but there's a lot of pain with back-to-front rendering and z-ordering for pseudo-3d complicates matters further) ✗ NPC movements (i.e. wandering, chasing, fleeing) must be coded by hand (a behavior that attempts to do this would have to tie into c2's tile structure, generating a dependency that the SDK doesn't tell us how to address) ✗ Inventory is hard to manage, requiring separate projects and, in some cases, even plugins ✗ Windowed interfaces are hard, little can be shared and there's no concept of "sub-layouts" to ease this. 9-patch object sometimes shows seams, hardcoded interfaces are tough to reskin, sub-components (sliders, checkboxes, accordions) are hard to reuse since "widgets" don't exist
    • Management games (sim-*, *-dash,*-tycoon) ✗ Complex interactions are hard when all you have are global/local variables (you can't even group variables) ✗ Some things that require interconnection are utterly alien: how do you implement a road network (including avenues and traffic lights)? A power grid (including blackouts)? ✗ Interfaces are hard: see above ✗ Saving and loading must be coded manually, since in these types of games the position of objects don't really matter all that much
    • RTS ✓ Advanced picking features, as well as families, allow for multi-team combat ✓ Composite units (tanks with turrets) are allowed ✓ Saving and loading can be handled mostly automatically ✓ Terrains/scenarios can use different layouts while sharing event sheets ✗ Coding AI procedurally gets messy very quickly, to work properly you need to develop a finite-state-machine interpreter by hand ✗ Drawing primitives like "selection boxes" or targeting lines don't exist, must be done manually by stretching sprites ✗ Objects require many variables, which cannot be grouped or organized in any way ✗ Functions are procedural and cannot be tied to objects - having a unit aim at another and chase it requires creating logic that doesn't make sense outside of a given state (such as "chasing"), as well as keeping instance-id references and repicking almost every tick
    • MMOs ✓ Real-time games are finally possible ✓ Can use peer2peer architecture to reduce bandwidth costs - you don't even have to host your own signalling server ✗ Server side coding must be done outside construct, with platforms like node.js, unless you want a flimsy server running on a browser tab (the sysadmin inside me cringes at the idea) - also you can't access databases or do any heavy lifting.

    Now, I understand that in the past, performance just wasn't there - but now the desktop side of things is already fast enough that such projects can be attempted in seriousness. It may look like we need a TON of features to get to that point, but in my next post I will propose some features that will alleviate this burden without placing a ton of work onto Scirra.

  • Doesn't construct already do variable nesting? Like, if I drag a global into a group, it only functions in the scope of the group. Or am I misinterpreting your meaning here?

    No, you got that wrong. I don't mean variable scoping (this is already implemented, like you said, and works fine), just variable nesting (which is just cosmetic) - similar to how javascript objects are accessed:

    player.equipment.armor.blunt.pctResistance

    As for instances vars...I've never had a need for that many, but...yikes. Yeah, if I was in that situation, I would want folders too...

    Yes, you got that correctly. What I wanted is a solution like this inside the instance variables pane (the image is just an example I took from an e-commerce widget thing, ignore the text and focus on the functionality only):

  • Variable nesting in general would be super useful

    Also, instance variables could benefit from this grouping as well.

    I don't get why this isn't already implemented, it seems so easy, especially considering it's only a visual thing with no impact whatsoever on the game engine.

    Here's an use case for variable grouping: a medieval RPG, where attacks can deal different types of damage:

    • Piercing
    • Slashing
    • Blunt
    • Magical
    • Siege
    • Elemental: Earth
    • Elemental: Air
    • Elemental: Water
    • Elemental: Fire

    Then I have different ways to mitigate damage:

    • Damage treshold (flat damage reduction)
    • Damage resistance (% reduction)
    • Evasion (% chance to completely negate damage)

    And for attack I would need:

    • Base damage (used as a base for calculating)
    • % increases and decreases
    • Flat increases and decreases
    • Effective damage (all bonuses and penalties applied)

    So I have 9*4=36 variables for attack

    9*3=27 variables for defense

    for a total of 63 damage-type related variables. For each "player" or "enemy" type. You can see how this can quickly become unwieldy with the current system of a flat list of variables.

    Under the current system, you end up with variables named attack_damagetype_blunt_basedamage littered all over your objects, and you cannot simply "hide" them or collapse their group.

  • I've already completed both a game AND its sequel ... I need to first be able to reliably export my games to my target platforms.

    Scirra ... are aware of the state of mobile games with C2 ...So it is clearly willfully misleading.

    Yes, the current state of mobile games with C2 is bad, I'm not denying it. But exporters don't help you either! Making feature-compatible native exporters for android AND iOS would take a long time, so you would have to seat on your games for at least another few years! Also, by the time those years pass, the devices in the market will already be powerful enough to run your games, so the exporter would probably be redundant.

    Now, I'm assuming you already tried to optimize your game and even sent a capx to Ashley for guidance, and those things didn't work. If so, right now your best bet is to hope intel exporter works better, or that C2 integrates with Ejecta, and that ejecta somehow solves your problems.

    There are no quick solutions to your problem. You are right to be angry that mobile sucks (but to be honest, threads complaining about performance are nothing new, why did you insist on making mobile games when the whole board consistently complains that mobile is broken?)

  • If it turns out this is an issue with WebRTC or the browsers themselves, instead of being something Ashley did wrong, there's still a workaround you can do:

    In your games, make different "rooms" for people, based on what browser they're using. This way you guarantee same-browser players play together and avoid issues.

  • Arima:

    You just described why the state of MMF shouldn't be used for comparison. Ashley has proven to consistently be a better developer with better design ideas. MMF has been stuck on legacy code and structure for ages and C2 was built properly without those problems. They're just too different to compare.

    nd clickteam has many developers, and had many others in the past. Like it or not, they were pioneers. Sure, they could've ditched old structures long ago, but saying Ashley has better design ideas is telling only part of the story. Construct is the superior product, sure, but it wouldn't exist if it weren't for clickteam.

    In addition, you're suggesting we forego the only baseline we have available to compare! Yes there are products that have successfully implemented the exporter strategy - unity comes to mind - but why are those better as comparison models?

    Someone's not 'sucking money from Scirra' if they are contributing to C2 and implementing features people want, even if you personally don't want them.

    wasn't very clear, sorry. I meant that a new employee is using resources regardless of what they're working on. I would rather have a new hire working on features that benefit everyone.

    I don't think the editor is perfect, and I haven't gotten the impression that others arguing for native do either. I've stated repeatedly that if native exporters were to happen without hiring someone else, then they should be made later after the rest of the todo list is done.

    he todo list will never be "done". What I wanted to say is that it seems like people want the exporters now, which in my mind implies - mobile issues asside - that they'd be happy if the software stayed the way it is now for a few more years

    That... Doesn't make any sense. It sounds like you're calling iOS overpriced hype because we're reliant on apple, a third party, to develop iOS? We're even more reliant on microsoft for their development of windows. Not to mention...

    don't like apple - maybe our cultural differences are making this feeling hard to understand - in my country, an iPhone 5s costs the equivalent to $4500 (adjusted for GDP per capita) so maybe now you can understand why I think it's overpriced hype (in the US it costs $800). I think they provide one of the worse environments for developers. Microsoft sucks as well. HTML5 at least is stable, in that there's less of a risk it will be discontinued, like both Apple and Microsoft have done time and again.

    You're arguing FOR one of the main reasons to make native exporters - exporting HTML 5 only causes scirra to be much MORE reliant on third parties, and more third parties, rather than less!

    disagree. With HTML5 you're reliant on a single technology stack. The responsibility for complying with the standards lie with the vendors. And that's not even counting the ease of use of the APIs, the many frameworks/OSS solutions and the community - an esoteric bug with HTML5 is more likely to have a solution or workaround than an esoteric bug with Android/iOS/WP8/etc.

    I'm not saying making native exporters would be problem free, of course it wouldn't. However, as said, the jit compilers on iOS being inaccessible is one of the points that native would solve since we wouldn't have to use them at all..

    nd I think it would only compound the problems. Just go to any forum for a product that offers exporters: the vast majority of posts are either complaints about lack of functionality or complaints about bugs.

    That's still relying on third parties to fix them. Besides, how do you know that they'll be fixed? Because they're large companies?

    The chances of something being fixed are better if you're not the only one experiencing the issue. I doubt XNA would've been abandoned if it were the primary mean of developing for the XBOX.

    As you stated, apple doesn't let anyone compile JavaScript except for themselves. They've had this stance for years. What makes you think they'll change that stance? I'm very grateful to intel for making node webkit and crosswalk, as well as them making it free, but what if they change their minds? What if ludei changes course and decides to become a publisher or makes some other decision that ends their service for getting HTML 5 games on iOS? What if they desire to use an exorbitant pricing structure that most of us can't afford? What if they never manage to get their platform working properly for everyone? Guess what happens - our only option is to switch over to another third party - if there even is one - and hope they do better.

    ecause if you're using a widely adopted tech, there's always someone you can run to if your current vendor doesn't work (see phonegap). If Apple wasn't considered a status symbol, I bet they would've gone the way of the blackberry.

    By making native, we rely on third parties far, far less than sticking with HTML 5, where every single device C2 exports to is more dependent on third parties than if it was native.

    aybe, but you'll also have less leverage if you need something changed or fixed.

    It's pretty obvious which platforms are the successful ones by now. Native could be made for the major players, and HTML 5 would still exist for the rest. A native exporter would not have to be made until a platform had proven itself.

    s time goes on, it becomes harder and harder to make money on app stores. If you catch the early boom, money comes much more easily, which means you'd have to figure out whose phone/os is going to be the next big thing. You also have to factor in the time it takes for you to create a working exporter, as well as a feature-complete exporter. Also the time it takes for a developer to create their game on said exporter. And that's not even counting the fact that versions change and SDKs break. By the time you're finished, what guarantee do you have that the platform will still be financially viable? It's a risk you have to take. It's a risk clickteam took, and they've been bitten in the ass for it many many times.

    ... and besides, what would be the point then if you had to bring it back from the web to desktop to export?...

    'm not talking about turning C2 into a web app. I'm talking about rebuilding the IDE in javascript while retaining it's status as a desktop software, downloads and all. See the brackets editor for an example.

    Juryiel:

    If he doesn't have the team size to support those things maybe it would behoove Scirra to stop implying those things are supported. C2 and mobile is not ready, and the fact that there isn't a huge 'Beta' or even 'Alpha' tag when they advertise that means that Scirra is misleading us.

    I wouldn't use the word misleading, as that implies malice, but yes, I agree. Maybe Scirra should clarify that exporting to mobile is quite finicky, especially on anything older than a top-of-the-line smartphone.

    You're thinking about this only from Scirra's perspective and your own perspective, but not from the perspective of small design teams with small budgets

    ...

    nor do you get special preference because C2 originally started with desktop support.

    hoah, it's not like that! If I really cared only about myself, I would be pressuring Scirra to add more application-making features, since that's my primary source of income.

    What I'm advocating are features that help EVERYONE, not just mobile users:

    • Better/more integrated tilemap object
    • more/better modularity features such as widgets and nested objects
    • ability to run construct apps without draw calls - for server-side programming in multiplayer, so you won't have to code your server in a different language - this would make small MMOs possible within construct, for instance.
    • better ajax support
    • collaborative design capabilities (two people working simultaneously on the same game)
    • an IDE SDK
    • converting the editor to open web tech and opening it's source code (for the IDE only, again I'm not talking about the game engine or the exporter)
    • who knows, maybe even an exporter SDK, so people like

      tomsstudio can try making their own native exporters

    —:

    If you believe that 17.5% of the market is Russian, then maybe you should learn to speak the language.

    ou want to convince me that localizing games to Russian is a good idea? I'm convinced. Hey, maybe learning Russian isn't so bad either.

  • As a user with a 5 button mouse, I agree.

  • Because "unlimited bandwidth" is a lie. All contracts have something like "reasonable limits apply" in the small print. If you use an "unlimited bandwidth" host, as soon as your game becomes popular, you'll receive a message from your host telling you to "migrate" to a (vastly) more expensive package.

    You'll refuse to migrate, and they'll shut down your game, just when it was getting popular.

    Bandwidth is very expensive, there's no way a host would just give tons of it away for a few bucks.

    Much better to go with a limited bandwidth host - at least you know the limits clearly!

  • rainmaker, I once programmed a solution like this, using text objects as well!

    What you do is, instead of creating 10000000 text objects for a big table, create only as many as the user can see at once, then add a scrollbar to the side.

    When the user scrolls, instead of scrolling the layout as you would do normally, just make the source text for each line advance by one.

    Say your source data is a list of fruits:

    [1] - Banana

    [2] - Apple

    [3] - Orange

    [4] - Watermelon

    [5] - Pineapple

    [6] - Grape

    [7] - Blueberry

    And the user can see 3 lines at most

    Line 1 -> fruits[1]

    Line 2 -> fruits[2]

    Line 3 -> fruits[3]

    Now say the user scrolls 1 item down. Instead of seeing "Line 4", the lines themselves don't change, just the references:

    Line 1 -> fruits[2]

    Line 2 -> fruits[3]

    Line 3 -> fruits[4]

    This way, the objects remain fixed, nothing new is created, just their text is changed! The only downside is the scrolling appears less smooth, since you can't scroll down, say, "10 pixels. You must scroll in whole lines.

  • It's probably not going to work on mobile for a long time. However, you should consider that mobile networks are VERY unreliable, almost useless for real time gaming, so you should probably use websockets instead!

  • If you decide to use your own signalling server, don't use hosts with "unlimited bandwidth", or you're gonna have a bad time.

  • Does this even work with node-webkit? I'm interested to see if it would work with it, since it's a natural candidate for a host in a client-host architecture.

  • - I understand that youve got a lot experience. im shocking that these thoughts are from an experienced developer like you.Because experience means years and you are not a child to speak this way. What it means we pressure for mobile and you with your rights will pressure Ashley to NOT focus on mobile. Ashley is not a dog or a cat...He has his plan for what he will do. And for the moment he gave us many alternatives desktop,mobile,consoles and we are talking about our problems/our worries to find out where things will go.

    In the end you bought c2 for a specific thing, others (like me) also bought it for html but mainly for mobiles. All have opinion there is no need to push someone.

    Well everyone has opinions, sure. I'm not saying mobile users deserve nothing. You and I want different things, and it's ok.

    I can understand if Ashley spends time creating a facebook/twitter plugin or looks for solutions to mobile-exclusive issues, even if I never use any of that. I understand. But it has to be done within reason.

    If everyone starts chanting "mobile mobile mobile" and no one disagrees, Scirra might get the impression that everyone wants mobile stuff, and that is not the case, so I speak - this is what I mean by "pressuring" Ashley.

    I want scirra to see that people like me, people who don't care about mobile, exist. And people like me would prefer if the desktop got a bit more attention.

    Heck, the decision to support an open source solution like ejecta might even be a good choice! I can stand a few months of Ashley working on that, even though it won't benefit me. But spending the next few years working on native exporters? No way.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I was one of the backers for the original pack, and I can vouch for this guy. Most of the assets he produced were great, and I have no doubts the new content will be good as well. I'd definitely jump in before the $89 tier runs out.