You've been plugged on Indiegames.com:

You've been plugged on Indiegames.com:

Indie Tools: Construct 2

In case you didn't know :)

People seem skeptical :) Yeah i hope one day C2 will have scripting support in-editor :D

I've tinkered with the demo for Construct, and although I really like it, having to click so much to achieve events that you could type out really quickly (especially with intellisense support) with a built-in script editor would be really handy. I think it wouldn't be too difficult to allow the developer to use either advanced script mode or drag and drop for beginners. Plus I don't know, I think it's a lot easier for readability to see a script to understand the logic flow of a complex program.

Game Maker does a really good job with providing support for both, and includes support for calling functions by string name and also instantiate objects by string name, its really great for creating game editors and such.

I was a long-time game maker fan, even till the day I discovered Construct Classic, which at the time was still quite lacking of features, but already so much cleaner and easier to use than Game Maker.

I worked on plenty of game maker games and enjoyed both scripting in GML and eventing. But the two aspects never felt as though they were an integrated experience for me. I felt as though I was calling scripts with events most of the time, or wholly using one or the other.

What I can see Construct doing now is having even scripts behave as drag-and-drop behaviors, which certainly doesn't give as much ease in changing options, but is much neater and easier for people who don't know anything about codes.

I've tinkered with the demo for Construct, and although I really like it, having to click so much to achieve events that you could type out really quickly (especially with intellisense support) with a built-in script editor would be really handy.

countofquad - you can actually type out events using the keyboard shortcuts.

I'm still skeptical about scripting in events - I think it's one of those features which sounds better than it would really be, like 3D (everyone thinks 3D is really cool, but noone seems to give much thought to the vastly more complicated modelling and level design processes and sophisticated matrix math that tends to go with it). Events are surprisingly sophisticated - don't forget a simple two-condition event in script would go something like:

for each sprite:

• if meets first condition:

-- add to temporary list

for each sprite in temporary list:

• if does not meet second condition:

-- remove from temporary list

for each sprite in temporary list:

• run action on instance

Throw in your curly braces and function calls and you have a pretty dense, unintuitive chunk of code. The event actually reads simpler and is quicker to put together. Of course this isn't really comparing apples to apples since you don't tend to write scripts like that, but it does show that events and script don't really play nice together. On top of that we added Python scripting to Classic and I don't think it really was particularly successful - it was extremely complicated and a big drain on development time, and the integration with the runtime was pretty limited (you couldn't write in script everything you could do with events, which kind of defeated the point). Plus I lost count how many times people described Classic on forums as a "Python game creator" which required programming :P

So I think events only is a nice differentiator. It's what makes C2 unique.

Anyway, nice to have a mention on indiegames.com!

Well, Ashley, I think events are as powerful as coding, if not more. All drag'n'drop game making tools have this discussion at some point and the result is always more or less the same: there's nothing you can't do with eventing that you'd be able to do with coding.

However, there are issues. Construct 2 isn't object oriented, for instance. There's no way to simplify coding, everything is always all over the place, it's like procedural programming all over again! We cannot make our custom ACEs with construct events, and that makes artificial intelligence in c2 games almost impossible - you can prototype the pieces, but you can't assemble them - it would be nice to have something like [if I have a shot at defeating the player] then [chase player], with all the complexities (that I coded myself) hidden away.

In addition, object-oriented concepts such as an object composed of multiple sub-objects each with their responsibilities, code reusability, design patterns and other things feel very weird (and that's not just with construct).

I think stuff like that has to change before "eventing" can be considered up to scratch.

There's no way to simplify coding, everything is always all over the place, it's like procedural programming all over again!

Not sure what you mean about procedural coding, but I disagree about everything being all over the place and no way to simplify. If you use lots of groups, sub-groups and sub-events well, I find it to be extremely organized, as an entire section of code can be described in a group name. It makes it very easy to find what you're looking for. It's how I manage working with a 5000-event event sheet in loot pursuit - and things are plenty easy to find, as long as I actually place them somewhere logically labeled.

We cannot make our custom ACEs with construct events, and that makes artificial intelligence in c2 games almost impossible - you can prototype the pieces, but you can't assemble them - it would be nice to have something like [if I have a shot at defeating the player] then [chase player], with all the complexities (that I coded myself) hidden away.

You can actually do A.I. with events as they are, and it's not almost impossible at all. You could do what you described above by combining some of the player's character's stats into a 'power level' variable that could be compared to the enemy power level, and to fight or run depending.

I haven't done any 'real' coding, but I'm guessing it's a lot different from how you're used to doing it though.

In addition, object-oriented concepts such as an object composed of multiple sub-objects each with their responsibilities

Containers are made for exactly that. :) They're not in C2 yet though.

code reusability, design patterns and other things feel very weird (and that's not just with construct).

Design patterns? I'm not quite sure what you mean by that?

Event system is powerful for me by customize plugins, more then having a text editor. Making plugin will force programmer to make a reuse-able code.

--

Very thanks to Ashley for creating this architecture (event system + plugins). I had made more then 70 plugins, and these plugins really help my team member in their applications.

scripting in events? No Ashley, don't leave your way! Keep all the Things simple! That's the only right Way!

I have testet all the other's like GM etc. Construct 2 is a sensation!

Can't sleep anymore before R100 is released.....jtc@Ashley - please drink some extra strong coffee's and work hard on your world domination Tool!

KMag

Don't get me wrong: I don't think construct should implement scripting, because I believe in the power of "eventing". However, construct "eventing" should be a bit more "object oriented".

If you use lots of groups, sub-groups and sub-events well, I find it to be extremely organized, as an entire section of code can be described in a group name.

In other words: we have something akin to "named code folding".

You can actually do A.I. with events as they are, and it's not almost impossible at all. You could do what you described above by combining some of the player's character's stats into a 'power level' variable that could be compared to the enemy power level, and to fight or run depending.

The standard way to implement AI in games is via a finite state machine. The example I mentioned is akin to one "state" of that machine (enemy). Things get a lot more complex when you have more states, and more complex behaviors. Sure, you can implement everything via events, but you can't easily go and change things once they're in place, and cascading states is also a lot more complex. Imagine your "power level" variable, now imagine 70 other variables like that, each used in a different context, by an enemy that already has to track things like distance to the player, current hp, current mp, max hp, max mp, list of available attacks, movement possibilities and tons of other stuff.

It quickly gets confusing, especially since we have no concept of "internal" variables - that is, variables that are specific to an instance, but that shouldn't be displayed in the editor, because they are used internally. A reload timer is a perfect example of this: you have the reload delay, which is a property of the object, and you have the reload counter, which the object uses internally to implement the reloading - you shouldn't see that second variable because you'll never want to mess with it in the editor.

Wouldn't it be easier to code everything up in blocks and call those blocks something meaningful? I.E: this section means "run away from player", this section means "kamikaze attack", this other section means "try to ambush the player", and this one "flank the player" or "gang up on the player", and so on - if we had custom ACEs we'd be able to do that.

Containers are made for exactly that. :) They're not in C2 yet though.

I hope containers can include other containers, and those sub-containers can contain other sub-containers, and that we can mix objects in those containers (not hard to imagine such a situation: think of a tank with a body and a turret [2 sprites], a buffer for dead reckoning in multiplayer [array object], player name [text object], post-processing layer [canvas object], health bar [another sprite] and effects [particle object]), and that we can dynamically include and exclude objects from containers.

Design patterns? I'm not quite sure what you mean by that?

Code reusability is the capacity to reuse elements of an engine. How many times did you have to code a platforming engine? Wouldn't it be a lot better if we could just design one with all sorts of fancy stuff like double jumping, wall jumping, jetpacks, powerups and whatever, then plug a game in it and tweak the values by enabling/disabling parts of the engine, or perhaps sharing such engine in the forums? It's doable now, but what if you have to work such engine into an already in-progress game, instead of building a game from scratch on top of an engine? This process should be easier.

As for design patterns, you'll have to read more on that, there are a ton of them.

Kind of a crappy article if you ask me. It's somewhat misleading and incredibly vague.

The standard way to implement AI in games is via a finite state machine. The example I mentioned is akin to one "state" of that machine (enemy). Things get a lot more complex when you have more states, and more complex behaviors. Sure, you can implement everything via events, but you can't easily go and change things once they're in place, and cascading states is also a lot more complex. Imagine your "power level" variable, now imagine 70 other variables like that, each used in a different context, by an enemy that already has to track things like distance to the player, current hp, current mp, max hp, max mp, list of available attacks, movement possibilities and tons of other stuff.

I don't know, I've coded things using finite state machines in events before, and had no problem with it. The enemies in loot pursuit have 79 variables and the number of variables they have has never really been an issue that I can recall. What was an issue was my inexperience designing code properly, which is how it turned into a tangled mess. ^^ Subsequent designs have been much smoother.

I do something like this:

enemies

     wandering

          If enemy variable 'mode'="wandering"

               Code for wandering about randomly

               If distance(enemy.x, enemy.y, player.x, player.y) < 500, check angle for field of view

                    If player variable 'powerlevel' > enemy.powerlevel

                         set enemy.mode to "running"

                    If player variable 'powerlevel' < enemy.powerlevel

                         set enemy.mode to "chasing"

     chasing

          If enemy variable 'mode'="chasing"

               chasing code, pathfinding, etc

               If distance(enemy.x, enemy.y, player.x, player.y) < 100, no obstacle in way

                    set mode to "attacking"

     attacking

          If enemy variable 'mode'="attacking"

               Code for charging towards player

               If enemy overlaps player

                    Set player variable 'mode' to "hit"

Which collapses to:

enemies

     wandering

     chasing

     attacking

Etc. Using this method I can make behaviors as complex as I want and still find it easy to work with.

It quickly gets confusing, especially since we have no concept of "internal" variables - that is, variables that are specific to an instance, but that shouldn't be displayed in the editor, because they are used internally. A reload timer is a perfect example of this: you have the reload delay, which is a property of the object, and you have the reload counter, which the object uses internally to implement the reloading - you shouldn't see that second variable because you'll never want to mess with it in the editor.

I'm afraid I'm not familiar with the term (even after several minutes of googling), and don't understand. What if you change your mind about what you want the value to be, or edit out that feature using that variable entirely, or change the variable name to something else? The variable has to be editable somewhere. Why not simply have it in the same list? It seems the most logical place for it. I think doing it some other way would be highly confusing.

Wouldn't it be easier to code everything up in blocks and call those blocks something meaningful? I.E: this section means "run away from player", this section means "kamikaze attack", this other section means "try to ambush the player", and this one "flank the player" or "gang up on the player", and so on - if we had custom ACEs we'd be able to do that.

Isn't that exactly what groups are? That's how it works the way I do it with my example above. Though I'm not arguing against custom ACEs, those would be awesome too.

I hope containers can include other containers, and those sub-containers can contain other sub-containers, and that we can mix objects in those containers (not hard to imagine such a situation: think of a tank with a body and a turret [2 sprites], a buffer for dead reckoning in multiplayer [array object], player name [text object], post-processing layer [canvas object], health bar [another sprite] and effects [particle object]), and that we can dynamically include and exclude objects from containers.

At least in construct classic, containers cannot include other containers (which is a great idea), but all the rest of what you said as possible regardless (dynamic ones could be created with the pairer object), having a tank with the two piece turret, etc. It works better if the health bar isn't part of the container though - all you need to do is create an instance of that for each instance of the tank, place it to the tank's position and set it to the tank's hp and it'll automatically place itself to the right instance.

> Design patterns? I'm not quite sure what you mean by that?

Code reusability is the capacity to reuse elements of an engine. How many times did you have to code a platforming engine? Wouldn't it be a lot better if we could just design one with all sorts of fancy stuff like double jumping, wall jumping, jetpacks, powerups and whatever, then plug a game in it and tweak the values by enabling/disabling parts of the engine, or perhaps sharing such engine in the forums? It's doable now, but what if you have to work such engine into an already in-progress game, instead of building a game from scratch on top of an engine? This process should be easier.

I know what code reuseability is, that... wasn't what I asked. I asked about design patterns. ^^

What was an issue was my inexperience designing code properly, which is how it turned into a tangled mess.

My point is that everything that's complicated enough soon gets turned into a tangled mess.

enemies

     wandering

     chasing

     attacking

The problem with that is that you have little reusability. For instance, this "If distance(enemy.x, enemy.y, player.x, player.y) < 100" could be compacted to a custom condition called "is within attacking range?" - you'll obviously need to repeat that all over your code.

You also have similar cases, such as "is within field of view" and "no obstacles between me and player" which could be abstracted away.

Similarly, if you have more than one condition that triggers "chasing code" or "pathfinding", you'll need to copy+paste the chasing/pathfinding code again at those positions, violating the "DON'T REPEAT YOURSELF" principle of software design - either that or you make a huge OR block with all the possible conditions that trigger pathfinding/chasing.

Violating the DRY principle is bad for obvious reasons.

I'm afraid I'm not familiar with the term (even after several minutes of googling)

I'm sorry about that part - they are known as variable visibility - there are public variables (what we have at the moment) and private/protected variables, which are related to inheritance (we can already do multiple inheritance via families, which is cool).

The point about hidden variables is that I don't want to clutter the editor with tweakable properties (public variables), which are things I need to adjust to balance/polish my game, with internal stuff (private variables) which are just small storage bins that allow the object to do its work.

You can edit/rename/delete/make public those hidden (private) variables, of course, it's just that they're hidden out of view in your normal workflow, similar to how you can lock a background object in the layout editor so that you can click your objects easily.

It's weird having a ton of internal variables mixed with normal variables, and having to resort to prepending "__" or similar to internal stuff.

Isn't that exactly what groups are? That's how it works the way I do it with my example above. Though I'm not arguing against custom ACEs, those would be awesome too.

I wasn't very clear there - although you can encapsulate the "kamikaze attack" in a group, you can't say "there you go, enemy! time to do your kamikaze attack!!!"

You can't do that without using weird workarounds like "is group active?" and "disable/enable group". It feels like a hack.

At least in construct classic, containers cannot include other containers

I know you didn't ask, but I'll give an example: I could have a sprite representing the turret body, another representing the beam (I'm thinking of a beam cannon), a particle object, a post-processing layer, and then have a big spaceship composed of other stuff, with multiple beam cannons across its surface. (the spaceship on the whole is a container composed of the hull, shields, hp bar, and then multiple copies of the "beam cannon" container).

I asked about design patterns. ^^

I'm thinking specifically of the Factory Pattern and the Strategy Pattern

I expect custom aces should make design patterns implementable.

That article is quite low leveled.. It is clear, that the author of the article didn't used C2 for enough time to get it's potential.