Anyone interested in a Shandalar remake (kinda) for Pandora?


Revenged

Still Fresh
Joined
May 31, 2012
Messages
29
I've been tossing around ideas for a remake of MicroProse's Magic: The Gathering game, and especially the Shandalar portion of the game. You know, the one where you wander around battling other mages, collecting new cards and upgrading your deck with winnings and purchases from towns. Yes, this one: http://en.wikipedia....Player_Campaign


It won't be a "remake" per se, but rather a similar kind of game developed especially for Pandora. And yes, single-player only.


The other day I spent like 8 hours juggling the screen game layout with a friend of mine...he doesn't know how to program but we managed to make pretty a good solution for Pandora's small screen, I think. Given some, or maybe a lot, fine-tuning it should work just fine. This was just the actual game table part though, the adventure map part of the game hasn't been given that much thought, yet.


About the development itself, I think Python would be an nice choice for the programming language. I've already looked at source codes for other homebrew computer MtG projects and with Python it would be quite easy (or at least easier) to build the ever-changing rules system. AI will be a tough one to develop for sure, but I don't think it needs to be _that_ smart - it's enough if the player feels challenged. It's a question of choice.


I know this is not a simple task: to build a MtG rules system, an AI to play it against, an adventure mode and of course the actual cards, but if you keep the number of cards to a reasonable amount and design it well enough it's not impossible. It will take quite a lot of time and I haven't really developed games this big before, but I've been working in IT development for 6 years and I have a engineer's degree in computer programming so I don't know...it's doable? Given enough time, at least.


So, what do you think? Would you play this? :)
 
This would be a very nice game for the Pandora. With a good AI but also online multiplayer it will rock!
 
The multiplayer portion would be really difficult to implement, so I think it would be single-player only. Or...who knows? :)
 
Why would you except multiplayer to be difficult? Are you talking from the game perspective, or just from a technical perspective?


If it's the former, there would be little difference in sending turn requests to an AI object than to a NetPlayer object. If it's the latter, once you get your head around sockets, it's not that difficult. Almost like writing to a file.


I'd be interested in playing this. I'd offer to help with the code, but I currently don't know Python (though I can't imagine it being hard to learn) and not sure how much time I'll have. Feel free to prod me though, and if I can help, I will.
 
Why would you except multiplayer to be difficult? Are you talking from the game perspective, or just from a technical perspective?


If it's the former, there would be little difference in sending turn requests to an AI object than to a NetPlayer object. If it's the latter, once you get your head around sockets, it's not that difficult. Almost like writing to a file.


I'd be interested in playing this. I'd offer to help with the code, but I currently don't know Python (though I can't imagine it being hard to learn) and not sure how much time I'll have. Feel free to prod me though, and if I can help, I will.

Technical perspective. Yes the difference between requests made by AI or a player is negligible...you could implement just a different controller for a generic "player" object. Never done much coding with networked games. But if you say it's not that hard? There's a library for pygame network capabilities called Twisted...that might work.


And thanks for your offer, I'll keep that in mind. :) I'm going on a vacation for two weeks but after that I'll start working more seriously on this.


Oh and by the way, I don't even _have_ a Pandora yet...
 
But if you say it's not that hard?
Well, it's still going to be hard work, but it won't be dissimilar to feeding off to the AI. If you implement both with the same base class, then they can force the same triggers. Just one sends across the network, the other to the CPU
 
But if you say it's not that hard?
Well, it's still going to be hard work, but it won't be dissimilar to feeding off to the AI. If you implement both with the same base class, then they can force the same triggers. Just one sends across the network, the other to the CPU

My thought exactly. One base class that isn't concerned with who is the controller. Maybe players could duel against each other with the decks they've built in the adventure? Maybe card trading, too? Oh well, I'm getting off the track here...


The only thing I'm worried about is the lack of any real server, so it would need to be implemented p2p -> brings issues like latency, not to mention cheating.
 
Unless you're changing the actual game mechanics, the game is turnbased. Network latency is really not all that much of an issue.


When I was looking at my designs for Master Class, I went through a lot of these thoughts. Cheats is one I didn't really come up with a solution for. You could encrypt packets, but that would only prevent alteration after it leaves the game, but really there's nothing to stop them opening your game in a debug process and manipulating things there (then writing cheat apps using interprocess communication).


Skeezix also started a thread on network code here:





My final thoughts on the network side of Master Class was the following:

  • Clients CRC all the data files they load (Creatures DB and Moves DB)
  • Clients submit CRC to the server
  • Server validates against local DB CRCs and permits/declines user
  • At the start of the game, each player is packaged and CRC'd and sent to the server for distibuting to the opponent
  • After each turn, both players would submit CRCs for both parties to the server
  • Any inconsistencies would result in both players informed that there was a problem, and drop the games.


This means that unless both clients have exactly the same data, when they each process a player's actions, they should both get the same result. If one is cheating and trying to switch moves, or upping the power etc., the game will notice that the HP's etc. are mismatched by the CRC and the game will be disbanded (unless the server also runs the game, in which case you can determine who the cheater is)
 
Unless you're changing the actual game mechanics, the game is turnbased. Network latency is really not all that much of an issue.


When I was looking at my designs for Master Class, I went through a lot of these thoughts. Cheats is one I didn't really come up with a solution for. You could encrypt packets, but that would only prevent alteration after it leaves the game, but really there's nothing to stop them opening your game in a debug process and manipulating things there (then writing cheat apps using interprocess communication).


Skeezix also started a thread on network code here:


http://boards.openpa...d-verification/


My final thoughts on the network side of Master Class was the following:

  • Clients CRC all the data files they load (Creatures DB and Moves DB)
  • Clients submit CRC to the server
  • Server validates against local DB CRCs and permits/declines user
  • At the start of the game, each player is packaged and CRC'd and sent to the server for distibuting to the opponent
  • After each turn, both players would submit CRCs for both parties to the server
  • Any inconsistencies would result in both players informed that there was a problem, and drop the games.


This means that unless both clients have exactly the same data, when they each process a player's actions, they should both get the same result. If one is cheating and trying to switch moves, or upping the power etc., the game will notice that the HP's etc. are mismatched by the CRC and the game will be disbanded (unless the server also runs the game, in which case you can determine who the cheater is)

Yeah, well, a card game can handle quite big latencies for sure. About that cheating, doesn't your idea include a server anyhow? I mean, if there's a server-side involved, one could run the actual game engine from there and clients would just send requests and handle responses from the server. But the problem is exactly that IMHO: finding and hosting a server. And of course, single-player part would need the connection to be alive as well, and this might not be a good thing...remember Diablo 3...


On the other hand, one needs to be like, the biggest loser in the world to go to such lenghts JUST to win a game of MtG on a Pandora... :)
 
Last edited by a moderator:
I think a server would be of better use, if just the turns of every player were stored on the server in multiplayergames so players can query open matches on the server and connect to them, whenever they like and no progress is lost when disconnecting unexpectedly. So the whole gamelogic is in the client, just the states of multiplayergames are stored on the server.


edit: This could even be done on a normal webserver, which you can get from ED for free for Pandorarelated stuff :)
 
Last edited by a moderator:
Yes, webspace, where you have your own mysql, php, cgi and stuff.


Of course no root server, but I don't know if it would be needed.
 
Yeah, it'd be possible to use a webserver with a single php script (or you could split up the functions to seperate pages if you wanted) and a mysql database.


- Post page/action to send your packets as a form variable, either MIME or UUENCODE encoded package. Store this in the DB


- Request page/action returns number of outstanding packets your client needs to receive


- Get page/action reads the earliest packet for the client to process


Edit:


That would add additional latency over direct player to player connection, but as mentioned previously, not a critical factor (unless it's really slow).
 
Last edited by a moderator:
Game logic with PHP and client handling via Python? Sounds kinda complicated just to ensure no cheating...one option would be just to disregard the cheating problem. I mean, who would really do that and if, if someone would...where's the loss? It's not the most serious game in the world...
 
No, gamelogic in python only serverside datastorage in php and mysql.
 
Back
Top