[BIG REQUEST] Big games support

Discussion and feedback on Construct 2

Post » Thu Mar 20, 2014 8:28 pm

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.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Thu Mar 20, 2014 8:28 pm

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.
Last edited by Fimbul on Thu Mar 27, 2014 4:35 pm, edited 4 times in total.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Thu Mar 20, 2014 8:45 pm

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.
Image ImageImage
B
168
S
50
G
163
Posts: 8,222
Reputation: 105,063

Post » Thu Mar 20, 2014 9:13 pm

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).
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Fri Mar 21, 2014 12:53 am

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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Fri Mar 21, 2014 1:28 am

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.
B
28
S
8
G
5
Posts: 429
Reputation: 6,997

Post » Fri Mar 21, 2014 2:03 am

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.
Image
B
242
S
29
G
13
Posts: 1,787
Reputation: 18,685

Post » Fri Mar 21, 2014 2:09 am

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!
B
103
S
38
G
19
Posts: 962
Reputation: 17,986

Post » Fri Mar 21, 2014 5:06 pm

Tobye wrote: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
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Fri Mar 21, 2014 10:25 pm

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.
B
7
S
3
G
1
Posts: 184
Reputation: 1,352

Next

Return to Construct 2 General

Who is online

Users browsing this forum: Cliffu and 11 guests