Developer thread

[Shendemiar]

I assume the server/client approach was due to multiplayer aim?

So, which parts of the game are to be identical to original and which aspects are up to consideration?

I'm not trying to stir the pot, I'm just trying to understand where things originate from, what are their current state, and what are the goals.

[WhiteMage]

I assume the server/client approach was due to multiplayer aim?

That is only one reason. It also helps with anti-cheat efforts, usability evaluation, game-to-AI synchronization, version control, patching, quality control, AI development, popularity assessment, debugging, logging, and data collection for future improvements.

So, which parts of the game are to be identical to original and which aspects are up to consideration?

Lead programmer VM declared that current efforts are for duplication (cloning) of original MOM, but not being fanatic about it. However, multiplayer is added now, but to my dismay only a simplified version, not what I discussed above . Maybe you can do the full client-server if you are up to it and VM agrees. Once we are done with the clone, we will work on upgrade and mod (complex, extensive topic). Current efforts make future upgrades and modding flexible through using XML and keeping code clean. Graphics is deliberately delayed. Currently extract from original MOM.

I'm not trying to stir the pot, I'm just trying to understand where things originate from, what are their current state, and what are the goals.

Short-term goal is moddable, open source multiplatform MOM clone with basic multiplayer and basic AI. Long-term goal is best 4X and best TBS game in history that include strong AI and competitive multiplayer and its long-term maintenance. VM knows most about current state, but check out http://sourceforge.net/projects/vismaior.u/files/

[Anthony]

That is only one reason. It also helps with anti-cheat efforts, usability evaluation, game-to-AI synchronization, version control, patching, quality control, AI development, popularity assessment, debugging, logging, and data collection for future improvements.

If done properly it also lets someone code a client without knowing the details of the server. My ideal (disclaimer: I haven't looked at your code at all) would be designed to support using a browser as a client (probably doesn't even need html5 sockets; a lot of this stuff could be done without persistent connections).

[Shendemiar]

All valid points, but it would have been easier to make just 1 to 1 remake as a starting point.

[WhiteMage]

All valid points, but it would have been easier to make just 1 to 1 remake as a starting point.

We are as close to that as reasonably possible, with the notable exception being the multiplayer. We have no access to original source code and noone fully understands the decompiled Assembly code. Noone fully understands the actual rules. We know of over 300+ bugs in MOM v1.31 and dozens of errors in the manual. There are probably more. Other features are just plain lame or lazy, such as truncating carry over of population growth and production. AI is superlame and noone understands how it was exactly done. Not worth replicating. So 1 to 1 remake is nearly impossible, so no it would not have been easier, but we try to stay close. Besides, being easy to implement is not top priority and a perfect clone alone would have little value.

[VM]

Hi!

yea, the point is 1 to 1 replication, but executed with actual sanity. The main point if the whole thing is the multiplayer part. My opinion is that its ok to deviate as long as tehre are good reasons for it, and we do not change the feel of the game. It should still play like MOM when 1.0. This way we have a base game that is playable, but can be modded to balance for multiplayer or for whatever other reason.

If you are interested in technical details, I propose making yourself familiar with the code. I can give you a quick tour if you like, then you can ask anything when and if you got questions.

About the server-client thing, the main reason for going P2P first is that so there is only 1 code. It shold be possible with soem effort to create a server--client architecture, should it be deemed necessary. I do have some ideas about that one, but I think it can wait until we have the base.

[Anthony]

It shold be possible with soem effort to create a server--client architecture, should it be deemed necessary. I do have some ideas about that one, but I think it can wait until we have the base.

Taking a unified system and untangling it is often significantly harder than designing it that way in the first place, and there's no particular reason not to have the display code be completely separate.

[Shendemiar]

yea, the point is 1 to 1 replication, but executed with actual sanity. The main point if the whole thing is the multiplayer part. My opinion is that its ok to deviate as long as tehre are good reasons for it, and we do not change the feel of the game. It should still play like MOM when 1.0. This way we have a base game that is playable, but can be modded to balance for multiplayer or for whatever other reason.

About the server-client thing, the main reason for going P2P first is that so there is only 1 code. It shold be possible with soem effort to create a server--client architecture, should it be deemed necessary. I do have some ideas about that one, but I think it can wait until we have the base.

I like this approach, and I do like client server approach too, too often people shamelessly cheat on PBEM games.

If you are interested in technical details, I propose making yourself familiar with the code. I can give you a quick tour if you like, then you can ask anything when and if you got questions.

I've skimmed through it but only very little. I also want to read all the threads in the forum to get better idea about everything.

[Shendemiar]

Reading the forum is done. I'll look more into the code next.

[VM]

It shold be possible with soem effort to create a server--client architecture, should it be deemed necessary. I do have some ideas about that one, but I think it can wait until we have the base.

Taking a unified system and untangling it is often significantly harder than designing it that way in the first place, and there's no particular reason not to have the display code be completely separate.

Yes, whgich is why we keep the UI code separate from the Gamemechanics. The main changes that would be needed to do, were we to go to a C-S architecture, is random seed redistribution and gamestate information distribution. A thin client is unlikely, because then Id have to add a lot of extra stuff to redistribute (graphics and such) but I would not rule it out completely. Im really not good with web programming.