Topics

1

Programming / Multiplayer roguelike implentation through MySQL???

« on: March 31, 2014, 08:29:38 PM »

Sorry if this might be a long post. Okay I want to make a multiplayer game I have tried in the past but failed. I sort of wanted to make it for 7DRL, but that is a sort of biggish project.

So I should start with concentrate and hope for people help or advice.

What tools will I use?
1. Libtcod C++ for game client
2. MySQL to store everything
3. C++ for server client
4. Oryx tileset for graphics(Through I might change this to ascii since I might just put everyone in tanks)

The problem is that I'm not that good of a programmer, but I do put a lot of effort into learning. I plan to give client only read only access to the MySQL database and give the server read and write access. Through I have to be careful with this to stop hacking. But, this would solve some of my issues like race condition if the client can just read the database and I don't have to worry about that. Just have to worry about race condition when I send a message to the server. I think using TCP might solve this, but I don't really want to use TCP.

The other problem is getting bogged down in details like race condition if I'm doing it correct is such a nightmare. Through I don't have much spare time so I will try to not think to deeply and just do stuff quickly. http://vdzserver.org/mmorl/mmoRLserver/ I'm studying this to know how to implement a multiplayer game, but I think he does things sort of bad here.

But, anyway I'm now currently creating tables in MySQL one for mobs and one for environment. It would be simple to query a list of mobs in a table and create them. It would be simple to create a new mob on the server and then do a MySQL insert into the mobs list in the database. So I'm sure it would not be that hard to create a multiplayer game like this. Just have to make sure the client is reading the information correctly and then server is writing to the database correctly.

Sorry if this sounds like a dumb plan. This is the easiest solution I can come up with. Aren't all multiplayer games just a big database?

2

Programming / New approach to AI. Need suggestion and help.

« on: March 22, 2014, 03:33:32 PM »

So I'm trying to make a game that is like DF and URR, however I first want to start with the AI instead of procedural generation of terrain, which would be easier.

I'm having a bit of a problem with mobs. In particular I'm spending the next two months on just one thing in AI, that is mob memory.

Now I've figured out what the basic information I need to store in the AI, that is map of the world that the AI currently knows, information about other mobs and if they are alive or dead, relationship information, information on items and stats of other mobs.

The problem is some information I want the mob to remember I have to take from other mobs, which I haven't figure out how to handle. Let say a mob has died, another mob comes into contact with that mob, he now needs to update his knowledge of the mob and in particular it is dead is the most important.

I've been told that I should use observer pattern I.e. if the mob who is dead has a method called isDead() that tells other mobs in it fov that it is dead. However, that would mean for every other piece of information I want to get I would have to do a similar method. So I would have to make say isStrong method to broadcast that the mob has 200 attack, or say if a mob loves another mob do I make an isLove method to broadcast this. So it becomes a mess.

So now I'm currently stuck as I have no good way of getting information from one mob to another. Observer pattern turned out to be a mess and I can't expand it.

I was wondering how could I solve this problem?

3

7DRLs / MobaRL

« on: March 14, 2014, 06:59:36 PM »

Hey guys I'm making a game that is a mix between moba and a roguelike. Because of burn out I can't balance the game and I can't add complex things like items and crafting items. However, it has mobs with interesting abilities and you can beat the game if your skilled enough.