I develop platformer stuff with the multiplayer plugin and in my experience, I have a blast with it.

Whilst I appreciate the development that Ashley did for the code included in the Multiplayer plugin, I don't use any of the built in sync stuff. I strictly send messages back and forth between players and have tried different experiments in the past to see how different implementations of lag compensation feel. I'm not really well versed with the standards of lag compensation, I understand things like dead-reckoning, but currently don't comprehend systems such as rollback. I feel that I have more control when I don't use built-in "one size fits all" stuff, to allow me to fine tune when I want to send a message about the players state/input/etc.

Don't trust my decision though, I may have missed out on an even better experience by not using the built-in sync stuff!

The main bad things I experienced (strictly speaking from my experience) were: my games become CPU bound due to me making my own platformer engines (To give me the freedom to add more complex stuff such as half-pipe slopes/Sonic-esque wall&ceiling running), I mean I optimised my events as best I can but having more than 2 or 3 players can strain the framerate. On top of that, having all the other gameplay elements to interact with (what good is a game if your just running around and jumping with no actions or hazards). I mention this because, oddly enough, disabling the multiplayer events and having the players exist as local players on controllers didn't destroy the framerate as bad, so maybe my online implementation wasn't that great, but certainly felt good for two players! I wonder how it would pan out if someone tried it with the platformer behaviour.

The other bad thing with my design was pings higher than about 70-80ms, which isn't too great; the game was functional but it didn't feel fair with things such as "Your opponent is 100 pixels behind you but still hit you!" kind of situations. (probably my failed lag compensation events, gimmie a break, I was only experimenting! )

It sure as hell wasn't perfect, but it was functional, playable with the right ping, and I was happy with it, and I will continue to try to exploit all the potential out of this plugin in the future. Then again, what online games are perfect? Even in tightly designed online games, there's always moments of chaos where something feels unfair or unexpected, but that is usually caused by lag. I guess the solution to this could be to design your game to make sure to lock people into connecting with other players in a similar geographical location, or make your game only online with friends

(not sure about this due to never looking into this with the Multiplayer plugin yet, considering you need to find a game in the signalling server)

, then that can solve that problem!

Networking is a fun concept to me, figuring out how to send data as lightly as possible, the whole ping/lag/latency/packet loss stuff and how/why it happens, it's all so interesting. It's Just as interesting as optimising the heck out of events, it's oddly satisfying to get things working really efficiently. But I could safely say, if I didn't have an interest networking and only knew the fundamentals like what an IP address is and what a server is, then I would most likely not touch Multiplayer in game development (and if I did, I know sure as hell I'd get frustrated fast, even if I had examples and guides laid out in front of me. Conceptualising how online synchronisation works can be incredibly confusing and stressful). I hope some of you guys develop an interest in the area. If you love it, it will feel less stressful to figure out in game development and more like "Ohhh how weird, lets figure out how that works. Ohh I seee, but then how does... woah... Internet u so crazy".

...or give me 2147483647 pounds and ill do a third of the events 4 u

...that latest blog post certainly took me by surprise!

I've been watching the whole Construct 3 announcement from the very beginning, and I remember being so pumped to see the first blog post that gave the first piece of information about C3, which was... insanely underwhelming. Upon reading it, I had a sinking feeling and felt demotivated, and predicted a lot of people aren't going to like this. (Also I was mostly worried about lack of offline support but that got clarified quickly).

I continued watching, reading each and every blog post, and I didn't really feel affected by what was announced, although I did find some stuff interesting such as putting C3 on mobile, but it didn't make me feel inclined to subscribe to C3.

Upon the beta release, I checked it out, thought "ah...c2 in a browser..." and thought this is game over for me now; blog posts are done, beta is out, this is it... No new fancy graphics stuff, no performance enhancements, no intricate control over things to lower CPU/GPU/RAM usage, etc.... ok... I figured C2 would eventually get phased out, so may as well move on from this editor that I've grown exceedingly comfortable with.

Then KAPOW, checked out the forums during lunchtime, saw someone mention a blog post, read the blog post...

https://www.scirra.com/blog/204/the-future-of-the-construct-3-runtime

A rewrite of the runtime? Admitting the runtime may have some issues/performance issues due to compatibility code and pressured workload as Scirra was only starting out as a business when writing the runtime (very respectable to include this in your blog post)?Mentioning optimisation and lowering memory usage, etc? Hot damn. This is definitely worth the money from me now, even if I'm only a hobbyist. This feels like a professional route to take, offering optimisation and capabilities that were only possible for Scirra to implement and users were unable to do. (I hope I haven't misinterpreted the blog post at all, correct me if I'm wrong at all! )

I don't post much at all and haven't shown evidence for this, but in my experience, I'm definitely bounded by CPU issues and I'm strictly developing for Windows. Having multiple particles, or lots of platformer enemies onscreen, it racks up fast. Perhaps over the years, I should have been more vocal about my CPU issues, but this blog post signifies that this issue can change, at least improve substantially. Games could be able to be big and grand.

Ashley , If this is the route you are taking, I'd love for you to take this opportunity before you begin getting too deep into developing the runtime, to ask the forum/paid users/professional users/random homeless person from London/forum section for subscribers, for their opinions/ideas that they feel would aid them in creating a large or 'busy' game (Busy, as in, lots of stuff going on onscreen). I have a handful of suggestions I'm eager to share, probably stuff that has been mentioned in the past, but I don't want this post to be another bombardment of seemingly random suggestions. Perhaps peoples suggestions would be unfeasible, or impossible within HTML5, or perhaps it will enlighten you on what people have discovered when making a large/busy game, but I felt if I had certain things in Construct, I could go above and beyond in development with your software.

I feel much more willing to subscribe and support the company, almost certain about the 1st year, even though this is only a blog post that isn't promising anything, but it does come across as eager and passionate; like saying "No" to Canvas2D and pushing WebGL to be the standard, to be able to provide much more graphical stuff for us. I hope I remain in this mindset on the official release!

You guys seriously done this whole process backwards! Start with this blog post, then tell us the other features, end with the browser-based + subscription blog post. I would have had a consistent stream of excitement if so and would have only queried offline support right at the end!

p.s. the multiplayer plugin is awesome, I used it a lot and will continue to use it when I get back in the grind of development.

NotionGames

Yeah... Some things have workarounds, like using VM's or WINE to run Construct 2 in Mac/Linux, but certain things don't have a workaround, such as this WiiU Export issue. You hit a dead end and there's no solution or workaround. Makes me wonder why time and resources were focused on doing things browser-based for Mac/Linux support when there was already a workaround for doing that, when there's loyal serious developers that would throw all their money at Scirra raising the concern that their export runs poorly and is hindering them. (Correct me if I'm wrong, as i have not used Mac/Linux, just going from memory here.)

Perhaps spending years to have C3 be browser-based may not be strictly for multiple operating system support; I believe there are things such the new Array editor that may not have been able to be developed in C2's environment... but couldn't that have had a workaround? Have a tiny EXE that is a small lil array editor within C2's directory that you can run from C2 by clicking the "Array editor" button or something, which then hooks onto C2? I don't know the logistics of software development that well, I could be completely wrong here.

On a more personal level, NotionGames, it's commendable that you are here voicing your concerns, especially in your position (Anyone else reading this that have been vocalising their opinions lightly or strongly, it's great! It's great to get everyone's opinion and learn what everyone is here for, even the frequent opinion of "can we have native exports".). I have mostly taken the back seat and observed, I've stopped developing in C2 due to a fear of a random unexpected direction that Scirra may/may not take, heck I've stopped developing completely and it sucks, although I'm only a hobbyist. But your thread has taken off, seeing it suddenly appear on the forum with so many pages really shows you have made an impact and created a lot of discussion, hence why I've crawled out from under the shadows once again to comment. Perhaps the sudden surge of discussion is due to your position, or it's the way you've written your posts, but either way, keep on keeping on, you speak for more people than you may realise.

Such a shame to see all this chaos on the forums nowadays. I've lurked the forums every single day for years now (Not often logging in or posting), and it went from being generally quiet with a few odd users now and then, to frequent heated discussions/arguments amongst long-time users. I see people convert from being very supportive, then a blog post or the beta is released, and they switch, etc.

In my opinion, to see that Construct 3 was quite literally an editor change is a shame, although it was told to us for a long time, but this thread shows why remaking the editor may have not been the best thing to spend years on. (tho it is impressive technologically!) It's not a terrible thing to have done, it's great for Mac and Linux users, and heck I'd love to be able to switch to Linux before Windows 7 is no longer supported and I bet a fair amount of people share that thought, but this is what we were waiting all this time for? Other things could have been focused on that seem to be highlighted frequently on the forums... Iuno...

It could all change though, right? I mean, once the majority of editor bugs are gone, what would be the next thing for Scirra to develop in Construct 3, especially after the uproar on the forums? There are genuine concerns being raised and they can't seriously be ignored or shutdown with a statement about technology, HTML5, 3rd party issues, etc. I think a solid road map would be brilliant, to know exactly what direction Construct 3 will go, and for us to make the decision if we want to be part of that journey.

Bleh, I wish Construct 3 was discussed publicly much much earlier, even if it was just a tiny bit.

Try setting the "Active at start" property of "Sine" to "No".

And in your events, do this event:

+On fade-in finished

-Set Active (Sine)" Yes.

Oh, and when the fade-out time comes; however you have programmed it to fade-out, just throw in another action to turn the Sine off.

Let me know if this works!

MadSpy oh whoops, thanks! I only skimmed the Bugs and Closed Bugs section briefly hah

Problem Description

Open Capx, notice there's two layers with one layer having a sprite on it. Delete that layer (Layer 1), then save. Then create a new layer, then save. You will get a Construct 2 Error message.

---------------------------

Construct 2 Check failure

---------------------------

Check failure! This is probably a bug:

Layers indexed incorrectly

Condition: (*l)->GetIndex() == expected_index

File: Projects\Layout.cpp

Line: 1547

Function: void __cdecl Layout::VerifyLooksOK(void) const

Build: release 230 (64-bit) checked

Component: Construct 2 IDE

(Last Win32 error: 0)

You are using a 'checked' release of Construct 2, intended for testing, which causes certain errors to be reported this way. Hit Ctrl+C to copy this messagebox - it's useful information for the developers, so please include it with any bug reports! Click 'Abort' to quit (unsaved data will be lost!),'Retry' to turn off messages for this session and continue, or 'Ignore' to continue normally.

---------------------------

Abort Retry Ignore

---------------------------

Attach a Capx

https://dl.dropboxusercontent.com/u/776 ... layer.capx

Description of Capx

Has two layers, with "Layer 1" with a sprite on it.

Steps to Reproduce Bug

• Open Capx, notice there's two layers with one layer having a sprite on it.
• Delete Layer 1.
• Save.
• Create a new layer, no need to do anything else, just create new layer.
• Save. You will get a the above error message.

Observed Result

Crash!

Expected Result

Not to crash!

Affected Browsers

N/A

Operating System and Service Pack

Windows 7 64-bit

Construct 2 Version ID

R230

Just to ask, regarding all of your curved tiles:

Do you use a collision polygon with multiple points?

How many points are on a curve usually?

Roughly how many tiles are in the level that have these curved tiles?

Yeah just to chime in, I also get this. Sometimes it eats up my RAM to a point that windows gets angry and starts giving me a message to close things before the RAM is filled up. Can be about 10-20 NW.JS instances in task manager.

Ashley

Perfect! Working in the beta2. Thank you, much appreciated!

I can really understand your frustration, it's hard to get a point across when you are standing on your own, as nobody else really cares about filesize on NW.JS. It sort of seems as though you may need to give a reason why you think that information should be provided, I mean I'm sure there's certain cases, maybe someone might want to distribute to an area where they have extremely limited bandwidth or something extreme and specific. Although it might be a bad idea to explain your own personal reason because it might become a backwards and forwards conversation with people that go "Well why not do this instead?" "No I can't do that" "Well what about this?", even if you know 100% that filesize matters in your situation. Maybe it's a tricky thing for Scirra to decide what information to put out because they will always miss something, maybe in the future a similar situation is going to occur where someone buys the software and realises something specific about one of the full versions features (can't think of a random example but I hope I make sense).

Although one things for sure, it'd help a lot to have the free version give a limited export option. At least you can then retrieve all the information you want, knowing that when you buy the full version, the watermark goes and time limits go and everything is exactly as you'd expect.

I think the filesize stuff may have been forgotten about and not mentioned in any FAQ because as Ashley said, it's such a rare thing for people wanting to export to desktop ask wonder about, and yeah perhaps Scirra may have just never thought about adding it until now. On mobile, that gets asked a lot because of the limitations some stores have that limit the maximum size to like 50MB sometimes, whereas other places such as Steam, or even physical media such as a DVD, as far as I know, the filesize limits are waaaay higher. You are probably the first person to ask about .EXE filesizes.

I do agree with the whole extremely limited testing with NW.JS.

This also does get me thinking of a probably really bad idea, what if Scirra developed a sort of export where it expects the end-user to have a browser installed, and this export contains the runtime and media of your game as well as a .exe file, which upon opening, it does whatever C2 does to commence "Preview-On-Wifi" (ofcourse only locally because you can't expect the end-user to handle all the port forwarding and firewall stuff that needs to be configured), and then it automatically opens up a link on the Browser and plays. Personally I don't know if I would use this as I prefer what NW.JS provides, but at least the filesize would drop immensely. Hmmmmm...