the built-in multiplayer features are host/peer, not client/server. For a trading game, you want a server you control to act as The Authority to control/allow/disallow exchanges and transactions. It's still doable, but it means you cannot rely on the built-in "easy" functionalities and you'll have to do some of the "hard" work yourself

Just a quick contribution - going back to the initial post, the problem seems to be about managing states and building a sequene of events i.e. logic blocks ; it sounds to be a perfect fit for a finite state machine. Building the logic as a FSM will make it easier to isolate each logic block, author transition logic, and manage state if you need to add/remove some

[quote:12rd9mxu]when you can get something more stable, and even free out there

I honestly wonder what you are referring to, because atm nothing beats C2 in terms of productivity for 2D games, assuming the project falls into the scope of what C2 can do obviously ; and that's coming from someone who has used custom in-house engines for mobile, console and PC games, bigger tools (Unity) and similar competitive frameworks (Torque2D, etc.)

Most of the major issues with C2 are coming from misunderstanding or misuses of the product.

[quote:12rd9mxu]C3 will be awesome, if they listen to their customers

The customers have conflicting requirements ; one wants 3D, the other wants native exporters, another one wants scripting, and so on. If people want more flexibility, they should use an existing framework, not a content integration toolset. But obviously the more complete and flexible, the more difficult it becomes to use. I don't think the Construct community is ready for that, given the amount of typical pitfalls hobbyist developers are reporting on these forums (performance killers, memory hogs, etc.)

Personally I just want C2/C3 to improve in what it does best : 2D games, nothing else. There already are products for other types of applications.

Have you measured how much bandwidth you are using at the moment ?

Have you disabled all the behaviours on the peers to ensure local simulation doesn't conflict with the host updates ?

If the app is pointless but the design/framework is interesting and well-designed, you can try to sell them as templates for others to reuse

they should [...] be [...] trying to determine whether their products do indeed have bugs without placing a lot of that burden on customers to create these example projects and reports.

Depending on the size of the user base, this is usually unrealistic, unfortunately, even for very large companies.

When a bug is suspected, it is part of the job of the user to demonstrate what the bug is, and therefore narrow things down in order to demonstrate the problem for someone more technical to investigate the issue efficiently. Support teams or communities can help guide the investigation, but in the end a proper bug report that actually demonstrates the bug in the simplest possible scenario has to be submitted.

That's what QA teams do internally in game studios, they try to understand as much as possible about a possible bug (esp. how to trigger it) before demonstrating the problem to the most relevant programmer. And that's exactly how it happens when dealing with big companies as well, like Microsoft, Sony, Nvidia, Apple, etc. When you find what you suspect might be a bug in the latest xbox sdk or a recent nvidia driver update, which does happen on a very regular basis btw, you don't send your whole project asking for someone to investigate. You recreate a simpler project to isolate the bug and send a test case for review.

The user knows its projects, he's the only one to know what to remove and what to keep to reproduce the bug ; if he doesn't, the user doesn't know enough about its own project. When it takes a few hours or days for the user to recreate the bug in a simpler project, it would take weeks or months for any external developer or support team to start to understand what a decent size project is all about. If the suspected bug is about sprite animation, you don't want the support team to thrall through dozens of thousands of events or lines of code that have nothing to do with sprite animation (controls, audio, effects, levels, physics, etc.). If, for example, a sprite doesn't animate as expected when some specific physics properties are applied to it, that's what the bug report should be about, not "something doesn't work in my project" (just exaggerating but I'm sure Ashley must receive quite a lot of similar complains)

The main "problem" with C2 is that it's almost too easy and/or flexible to use, therefore it is possible for people with very limited technical knowledge to create quite complex things. Which is great - nevertheless, it also means that a very large majority of the "suspected bugs" are just misuses of the product

Have you tried measuring the size after export, to include the wrappers and possible optimisations (resource packing with atlases and sprite sheets, etc.) ?

I'm not really answering your questions, but maybe this would be a useful quantification as well

I'd go with the same approach ; it's always a safe bet, at least at first before you start profiling a finished level and identify actual bottlenecks.

Also, there's always a trade off between memory and cpu usage, granularity and batching. Usually going with a large texture atlas helps with batching, and using small elements helps with scene management (culling, etc.)

To be honest, if you can afford a Nintendo developer license to deploy to Wii U, you can afford a license for C2 or whatever tool you use to create your game.

My bad, I didn't see that blog entry ! Thanks

Hi -

I don't think anything official has been said, but I wouldn't assume upgrading to C3 would be free (actually I would assume the opposite). Though owners of C2 might benefit from discounts to encourage people to buy the new version.

In the absence of a release date, I wouldn't wait. If you keep waiting, you never buy anything.