Ashley

Tom

Personally, i would go with a similiar subscription plan like InvisionPowerBoard is using it.

It works similiar to this:

1. You buy the product at a fixed price, which means you own it

Which includes updates for, lets say 3~6 months.

Then you will have to pay the monthly subscription (or 3 months or whatever you choose) to get updates

2. Pay the subscription to download/install/use updates

This includes fixes

This includes new features

This way, we could ultimatively decide if we want to get the latest updates or not.

And it increases Scirras income, stable and predictable.

Some people might not pay the subscription in the first place, but once some important fixes or great features have been added, i'm sure they will jump back in and pay for another month.

This could be pretty well balanced and would probably something both sides could live with.

Or of course, the unrealistic version which will probably not happen:

Get your money from somewhere else as everyone says xD

> you should have given us the bad news up front like you did, AND give some features that people can get excited about. Even one major feature.

>

We did! It runs in the browser. That's a huge feature. Maybe some people are sceptical, but it works beautifully. You can't get the feel of it from screenshots, you'll just have to wait for the public beta.

It's a huge feature as in being capable of running on different operating systems which expands as in possible sales for you guys.

That's nice to hear, really, but is it interesting for the customer as in being useful or more powerful?

Not really...

Most people are working on their games at home or in their studio.

So we use a computer which is made for developing games which is most likely a Windows OS.

The cloud is a nice addition, but until now we were able to use our own cloud also...

I understand that it must have been extremely hard to realize this, so it's probably a pretty exciting technological achievement.

But from the user standpoint, it feels.... extremely pointless?!?!?! Or maybe that's just me?

I also don't think that anyone was asking for this.

The only thing i hope is that it somehow helps with your workflow pipeline to speedup updates.

Other than that... i don't like it at all.

Because it does not really help to improve our games in any way.

If C3 is only about running on the browser and some other user interface cleanups, then i think you're going to have a big problem with your community.

Because i can't see any big exciting changes on the interface either.

So lets hope you guys got some features up your sleeve, maybe stuff we've been waiting for.

Or something else which gets us really excited. *Fingers crossed*

It's necessary somehow.

If you can't see why, then you aint got any idea how selling a product works.

How else are they going to maintain or increase the size of the team?

Tell me?

I'm really interested into your strategy to pay Scirras wages.

Please enlight me, because i can't see any common sense in your statements.

Solely selling C3 at a fixed price won't make it.

I'm sure Construct 2 reached a point where they made almost no sales anymore.

Yet they've continued to work on free updates for you, all the time.

The only way Scirra maintained some additional income was with the introduction of the store with user created content.

Going with another normal sale of C3 would be a dead end at some point.

Unless they are able to bring out C4 within just a few years, and going on with C5 ....

So they would have to release a new construct when the sales are going down.

Which holds back updates to the Construct version you're currently using (just like now when we were wating for C3)

Is that what you want?

We don't know all the details of the new subscription model just yet.

Maybe they give us the option to still use Construct 3, we just won't get any further updates.

Who the heck knows, we have to wait for their final release of all the details.

Maybe they can also lower the subscription costs at some point, we will see.

Clickteam has more than just one product to sell.

Which generates of course, more income...

And Clickteam does not have much more people employed than Scirra.

In my perspective, it's not Scirra who's greedy, but the customers who are asking for everything but who're not willing to pay for it.

It feels like you guys actually think that Scirra did not think this through.

But i guess i'm talking to a wall.

I understand that Scirra is moving towards a subscription model.

Am I happy about it? No

Is it necesary ? Yes

Scirra is working on Construct for a living.

Since their team has grown, they have to pay some more wages than before.

You guys were asking for a bigger team in the first place... what do you expect, a miracle?

A subscription based model gives them the possiblity to be able to actually predict a stable income for their entire team.

Depending on how much customers are following the subscription plan, they might be able to hire even more developers.

This is exactly what each one of you has been asking for.

And now, when Scirra finally reached that point of a bigger dev team to push Construct to the next level you're all crying out loud.

Yes, other engines/tools use a model where you have to pay once you're making money with your project.

But due the fact that Construct Customers do not create AAA titles or anything that comes close, that model would never work out.

So please, just shut the **** up, seriously.

If you're so upset about it, share it with your imaginary plush.

This is the real world.

And to the other point:

We all knew that C3 is building up on the core of C2.

Yes, no one asked for a web based editor.

But going crazy before you've even seen what they've been working on exactly is nuts.

I'm sure they have been listening to us, but that does not mean that they are going to realize every single thing we're asking for.

This is Scirra's vision, not yours.

The native situation has been discussed for years.

And you've known the answer before they have announced C3.

There's no reason to bring it back up each freaking time you get the chance to do so.

Let's wait and see what they've been working on.

And once the beta comes out, create topics with proper feedback.

Thank you

That's basically what lannaert used to reach this goal.

The problem is here that, bounce off triggers once it overlaps already.

So you actually bounce back and forth each tick...

It's not reliable when high velocity objects move towards walls.

And objects can be pushed through walls in multiplayer scenarios, when 2 players walk into each other for example.

This causes really unpredictable bugs.

I wasn't able to find an actual real solution until this date.

And the fact that Ashley and his team do not take care about further enhancements on the Multiplayer feature, i'm not sure if Construct is the place to be.

Especially not within an isometric/online multiplayer environment.

Rewinding Time:

https://www.scirra.com/tutorials/892/mu ... ge-8#h2a18

Local Input Prediction:

https://www.scirra.com/tutorials/892/mu ... ge-7#h2a15

I can only recommend reading through the entire tutorial.

But using the Rewinding Time will ensure that the HOST is able to recalculate what the player actually saw, and handle accordingly.

Just think about it in a Shooter Game like Battlefield for instance.

What would you think if you shot someone in the head, but the server didn't recognize it?

That would kill the entire fun.

With rewinding the time, the server can recalculate the actual position of where the enemy was standing from your standpoint when you triggered the shot.

Otherwise the Host will think, the enemy was already behind the wall and you shot into the void.

With local input prediction you can ensure that the players input will be immediatly shown on their screen.

Even though the server did not even get your input as of yet.

As soon as the server recieved your input, it will sync the information back to the player, and in case the prediction was wrong, it will do some small corrections to get you back in place.

Otherwise, if you only let the players move as soon as the server responded, it will feel very very laggy for the players.

For a real-time multiplayer game.

It is KEY, to send really ONLY required information.

AND the information sent must be set as SMALL AS POSSIBLE.

More details at the bottom.

What do we want to sync?

And which ones need to be fast?

- NO client side prediction for deaths

Because if we blow up a player and then realize it was mis-prediction, we would have to bring it back together.

This would look kinda weird!

Basic Information

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

High (double, 8 bytes):

a double-precision floating-point number that can store numbers without affecting their precision.

It has about 15-17 significant digits of precision. However it takes 8 bytes to store a single number,

which can end up increasing bandwidth requirements significantly.

In practice this is unlikely to be a necessary choice.

Normal (float, 4 bytes):

a single-precision floating-point number that can store fractional numbers with about 6-9

significant digits of precision. This means some numbers will be rounded to fewer significant digits.

However it is usually far more practical than a double, since it only takes half as many

bytes and digits beyond the first 6 are usually unimportant

(e.g. 0.333333 is close enough to 0.333333333333333 for practical purposes).

Low (int16, 2 bytes):

a signed 16-bit integer that can only store whole numbers in the range -32768 to 32767.

Very low (uint8, 1 byte):

an unsigned 8-bit integer that can only store whole numbers in the range 0 to 255.

To minimise bandwidth, it is important to choose the lowest precision possible that will

not seriously affect gameplay. For example X and Y positions can often use low (int16) precision.

As long as the layout is smaller than 32767x32767 (which is very large), and sub-pixel positions

are not important to gameplay (since this will round off any fractional value), it is perfectly

sufficient and uses four times less bandwidth than a double.

For example:

If your total of all synced data is 32bytes:

2 players = 32 x 2 x 2 = 128 bytes per update x tickrate 60 = 0,06 Mb/s (Required Upload Rate of Host)

4 players = 32 x 4 x 4 = 512 bytes per update x tickrate 60 = 0.25 Mb/s (Required Upload Rate of Host)

Even though the player count increases linearly, the bandwidth requirement increases proportional

to the square.

It depends on what you're willing to achieve.

For a turn-based online game, having a high latency wouldn't be an issue at all.

For fast paced action it's important to keep synced information as slim as possible.

In the end, peer to peer can be a good choice, depending on design of your game.

I've done several local-tests, and never had any real lag issues.

It's important that you don't make any mistakes with trying to sync information which you've not properly set.

Doing so can cause major lag problems. It will look as if the "internet connection" is terrible.

For a 1vs1 fighter game it would be important to create a proper Host-Side check which calculates "back in time" where exactly the player was staying at the time he punched. That way you can prevent issues that the player sees what actually happens. Otherwise the player might punch the opponent, the host however thinks that the opponent was too far away, with that does not count the hit.

Ashley made some good examples in your examples folder of construct 2. You should also checkout his official tutorials.

If you tech yourself the multiplayer features, i think you should be able to get it done right.

But i can only recommend to read the tutorials entirely through.

Alternatives are not easy and require more knowlegde.

Construct 2 does not offer a Dedicated Host feature. So peer to peer is the only official solution available.

Unless you use a workaround by running the game as HOST on a dedicated server and leave it nonstop running/online.

Sony and Microsoft are heading more and more towards Indie Devs.

Since Construct2 is a great tool for designers (without programming skills), i think it's a great opportunity for Microsoft to get their hands on some very unique Indie Games.

And of course for us, to reach out to a much broader and great audience!

I would love to have access to:

Online Multiplayer

Achievements

Cloud Saving

I'm also working on a bigger project using it. I hope it's still in C3 as it will take some years to finish it.

And no problem, i'm happy that i was able to help.

Installed a SSL certificate but for some reason i can't connect.

I will just leave the current running signalling server online.

It seems a few people are using it already, so i guess it's enough for now

Someone just connected.

And omg sorry i posted the wrong IP xD i forgot 2 digits

corrected it now!

But i'm setting up a SSL certificate right now, i will keep you posted.

tonypond

It works for me, just tested it.

Did you enter the correct IP?

The problem might be that i'm not using SSL

It states:

// SSL configuration. Use of SSL is strongly recommended. Due to some firewalls, routers or

// NAT devices in use on the Internet, insecure WebSocket connections may not be able to connect

// where a secure WebSocket connection can. Encryption prevents buggy packet-inspecting

// middleboxes from meddling with the traffic on the assumption port 80 is HTTP web traffic.

and

Choosing a

// non-standard port may cause some firewalls, routers or NAT devices to block the connection.

The problem is that i can't offer you any of it.

Because i'm running other services on this server which would interfere and i don't have a SSL certificate

Letme check, maybe i can get a SSL certificate.

I'm on it.