So you're saying its up to the player to change his own health in this time. What if the DoT kills the player? That means that its up to the client to decide when the dot has killed him (of course insecure). The only secure way is if the server checks ever DoT tick if the player has been killed.

I'm pretty sure they stream data and thus the damage tick comes in at regular intervals. It's speculation, but indeed, more secure.

My only point was demonstrating how events may work

I do not sniff packets or view incoming traffic while playing games... I tend to just play the games =)

[quote:377nwjbm]...but then how do you control the instance? You need some type of mapping to an instance (for sake of code simplicity, unless I'm missing a better way). The second option is to update everybodies ID's when somebody dies, well actually this would have to happen in all cases since instance numbers change. When somebody disconnects or dies, you could send out an update to all of the players changing their global playernum (and thus which instance they control) and also send out a delete player "X".

This is all the ID talk that was going on between me and Alee. An ID would allow your client to know what object is being referred to when it receives updates from the server. When the client received a new object creation event/request it would assign itself the ID from the server.

Incorporating that into Construct in a reasonable fashion may be interesting, but I hadn't thought about it a lot. Does python have access to private object variables yet? Sadly, I have not yet begun on object replication at this time (nothing goes as planned with a newborn in the house! But I don't gotta tell you that

I did get distracted on a few side things though... A* pathfinding and box2d within Construct (I had done some box2d things prior to discovering Construct).

But, one of these days. . .

There are so many events that need not be duplicated into the server. My game is just a graphical representation of some maths. (For example, Player 1 shoots player 2 and does 20 damage each second. The server will take 20hp from player2 each second, however on the client screen it will appear to be an epic battle with thousands of bullets or whatever. Another example is shooting a missile. The server will decide whether it hits and how much damage it will do and roughly how long it will take to hit player 2. However on the game screen the missile will fly and curve around etc.)

I won't have any physics. Interpolation is done client side (ofc) and If I choose to trust the client with his own movement, i'll have the server check if his movements are in the realm of possibility and disconnect him if not.

I've bolded the trouble points in your thinking. This is what I'm laboring to tell you. If you use Construct's built in events and functions on your client, in order to move things, time things, etc, and you do not do the same for your server, your simulation will simply not look right.

You're taking for granted these things, and I'm just trying to save you headaches later on down the road

1) Either use construct for server and client and not worry much about it,

2) Delve into Construct's source code for the simulation features you use on the client, but not on your python-only server

3) Write both the server and client code from scratch, and forego Construct entirely.

Truthfully, the second option isn't so difficult, and the third option seems silly since I know you're here to use construct to begin with. So it seems you should probably just embrace 1. Ideally the python only server seems sound, and it's not impossible, it's probably just more effort than it's worth for the scale of project you are working on.

[quote:3j4sedgq]

This is exactly what I was talking about. I don't want the list to ever "fill up", it has to be robust so it cannot be exploited in this way. I figure when clients disconnect i'll just replace them in the list with "empty", then when a new client connects it either goes in the earliest empty slot, or if there are no empty slots, we'll add him to the end of the list.

Try not to think so much in terms of slots, I believe a list is not the best way to organize this. You'd probably find it more convenient to use a dictionary, preferably one of the smart ones. A list might work alright for you, but I'd personally be after something more robust... probably a custom class built on top of a list or dictionary. I haven't really sat down and worked on it yet though in python... I need to do that

[quote:3j4sedgq]

Why exactly is it necessary to use a GUID/UUID? These IDs are only there so we can pick the correct player to update positions of on the client when we receive new movement vectors etc. I don't see why it needs to be anything other that just a short,simple value?

Well, it's not necessary, I'm just throwing ideas out there. Now.... 1 and 2,142,683 are essentially the same thing. They consume equal amounts of memory. So, if you're going to be using the same amount of memory/bandwidth, you may as well use a more robust numbering schema than just incrementing a variable.

import uuid
id = uuid.uuid4()
id.int
[/code:3j4sedgq]

Granted that's 32bytes long, you won't get a duplication in any kind of ordinary span of time (our lifetimes, easily).  You could also save some memory by using just the first or last few bits of the ID (for example: id.node or id.time_low), though your randomization takes a dip (still, the chances will be quite tiny).

Even if you do get a freak duplication, you'd be checking it against active IDs anyway.  If a duplicate exists, just generate another one.  Couple this with a unique field in a SQL distribution of your choice.

[quote:3j4sedgq]
As to the response based communication. What about in WoW in the case of DOTs (damage over time attacks) for example. The server needs to keep updating the health of the victim even when there is no "event". Perhaps I misunderstand this part? But in these cases, the server will need to send updates to the clients of their health/damage done etc. even when there is no event or packet sent to the server from the client.



Events can happen in both directions, obviously.  In the case of a DoT the client will receive an event that they have a DOT which does X damage over Y interval (display the debuff icon, duration, graphic, etc).  The client could then simulate that effect with just the one packet send from the server.  It could be broken up based on the tick duration too (multiple packets), but somehow I'd think they would resolve the damage ahead of time and let the client simply display the results over the course of the spell however it sees fit, rather than waste packet overhead simply on that.

Alas, WoW probably serializes a lot of data at regular intervals (watch the combat log, heh).  So they might indeed elaborately break that data up on a per tick basis since data is streaming in that fashion. I've never sat down and sniffed out WoW traffic, so that's just an honest guess.

Here's a link that might interest you:

[url=http://www.wowwiki.com/Events_From_Disassembly]http://www.wowwiki.com/Events_From_Disassembly[/url]

[quote:3j4sedgq]
Thanks a lot for the help so far man! Hope i don't sound like I'm arguing, I often find challenging something I don't understand is the easiest way of understanding it 


Sure.  No worries about the argumentative stuff, it doesn't really come off that way.  I just hope I'm being helpful and not wasting precious posting space

I plan on writing a server that is purely maths (made in code) anyway. So it wouldn't be too different writing the server purely in python.

Maybe you missed my point, but I meant that if you're going to go through the trouble of duplicating all of Construct's helpful events and what not into python, why not just write everything from scratch to begin with?

The method of thinking you're taking will lead to road blocks down the road, primarily in the form of physics/extrapolation/interpolation. If the server-client movement code, for example, is not identical, your simulation will be off if you're using any kind of client-server architecture.

[quote:ekplc39o]

this way we don't end up with a huge list (because the list re-uses empty entries). I assume this is the best way to do it?

Your "list" will only ever be the size of the amount of people connected. If you're worried going out of range on your indexing, perhaps you're not picturing it right in your mind.

First, you can use an ID generated by a storage medium (SQL, for example). Bear in mind the max int size within python is a signed long (for most distributions)... +/- 2,147,483,647. Try to imagine how long it would take to exceed that. At 10,000 connections a day, which ain't bad for most websites, that's 214,748 days until that number fills up. Or 588 years. Of course a malicious user who writes a connect/disconnect bot will make your server throw an exception rapidly.

Secondly, and probably more realistically, you should be using a guid. In which case, the concern isn't really valid to begin with. If you're going to send 4-8 bytes anyway, it may as well be a unique identifier. This might lend some security as well, if you use the first method and only that, objects will always be the same ID, which could give sniffers an advantage (hard to imagine how, but scripting would be much easier).

You might find a combination of the two to be the most appealing approach, though.

[quote:ekplc39o]

How do you do this in python, or is there a more appropriate way?

Heh. You may be a little over your head at this point, no?

http://docs.python.org/library/uuid.html

Otherwise, in your class's add method, you could simply increment a private index value each time there's a connection. Off the top of my head... index = len(list)+1 would probably suffice.

[quote:ekplc39o]

• also, wouldn't each client need a unique "ID" so you can send messages directly to certain clients from the server?

Well, PodSixNet is a connection based library... You'd just send directly to their connection. You might organize that into a set of containers (channels, for example), in which case, if you just want to talk directly to clients you could keep a "master" copy container (dictionary) for convenience. If I recall, that's how the author of PodSix does it, although he uses WeakRef (which is probably cleaner at the end of the day).

Try not to overthink it too much, in most cases, you'll be sending a response to the client directly so you'll know which channel to reply to at the moment of receiving their request (try to think of an event-based networking system -- this is how WoW does it).

[quote:ekplc39o]

2) I couldn't quite work out how channels work. Can we send messages to all players on a channel? And can channel names be strings? Surely its important to ensure that we can send messages to certain groups of clients, but not everyone connected?

From a limited amount of looking at PodSixNet's innards, it does not do client channeling for you. I'm not familiar with the tutorial you're referencing, but client channeling is fairly easy to pull off. Use a dictionary (or some variety) if you wish to look them up by a string (probably pointing to a custom class you make which keeps references to the clients in said channel). This is where the various smart pointer classes in Python will be handy, since likely, you'll have references in multiple containers. Again, this all depends on how you design the data structures of your program.

Truthfully, I think you're asking the wrong question. C++ is a tool, and like any tool, it has strengths and weaknesses. Construct, too, is a tool with strengths and weaknesses. The most important question is, are you using the right tool for the job?

You've said nothing about what your game is, what its goals are, and what you're ultimately trying to make; so there's no good answer to receive.

If you want to make games, you should know how to program. At this point, for you, that means start learning something. Truthfully, it doesn't matter what language you use so long as you can understand it and use it to its potential. Likewise, the language must support whatever it is you are trying to accomplish.

C++ has a ton of support, examples, and projects you can use to achieve your goals. But then, so does Python. So does C#/XNA. And the list goes on. I encourage you to use what works best for you, and what will make your game more of a possibility. Think first about your target, your goal, and your needs. No matter which route you go, it will contribute to making your projects more of a reality.

At some point you will realize it's less about the language, and more about the APIs you use (or make for yourself). Since it's asinine to sit down and write your own 3d API, you'll be looking at Ogre3D, Irrlicht, CrystalSpace... etc. ClanLib... SDL... Allegro... PyGame, PodSixNet... etc. See where I'm going with this?

People hail C++ as the best "game making" language, it's not that it makes games "better," it just gives an experienced programmer a lot more control. Control is important. However, if it's "too much" language for you, you can easily get stuck and discouraged because making progress can be harder than making progress in, say, Python or BASIC. And it's simply been around so long, it's more or less the standard for the way things are done. It's not better than Python, it's different. Lua isn't worse than Python, it's just different.

Whatever you decide on, stop talking about it, stop considering it, and start WRITING it.

"Taking 6 months to learn C++" is a silly thing to say, and it only emphasizes the lack of maturity you have about this topic. I've been coding for 15 years or more, and I still consider myself a learner.

• If I was going to write the next best 3d game with massive multiplayer support, I'd use C++.
• If I was going to write a small 2d game that's fun and more of a side project, I'd use Construct. Or PyGame.

And if you truthfully want to know which is more important to your development, it is hands down the second option there, because the ability to see a project through to completion far outweighs any delusion of granduer you may have about the first. And, it will get you to the first option MUCH quicker if that's where you want to go with your life (tip: option 1 requires a group of developers, hence why option 2 is m ore important for the soloist).

I suppose I don't see how that is a list, though. You're saying I have to make my own list and store the references returned by SOL... so is it a misnomer? Should it be called LastObjectRef instead?

A list would be.. a list. Not a single reference after 10 calls of Create*()

It would probably be prudent to do a write up on all the functionality of SOL... lest we all sit around trying to figure out it's actual functionality. As it stands, the Lucid's plugin is more useful for picking objects. I must be confused, I thought this was proper built in support for that bandaid fix.

As it stands it seems like a wrapper to get the last object created, and not a list at all.

Surely I am mistaken?

Luomu, that will work no problem. Also you can eliminate the "objref" variable and do it directly:

System.Create('Sprite', 1, 0, 0)
SOL.Sprite.x =300[/code:2btwhewz]

So, can this be used in the fashion of the py fix plugin?

Is there a len() operator of any fashion?

Is this correct?

import random

for x in range(10):
	System.CreateByName("spr", 1, random.randint(10,400), random.randint(10,400))

for i in range(10):
    spr[i].X = random.randint(10,400)
    spr[i].Y = random.randint(10,400)
[/code:2btwhewz]

Just wondering.  I couldn't figure out how to use the SOL class for iterating, but the above works (not sure if it's intentional or not, or if that was always functional).

What I suggest is put all of your letters in a long strip, tiled at a uniform size.

Use a SINGLE SPRITE and import them as animation, with speed 0. You can use the import animation panel to chop them up automatically.

Choose the frame number at runtime, right after creating the sprite.

This will be much more manageable, in terms of not having a jillion objects, no unwieldy text rendering and you get to control the letters behavior as individual sprites.

If construct does batch rendering like opengl, this will be much faster as well. If not, I agree with them being more manageable at least.

other than having used c++ for years I pretty much agree with the rest of it. I used think game makers were silly toys no one could use to make anything serious.

also, don't forget you can use c++ to make plugins, which takes away almost any remaining limitations.

btw, if you've been using c++ for years, check out the sdk, it's pretty easy to get something awesome happening

Indeed. My time has been so limited lately I barely have time to even use Construct as just an end user (we just had another baby! whew!) Anyway, I'm still a novice user of Construct, so I haven't thought of a lot of additional needs yet (a few ideas...)

But in time, I plan to.

If I'm not mistaken, you probably just want to use one of the various Create* functions.

You can do this quite simply in python with System.CreateByName.

There is an event also under System (amazingly, called CreateByName!)

Hope this helps.

EDIT: About your brain dump second paragraph, if letters are going to be a integral part of your game, make them sprites. Text boxes are handy dandy, but you should get better performance using sprites as... well, sprites.

I'm confirming i can now run these examples using the latest unstable build which ROJO fixed this issue in.

What might be cool is some help in making the server in something like pygame and have it talk to construct - This way (unless im mistaken) we could make our servers run on linux for example?

Maybe its better just to write the server in bare python, but its nice to have a GUI

Just an idea, but I think the ideal solution for networking in construct is to have the server running on linux - This cuts server costs hugely as linux VPS are very cheap etc.

This is a perfectly viable option, however, keep in mind you'd be writing the core of your game python, and not Construct at that point.

The server and client should be executing the exact same routines for things like motion (unless you're doing fixed frame, or perhaps turn based). If you want any kind of interpolation or extrapolation, the client and server must run identical movement code for accurate prediction (physics also).

Which might be rough if you're relying on Construct for anything other than a drawing medium. In which case, SDL or pure pygame is likely better.

Just my thoughts. I'm known to be wrong from time to time

EDIT: Though another thought... while Linux is at the end of the day a better server platform punch for punch, if you're writing a game so complicated and optimized a decent windows system will choke up on it and you need to consider superior OS platform... you've probably outgrown both PodSixNet and Construct. Is that even an issue most AAA games have to concern themselves with? I doubt it

It was my understanding that using "Every x milliseconds" will result in the same speed whatever computer it's run on, and whatever frame-rate it ran at, because it's already factoring in the time delta and will run based on actual time passed.

In which case, your first post should run fine.

It's when you use "Every x ticks" that the speed is affected by frame-rate and computer speed.

Correct me if I'm wrong, because all of my game is based on "Every x milliseconds".

Krush.

For simulation events (eg: movement, motion, physical behaviors) you should be using TimeDelta.

For things that simply must fire at steady intervals (health regeneration, maybe), you should be good.

Try to think of these as multiple parts of a single system; don't just use one or the other. Different tools for different jobs. I can't see basing motion on "every x ms." That would drive me nuts. But tossing in a timeDelta in your equations is easy

Likewise if I just want to check for something every second or so, give or take, it's a pain to make a variable and increment it by timeDelta every step... thus the convenience of "every x ms."

Hope this helps. And not to plug gaffer, but everyone should read his article on time stepping. It's essentially the best things written on the topic.

http://gafferongames.com/game-physics/f ... -timestep/