I suspected different exporters would use different languages, but... Wouldn't that make developing plugins a hassle, having to develop for different languages in order to work with all exporters, or am I mistaken?

Since there will inevitably be a Windows EXE exporter, I am kinda concerned about the speed of games made in Construct. While Javascript is all well and good for web applications, there's a reason why it's never used for desktop applications - it's slow, compared to other languages. Unity uses it, but that's because Unity optimises it to insane levels. And even then, it provides alternatives.

Do you guys think Javascript's speed is gonna be an issue for desktop exporters? You could use Lua as an alternative, since it's a very popular scripting language for games, or go back to Python... It's up to you guys, though.

That's one thing that has been bugging me... Why are you guys using pounds instead of dollars? Unless I've missed something and you guys actually live in the UK and not the US, haha.

I can't stop laughing. It can't be a coincidence, surely, with the time-frame they admitted themselves.

Honestly, I don't really care about Game Maker. I find the interface and how it does things unintuitive and the event system is almost useless without scripting.

I mean, who knew people would pay hundreds of dollars for smurfberries?

As Valve have proved, people will pay for hats that can be gotten without paying.

I'd totally love to support you guys, and I fully understand your reasons, so I don't think moving to a closed-source system with payment is a bad thing. However, getting a reasonable system that everyone is okay with, is, of course, a tricky business, hence all this discussion. I think I'll stay out of this one for now, and wait for the updated proposed model.

Ash, since when did you become the anti-Notch?

Anyway, I hope Davo implements transparency along with the image editor and animations.

Behaviours. They make things a lot easier and quicker to implement, such as platforming and eight-direction movement. Plus, users will be able to write their own, and I swear there was a mention on the ability to possibly write behaviours through events. My recommendation would be to implement Custom Movement first, since it's so versatile.

The Image Editor and animations would be a very close second, however, same with fine collisions.

Also, Ash, out of curiosity...

Are you actually gonna be taking that break anytime soon?

Fantastic. I can personally verify, using my family's iPad, that touch controls do work, and quite well.

That being said, on the same iPad, it ran rather slowly, for some reason.

[quote:177aib69]Do they have to be either string or integer?

Well, I never said it HAD to be either or, but those are the most commonly used data types. As Silent suggested, there should also be floating-point, array, hashtable, and boolean.

Anyway, I saw someone pledge $75 on Fundry for this sort of thing, but I don't think having it as a separate object would be a good idea, because it just makes it harder to have a visual editor.

One of the biggest things about the 'S' plugin which lucid made for 0.x was the fact that it allowed data structures. Variables on their own are fine and dandy, but structures that store arrays of variables, be it string, integer, boolean or other can make various tasks, especially stuff in RPGs, much easier.

There's other uses, such as save data, and storing conversation data for cutscenes, and stuff like that. That, and we need a good replacement for the Array Object.

Yes, it is early days, I am aware of that, but in the long run, data structures, especially being able to visually create a series of 2D arrays that can be used in a meaningful manner could well be extremely beneficial, and in some ways, could eliminate the need for an ini object as well.

Alright, here's how I think it should work. Say we start out with a new project, we're trying to create an RPG. We want to create a series of arrays for the player's party. In the project bar off to the left, below the Layout, Event Sheet and Objects folder, there's a folder called 'Structures', or 'Supers' or 'Tables' or whatever Ash would think would be most suitable. We right-click on that folder, and click "Add New Structure/Table/Whatever". It'll ask if you want a single 2D array, or a Structure. We'll go with the latter here.

Then, Construct sets aside a new tab, and gives a dialog much like the Instance Variables editor, where you can insert new arrays of Strings, Integers, Booleans, etc. and order them however you wish. For this example, our arrays consist of:

• Name: String
• Level: Integer
• EXP: Integer
• HP: Integer
• Attack: Integer
• Defense: Integer
• Speed: Integer
• Luck: Integer
• Weapon: String
• Armor: String
• Ailment: String

And so on and so forth.

Once you're done, the "Structure Editor" gives you an Excel-like table, which one can adjust the margins like any Excel table, and start entering in information if they so desire. In this case, we can enter in the name and stats for our game's player characters. For cutscenes, you could have an integer for which line in the conversation, a string for the actual dialogue, another string to identify the speaker and an integer which tells Construct which frame for that character's mugshot should show.

For save files, you could save every structure into a single file that the game can load when the player chooses to load a save, along with some other information if need be.

It's not the most perfect of explanations, but... Well, I cannot stress how useful something like this could be, and it could help further set Construct 2 apart from the competition, especially if it's done in a user-friendly manner. It could be used for simple arrays, as well as more complex stuff.