I think it's just the space in the http ; urls get removed from posts for new users

repost :

http://gyazo.com/378b054bd46624296b809542878c8c48

http://gyazo.com/b87ef8cf7e62cb17a83d7c52a0f3ce95

Ahaaah ! Great, thank you very much, I will be experimenting with all this !

Interesting ! That would make peer objects persist across layouts, giving me full control of their life cycle (created by the host, destroyed when players disconnect as you said). That should remove the destroy/re-create question altogether. Thanks

I'll investigate that ! Though I'm still curious about what actually happens to synced objects when changing layout

Hi all !

I've been encountering a small glitch in multiplayer when changing/resetting layouts ; basically, peers positions' still seem to interpolate between the old position and the new one (before/after changing layout), and peers also leave a "ghost" (multiple instances of the peer's player object bound to the same peerID)

Surely it's got something to do with the way I use Multiplayer.Associate(peerID), or some assumptions about the layout transitioning logic I don't fully understand (my guess is that all objects should be wiped clean and re-create, but are they...?)

Bottomline question : what happens to synced objects during layout transitions ? What are the best practices in terms of object creation/destruction and peer association to deal with layout transitions ?

I have re-created a "small" .capx example demonstrating the problem (nothing is really "small" with multiplayer, even if C2 makes it easy, but it's as minimal as I could make it) : 2+ players (blue squares) need to collect all the collectables (yellow squares), upon completion the layout is restarted (hosts restarts and broadcasts a "restarts" message to peers)

.capx : https://db.tt/4X0NpqRh

video : https://db.tt/5qaa0ktJ

4 layouts to deal with the front-end and 4 stages of multiplayer setup : menu (checks for multiplayer support), login (player id), matchmaking (room id), and lobby (multiplayer set up, waiting for all players to be "ready")

1 dummy layout containing prototypes of all entities

1 actual "game" layout where the collection / restart logic is

WASD to move

Any suggestion would be greatly appreciated <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> Thanks !

Hi all -

I've been writing a short 10 page article to share my experience of production and help amateurs, hobbyists and junior game developers manage their projects more efficiently using simple tools and processes, especially regarding planning and tracking.

A first draft is available ; if anyone is interested, I am opened to feedback and criticisms to improve the guide.

OneDrive : http://1drv.ms/1BJwiWo

DropBox PDF : https://db.tt/Qx7ncPCe

Thanks !

Hi !

Do the samples and tutorials (ghost shooter, etc.) behave properly ?

If they do, check your logic, setup and game updates against the samples. I couldn't open the capx, but did you disable the behaviours on the peers ? host authority vs. peer logic could cause this kind of shakiness

[quote:27cwxw6x]it's still an authoritative server model - the host acts as the server

Absolutely, fair statement - my apologies for the misleading over-simplification, I only mentioned this as a quick way to make sure the OP, who doesn't seem to have used C2 yet, wouldn't expect distinct modules for the client and server sides, like some other tools do, and would need to understand the symmetry between peers to develop proper host "authority" logic

Hi !

C2 sounds perfectly suitable for this project ; just be aware that the built-in multiplayer functionalities are designed around the host/peer architecture, not server/client. It may or may not be an issue depending on your concept

You're absolutely right that additional sheets can and will generate more draw calls ; what I meant by "minimal impact" is that the cost of a few extra draw calls (i.e. a few factors e.g. 2x-10x, as long as there's no order of magnitude e.g. 100+x) is pretty negligible in terms of performance. Though we should think in terms of materials, as objects and/or textures usually don't relate directly to the number or complexity of materials

Basically there are games where each model can require dozens of drawcalls (typically, games with a lot of character customisation, like MMOs, lots of materials, armor pieces, etc. making batching difficult) ; for these, the frame time spent in the graphics drivers start to matter. Assuming a med-size 2D, not so much

I don't have the answer to explain why the atlases don't batch everything in one sheet in your case (and I'd love to know too !), but unless you clearly identified a perf killer or bottleneck through actual profiling, I wouldn't worry and would continue to progress on other fronts while waiting from an answer from Ashley or someone who knows the internal logic of the texture batcher

Texture atlases and sheets only help with batching, as less textures means more quads can be drawn using the same material without having to issue render commands for individual sprites.

As long as all the required textures for a given scene fit in memory, the actual organisation of the sprites has only a minor impact. It's always possible to fine-tune when hand-crafting everything manually, but in the context of a C2 game whether an animated sprite is using frames from different sprite sheets or not should not be detrimental to performance.

Though it would be interesting to know the logic that decides the size of the atlases I guess some platforms are still limited in terms of hardware when it comes to large textures

*UPDATE* Now with dual tones, to make word highlighting easier !

Why try to turn the product into something it's not ? If people want 3D, there are tools already - why not use Unity with some of the numerous plugins to help with gameplay logic (node based logic, event sheets, etc.). It's the easiest it can be when it comes to 3D ; an easier solution would necessarily become too restrictive or constrained.