In a multiplayer encounter, I want to have a monster that randomly targets one player and then aggressively attacks that player. How would I go about doing that?

What's wrong with just having the tilemap layer that's visible and the collision layer that's invisible, and just make sure the collision layer matches up with the visible sprites?

Thanks for the messages all, traveling now but will have time to respond in the next 48 hours!

Bump!

Hi all,

I've got a plan for a game with a core feature-set I want to implement, and a lot of experience building mods/content for other game systems, but relatively little experience with C2, which makes it hard to know whether I'm doing anything the 'right' way or not when I work in C2. As I put together the groundwork for my game, I want to ensure that I'm not screwing up how I structure the game's fundamental systems, so that my 'content creation' phase is as pain-free as possible. The game is slated to be content-heavy, flexible and extensible down the road; as a result, time spent now to ensure I've got my design 'right' will hopefully be worth its weight in gold down the line.

Ideally, I'd find someone who has thoroughly played and experienced the following two games:

-La Mulana (or perhaps Super Metroid)

-Zelda (the 16-bit, non-3D zelda)

And who is experienced enough with C2 to think creatively about how to implement the featuresets of these two games. Also, experience/understanding of C2's multiplayer capabilities is a must.

I'd be happy to pay for your time (I'm sure we can work out a rate we both find reasonable) to work with me on how to translate my 'design document' into a solid C2 implementation (with CapX examples of anything tricky). We wouldn't be worried about the specific content of my game, we'd be looking at systems design together.

Anyone interested?

I think the multiplayer plugin could improve a lot if Scirra added a syncing condition to it, for example if all players has a room instance variable you could make the peers only sync players/objects positions that has the same room value and the host would work more like a dedicated server, correct me if I'm wrong.

This doesn't sound like a huge request to me but I'm not sure how it's programmed in the backend. Would definitely help with this problem a lot though.

Even if this would be a pretty small amount of work compared to what's already been done on implementing multiplayer, the problem is convincing Ashley that we (those of us who want to build worlds for players to inhabit) exist; because people aren't out there making Multiplayer 2D Arena shooters etc. with C2 right now, the impression he has is that multiplayer isn't really what people want to do.

EncryptedCow

DatapawWolf

You guys are simply going beyond the multiplayer behaviour capabilities of scirra.

The official multiplayer system is a simple signaling server which connects players with each other, so one player will always be the host.

What you guys are talking about is a simple dedicated server, that's it.

So as long as you're not going to code a dedicated server, there's no way you're ever going to achieve what you're looking for.

From what i've read from Ashley so far... he's not really interested into further developing the multiplayer part.

It looked like he felt that the multiplayer feature was a complete waste of time, because there are not enough people actualy using it. (i'm just interpreting what i've read so far, but his words came pretty close to that) So according to that i would guess that he's not willing to help you in a dedicated server matter.

(i would love to get my hands on a dedicated server version as well)

The only way to prevent players to become host right now is, to run the "main game" on your own server.

What i mean is.... run the game itself on your own private dedicated windows server (for example) which will then always be the host.

That would prevent players to become host themselfs, and you could offer your players a dedicated bandwith.

But it's just a simple and bad workaround.

So either you're going with lennaerts suggestion, which is actually pretty good.

Or you're going to code your own dedicated server.

Using lennaerts suggestion would simply mean that creating an actual (dungeon) instance will just be a new player being abused as a new host.

This would save you an *** full of money rather than being forced to host a dedicated server.

Of course there's a big downside on that, as you would have to rely on the players internet connection/location.

But i'm sure you would be able to add some checks on the players connection to prevent such players to become a host.

If you're actually willing to go for a real MMORPG, just keep in mind that this will require a really fast and big database / a good dedicated server. MMORPGs require the most powerfull servers when it comes to gaming (compared to a shooter for example)

In short: it's expensive

What a lot of us are aiming for is a multiplayer world without the 'massiveness' of MMORPGs -- you might have, for example, a cap of 50 people per server, movement in two dimensions (which is a lot less data being passed back and forth than a 3D MMO), inventories that are simpler and require less data storage than an MMO with, say, loot permutations (so an object in a player's inventory is simply recorded as "Item #263," which references local data on what all the items are, rather than all the special properties and permutations a modern MMO's 'Vorpal Sword +3 of Shadows' has undergone.

Multiplayer without persistence is boring and done to death. Who wants to play another competitive 2D arena game? But we're not trying to compete with the Big Boys here. We can do a form of persistent-world on the cheap.

As for a player potentially hosting with a poor connection, this is one more reason for me to split up every single screen of my Zelda-y multiplayer game into its own layout... if a screen is choppy because the first player to arrive on it is a poor web host, well, hop to any other screen and you'll be fine.

The one downside is that if players aren't 'connected' until they're on the same screen, how will I handle chat? That'll be tricky... Unless there's some way to have the chat box as a 'separate' multiplayer connection that I permanently host and have all players of the game as permanent peers... if that's impossible, though, text is simple enough that there's gotta be some weird Java-y way of handling it.

I'm still very very satisfied by how well a C2 game can run, even on old hardware.

My game runs very smoothly even on crappy laptops now, I'm impressed.

You definitely can push hard on C2, and have tons of ressources with no problem. It does a superb job at managing/optimizing the memory for you.

As jobel mentioned it, I had some problems with people wanting to stream some Penelope footage.

Half of these problems were only because of me (you would want to have a look at "delta time" management way more closely than I did) as I didn't test enough my game in extreme conditions (under 15fps or at more than 100fps on top end monitors).

The other half is how the frameskip is handled in C2. 40fps doesn't look like 40fps but sometimes feel more like 20, and when people stream the game in bad conditions (play+local record+ online stream on poor setup) it shoes. For normal use, aka only play the game at 60fps on many many machines, you can be sure it will compare very well with games made using Unity or GM. Again, even 2 years later, I'm still happily surprised by the C2 perfs.

Honestly, if you're not interested in consoles (<be really sure of this, all consoles), I don't see why you shouldn't pick C2 for your game. No engine is perfect, and this one is very good, very fast, very cheap and have a GUI designed by a brilliant mind. Wish you the best with your game!

Not to mention that Unity requires you to have serious coding knowledge, and GM doesn't do multiplayer nearly so easily.

Televangelist yep, pretty much. I think I'm just going to switch over to a grid based movement system (think FF1), and not require any actual collisions in C2, just grid based collisions which will allow all players to be in their own layout with a relative position of their own map. It's the best I can do with what I have.

Is there a good guide to implementing grid-movement collisions somewhere? This was something I was having trouble implementing in my grid-based movement system... assume there's some way of doing it simply/elegantly that I missed.

> Wait, my players have to be *on the same layout*? This is a huge, huge problem.

>

> My plan for multiplayer (a zelda-y world that players can move freely around in) was:

>

> -Every screen of the world is a separate layout (makes life easy in a number of ways)

>

> -Players only sync data with other players in the same layout as them (so if you're the only player in a given layout, you're not syncing with anyone)

>

> -Global world variables (is it day or night? Are there orcs attacking the castle?) sync globally once every five seconds (for low bandwidth consumption)

>

> This seems like it would be low data while still allowing the feeling of a 'permanent' world (with most things including character save data handled by the client, at least at first, I'm not a professional operation I don't feel the need to move everything server-side).

>

> But according to what you're saying, this extremely simple vision would be impossible?!

>

> Ugh.

>

No your players do not have to be on the same layout.

As long as you do not want a single host determining everything, you should be in the clear.

ATM it is like, every single layout, requires at least 1 host. Be it peer or a 'super host'

Ah, okay! So could I do it like this?

No super hosts; whenever a player moves into a layout, that player becomes the 'peer host' of that layout, and anyone else who enters the layout will enter the peer host's version.

So when a player enters the "Dangerous Cave" layout, the game pings the signaling server to see if anyone else is currently hosting the 'dangerous cave' layout, and if so it connects them, and if not that player becomes the first 'peer host' of the 'dangerous cave' layout. That will work?

And then for syncing global variables, I could use WebKit or something like that for syncing the global variables from a simple data file I host on a server somewhere? So, for example, if the world has a day/night cycle, that will sync up across all players playing the game through a separate mechanism than the multiplayer object?

JSON is definitely faster, but the data volume is most likely not heavy enough for it to make a difference. I find it easier to navigate with XPath than using JSON... maybe with a decent JSON plugin I would consider it over XML.

The goal is many thousands of lines of dialogue by the end, so speed might come into play eventually? Hmm.

Excellent, thanks! I've used XPath at work, so I'm comfortable with that.

Just wondering -- I've heard that JSON is better than XML for dialogue-heavy games. Do you agree? Or are there good reasons for doing this with XML rather than JSON?