DSMatticus Want Make Vidya Gaem

Discussions and debates about video games

Moderator: Moderators

Username17
Serious Badass
Posts: 29894
Joined: Fri Mar 07, 2008 7:54 pm

Post by Username17 »

In case there was any doubt, of course you can use my Asymmetric Threat fluff for whatever you want. If you need me to send in some flags or corp logos or whatever, I'd be happy to help with that.

One thing that puzzles me is how hard it is to get a decent Heroes of Might and Magic game. Ubisoft is currently putting together Heroes 7 after the disastrous and poorly received 6 (and extremely buggy on release HoMM 5), and they are currently holding polls for which six factions get into the game. Heroes 3 released with eight.

I know that making all those 3d models and getting voice actors and shit for all the factions is expensive and time consuming, but honestly Heroes players don't really give a shit about all that. Payers want more factions and more creatures far more than they want 3d models and cut scenes. Yes, there are people jumping up and down for 3d town screens and shit, but they are a tiny minority compared to the people who want the return of the Dwarf faction, which was only available as an expansion for H5 and was possibly the least inspired faction in the franchise's history (the lineup was literally just six dwarves and a palette swapped dragon). People demanding the return of factions that were ever actually interesting are of course in even greater numbers.

And the thing is, you could design a faction for HoMM in minutes. You need a Town/Castle Name, which you get out of a Thesaurus (Castle, Bastion, Bastille, Fortress, Necropolis, Shire, Labyrinth, Hideout, Bazaar, Stronghold, Temple, Hive, Estate, Dungeon, Encampment, etc.). Then you need to pick a basic race, which you get out of extensive roleplaying history (Humans, Elves, Dwarves, Orcs, Halflings, Undead, Lizardfollk, Gnolls, Dark Elves, Nezumi, Bug People, Gnomes, Troglodytes, Goatfolk, Demons, etc.). Then, having chosen a town/race combo you choose a primary cultural inspiration and a terrain, and shortlist 6-10 monsters who live in that terrain or are associated with that culture or fantasy race. Now you whittle it down into slots, with 2-4 examples of the basic race wearing different pants and the rest of the monsters taken off the short list to get the right mix of low, medium, and high level units as well as the right mix of archery, melee, skirmish, and support units. And then you're actually done with high-level design. You could literally take a bath and do the high level design for a dozen or a score of factions, and when you got out of the bath your toes wouldn't even be wrinkly.

Fiddling with game balance can be complex, and making sure spell effects are implemented properly in the face of all the monsters and their special abilities is doubtless difficult - but holy crap. It is absolutely trivial to do the main design work on the parts people actually care about.

-Username17
User avatar
Dean
Duke
Posts: 2059
Joined: Mon May 12, 2008 3:14 am

Post by Dean »

HOMM 3 is probably my favorite game of all time. It also still looks beautiful and with the exception of the intro cut scenes could have been released today without critique of its visuals.
DSMatticus wrote:Fuck you, fuck you, fuck you, fuck you. I am filled with an unfathomable hatred.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

FrankTrollman wrote:In case there was any doubt, of course you can use my Asymmetric Threat fluff for whatever you want. If you need me to send in some flags or corp logos or whatever, I'd be happy to help with that.
I figured, though explicit acknowledgement is appreciated. ICBINSR was and still is an incredibly tempting idea. A tactical stealth shooter with strategic overview elements about heist planning and heat management and a light side of "Sims: Sci-Fi Thug Life Edition" sounds awesome. But ultimately, that's a fuckton of work for a hobbyist testing new waters. If project #1 goes well enough that there's a project #2, it'll almost certainly be ICBINSR.
Funny aside apropos of nothing: today I learned that the man behind SpaceChem already made a game about building Steampunk mechs and having them beat eachother up. That would have been awkward.

Anyway, as for TBC: I don't have much to talk about at the moment. Right now, I'm just brainstorming goals, features, and brief notes about whatever into a giant document that soon I will turn into the start of a proper design doc. Also: slapping together some placeholder art and thinking about what I need to do to put a barebones engine together (questions like "what does a world look like as a data structure? As a file? How are entities managed and tracked?"). Actual coding on that should start in the next day or two, just so I can get something tangible (albeit minimal) done ASAP and build from there. But there are two features I can/should talk about, one because it was central to "why do this?" and one because radthemad sort-of-close-enough set me up for it.

Automation, Inventories, and ARMS
There are a billion and one Minecraft clones and half as many Terraria clones, and the fact that most modern entries in the genre still haven't figured out a better way to handle building large structures than manually placing or removing individual units of terrain at a time is pretty shitty. So I should probably actually talk about automation and how I think it should work.

First off, a note about the inventory: the player doesn't carry around blocks or background tiles in their inventory. They carry around blueprints which consume resources when used. Blueprints have their own pane on the inventory screen which is infinite in size (i.e. you are always carrying all of your blueprints). The goal here is to reduce inventory clutter; instead of carrying around multiple stacks of walls and tiles and furniture, you carry around stacks of incredibly fungible resources like wood which are consumed by using blueprints to place blocks, tiles, or objects. This makes managing your inventory a little simpler, especially if you're working on building something large.

In order to interact with the blocky environment around them, the player equips and uses tasks from their hotbar, and then a pair of small drones fly off to complete those tasks. For this purpose, a blueprint is the task "place the thing this blueprint makes here," but there are bare minimum at least two other tasks; remove foreground and remove background. Using a task means drawing shapes on the screen with your mouse free-style, but there should also definitely be a "drag to make a rectangle" mode. Enough things are rectangular that you shouldn't be routinely free-styling them. And the ability to include or not include interior spaces as part of the selected area is essential, because sometimes you are digging a hole and sometimes you are putting down a room that you need to be able to be inside of.

So digging a 4x10 tunnel might look something like "select 'remove blocks' task, toggle into rectangle mode, left click and drag to highlight a 4x10 area, tap 'select interior' key, right click to finalize." We can even get the one-click, single-block functionality people are used to from other games (useful for minor touch-ups) by having finalize auto-select the single block under the cursor when no other selection has been made.

Fluff-wise, the player has something called an ARMS unit (catchy acronyms are catchy) that serves both as a personal drone platform and it'll probably also end up being how you advance through the game and upgrade your character. Something of a personal tech hub that you feed technology and rare components.

Worldgen
So, radthemad mentioned terraforming, something I have absolutely no plans of adding at the moment. It's ultimately a fantasy game; the "ancient civilization with awesome technology magical trinkets" is just an excuse to give the player helper drones and add another theme of dungeons and bosses. But he also mentioned terrain axes, which is... still not really something I planned on doing. But it is close enough that I'm going to use it a clumsy segue.

I want to use a traditional elemental system (air, earth, fire, water, heart) in worldgen. The basic idea behind worldgen is to have the game create collections of playable maps at a time called continents, with the maps in those collections called regions. Continents have simple descriptors like 'fiery' or 'volcanic' or stormy,' and those descriptors change the frequency at which elemental tags occur among the regions of that continent. So for example, a 10-region volcanic continent might have A2/E8/F7/W1 total tags to distribute among its ten regions; basically, a lot of earth and fire but very little air or water.

The elemental tags of a region influence what biomes it is likely to have, but there is also a chance those tags will be applied to the various flora and fauna of the region, and when that happens those flora/fauna get random selections off a corresponding list of cosmetic differences/new abilities. So sometimes the [generic flying enemy #1] is just a [generic flying enemy #1], but sometimes it's red and breathes fire, or has a fiery sfx trail and explodes on death. Bosses get the same treatment, though their lists will probably be smaller. It is simply a fact that you fight bosses less often than you fight monsters, so if you are at all going to be able to learn how a particular boss works (and you should be) there need to be less total varieties of them.
Anyway, like I said the next couple of days involve me organizing my notes and starting on the engine. I'll probably intersperse that with breaks of "design a monster or a boss" and "pick some small aspect of the game, flesh it out on paper."
Last edited by DSMatticus on Wed Oct 15, 2014 9:28 am, edited 1 time in total.
MisterDee
Knight-Baron
Posts: 816
Joined: Tue Apr 10, 2012 8:40 pm

Post by MisterDee »

FrankTrollman wrote:One thing that puzzles me is how hard it is to get a decent Heroes of Might and Magic game. Ubisoft is currently putting together Heroes 7 after the disastrous and poorly received 6 (and extremely buggy on release HoMM 5), and they are currently holding polls for which six factions get into the game. Heroes 3 released with eight.
I imagine it's a hard balancing act between being able to sell the base game for the full amount, having some extra bonus if you buy it via Uplay, having a bit of an XBOX/PS exclusive, and selling extra factions as DLC.
radthemad4
Duke
Posts: 2073
Joined: Mon Nov 18, 2013 8:20 pm

Post by radthemad4 »

I like the idea of blueprints in your backpack. Do you think you could add the ability to make your own in some kind of custom blueprint designer? While playing minecraft I often wished I could just reuse even something as simple as a 4x4 block of whatever.

Shamus Young (The DM of the Rings guy) messed around with procedural world generation and wrote some informal articles about the development process.

http://www.shamusyoung.com/twentysidedtale/?cat=66

Project Frontier (heightmaps), Octant and Unearth (blocks) (Ctrl-f that page, lower stuff is older stuff) might be of interest. You could also check out his Pixel City project (a procedurally generated city (that page too)).

You can also peek at the source code of minetest (an open source minecraft clone). IIRC the source code of Infiniminer (the thing that inspired minecraft also made by the space chem dude) is also open now.

Incidentally, there's some info on procedural generation in general here: http://pcgbook.com/
Last edited by radthemad4 on Wed Oct 15, 2014 7:15 pm, edited 1 time in total.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

radthemad4 wrote:I like the idea of blueprints in your backpack. Do you think you could add the ability to make your own in some kind of custom blueprint designer? While playing minecraft I often wished I could just reuse even something as simple as a 4x4 block of whatever.
Anything larger than a single object is called a template, but is used exactly as a blueprint - you equip it to your hotbar and use it as a task. On further consideration, saving an area as a template will have to be a third non-blueprint task. So, yes. You will be able to copy-paste structures you find useful.
Username17
Serious Badass
Posts: 29894
Joined: Fri Mar 07, 2008 7:54 pm

Post by Username17 »

MisterDee wrote:
FrankTrollman wrote:One thing that puzzles me is how hard it is to get a decent Heroes of Might and Magic game. Ubisoft is currently putting together Heroes 7 after the disastrous and poorly received 6 (and extremely buggy on release HoMM 5), and they are currently holding polls for which six factions get into the game. Heroes 3 released with eight.
I imagine it's a hard balancing act between being able to sell the base game for the full amount, having some extra bonus if you buy it via Uplay, having a bit of an XBOX/PS exclusive, and selling extra factions as DLC.
It's all very puzzling, because of course the real difficulty is getting the AI to work, getting the skill trees to happen, make the User Interface, have the combat mechanics handle themselves, and shit like that. Adding new units is basically just a couple lines in a database and a new art object (which may or may not be a palette swap of an object you already made). Once the rest of the game is up and running, adding a new faction could be done in an afternoon. And going all hot and heavy and giving them new sound effects and a unique city art style and stuff wouldn't take that much longer.

There's no compelling reason for a new HoMM title to launch with less than 10 factions in it. And every expansion could add another five.

I'm dead fucking serious when I say you could design a whole faction from the ground up while taking a shower. And programming it into a functional game wouldn't be a whole lot more time consuming than that. The content people whine about is actually extremely easy to put into the game. Making the computer factions prioritize picking up resources is the hard part.

-Username17
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

Balance testing is best done on a per match-up basis, and so it increases in difficulty very rapidly as you add factions. But honestly the HoMM games have always been pretty simple mechanically and balance testing should not be an especially difficult affair. If you're determined to add a campaign for each faction, that's a... small-medium extra bit of work, but still not that much. If I were to guess why they put so few factions in the base game it is specifically because that leaves them room to save conceptually interesting factions for expansions, and as a result they expect their expansions will move more copies. It's the same reason day one DLC is becoming an industry standard for AAA titles: large developers are fucking assholes.

Of course, that completely fails to explain why HoMMV's first expansion was dwarves. Not exactly leading strong.
User avatar
Chamomile
Prince
Posts: 4632
Joined: Tue May 03, 2011 10:45 am

Post by Chamomile »

If I wanted to make sure I had interesting factions in the expansions, I still wouldn't assign only six factions to the main game. I'd come up with thirty, assign six of the best/most traditional or iconic ones to the main game, then shove in four of the filler leaving me with twenty leftover factions including several good ones to stuff into expansions. Ration out the remaining good factions into the expansions.
Username17
Serious Badass
Posts: 29894
Joined: Fri Mar 07, 2008 7:54 pm

Post by Username17 »

DSM wrote:Balance testing is best done on a per match-up basis, and so it increases in difficulty very rapidly as you add factions.
I could buy that sort of explanation if there was any evidence that Ubisoft was actually balance testing their games. But there really isn't. On release, not only was Heroes 6 a game that revolved almost entirely around healing where the Necropolis got more healing than you (and was thus the most powerful), while the Stronghold got less (and was thus the weakest), but critical hits weren't even implemented for any unit except a couple of Necropolis melee guys. Seriously, the critical hit animation would play and then you wouldn't do any extra damage. It got released like that. For reals.

This was seriously a game where one of the five factions had a shtick that revolved around crit fishing (the Inferno), and yet their critical hits weren't actually implemented. Can anyone seriously claim that there was any pre-release balance testing of those factions in their final states? Of course not.

My guess is that Ubisoft has committed themselves to animated cut scenes and voice actors for each faction, and they just don't want to hire more actors to do the speaking parts for more factions. I don't think it's more complicated than that.

-Username17
User avatar
Prak
Serious Badass
Posts: 17340
Joined: Fri Mar 07, 2008 7:54 pm

Post by Prak »

Another idea: I know people who actually loved the gummyships from Kingdom Hearts (and my only problem with them was the silliness of spaceships made from gummi-pieces). That should be pretty simple to make too, it's just a space-shooter where you get pieces to upgrade your ship with.
Cuz apparently I gotta break this down for you dense motherfuckers- I'm trans feminine nonbinary. My pronouns are they/them.
Winnah wrote:No, No. 'Prak' is actually a Thri Kreen impersonating a human and roleplaying himself as a D&D character. All hail our hidden insect overlords.
FrankTrollman wrote:In Soviet Russia, cosmic horror is the default state.

You should gain sanity for finding out that the problems of a region are because there are fucking monsters there.
User avatar
Meikle641
Duke
Posts: 1314
Joined: Mon May 05, 2008 8:24 pm
Location: Ontario, Canada
Contact:

Post by Meikle641 »

So, basically Robocraft but in space rather than on Mars.
Official Discord: https://discord.gg/ZUc77F7
Twitter: @HrtBrkrPress
FB Page: htttp://facebook.com/HrtBrkrPress
My store page: https://heartbreaker-press.myshopify.co ... ctions/all
Book store: http://www.drivethrurpg.com/browse/pub/ ... aker-Press
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

I've been dragging my heels a little bit since my initial burst of enthusiasm (who could have seen that coming, am I right?), but the project isn't dead by any means. As a sign of life, here's two somewhat interesting technical problems. First, some useful observations:
  • Regions (i.e. playable maps) are finite, and you can reference coordinates by their absolute position without any complications.
  • Regions are chunked into large blocks (32x32) for convenience and performance purposes.
  • Only chunks near the player are kept active for the purposes of receiving game updates.
  • Whether or not inactive and unneeded chunks are unloaded from memory is an open question, and if leaving the entire region in memory provides an elegant solution to any of the problems below then it is actually an option.
I want to implement terrain locks which place arbitrary restrictions on the ways that the player can modify arbitrarily-shaped selections of terrain. The idea would be to put them on dungeons or boss arenas until the dungeons are cleared/the bosses are defeated, forcing the player to deal with the environment as is - and eventually the player might want to use special placeables to generate locks for their own homes, protecting them from block-destroying mobs/events. That isn't to say there won't be dungeon puzzles you can circumvent with piles of dynamite or build-your-own-arena boss fights - I like both of those things, but it would be nice to have some platforming segments that aren't solved by dirt and it would be nice to be able to design some bosses with specific arenas in mind.

Most information about the world is stored on a per-tile basis, so your natural inclination might be to take that approach here, but in this case that's crazy talk. There are a lot of problems with it, but the most obvious is that a single lock might potentially affect hundreds of thousands of tiles (or more) and as such the act of adding or removing a lock to the world would require a fuck-off huge number of tile updates - and if I choose not to keep the entire region in memory then that's a bunch of time-consuming disk i/o to boot. On top of that, different locks have different effects (I did say arbitrary), so it's not binary - you have to store a way to identify which specific locks are active on a particular tile. Did I say locks? Yes I did, because the final kick in the balls is that nothing actually stops locks from overlapping. Basically you're left with declaring that you will have X maximum locks per region and then assigning X bits per tile in which each bit represents a particular lock being on that tile, and then performing a bunch of tile updates each time a lock is added or removed from the game world. It's pretty terrible.

I think one of the best solutions is to keep a table of chunk:locks:offsets, such that given a chunk you can retrieve a list of locks active on that chunk AND the offsets that match the chunk's (0,0) to a position on a model representing the shape of that lock - so you can overlap the model directly onto the tile representation of the world without actually making it a part of the tile representation. That makes adding/removing locks from the game world completely trivial, and the extra work involved in determining whether or not a block is destroyed or not is only one extra check per lock active on that chunk - similarly trivial in all normal cases.

Now here's a problem that I haven't decided how I want to tackle yet: wiring, a la Terraria's wiring or Minecraft's redstone. Wiring shit together is the primary reason I haven't decided whether or not I want to keep the entire region in memory yet. You'll note that if you unload chunks as they aren't needed, there's no way to guarantee that whatever's on the end of any particular wire is actually available to interact with. Terraria handles this by keeping the entire world in memory at once. Minecraft handles this by not handling it at all, and just letting your circuits break as pieces of them are unloaded. I have no idea what Starbound does.

Here are the possible solutions:
1) Ignore it. Large circuits break because you can't load them all into memory at once. Lame.
2) Terraria it. The entire region is kept in memory, meaning you can read/write to any part of it at any time. This has the largest memory footprint, but honestly it shouldn't be that large. At 4 bytes per tile (incredibly generous), even a large Terraria world should only be ~75 MB in memory. Weirdly, the difference between opening a small Terraria world and a large Terraria world is three or four times that and I have no idea why. Seriously, I don't. The extra data they're trying to hold is just not that large. I can only assume they're keeping some intermediate processed graphics assets related to distant parts of the map in memory instead of disposing of them and recreating them as needed, which I won't be doing because that's what my chunking system is for. There's no reason I couldn't have four players running around four different regions and still be completely within reasonable RAM limits.
3) Hybrid it. The wiring layer will by far be the smallest layer, so if I pull the wiring layer out from the rest of the data and keep only the entire wiring layer in memory, I can keep large circuits working even as I drop the chunks which contain them and save a bunch of memory.

I'm leaning towards 2, because if it isn't broke why the hell am I trying to fix it. But if it turns out to be a problem later, it'll be a lot more annoying to try and change it then - so I am thinking about it a little more (and posting here) before I commit to anything.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

I also want to talk about content themes, in that I have absolutely no idea what kind of themes I want to use for the game's content and that is making it very hard to come up with ideas for enemies, bosses, items, dungeons, tile sets, and whatever. Obviously, the wildlife wants to murder you. This is a videogame, and that is how the wildlife do. Obviously, there are other people, and a bunch of them probably want to murder you too. Obviously, the ancient ruins I mentioned last time are full of robots golems and traps that also want to murder you, and maybe more scavengers/bandits who still want to murder you. But I would like more than that, and that means I need to flesh out the lore a bit and add shit to the setting for the player to interact with (and by interact with, I of course mean more murdering). I am very open to ideas or suggestions on this front. And by that, I mean please give me shit I can steal from you.

Speaking of stealing shit from people, I always thought that the King with Three Shadows was an awesomely evocative name and the story about how an entire kingdom disappeared into hell because their king was an evil douche is a surprisingly convenient explanation for why the landscape is scattered with the abandoned ruins of a technologically magically advanced civilization. It's also a decent prompt for alternate ruins and alternate biomes full of tainted magitech items, tainted golems, tainted monstrous wildlife, demons, the occasional portal to a secondary dungeon full of fire and brimstone, and a late-game boss. Though I can achieve the same results with the Stereotypically Evil Grand Vizier or whatever, so it's not strictly necessary to steal the KwTS himself, but rereading that in AS on unrelated matters is what gave me the idea. Also, one of the early game bosses clearly needs to be a crazy factory AI that drops its core when defeated, allowing you to install it into your house as an antagonistically helpful NPC vendor who unlocks the recipes needed to start your transition from low fantasy hobo swinging iron swords to (magic) sci-fi hobo swinging (magic) sci-fi swords. More on tiers of play and what I think they mean at some indeterminate point in the future.

But other than wilderness, generic NPC's, and the aforementioned ancient ruins and the robotic nemeses therin, I really have no clue what to put in the game, and that is something of a problem.
User avatar
Dean
Duke
Posts: 2059
Joined: Mon May 12, 2008 3:14 am

Post by Dean »

Have you ever played A Dark Room? I feel like that has exactly the vibe you want for your game. Having a minecraft version of A Dark Room is a thing a lot of people would be really into.
DSMatticus wrote:Fuck you, fuck you, fuck you, fuck you. I am filled with an unfathomable hatred.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

Dean wrote:Have you ever played A Dark Room? I feel like that has exactly the vibe you want for your game. Having a minecraft version of A Dark Room is a thing a lot of people would be really into.
A Dark Room has a bleak, post-apocalyptic Fallout vibe, and while there are the forgotten ruins of an advanced civilization literally beneath your feet I was aiming for a fantasy RPG world of (mostly) happy, colorful villages full of turnip farmers. The end of the world is old news, and the wheels of time have been turning long enough since then that basic iron age civilization is back up and running. But I could just scrap that idea and go A Magical Dark Room such that the recent apocalypse is a pressing concern and the player is responsible putting their little part of the world back together by founding and maintaining a village. It's something I will think about, but either way interacting with and directing the development of NPC villages is on the planned features list.
Last edited by DSMatticus on Wed Nov 26, 2014 12:59 pm, edited 1 time in total.
radthemad4
Duke
Posts: 2073
Joined: Mon Nov 18, 2013 8:20 pm

Post by radthemad4 »

Is your game 2D or 3D? Asking both in terms of graphics and world space. You're referring to tiles rather than blocks or cubes, so I'm guessing Terraria style 2D, but you also refer to them as chunks sometimes which could be either.
DSMatticus wrote:
  • Regions (i.e. playable maps) are finite, and you can reference coordinates by their absolute position without any complications.
  • Regions are chunked into large blocks (32x32) for convenience and performance purposes.
  • Only chunks near the player are kept active for the purposes of receiving game updates.
  • Whether or not inactive and unneeded chunks are unloaded from memory is an open question, and if leaving the entire region in memory provides an elegant solution to any of the problems below then it is actually an option.
If you're only updating the area around the players, I don't get why you're making the world finite, unless you're planning on designing levels rather than PCGing them. If you're putting the whole thing in memory and updating everything, then yeah, finite is probably a good idea.
DSMatticus wrote:I want to implement terrain locks which place arbitrary restrictions on the ways that the player can modify arbitrarily-shaped selections of terrain. The idea would be to put them on dungeons or boss arenas until the dungeons are cleared/the bosses are defeated, forcing the player to deal with the environment as is - and eventually the player might want to use special placeables to generate locks for their own homes, protecting them from block-destroying mobs/events. That isn't to say there won't be dungeon puzzles you can circumvent with piles of dynamite or build-your-own-arena boss fights - I like both of those things, but it would be nice to have some platforming segments that aren't solved by dirt and it would be nice to be able to design some bosses with specific arenas in mind.
How do players identify locked blocks?
DSMatticus wrote:I think one of the best solutions is to keep a table of chunk:locks:offsets, such that given a chunk you can retrieve a list of locks active on that chunk AND the offsets that match the chunk's (0,0) to a position on a model representing the shape of that lock - so you can overlap the model directly onto the tile representation of the world without actually making it a part of the tile representation. That makes adding/removing locks from the game world completely trivial, and the extra work involved in determining whether or not a block is destroyed or not is only one extra check per lock active on that chunk - similarly trivial in all normal cases.
Could you elaborate on this? I don't understand.
DSMatticus wrote:Now here's a problem that I haven't decided how I want to tackle yet: wiring, a la Terraria's wiring or Minecraft's redstone. Wiring shit together is the primary reason I haven't decided whether or not I want to keep the entire region in memory yet. You'll note that if you unload chunks as they aren't needed, there's no way to guarantee that whatever's on the end of any particular wire is actually available to interact with. Terraria handles this by keeping the entire world in memory at once. Minecraft handles this by not handling it at all, and just letting your circuits break as pieces of them are unloaded. I have no idea what Starbound does.

Here are the possible solutions:
1) Ignore it. Large circuits break because you can't load them all into memory at once. Lame.
2) Terraria it. The entire region is kept in memory, meaning you can read/write to any part of it at any time. This has the largest memory footprint, but honestly it shouldn't be that large. At 4 bytes per tile (incredibly generous), even a large Terraria world should only be ~75 MB in memory. Weirdly, the difference between opening a small Terraria world and a large Terraria world is three or four times that and I have no idea why. Seriously, I don't. The extra data they're trying to hold is just not that large. I can only assume they're keeping some intermediate processed graphics assets related to distant parts of the map in memory instead of disposing of them and recreating them as needed, which I won't be doing because that's what my chunking system is for. There's no reason I couldn't have four players running around four different regions and still be completely within reasonable RAM limits.
3) Hybrid it. The wiring layer will by far be the smallest layer, so if I pull the wiring layer out from the rest of the data and keep only the entire wiring layer in memory, I can keep large circuits working even as I drop the chunks which contain them and save a bunch of memory.

I'm leaning towards 2, because if it isn't broke why the hell am I trying to fix it. But if it turns out to be a problem later, it'll be a lot more annoying to try and change it then - so I am thinking about it a little more (and posting here) before I commit to anything.
While 3 is probably the right choice, you could try out 2 for a bit and see how it goes. Do a bit of load testing with large numbers of extremely complex circuits. Go with 2 if it works fine even with ludicrous numbers of extremely complex circuits, before considering 3.


How about you determine the nature of any groups of people you find via extremely simplified parameters. e.g. collectivistic vs individualistic culture, more active during daytime or night time, sedentary vs hyperactive, extravagant vs miser, etc. Maybe even determine their technology level and community size (village, town, city, etc.) randomly. They may encounter other communities and become allies or enemies depending on how much their values match up (you could randomize the priority each community puts on these values, how much individuals in the community differ from these values, etc). You can ally with, oppose, trade with and influence these communities.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

radthemad4 wrote:Is your game 2D or 3D? Asking both in terms of graphics and world space. You're referring to tiles rather than blocks or cubes, so I'm guessing Terraria style 2D, but you also refer to them as chunks sometimes which could be either.
It's 2D. I described it as a Terraria-clone at some point, but I guess with including Minecraft in my joke title I could have been clearer. Chunking refers to the Minecraft and Starbound practice of dividing the world into equal-sized groups of blocks or tiles or whatever. In the interests of future clarity (I hope I've been using these terms consistently so far, but no promises), a tile is all of the world data for a specific coordinate; foreground, background, and wiring. Block is the term for a foreground object. Wall is the term for a background object. There's no nifty name for "whatever goes in the wiring field." Doodad?
radthemad4 wrote:If you're only updating the area around the players, I don't get why you're making the world finite, unless you're planning on designing levels rather than PCGing them. If you're putting the whole thing in memory and updating everything, then yeah, finite is probably a good idea.
Reminder/clarification first: I'm taking a Starbound-esque approach here. Individual playable maps (regions) are finite, but you can travel between an effectively infinite number of randomly-generated regions in-game (organized further into continents). In part, having multiple finite regions instead of one (or multiple) infinite region(s) is just a way to help players organize their exploration of the world and travel quickly between different interesting locations they've found.

But also, having finite regions which are stored entirely in memory allows you to read/write to any part of the region without any meaningful additional overhead or disk i/o, which is useful for shit like wiring as I explained below - the only real cost is a slightly larger memory footprint. But the worlds are still large enough that doing ordinary game updates on every single chunk is a ridiculous waste of CPU cycles in the game update loop. You'd want to handle things like crops growing on the other side of the map with locally-stored timers that just get advanced a lot all at once when the chunk gets marked active again.
radthemad4 wrote:How do players identify locked blocks?
Hovering the mouse over any locked tile with a tile-modifying task/item should throw up a lock icon somewhere on the UI - red if the equipped item would fail, blue if it would succeed. Hovering over the lock icon itself will give you the details of the lock, and to that end the icon fades out after a brief delay once the criteria for displaying it are no longer met (and you aren't hovering over the icon itself, of course) instead of disappearing immediately.
radthemad4 wrote:Could you elaborate on this? I don't understand.
Imagine that you have a lock object which stores its own shape as a grid using its own local coordinate system. If you want to overlay the shape of the lock onto the model of the world (so that you can determine which world tiles fall under the shape and are 'locked'), the only thing you need is the offset between the two coordinate systems; i.e. lock 3's (0,0) is world's (581,402), so in order to check if world's (582,403) is locked you query lock 3 about its (1,1).

But if you stopped there, in order to determine if a particular tile was locked you'd have to iterate over every single lock in the region. Instead of doing that, you determine which chunks are affected by a lock during its creation and add that information to a dictionary/map with the chunk as the key and a list of locks as the value. Given a chunk, you get a list of locks that are affecting any of the tiles in that chunk and the offset that matches that chunk to the lock, and you only have to check those locks. It's a way to prune the list of locks we have to iterate over for each tile interaction.

At second glance, the offsets for the lock objects should obviously be stored in the locks themselves. Coordinates are indexed absolutely, so you don't need chunk-specific offsets.
radthemad4 wrote:While 3 is probably the right choice, you could try out 2 for a bit and see how it goes. Do a bit of load testing with large numbers of extremely complex circuits. Go with 2 if it works fine even with ludicrous numbers of extremely complex circuits, before considering 3.
Circuit complexity shouldn't be an issue. I'm leaning towards complex devices and information-rich transmission events, so the wiring itself should be fairly simple. I'm definitely not going to go with the Minecraft approach of managing your own system clock. That's sort of fun in a horrible, geeky way, but fuck no to that. And worst case scenario, you can abstract away the wiring itself into a map of nodes with edges representing connections, which you only have to change when the player changes the wiring.

I'm actually really tempted to go full wireless, such that instead of laying down wires you intermittently throw down wireless relays and control communication by setting listen and transmit frequencies/channels in an object UI. Not just because it's lazier, but because it's awesome. That would get rid of the wiring layer entirely, and wireless devices would just be special foreground interactables like containers or whatever.
Last edited by DSMatticus on Thu Nov 27, 2014 6:51 am, edited 1 time in total.
radthemad4
Duke
Posts: 2073
Joined: Mon Nov 18, 2013 8:20 pm

Post by radthemad4 »

DSMatticus wrote:Hovering the mouse over any locked tile with a tile-modifying task/item should throw up a lock icon somewhere on the UI - red if the equipped item would fail, blue if it would succeed. Hovering over the lock icon itself will give you the details of the lock, and to that end the icon fades out after a brief delay once the criteria for displaying it are no longer met (and you aren't hovering over the icon itself, of course) instead of disappearing immediately.
I'd probably put in a button you can press and hold that makes all locked blocks glow. That way, I wouldn't have to hover over an entire region 'just in case there's an unlocked block I can dynamite somewhere'.
DSMatticus wrote:Imagine that you have a lock object which stores its own shape as a grid using its own local coordinate system. If you want to overlay the shape of the lock onto the model of the world (so that you can determine which world tiles fall under the shape and are 'locked'), the only thing you need is the offset between the two coordinate systems; i.e. lock 3's (0,0) is world's (581,402), so in order to check if world's (582,403) is locked you query lock 3 about its (1,1).

But if you stopped there, in order to determine if a particular tile was locked you'd have to iterate over every single lock in the region. Instead of doing that, you determine which chunks are affected by a lock during its creation and add that information to a dictionary/map with the chunk as the key and a list of locks as the value. Given a chunk, you get a list of locks that are affecting any of the tiles in that chunk and the offset that matches that chunk to the lock, and you only have to check those locks. It's a way to prune the list of locks we have to iterate over for each tile interaction.

At second glance, the offsets for the lock objects should obviously be stored in the locks themselves. Coordinates are indexed absolutely, so you don't need chunk-specific offsets.
You could also put a list of lock references on each tile and have locks added/removed from it when they're created/destroyed, so you can call tile.getLockList() or something whenever you need to see which locks are linked to a tile. More overhead perhaps, but probably easier to implement.
DSMatticus wrote:I'm actually really tempted to go full wireless, such that instead of laying down wires you intermittently throw down wireless relays and control communication by setting listen and transmit frequencies/channels in an object UI. Not just because it's lazier, but because it's awesome. That would get rid of the wiring layer entirely, and wireless devices would just be special foreground interactables like containers or whatever.
Yeah, that's a great idea.

Are you using Quadtrees? Those could help you with ignore large areas that don't have any dynamic elements.
Last edited by radthemad4 on Thu Nov 27, 2014 12:31 pm, edited 2 times in total.
User avatar
silva
Duke
Posts: 2097
Joined: Tue Mar 26, 2013 12:11 am

Post by silva »

DSMatticus wrote:I Can't Believe It's Not Shadowrun:
Courtesy of Stahlseele, though the idea has occurred to me before - a 2.5d/isometric/whatever tactical stealth shooter set in a randomly-generated open world sandbox. You play a team of Shadowrunners in a cyberpunk world with magic and elves in an open city.
Basically this already exists and its called Shadowrun for the SEGA Genesis console. It would be just a matter of improving its gfx and increment some more functions. Perhaps creating a mod for it ?
Last edited by silva on Thu Nov 27, 2014 10:36 pm, edited 1 time in total.
The traditional playstyle is, above all else, the style of playing all games the same way, supported by the ambiguity and lack of procedure in the traditional game text. - Eero Tuovinen
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

radthemad4 wrote:I'd probably put in a button you can press and hold that makes all locked blocks glow. That way, I wouldn't have to hover over an entire region 'just in case there's an unlocked block I can dynamite somewhere'.
Good call.
radthemad4 wrote:You could also put a list of lock references on each tile and have locks added/removed from it when they're created/destroyed, so you can call tile.getLockList() or something whenever you need to see which locks are linked to a tile. More overhead perhaps, but probably easier to implement.
That is the solution I discussed first, mostly to point out the problems. First and foremost, storing the information per-tile means that the creation/removal of a lock involves updating an absolute fuckton of tiles (roughly a thousand times as many tiles as chunks, because 32x32). But also, regions are tens of millions of tiles and pointers are 4 bytes (8 bytes in 64-bit). You're easily talking about an extra 100 MB just to store null pointers for a region with no locks at all, and regions with locks will be larger still. You'd double the amount of memory used by a region object, in my case.
radthemad4 wrote:Are you using Quadtrees? Those could help you with ignore large areas that don't have any dynamic elements.
As I've said the world is chunked, so I can use the chunking as an initial step for collision pruning whether the collisions in question are concrete as in "is player touching monster?" or way more abstract as in "are these wireless devices in range of one another?" I don't actually have any experience with collision detection, so I really have no idea whether or not chunking will be sufficient (I'm guessing no) and probably won't have any idea until I have a bunch of entities bouncing around on screen doing things and taking up CPU cycles.

But on the plus side, it will be just as easy to add additional collision pruning (i.e. quadtrees) now as it will be the day before this project is finished (release is currently scheduled for Q2 of the apocalypse - a refreshing break from all the fire, brimstone, and Angry Face Jesus) - it's a total blackbox and the acceptable inputs/outputs are so obvious the specs write themselves. Nothing is ever going to really care about the specific implementation of collision pruning, so I can optimize to meet my needs as I find my needs going unfulfilled.

Note to self: Angry Face Jesus would make a fantastic boss battle.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

So I've been doing a lot of thinking about the setting, and here's some stuff. Spoilers contain non-narrative notes.

Overview
Oreia is a world of countless divided landmasses adrift in a seemingly endless sea. Much to the frustration of cartographers, the positions of these landmasses are not fixed - from the moment the last sliver of shore slips beneath the horizon, you are lost and not even the stars may guide you to your intended destination. Despite this, travel across the sea is both common and reliable. It is said by sailors that the sea remembers, and arcanists would add that it listens to those who can make themselves heard.

Frequent travel between two landmasses carves a path in the sea that "draws" ships into it, and experienced captains can usually find their intended lane without even being able to explain how. The sea is complicated enough to baffle scholarly explanation, but not so complicated that it can defy the wisdom of experience. Needless to say, captains are a superstitious lot, as their inability to explain their successes causes some very bizarre causal attributions. An accomplished arcanist can send any ship anywhere he has sufficient knowledge of, though no one would ever call this process simple or inexpensive.
<Notes>
Landmasses (previously called continents; these are collections of the playable maps called regions) are generated in graph-like clusters. The high-level information for a cluster (including the biomes, monster varieties, dungeons, and bosses of every region in every landmass contained within) is generated when you first enter the cluster, and the specific placement of tiles for a specific region is generated only when you finally enter that region. Travel along the graph's edges is essentially free, but by building a special device and expending some resources you can travel without an edge to any landmass you've "learned" about. You can learn about landmasses from NPC's, books, and so on. If you're wondering what the point of this is, when you learn about a landmass you also get a bunch of information about what's on that landmass, so you can make informed decisions about where you want to explore next as opposed to accepting the whims of the RNG. You can always "abandon ship" and end up in a new random cluster, if for some reason you feel that is necessary.
</Notes>
According to well-read men with very long beards, Oreia was not always fractured as it is now. They will tell you that once, long ago, the world was whole and men could travel from one end to the other several times in their lifetime, and that no matter where they stopped on their long journey they would owe allegiance to the same sovereign. Yet not a single one of these scholars can tell you what happened to make "then" become "now," and many cynics will observe that the lands in the sea are by all estimates so innumerable that they could not possibly be combined into a single landmass traversible by land. Oreia is currently both less and more than its history suggests.
<Notes>
Landmasses are generated using two seeds; the first is simply a pseudorandom number used to fuel the procedural generator, and the second is best described as a "distance from center." There's obviously no actual physical center, but this second seed serves as both a minimum difficulty, inverse likelihood of civilization, and weird factor. It's intended to give the vibe that you're venturing into lands that aren't real and never were; they're loosely-inspired parodies and imitations.
</Notes>
The People of Oreia
There are four major intelligent races among the lands of Oreia; humans, dryads, jotun, and vessels.

Humans are [exactly what you would expect goes here].

Dryads have bark for skin and leaves, flowers, or vines for hair. They prefer to live in forested areas, though they have no special love of nature and they chop down trees to create clearings and build homes exactly like humans slaughter pigs for food despite the fact that both have pink, fleshy outsides. There are a lot of myths surrounding dryads and a supposed reverence for nature, and dryads find these myths absolutely perplexing. Within dryad society, diplomatic envoys are considered a responsibility of women with status, which is the cause of yet another myth - that there are no male dryads. There are, though when speaking specifically of male dryads the proper term is treant.

Jotun are giants. They are approximately one-and-a-half times as tall as a human, and they prefer to live in small, isolated communities deep within the mountains. They can subsist on stone, but it is exactly as appealing to them as it sounds to non-jotun. They live very long barring misfortune, but even their histories do not contain any insight into the distant past of Oreia. There are four tribes of jotun; fire, frost, storm, and stone. Despite this internal division, conflict between tribes is only slightly more likely than conflict within them; they are still one people, and individual communities are rarely perfectly homogeneous.
<Note>
Ideally, all four races will be playable. Jotun will automatically "stoop" to fit through human-sized spaces, and other races don't get to stoop or crawl because reasons. So yes, there are still disadvantages to being bigger (like being a bigger target), but all the playable races will fit in the same spaces even if one looks a little ridiculous doing so. It's not like pregen dungeon segments are going to be designed to scrape human/dryad heads, so for the most part jotun are just closer to the ceiling and have to stoop through doors - seems right.
</Note>
Vessels are artificial containers for artificial souls - they are slumbering golems created before the sundering of Oreia who wake only when disturbed or when the restlessness of their imprisoned soul finally overcomes their body's programming. They were created to be servants, and most vessels suspect as much. Being freed from that fate has made their existence no less cruel. Every vessel wakes without purpose, and when they look to their natural counterparts for lessons on how to find such a purpose they find nothing to be learned; every vessel is without family, community, hunger, or thirst. Most become purposeless wanderers or hermits, though rarely they will settle into other communities or even form communities of their own.
For the primary races, I am torn between randomizing simplistic communities or making a handful of elaborate preset grayhat and blackhat cultures that communities get to pick from and have some meaningful lore and named NPC's for each. I'll probably go random, as it captures the scattered, disconnected world vibe I'm going for.

But at the very least, there are four organizations/forces which will absolutely be included mostly as is:
[*] The environment. There are things in the woods. They want to eat you. Others are delicious and you want to eat them. Some are both.
[*] The ruins of [insert empire name here]. I'm going with the KwTS-inspired fluff of a demonic bargain which disappeared the empire and sundered the world. I will probably use an original idea for the particular sovereign, because... that feels less cheap.
[*] Some demonic defilement of the aforementioned ruins and surrounding biome, as well as the occasional portal to hell, and the demon with whom the bargain was made.
[*] Undead. There are going to be undead, and they're going to have a common source; the Twice-Slain King. Here's what I've got right now:
One of the last great threats to the [insert empire name here] were the armies of the Twice-Slain King. Somewhat misleadingly, the Twice-Slain King is not one man slain twice; it is a pair of twins slain once each. When they learned that their father, the sitting king, intended to cede sovereignty to the [insert empire name here] in exchange for status as a governor, they slew him and usurped his throne in order to declare war. It was this war which earned them their title, as each twin briefly held the throne.

By whatever mechanism, the Twice-Slain Kings have returned to some semblance of life, and it is their spite for the world which animates and drives undead throughout Oreia. In life, the twins and their armies were proud jotun, but in death that means nothing to them and their hatred can drive humans and even dryads to rise from their graves.
Last edited by DSMatticus on Thu Dec 04, 2014 12:58 am, edited 6 times in total.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

Fucking hell, I double posted, didn't notice, and was fixing half of my mistakes in one post and half in the other.
User avatar
Judging__Eagle
Prince
Posts: 4671
Joined: Fri Mar 07, 2008 7:54 pm
Location: Lake Ontario is in my backyard; Canada

Post by Judging__Eagle »

Related to the issue of "building installations" with use of "blueprints"; the currently in Alpha game "Factorio" has blueprint aspects to it.

The game final/ideal state of play is a factory complex that can create a new factory complex at a differentl location on a potentially infinitely large world in 20 minutes. Getting to that point is much more challenging however. While the game has conveyor belts and players can eventually get automated drones to shuffle resources; the game also requires laying of rail networks and subsequent signal installation so that your trains don't crash into each other.

For a game in 0.11.X Alpha; it's more complete than many finished games. It's easily torrented if you need to research its details. While the playlists of tutorials on Youtube are helpful, optimizing and making mistakes on your own teaches other lessons.
The Gaming Den; where Mathematics are rigorously applied to Mythology.

While everyone's Philosophy is not in accord, that doesn't mean we're not on board.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

I've been thinking about procedural generation lately (DSM's Terraria clone slated for release in two thousand and never!), and something's been puzzling me. I figured I'd ramble about it here in my dead gamedev thread, because maybe someone will find it a little interesting or have their own two cents to throw in. It's not related to anything I'm working on and/or procrastinating working on at the moment, it's just a random musing.

Let's talk Minecraft, because it's an easy example. Minecraft worlds are divided into 16x16 chunks which stretch from the bottom of the world to the top, and each chunk is generated only when the player encounters it. Note that because chunks are generated only when they are encountered, you cannot know which (if any) adjacent chunks exist yet, so each chunk has to be generated independently from its neighbors. But despite being generated independently, it's very important each chunk blends seamlessly with its neighbors and looks like part of a larger whole. For terrain and caves, this turns out not to be a problem. I don't really want to get into the details, but picture the graph of a sine wave in your head - that's a smooth unbroken curve, and it will always be a smooth unbroken curve. Terrain generation is considerably more complicated than that, but that's the very very basic principle behind it. If you can put together a function whose 3d graph is a reasonably smooth height map, you can just use that as your terrain. Voila.

Buuut there are parts which are a little more complicated. Let's consider something as simple as a tree. A tree isn't a single block (a point). It's not even a single vertical pillar (a line). It's a three-dimensional shape, and that means that it can occupy two (or more) different chunks simultaneously. Your program has to recognize the need to generate a tree regardless of which chunk is encountered first and/or generate that tree into multiple chunks - some of which may not even exist yet. Is there any way to handle this pesky border-straddling stree without discarding the perfectly independent generation of chunks? If you're willing to discard perfectly independent generation in favor of nearly perfect independent generation, will the solution still work when I point out that the problem extends from small trees to gigantic castles?

I thought it was an interesting problem. I can sort of see how I'd handle it - set aside the first X passes of procedural generation to note basic details of a very large area, and then in subsequent passes fill in the actual terrain of the much smaller area you would normally cover. As long as none of the "basic details" I'm worrying about are themselves larger than the distance between the boundary of the smaller generated area and the larger sketched area, it works. And this also appeals to me because it's a way to make large scale modifications to the terrain that you couldn't do if you were only focused on handling one chunk at a time, which you could use to make worldgen less repetitive. It's the sort of thing I'd be tempted to do even before considering the "multichunk structure" problem, so that it could be used to handle multichunk structures is just a bonus.

I don't know what Minecraft does to slap down trees or temples or whatever else the game has. I don't know what certain Minecraft mods do when they add absolutely fuck-off-huge dungeons. I strongly suspect it's not the same thing I'm talking about, so that makes me curious.
Last edited by DSMatticus on Sat Jan 09, 2016 7:55 am, edited 1 time in total.
Post Reply