Messages

Ah, i see. Of course it is because of the virtual interface. I was so into gcc recently that I totally forgot about such things. Thank you very much for pointing me towards the right direction, wyz!

Hi fellow AGS users,

today I discovered a possible bug in the AGS api interface. When using MinGW (32 bit) together with the new C++11 standard, something's wrong with managed objects. As soon as one instance should be deleted it's corresponding Dispose() method is invoked. However, the instance address it passes always refers to zero, no matter what.

I tested this multiple times using different approaches and everytime it failed. I also tested the string array plugin on google code (http://code.google.com/p/ags-plugin-stringarray) with bad results.

Is this a known problem? I haven't been able to find any information about it (or the Managed object interface in general). I cannot guarantee that it has something to do with C++11, it is just the only setting in my project that might be slightly deviating.

Although i find this piece of art absolutely fantastic and I'm really having a hard time finding anything I don't like about it, you asked for improvement suggestions, so:

- The locker on the right side does not have a doorhandle while the ones have. I'd suggest adding at least some hole in it to make it look more openable.
- The clock at the wall seems to be a bit huge. I mean, this is a morgue, not a train station or classroom. Time shouldn't be such an important issue here.

Yeah, that's all. As I said, I would hardly notice those both points of criticism if you hadn't asked for it. I find this image very harmonic in colors and setting and yet I think I absolutely like it the way it is. Good work at all!

I'm sorry if I upset you. It is not that I don't want to expose technichal details on the implementation here, but the whole network thing got quite a bit beyond this topic, you know. I'd really like to discuss those details, but maybe this thread is just not a good place to do so. I hope you understand and do not feel offended by my response.

Just for clarification: It doesn't matter what network model you choose to decide for or against NAT punchthrough. This is simply the step of readressing packets coming from a given subnet (i.e. www) into another most commonly local subnet (lan) using a bottle-neck node such as a router or modem. Since all connections made through this are addressed at the same IP, that is to say the public IP provided by the ISP, NAT routing is required in order to propagate the packet further over the "black box" subnet (LAN) to the correct receiver.

The reason I'd like to point this out is to make sure other readers of this topic won't be anxious about wheter the plugin uses a server-client structure with login functionality or not... just because - sorry to repeat myself, but I'd stick to the fact that this has absolutely nothing to do with NAT traversal.

I disagree about NAT punchthrough though, I mean, to the average player it would make a HUGE difference if they could just hit the multiplayer button, find a game and play away just the way they're used to in any other game. Otherwise it's going to be kinda technical to set up games, you would have to share contact details with people before playing etc.

Well, honestly this barely has anything to do with hole punching. What you're describing is (in both cases) a server-client model. While your preferred choice also provides a static login server (that is a dedicated machine where players register through a static IP or DNS entry), the second model is a decentralized approach. In both cases, this has nothing to do with the IP-Layer or number of P2P internodes (such as a NAT), but with the network topology. You could do both without providing punch through. A login server is indeed a nice thing, but since it uses its own protocol and sits in a dedicated place it could be retrofitted anytime.

Well, i think these questions are a little bit out of topic, because they're restricted only to the type of network connection and do not relate to anything regarding AGS. However:

- I'm using TCP. Adventure games do not need this kind of perfection in terms of timing. UDP would be overkill and needlessly complicated.
- I don't have any plans to implement such a thing like NAT punchthrough. This might be implemented later, but is not a big concern right now.
- It's a combination of both. The sockets are timed (blocked for a certain amount of time), but run in a seperate thread, so the game won't be affected at all.

Just an update of the current progress. I tried to consider as many of the suggestions made in this thread as possible. I spent most of the time working on a plugin interface that allows me to make more advanced implementations to the engine (through many custom native and scripting events). Recently I started working on the network code. It really isn't that much of a problem since the basics have been set up and as time goes by I'm glad to see everythings slowly taking shape. I'm planning to install a git repository, but the code is not polished enough yet.

About your feature requests/suggestions:
- Chat is not implemented yet, but should be a piece of cake. I'm pretty sure that could be solved with a pure scripted implementation (based on the functionality provided by the plugin of course)
- Full synchronization of character and object movement will be there. The old plugin already had this feature and I'm currently on reimplementing it.
- Multiple rooms are also supported (due to caching the visited rooms in backround)
- Inventory will be synched. This is already implemented.
- Script variables are not synchronized. I clearly see no possibility of doing that without hacking the interpreter (which I'm not planning to do because of compatibility). But I could think of a couple of NetSet/NetGet functions allow the user to store primitive types (numbers and strings). However, this is absolute low priority right now.
- Save states might be synchronized. Didn't think about that too much right now, but I guess it's doable.

Although I'm planning to make this plugin as flexible as possible, there are certain things I'd like to automate. These things are most likely synchronization tasks. I guess this is the kind of hard work I'd like to take out of the game developers hands. If there is anything I forgot about, please let me know!

Well, first of that you very much for your positive comments :-)

The sad news is that I accidentially lost the sources of this plugin. I basically did this in about 24 hours for a compo, so I didn't pay too much attention in making sure nothing gets lost. Sorry bout that :-(

Now over to the not so bad news: While this happened to be a research project, I began to put some more effort in it a few months ago and eventually started a new project from scratch. Reading your posts made me want to reconsider taking on this project again. At all there's not much interest in having some sort of cooperative gameplay style in an adventure game, but I still kind of like the idea.

The new approach at this is to make the network interface more open for customizations, while still doing the 'hard work' in keeping track of the game world. First of all I started out with a global caching and advanced event system that aims a bit beyond the native plugin API. You can, for instance, control objects that are far away and not only those in your current room.

As for networking, I'm thinking about a dedicated server. I did not like the fact that the host needs to start the game as well and players are only allowed to join as long as this game is open. It is needless to say that the technical gameplay and the style of playing an adventure game is much more slow and careful than a more common multiplayer game and I don't wan't to invent some Monkey Island Tournament here. So I guess the idea of having a dedicated server gives the game more time and therefore hopefully retains the spirit that we do love when playing adventure games.

Following your advice in terms of synchronization, I came up with a pretty flexible event system that allows components to be linked to certain actions if the user (better:game developer) decides so. I think that should do the trick. What do you think of that idea? Is it still something or am just totally wasting my time?

First of all, thanks for your comments! We were discussing this recently and it seems you were absolutely right, this theme doesn't really fit into a super hero hideout. The guys I'm working with had seemed to have something different in mind when talking about the music. While I'm still a big fan of more "natural" music, especially for the background of a hand drawn adventure game, it pretty much looks like we're going to have a bit more of electronic typed music for our game. Maybe there's some use for it in another project though...

@Kimbra Thank you very much! I used a sequencer (Cubase) and a combination of VST instruments (Piano, Drums) and soundfonts (Organ) for it. The guitar and bass are real, only passed through some quite clean amplification. I wish I could have used a real contrabass (altough I've never even touched one ;-), but due to the lack of several thousand bucks I sticked to an electric bass.

And now for something completely different...

http://kiwi6.com/file/efm20r3ieg

No sprites/artwork this time, but a small demo song I made for our team to decide about the acoustic style of our game. The game itself is intended to be some kind of cartoonish / 'superheroesque caricature' style. This song is to accentuate the heroes headquarters, a cave filled with desultory and only partially working equipment. I was hoping to catch the sleazy atmosphere in this song. And yet, almost instantly, I had the freelance police office in my mind, so I thought I give it a shot and try some jazz ... or whatever it's called. As always, I'm very open to criticism, so let me know what you think about it! :-)

I'm not sure what you mean by that. Unless we are not talking about some esoteric scripting language, you can save the state of any VM by saving its cache (ie. stack) and memory contents, doesn't matter if it is AngelScript, PHP or Python.

Right now im not at home, just got my mobile to reply, but i just couldnt wait to say: i absolutely fell in love with this idea.ways been a great fan of letterbox graphics and this is like a dream come true :-)

I've also developed a plugin providing game state synchronization in a server/client structure using tcp networking, but I did not spot any interest around here. The plugin is already in a usable state, you may want to check out the topic in the critics lounge.

I absolutely like this look! You could do some experiments with the dithering though. I'm having some problems understanding the full tone shadow parts in the upper edges of the room. Regarding to this the light source would be somewhere at the wall right above the door, but all other shadows don't match this position. Also, the dithering pattern on the ground confuses me. I guess it is because of the tile borders seeming slightly thicker with a dithered shade.

All in all it is a great looking, could use some more detail, but I guess you're just planning the overall style right now.

By the way, great job on improving your character sprite!

I second that. But I don't think there will be any game like this in near future, at least not made with AGS. I thought the audience would be somehow attracted by the thought of playing adventure games together with a friend (hence my plugin attempts), but on the other hand noone really seems to care about making one. Mixing up those genres still seems to be a little weird at all i guess.

I did not intend to make the testing something exclusive, so I put up the sources and binaries of the demo game above. While the second one contains the actual plugin, the first can be used for reference. I'm doing this plugin in my spare time and unfortunately I'm currently quite busy with other things going on.

However, the plugin is in a usable alpha state, it only seems that people aren't very interested about it and therefore not much testing appears to be done.

But I will inspect your suggestion about setMultitaskingMode(), thank you very much for that idea.

I did inspect the centered text bug, maybe you save some time this way.

The problem comes from the first div inside #main_content_section . It has an old attribute (align="center") that should be replaced by 'style="margin:auto"' (or nothing at all, seems to work pretty well without for me).

First one :-)
Darn, too late.

Good work, I really like it. Looks nice and cleaned up. But one thing that's still bothering me: Would you please consider turning off the wait time between the logins? I tend to forget my password and waiting to log in again is somewhat annoying and not quite common anymore.

Well, I don't want to spoil this for you, don't get me wrong here. I really admit the work and effort you put in your project, but I just wanted to point out that in a common way you would most likely do the technical concept and strategies behind in prior, allowing you to get plain view on how the interface should look like. I always obey the form-follows-function rule here, since it is clearly more profitable to me (as well as every professional I've been speaking yet).

Ensuing from this point of view, I'd be interested in how you decided to manage the asynchronous data transmissions that are required once you're getting into iframes and common GUI stuff (such as window positioning, dimension keeping, user preferences e.g). Right now you're only using JavaScript and referred to your statement about the triviality of implementing server side scripting and databases I am wondering how exactly you planned to integrate this after the interface has been done. Will you allow user login and furthermore preferences storage? This would include a snapshot of any windows and things going on in the GUI, and as we are talking about a passive and non-persistent connection, this could get a real pain in the ass if not well designed.