The problem I ran into with regenerating the obstacle map is that it is not optimized for moving objects. So it chugs through everything, even objects that have been in the same place forever, and it causes a little pause in your game that's noticeable.

However, placing such objects outside of the layout may just work like Arima said. It's worth a shot.

The only real issue I see even with using a properly optimized obstacle map is that your enemies will consistently move in odd directions to avoid each other while moving, or not move at all.

So you would need to make them move only a bit at a time.

For instance, say you have two enemies, one behind another in a back alley, with only room wide enough for one enemy.

If they both use pathfinding to get to the player, both set to avoid colliding with other enemies, the one closest to the player will continue to move towards the player as expected, however, the one behind the enemy is now blocked from access to his destination, and will not move.

It's extremely tricky in C2. I had to abandon one project for now because I simply don't have the experience in pathfinding enough to overcome these obstacles, and because the pathfinding plugin isn't quite up to par when you have any dynamic obstacles.

[TUBE]http://www.youtube.com/watch?v=72wbcdXSB3A[/TUBE]

This is the current state of my game "Tic-Toe-Tac" I have been working on. :)

This was an amazing help, thank you!

I've also had odd crashes but and the latest did in fact happen to occur right after an accidental undo.

I redid the action, alt-tabbed, and when I went to get back to C2, it stopped responding.

I'm wondering if it could be an auto-save issue when undoing? I have mine set to every 5 or 10 minutes, and it was just about due.

I know whatwith multiplayer and all, you guys have been busy, but Ashley and Tom, any possible ETA? 1st quarter? 2nd? 3rd? This year?

I'm really looking forward to the next gen of your arcade. :)

I did note the compression schemes. Tiled has an option to use uncompressed XML, which I was considering, but it takes up more data than it needs to, hence why I said it was taking up relatively more space than their JSON export.

There is a tutorial explaining how to import Tiled's TMX XML maps at runtime, and I am hoping to get down one type of file. XML would work for now, I just can't think of how to get started.

However, I do need to do all this without preloading anything through the editor.

What I want to do is be able to load TMX files and/or the JSON files generated by the map editor Tiled into C2.

However, I need this to be done by loading from my website.

I'm a bit confused by the process, and information regarding loading tilemaps is incredibly vague, let alone on how the current JSON importer works with the tilemap plugin. I saw mention but once about loading TMX files into C2, but there was no mention of whether or not this could be done during, say, gameplay.

What would be even better is if I could load the JSON files generated by the Tiled exporter, as the file size is cut to about a quarter of the TMX size.

Is there any native functionality of C2 to load these files? If not, how would I go about loading and parsing the JSON files created by Tiled? It seems pretty straightforward, but I have little experience writing parsers.

I found a few other tutorials with similar content, and one for parsing the XML of Tiled's TMX file, but nothing about handling JSON.

Can anyone help?

Yeah I've had this issue since forever. However, it does work. There is a portion of the box that is clickable if you move the cursor around it.

So I think there is another object overlapping the box. :P

Could be worse on different resolutions though. Mine is like 1376x720 or so. Can't remember that exact number.

*coughbumpcough*

Maybe a Christmas gift for all us C2 fans?

Bringing this back up, it appears that Socket.IO flat out refuses anything Construct 2 can throw at it.

I've made the most simplistic server I could possibly manage, even disabling the retarded "destroy upgrade:"

<font color=black>var io = require('socket.io').listen(8000);

io.configure(function(){io.disable('destroy upgrade'); console.log('configured');});

io.sockets.on('connection', function (ioC) {

     console.log('connection opened');

});</font>

This successfully starts the server, and the string "configured" is logged as expected. However, no connection is made. At all.

I've taken a look at dozens of user snippets and there are no diversions from other code. It's just boggling my mind.

With my client I can connect perfectly fine to the WS module server I set up, sending packets like mad, but Socket.IO just fails.

Any help? Suggestions? I feel only like I've wasted two hours trying to get it to work, with 0 results.

Index, Ashley

Edit: I started typing before Tulamide's post. XD So this is a little redundant, but still fits the point I was trying to make, heh.

---

If you don't mind, I'll break down your response. :)

DatapawWolf - And I rebuke! ;) So far multiplayer requires coding to some degree. The fact that 'not everyone can do it' is against the mission statement of Scirra and excludes the bulk of their users.True, but what I'm trying to say is that right now multiplayer is adequate to satisfy those serious enough in pursuing multiplayer games.

I think part of the opposing sides in this are that there is both a little bit of modularity and a little bit of multiplayer, and both are important facets of Construct 2 and most other game development tools.

So I can't speak for others, but I myself would find more use for modularity than any more multiplayer features.

If you don't mind dealing with websockets you won't mind using Unity, so why use Construct?onestly Unity is many more times complicated than Construct 2. Every version update they make breaks things, including any of the tutorias and examples my Game Design Club leader had put together a year or two back, and even Unity's own tutorials, as we discovered a ton of them disappeared from their website. It's also not designed for 2D games, which is a personal desire of mine, and isn't really cross-browser. So, I'd much rather I can spend about 2 minutes setting up the client to connect and send a message to a server, and using Construct 2.

Maybe the server is a pain to make, but creating a multiplayer client is a breeze.

There is no argument that modularity would be awesome, but as long as a massive feature like multiplayer is still absent from events, it needs to take second place.assive, hence developing it will take away from all that time that could be spent developing and building the community around a modular system, and slowly accomodating multiplayer, rather than vice-versa.

Everyone wants to make multiplayer games, and currently they can't. Not many people want to collaborate, but they can. So modularity is clearly a second place here, although a massively important second place.)Tobye I'd argue against that. WebSockets right now allow the majority of multiplayer to be implemented. While it's not an "everyone can do it" kind of deal, it's not no one can, it's just that there are next to no resources and little (but not no) help on how to start a server with, say, Nodejs and create a connection between it and a Construct 2 client. With a little effort I've managed to at least create a server that sent messages to the client which sent messages back. It's incredibly rudimentary, but the system is available, just that few people seem to be posting their results and actively experimenting (and honestly I'm guilty as well).

(Just no one pull that "WebSockets" aren't adequate for a real-time game" crap, I'm currently volunteering for an HTML5 Nodejs game that is using them for just that. Maybe not be the best for large-scale MMORPGs, but it does work for real-time.)

In my opinion, modularity should be before multiplayer, and then maybe more users could put forth the work into community multiplayer efforts; that multiplayer will benefit far more from modularity if modularity is implemented first.