[BIG REQUEST] Big games support

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.

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.

• Spriter (art and animation)
  
• Tiled (map editing)
  
• Storybricks (emergent AI, NPC behaviors)
  
• articy:draft (RPG workflow, dialogues, map editing, a ton of stuff)
  
• Chat Mapper (dialogue tree editor)
  

Well when you talk about "Big games support", you are going to have to talk about "big money contributions".

Obviously C2 can't do much about that, but the truth is money will always be the biggest motivator.

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).

This post is interesting, I know that C2 will never go off track of multiplatforming (and so it'll not do only-mobile nor only-desktop, which is good), but I think it can improve even with that in mind.

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. Sorting/folders for instance variables and variable families are high on my want list.

One thing I would love to see though is an editor editor in a way - so I could make check boxes and other shortcuts within the C2 editor to make it more efficient and easier for others who haven't built the game engine to use. Of course this would be an incredibly large task and I don't expect it, but it would be nice.

[quote:1uhqxp8h]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.

It's really annoying to read this so often... Most "big, serious projects" take longer to develop than C2 has existed. There are quite a few in the works anyway.

I do agree more features along these lines would be very helpful! I think I have one of the further-along RPG's in C2, so I'll comment on some things I've done in regards to come of your points:

RPG (à la RPG maker)

✓ Dialogues can be easily tied to NPCs via the use of families, and downloaded individually

Right. I didn't want too many external calls, so I do it through events, but I simply have an instance variable on the invisible rectangle I use for each NPC. Then I just have sub-events for each one. Pretty simple, easy to follow, allows for them to say different things depending on game state. Maybe not as elegant as what others may do, but it looks and handles nicely and I don't have to play with strange formatting or parsing issues. It could even be simplified with functions, but I'm happy with how I'm doing it and it hasn't bothered me for the 50+ NPC's I already have in-game.

✗ 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)

For tile-based games, I'm sure this is significant. I don't use that technique to build maps, though, so I don't have these issues. I have a lot of tiled backgrounds and sprites that I use (and re-use in different ways) as overlapping building blocks. That way, I can get a lot of customization, I'm not tied to a grid, and performance doesn't seem to be an issue even on my older desktop.

✗ 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)

It's a pain. It works for me, but there are still minor tweaks that always need to be done. This is particularly cumbersome with Sprite files because any global z-ordering shenanigans will re-order the body parts (and then I have to re-order them correctly after each z-ordering pass). This could be better, but I do have it working fine. I have a layer where things can be sorted and then layers above and below that are static. This reduces the amount of objects being ordered quite a bit.

✗ 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)

Also a pain. I just have to do it manually. There are a few good ways to do it (the best, to me, being to set waypoints and have characters move towards that then advance to the next).

✗ Inventory is hard to manage, requiring separate projects and, in some cases, even plugins

I don't have this problem. Granted, I do limit the number of inventory objects in the game. I have 6 always-there item types (money, potions, etc) and then 4 slots for quest-related objects. The code for the 6 is easy--just pull numbers from an array and update the UI with those values. The 4 slots are a little tougher since I need to have imaginary holding slots and such for letting the user place objects and such. I just have cross-reference array values and then set the visuals to match based on what values are in those slots. It's complicated, but works flawlessly.

✗ 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

I just have the UI set up on a layout how I want it, I wrote down where everything needed to be (relative to the window since I support multiple resolutions) and just create the objects at the start of each layout like that. Then, to change it, I just have to change that create call. Now, setting up that create event the first time is obnoxious, but it's the best solution I can think of. I'd love for something better, but this seems best to me.

Good list! I hope it leads to more features!

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

I've been on/off working on a MMORTS browser game, more to see how to put one together than anything else. I would have to agree with many of the points that Fimbul has mentioned. I think arrays could definitely be more integrated. My biggest issue around C2 is not the functionality that it can provide, but around the coding environment. The multi-person collaboration is one example, but for me the thing that gets me is that as games get large it is so time consuming to go hunting for functions, variables, etc. Yes, I've read of all the tricks and approaches people use, but that's to get around the problem that C2 doesn't manage that problem well. Look at modern IDEs to see how it could be done.

Finally.. please can we have a proper search that runs over the project and not just an event sheet!!! pretty please.

For arrays, I'm with Fimbul, I can't comprehend why they aren't a primitive, but looking at it on another angle, C2 is supposed to be easy to use for a beginner, but with arrays comes dynamic resizing, clearing, manipulations (pushing, popping and such) and those are all available via events (like doing a double-for loop for clearing) but that is not something you can gulp easily (double-forloops, ok, but pushing or popping, good luck), so yeah, it goes counter to the design of using C2 without any programming experience, +that would make C2 more of a written language too and that's not what it is (Even if I want CScript so badly )

Anyways, nice list!

This kind of topics make me smile. C2 is already very accessible and customisable development tool. You can develop any 2d game genre and even more by using only event system. I don't even speak about this huge amount of 3rd party plugins and behaviors and awesome official multiplayer functionality. Everything is based on cutting edge web technologies. You guys are searching for a magic button.

I agree with some topics and not others Fimbul.

I agree we need more of the core Functions need to be made as Primitives as string/number already are. Functions and Array absolutely especially Function.

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.

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.

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.

However even after saying that. I agree with design decision haven't always been the best.

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.

Just asking. How would Function and Array be different as primitives. Would it still be possible to add Array to containers.

jayderyu is kinda right, C2 is just an API wrapped into a GUI (kinda...), it's not supposed to give a solution to everything in game programming, it's doing it's best to do so but you need to learn to get your hands dirty, C2 gives you the tools, but some of the tools you'll need to build them yourself and learn new stuff or you can buy 'em at Canadian Tires (Or at an asset store), all for your game's sake

+999 for the assets store, Unity has one, and it's a blast, Ashley could always take a percentage of the sales for C2's development and everyone would be happy! Tom & Ashley what do you guys think ?