Online plugin-Updates

Hey. That wouldn't be fair. I'm a constant lurker. I just don't like posting often. But I'm always here.

Eeek, this has quite a few problems that need to be worked out. I mean suppose someone gets the go ahead to be able to use a server, then that person releases a cap file.....

...uhm, sorry if i read this wrong but youre basically suggesting to have a single server and a closed-source plugin? not let people setup their own servers? wouldent that be against construct principles?

Ashley's stated that he wants plugins to be licensed by the individual creator.

They can be open, closed, sold even, as a separate entity.

People might be getting a bit carried away with this plugin and the thread is starting to derail again.

There is an obvious demand for an online plugin. Ideally this should support client/server as well as P2P connections, as well as everything else you can think of.

How developers use this object when it's made is irrelevant! How about we actually get it made first? Then, if someone wants to run a free server, let them. If someone wants to offer a paid server let them. The point im trying to make is that the use of the object is irrelevant to us, (note the word 'use').

It's not though. Most people here want the object based on it being easy to use immediately, not having to jump through hoops to set up or pay for a server.

Obviously there's no need to get carried away finding one now as the object doesn't exist, but it's something to consider that if so many people here seem to want one, how many would use it with no server available?

It's the sort of thing probably best worried about after the object is made though?

About a hundred hours work for a very underused feature sounds like a waste; practical considerations seem like a good idea.

In pretty much every game creation system that has online functions, the GAME is the server.

That is, one player presses "Create", notes the IP, other people join.

A game lobby is often set up by the developers, and that would require a dedicated server, but that would be the worry of the developer of that game, not Scirra. All we need is a plugin that lets you send TCP/IP messages. Something easier and sleeker that might need a server of its own might be introduced later, but right now that's all we need.

i seriously doubt an online plugin would go underused. in PC games, local multiplayer isn't popular or ideal -- barely anybody has multiple gamepads for their PC and it's no fun having 4 people huddle around a keyboard. for multiplayer PC games, online connectivity is a necessity. almost any multiplayer game will use it. the project i'm working on now is intended to have online multiplayer down the line (and if it is to become a popular game on PC, it basically requires it, as it's a multiplayer-focused game). someone else was making an online space game. there are already people lined up to use it -- the ability to make online games will draw even more users interested in making multiplayer PC games.

all that'd be expected of the online plugin creator would be simple TCP/IP connection where you can type in the IP of a game you want to join. after that, it could be expanded to support a master server and he could code an example master server in something as simple as ASP (and update the plugin to let the games talk to that master server -- just let us spefiy IP/port of that master server). master servers don't handle game logic -- they simply keep track of a list of game servers (name, ip, number of players, etc). let the gamedevs find a way to host that master server for their game(s) (i'd probably just host it on my home fios connection).

Whilst the subject of servers and online use is obviously important, and it doesn't hurt to discuss it at great length during it's production, my thoughts are on the usage of the object in Construct.

With MMF2's plugin, and obviously with any online code written in any language, the game designer has to decide how often packets are sent, and then write the code to implement this.

What I was wondering was whether the online plugin for construct would allow the user to assign specific conditions to specific objects, and then the plugin would deal with the sending of information.

To clarify, you have 2 cars ("carA" and "carB"), one controlled by you, and the other controlled by a person elsewhere.

Now, as anyone who's coded online apps before will know, you can't just constantly send a stream of data for the postions of the cars, as this will just bring your app to a standstill, so data has to be sent whenever it's needed and no more.

So, in an ideal world, the "SEND" part of the plugin would allow you to:

Add an object to it (say "car2" for this example) Send packet when condition met (position changed/time elapsed/predictive position/etc)

In the "RECEIVE" part of the plugin, you would be able to:

"Listen" for packets with a recognisable name Run functions or groups depending on the name of that packet

If the plugin is a simple send and receive packet plugin, like MooClick, then it would be easy enough to code the sending and receiving using it, but if it was built-in it would be a lot faster (processing, not sending and receiving ) and it would also be a lot easier for those without experience of online coding.

Sponge.

Assigning movements to the online plugin would be an excellent idea, with each movement assigned being able to have individual settings, IE send when/every, on receive for this etc

10ms-1000ms ping. What gives?

I didn't read the whole topic but maybe you could use a php file for the webserver. Before I found out that construct sdk was incompatible with express 2008 I was in the process of conceiving a Socket object that sent and received lines from a web server. Anyone fully willing could make one out of sockets - although if they want a socket object they need to wait for me to get another C++ program.

I feel that assuming nobody will want to setup their own servers for an online program is just stunting the creation of the Online Plugin further. There are quite a few users here dedicated to their projects and are really banking on the creation of an Online Plugin.

The plugin should be focused as it is so that the user can point to their own private server. Upon release you can see how the userbase is using the plugin and see if people are actually purchasing their own server space and utilizing the plugin. If not then you can worry about setting up a public server.

Otherwise all this worrying about something that really should be the user's problem rather than the plugin developer's problem is just going to prevent the plugin from ever being created.