• Content count

  • Joined

  • Last visited

Community Reputation

104 Neutral

About ne_xim

  • Rank
  1. Non-Permanent Perma-Death

    Resurrection is a possible means of preventing permadeath, but I feel it is going to wind up only benefiting hardcore players in the first place, and alienating your casual userbase. I once saw a method that worked well: inheritance. Once your character died, you could inherit their legacy with your next character. You would keep a portion of their experience points and if you could get to their body, their items. This worked very well for an mmo I used to play. My game has a sort of permadeath, but you have to enter the permadeath metagame servers to access it. I plan on breaking my sandbox game up into multiple servers, each with different rules. One is pvp, one pve, one pvevp, and one is hardcore mode (no-rules pvp permadeath.) Since our world has an end goal, when the map is conquered by the players, the world gets rebooted and all old player data is offloaded to the pvp or hardcore servers. These servers are all connected, and can be traveled to and from using map edges, but certain players are restricted from travel back to the pve server. Only players from the same reboot of the world can go back after leaving the pve server, meaning old characters are stuck on the pvp server. Pvp server resets offload their userbase to the hardcore server after the age ends, and players on the hardcore server will permanently die when they die without any karma. Karma is lost with muders, theft, and vandalism. Players who engage in pvp actions with members with a higher karmic score with themselves outside of their territory will eventually lose all their karma and be permanently killed.
  2. World of Kallen

    Hey, I'm working on a pretty similar project to yours, from what it sounds like. I'm bulding it in 3D with 2D sprites for objects, and a heavily pixelated approach to the texturing, the game is played from an isometric free camera view with the option of a 1st person perspective. I'm writing the client engine in unity and the server in mono/c#. Mine's not really an MMO, though, by definition. It's a sandbox MOG with deep MMORPG elements, sim elements, and RPG action shooter elements. I, like you am splitting gameplay paths to builders (outpost/town makers), adventurers (dungeon crawlers), and crafers/merchants. Maybe we could talk a little deeper about game design elements. I think our ideas might be able to feed off of one another.
  3. I'm playing with a terrain generator and renderer in Unity3D. The terrain renders properly, assuming it is passed reasonable values. I'm attempting to construct a world generator using a set of filters and a port of the libnoise code. (Perlin generator, mostly.) I'm attempting to wrap my head around the idea of biome generation using complex perlin noise filters. I'm aware that generating terrain from perlin fields on the fly takes a lot of time. I know you can lessen the time by pre-rendering the terrain, but this trades cpu for memory and network usage. Instead of streaming world data to the clients, I will be using a perlin noise generator on the client side to generate the terrain. Are there any serious pitfalls to avoid with trusting the client to generate the terrain on the fly? Under what conditions would this be problematic? I'm currently trying to figure out how to handle world generation as a whole, though. I'm doing some pregenerated stuff using a voronoi model of the world on the server, and then calculating the biomes of each cell by a quick noise elevation model, compared to an A* distance map from water for moisture, and a reflected gradient for temperature. From these three variables, I am getting the biome of an entire voronoi cell. All of this data is pre-generated, and each pixel in the model corresponds to a 16x16 tile block on the client. Only the minimum amount of data will be sent to the client to build the local region. On the client end, this means I don't have to do much sanity checking, as the local terrain is not wildly variant. This means I can generate data from the inside out, as the server has met the client halfway, generating a plain world from the outside in. The client takes the data the world has sent the client, and it uses it to locate a preprogrammed noise filter. Each biome uses its own filter, saving time pulling data from each filter, as data only needs to be passed through the biome filter the tile belongs to, or possibly a neigboring biome if it differs. I'm running into a few conceptual problems: How to store changes to terrain, such as cut down trees, player-made roads, etc. I could store it as a raster, but taking 16^2*2B + 17^2*2 bytes of data per tile just to save the data of a single tile change seems inadequate. Is there a more effective way to compress and process regional data pertaining to tile or vertex altitude changes? Also, in addition to how to store the regional data, what would be the different ways I could store terrain on the server? Would it be better to break up the world data into raw map files and stream them into memory when needed, or would it be better to put the data into some kind of database. If database, what exactly would be the optimal method of storing it within a database? What would the pros and cons be of either? Second, is there a good resource available for generating random terrain? I've been manually experimenting with how to use filters to randomly generate swamps, mountains, hills, plains, etc, but I'm really not seeing a lot of good documentation on how to get specific terrain effects out of a generator. Any documentation, or examples would be awesome. Thanks, Ne_xim