>Oh, and you don't need to worry about people's directx9 being up to date.

This is a huge reason for C2 as most folks (especially casual gamers) might not have the right version of Directx. And new systems with DirectX 11 still require that users download the older DirectX libraries. So your 5 MB game just turned into a 90MB game!! :-)

I still like all the power of CC as well, even with the quirks. I'll probably start building with C2 once it reaches CC's functionality but I'll probably jump on the early adopter license.

Hey SOL..

To answer your questions:

1. Sending x,y angle, UID, and name every game tick is fine for a LAN game. Other than that, it causes too much network traffic for internet clients that don't support lots of bandwidth. There are a couple of solutions:

a. Send updates less often and then use a lerp to smooth movement. I show a simple example of this (lerp) in the netshooter .cap. Either way, over the internet with more than a couple clients..definitely need to send data less often. Valve's engines send updates every 3-4 frames and interpolate (lerp) to smooth the difference.

b. Use the RoundTripTime expression combined with player's speed/angle to "predict" their path/location. For example, send a packet that says "player 1 pressed the up arrow at angle X w/ velocity Y". Knowing that you can predict how fast he will be traveling and path is will take without ever getting new updates (i.e. if you know the player is traveling in a straight line then it makes no sense to send updates every tick for a path along that line). Having the RoundTripTime you will know what the lag is and can compensate (took 100 ms for packet to get to you so player is already moved further along that initially. If the remote peer takes their hand off of the up button then you immediately get that message and can predict based again on lag where the player stopped. Every few ticks the server can send the TRUTH out to everybody and everyone will get synchronized again. CAUTION: prediction does have it's shortfalls with games where movement can change rapidly so you have to send out the truth synchronization more frequently

c. Combine sends together vs sending lots of little ones out at a time..not sure if this applies in your case. However, try not to let your packets get bigger than MTU (1500 bytes).

d. Reduce the size of the packets through serialization. * This is not implemented in the plugin currently so I should be able to reduce bandwidth consumption by about 25% or so. Only problem with this method is that the way network data is constructed must change. Instead of being able to do a: playernum & : & angle &... I would have to define parameters that you would add like: param1 = int with playernum....kinda like the function object. This is a massive change to the plugin and I probably would fork the source and build up a new version.

2. Laggyness building over time. I'm not sure if it is a memory leak in the plugin as the core library ENET supports games with hundreds of players. Here is my guess with what is happening...you are sending out packets every tick..at first clients are able to handle things ok, but after a while packets start stacking up, ENET's automatic load handling takes over and starts dropping unrealiable packets (your x,y position packets) to help guarantee the reliable ones make it through. The more packets stack up the more that ENET will drop to maintain bandwidth levels.

Try doing an experiment and only send data once every 5 game ticks. See if the laggyness increases the same over time.

Hey SOL, can you post or PM me a .cap that shows the problem? The example you showed seems odd since one of them has nothing to do with Network data..it is just a global variable kept local to the client. Also highlight the difference between which server events and client events are different.

One of the challenges with a network plugin is that we are piecing together all of these code parts and some might not be meant to use together (as I've written it now). Sounds like I have a few bugs to workout. :-)

This caught me by surprise...trying to decide now if I should enter. <img src="smileys/smiley24.gif" border="0" align="middle" />

Hey Jayjay,

Can you post or PM me a simple .cap that will trigger crashes? Or a step 1-3 that will duplicate crash. I'll take a look at it his weekend and see what might be a good solution.   <img src="smileys/smiley1.gif" border="0" align="middle" />

hmmm... just noticed this thread.

I got 15.19 Mb/s down and 5.14 Mb/s up.

Its a funny stereotype, but only halfway true nowdays. I work with programmers who range from your typical jock look and bodybuilders (no kidding) to really super geeky anti-social types. Most are in the middle somewhere.

OR like this: Host server and connect to it in 1 app(use 1 app to server and client in the same time) and other client will connect to server? What about this methods?

I think I should be able to implement this method, but it will require quite a bit of update to the Plugin code. It's not a major change, just a change that is in every part of the plugin. I think it is a good idea since lots of casual players will not want to have an extra app just to play a two player game. It on my TODO for version 0.4. :-)

Soldjahboy. Thanks!! :-) Let me know as you spend more time with the plugin how it goes. It was exciting to see Jayjay make a short game with it so hopefully others follow suit.

On the bug you mentioned...I have too experience a very, very hard to duplicate bug where one player is able to connect even though the other hasn't yet. I can never reduplicate though until maybe a week later. I believe it is tied to messages being used for Player tracking vs being built into the plugin.

Both the host/client update and player tracking are pretty time intensive so not sure how long until I get to that...I'm technically still on my "break" from this plugin. ;-)

Has anybody else experienced bugs with player tracking??

ldmn   Today's standard programming languages would be more time consuming for >>sure, but perhaps Construct needs almost the same quantity of efforts if it >>has born so few games.

It impossible to say how much Construct speeds things up because there are so many variables. I can speak from experience in that I entered a Ludumdare competition a few years ago and made a game in Python/Pygame. I spent about 15 hours coding a game. The result is something I have since made in Construct (not the same game but something similar) in about 4 hours. This was a simple game and I had roughly equal skill in regards to Python and Construct.

I'm more of a tinkerer of technology myself and always fascinated with latest music algorithm or socket library which is probably why I haven't made more of a full game....other people's reasons will vary.

I have always wondered why we haven't seen more finished polished games but the obvious answers are money (if Construct Classic had been commercial then they could have advertised like crazy, hired more developers/testers, made all sorts of accessible tuts and videos,fancy website, paid game competitions, etc) and time (CC is very young and only recently in the past year has added more features like better Python support, networking, better bug fixes, etc). I think most people were waiting until 1.0 to make that big game... Now they can since 1.0 isn't coming and there is just CC.

I wonder if I sponsored a 2 month, $5000 game challenge if a cool game would result. Not saying I would or anything...maybe a $100 buck challenge <img src="smileys/smiley2.gif" border="0" align="middle" />

I would add to scidave's point that bugs in C2 are handled even quicker than CC's as Ashley is actively coding and scruting the forum, especially the bugs report section.

This is a good point about bugs...if you have a bug with CC (especially something complex) odds are it wont be fixed or will be fixed very late. If you start working with C2 your bugs will probably be fixed by the next build.

On final point is that CC is pretty much limited to teams w/ 1 developer. You can get by with another but collaboration is difficult (can't copy and paste easily from .cap to .cap unless you use Python ). C2 will eventually support easy collaboration for teams of developers.

Hi WAC..welcome to the forums. Your question is similar to what has been asked before on pros cons of either tool.

It really depends on if you want to make a complete game NOW. If you want that use Construct Classic. If not, then I would still say use Construct Classic. What you learn will port over well to the event system for Construct 2.

On bugs...I think the consensus is that you can make a big/complex game with Construct Classic just fine. It just takes some skill to work around the bugs. When I get more free time I may pick up fixing bugs, but right now I'm more looking at Plugin dev and game building. But still there are several here that will continue to support Classic in some way. On DirectX I'd say she should just get over it or you have an easy choice to use Construct 2 now.

Finally, I think HTML5 is the wave of the future as well and will just grow more and more powerful as time goes by. For example the game Far7 is freaking awesome and doesn't look like a flash game:

https://gaming.mozillalabs.com/games/133/far-7

So Construct 2 when finished is going to be pretty darn awesome.

Happy Constructing!!

Notsu - Thanks!

Based on Jayjay's and some other feedback. Fixed two bugs.

1. Now you can send any characters in chat messages.

2. Instead of the client closing when it can't connect to the server..instead condition "On connect failed" is triggered.

Enjoy!

http://www.box.net/shared/lbgncqnaufixv3umfyj1