Weekly devlogs: Rogue Legend 2
Get Rogue Legend 2
May 8 - How to make a world
This week I worked on mapgen to create an interesting and realistic landscape for you to play in. Let's take a look at how I did that:
First, it generates elevations. Since we're on an island for now, and islands form from volcanoes, this is relatively simple: have elevation increase as you make your way inwards towards the center of the island. Also have the scale of the elevation increase based on the same as well, so there's small elevation changes on the edges and bigger/steeper cliffs as you make your way towards the middle. This creates mostly flat coasts with a big mountain in the middle.
Then since it's an island, it needs to be surrounded by coasts. I use a perlin noise generation to determine oceans around the edge to create coasts, and inside the island to create lakes. To determine my biomes, I want to use a mixture of elevation and moisture to figure out where they should go, so I also calculate moisture. Moisture works similarly to elevation but in reverse: The farther you are from water, the less moisture there is. With both of these defined, I can start to figure out where my rivers and biomes are.
To run rivers I start at a high elevation point, and flow down, since I know the ocean will always be at the lowest elevation. Rivers will also prefer paths that are higher in moisture, to ensure that they run into lakes. Thus I start at a high elevation point near the middle, and choose random directions that are lower elevation and high in moisture. This way we get rivers flowing off the mountains and into lakes and the ocean.
Finally, biomes are determined. For any given spot at the map, its elevation and moisture determines its biome. High/dry spots are mountain, while low/dry spots are deserts. Wet/low spots are marshes and tropical forests, while high/wet spots are snow or the pacific northwest. Plains fall somewhere in between.
This gives me a fairly realistic representation of an island. I started on volcanic activity and towns/trade routes, but didn't quite have them done in time for the weekend, but I should be able to get them down next week. Roads are currently in, so I'll talk about those.
For roads I wanted them to sort of meander around the island, through spots that would create good settlement locations, and avoiding inhabitable or difficult locations. I defined a maximum/minimum elevation where they're allowed, and had them work their way around the island similar to rivers, but instead of preferring to flow downwards they prefer smaller elevation changes, which creates nice little loops around the island which start to look like trade routes. I ended up with two trade routes: an upper and lower, so I had to connect them up using a similar method to rivers. Starting on the upper route, flow downwards in elevation until you reach the lower route, trying to avoid water.
The next step will then be to form settlements at the most attractive spots along these routes using my existing settlement code. For now there's still a guaranteed settlement that's force-spawned in so you can do all your seed/animal/supply shopping, buuut it also means they just decided to settle anywhere so you can end up with a town in a weird spot. In my tests it did end up connected to the road though, so if you get lost you should be able to follow a road to find your way back to civilization.
Next week there should be multiple settlements at good spots along the road and I'll talk more about what determines a "good spot." Also lava and volcanic activity, and maybe waterfalls? This week's task was determined by the poll on my site, if you'd like to vote on what I work on next (or continue to work on) you can vote here: http://kassoon.com/content/forums/viewtopic.php?f=4&p=764
Evil Report
In this special and rare Evil Report we see the terrifying final moments of a piece of chicken
Continue Reading in the Dev Forums >>
November 29 - Sync, trust, relaxing pictures
The road towards multiplayer completeness continues with a few catastrophes. Unity had been crashing multiple times a day and would freeze up when clicking on stuff, so when a new version with fixes came out I jumped on it. Except the new version completely broke multiplayer, so I had to fix that. It also didn't fix the freezing. Why did I upgrade again?
Anyway, the biggest remaining issue in multiplayer was server objects, so let's chat a bit about server/client interactions and trust. I'll include some relaxing pictures. When you host a server, it tries to allow each client to handle as much as it can while doing as little as necessary on the server. It's an issue of scale, if I had the server do all the calculations for every client, and there are 30 clients connected, then that's single player x30 being run on the server. No computer can handle that, hell, some can't handle single player x1 with its current level of optimizations.
Instead the server tells clients where things are, and then leaves it up to the individual clients to handle the rest. Since maps are large, it only tells them the important stuff in their immediate vicinity. The only communication that occurs is when necessary, like when you interact with something you tell the server you interacted with it, the server then spawns in the object on its end, emulates your interaction, despawns and saves the modified object, and then tells the other clients to do the same. So, when you shake a tree, everyone around you sees you shake it and sees a stick fall out. The command is ignored if the tree can't be found. If a person is cheating and saying they're shaking a tree that doesn't exist, then things only get weird on their end which is ok because they're a cheat anyway. If they're not cheating though and the other clients just couldn't find it then you get desync issues.
Anyway, all this comes down to trust. You want the client to handle as much as possible on their own, because the more they rely on the server to resolve the more taxed the server becomes. However, since some players cheat you have to assume all clients will potentially lie to you. It's a balancing act of deciding which things are worth verifying and which things you don't care if the client is lying. To tie it back into the above, what about a stick that falls from a tree and then rolls down a hill? If I continually update the position and simulate the physics on the server, that's way too taxing. If I don't, the stick will end up in a different location on each client. How do I tells two sticks from two different trees that roll down hills and end up nearby each other apart? Use a UID for every interactable in the world. How can I tell that a player is close enough to pick it up if it's in a different location on my end? For the most part don't care, so long as it's within an acceptable range of error. How do I quickly find the stick on the server and other clients without scanning every single item in the world every time someone clicks on something? Store lists per-chunk and tell the server what chunk it's in. What if the stick rolls into another chunk on my end, but not on the client? Have a fallback spawnpoint that I also check.
That allows clients to handle physics and world spawning and interactions on their end, while also not really needing to trust them about their current state. However, some objects you can't do this with. Let's take a bucket, for instance. You can place buckets on the ground, and when it rains it will fill up with water if it's outside. I want clients to handle as much as possible, so do I just let clients tell me how full their buckets are? Well, no, that gives a cheater an advantage as they can just always say their buckets are always full of whatever they want. Buckets need to know several things every few seconds: if it's raining, if they're outside, what liquid they contain, and how full they are. So how do I handle that? If I spawn every bucket in the world, and the world is several kilometers in size and contains tens of thousands of buckets, that's way too taxing. So instead I have server objects.
The way a server object works is similar to how I normally spawn things. Each client will scan an area around them and spawn in all the terrain and objects that are within range. When an item is marked as a sever object it's not sent to the client, instead the server iterates through all the players, scans the area around them, and spawns in all the server objects that are within range. When a server object is active but has no players nearby it anymore, it despawns. Problem #2: physics. The server doesn't spawn in terrain, because again the issue of scale. If I spawned in all the nearby terrain near all the players and had 30 players that would be way too much to handle. So server objects, when spawned on the server, are floating in the void. If they become physics enabled they'll just fall, and on all the clients the object will blip into existence and then fall through the ground. There are two possible solutions: Spawn in a tiny bubble of invisible but physics-enabled terrain around each server object, or, since I have the map data I can use custom physics that doesn't rely on colliders and instead knows "there's no ground beneath me, so fall." The latter is more optimized and less taxing on the server, the former may be faster to implement. Though, that depends on if any issues arise, and the latter may cause goofy-looking physics to occur. Always pros and cons with multiplayer.
I want as few objects as possible to be server objects, and currently there are 3 that are necessary: buckets, beehives, and npcs. Buckets were pretty straight-forward and are done. Beehives need to be rewritten to find flowers in an empty void where no flowers exist, and npcs need to be able to move around, collide with stuff, and pathfind in an empty void where nothing exists. The complexity of NPC pathfinding and physics may cause me to go with the "bubble of terrain" solution instead of rolling a custom data-based physics solution. Though it's also that complexity that makes the bubble un-appealing. Let's again imagine 30 players, each in a dungeon with 10 or more enemies nearby, that's 300+ npcs all spawned on the server, each running AI and pathfinding, adding on the spawning/despawning/physics of 3000+ colliders around them on top of that? Could get messy.
Continue Reading in the Dev Forums >>
November 22 - Combat, abilities, balance
Combat is 95% done. Just need to finish the remainder of zones, target HUD, and visual effects which are all close to done. Which I'll do tomorrow, and then upload another version. Since the majority of you read this on Monday then combat is done! Yay! That means the only thing left for this milestone is the rest of the multiplayer functionality (about 80% done) and then world generation where we'll see the most drastic visual changes. [Note: New update was uploaded and combat is done now. Yay!]
There are 4 classes with 5 abilities for now. Much of the week was spent on functionality and math, but now that it's all set up it's fairly easy to add more abilities quickly so there will be many more to come. Dragoons take hits and make it difficult for their enemies to get away, all while zipping around in a steam-powered jetpack. Assassins assassinate, they fill their targets with poisons and vulnerabilities and are hard to pin down, and have a lot of burst potential. Conduits channel the elemental planes to heal and buff their allies. Alchemists control the battlefield by applying powerful debuffs and creating zones by drinking and throwing lots of potions of various effect.
This is where the allure of game design is lost on a lot of people: it requires lots and lots of math. Fortunately, I love math. As I mentioned in the last update all the abilities use vancian spellcasting, meaning you can only use them a certain number of times per day before having to rest. All the abilities are meticulously balanced based on damage, effects, casts, range, and cast/charge time. I'm pretty happy with the results, but obviously testing will weed out the issues. The system for balancing I've designed should make it pretty easy to tweak values while maintaining consistency across the board. It's easy when you're making a PvE only combat system as you can just adjust encounters as needed, for a PvP system to work everything needs to be balanced and properly countered against each other, as players will always find the dominant strategy and milk it to death.
Additionally, it's also important to create a system that doesn't require a lot of obscure knowledge, or give a major advantage for having obscure knowledge. Or be too overwhelming with your choices. When I say "obscure knowledge" I mean something like "If you swap out your weapon after using this certain ability then you'll gain a half-second cooldown advantage." That was an actual issue in another game. The issue there is only very certain players are going to know about that, and it'll give them an advantage over players that don't, making it necessary to do in order to remain competitive. So it begs the question, is having to manually do a weapon swap after that ability actually fun and engaging? No, so away it goes. Players will always be mad when you "nerf" something like this, but will also get annoyed and leave if you don't. Creating depth without also creating complexity is one of the more important aspects of game design, and also one of the more challenging.
Continue Reading in the Dev Forums >>
Check out Rogue Legend 2 or Patreon for automatic rewards!
Shout outs: Stacey, mike richard, Brian Tanner, Serafina Moon, Thomas Spence, Armand Desharnais, Trev909, Bob Goode, TODD RICHARD, Iofire, Caitlin W., Damon Carrington, Mario Pizzamiglio, Phil Mehl, Wesley Muncy, elijah D. maben, R., bruschkin, Vincent Drone, thea musing, Brian Nunziato, Matt Yates, Elisa Martinez, Ryan Flagg, Jade Arrowood, Angelo Anderson, Syn21, Dave Walker, Jonathan Lekse, Katie White, JollyGamer, Tiernan Greenman, Burlyfighter, David R Abbott, Rick Marsh, Brittany DeNicholas, Amanda Kettles, Lou Bliss, Sik Makoyi, Pythor Sen, Bryson Waits, Desedent, Irate The Pirate, Mark L, Siren, AstroLass, Lizzie, Michael Hamilton, Vedie V, Mylon Schroder, Nathan, Jordan Florez, Robert Rich, Jess, Zee Livezey, Kevin, Kerry Melton, SallySparrow132, Millergendraft, Federica Frezza, Nick Soucy, Jeremiah Walker, Bryan Sheairs, chris wilson, Max Hops, Sarah Holland, Joshua David Maddox, Jennifer Smith, Packratt, Liz Fontain, Ray Bissonnette, Joe Dalby, Matt Price, Nicholas Zamora, ShortyMcgibble, Mr. Vinclair, mtnman1979@aol.com, KFB_Patreon, eric sun, Gundar Wez, Nahellion, That Video Editor Nic, bilbens baggo, Stuart, Brysen Packer, Maxwell Mayer, Thobek, XMrMonkyx ., Miss Zilla M, Jordan Brazeal, Kyle Clark, Jake Lane, Phillip P Torchia, Stefan Gottschalk's, Remora Jewel, Connor, jeremy baisch, Daniel Edwards, Zealot23, Shane Andrews, Brandon Mußiq, CJMAXP, Festus, Lisa Tucker, KingHavok1217, Mx Charlie, Justin Snyder, Zachary Burgess-Hicks, Steve Rosenlund, Ezzela1891, John Nazario, Gordon Alexander Fallon, zachary gee, Jason Clark
Their contribution stands as a beacon of hope for all adventurers!
