Search Unity

Games [Devlog] ink & Paper Engine: Lord Ragnavaldr and the Wishing Stone

Discussion in 'Works In Progress' started by CarterG81, Sep 6, 2019.

  1. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Game Title smaller.png
    Paper Engine
    Paper Engine is a middleware tying together Ink by Inkle & Unity Engine, but with a lot of extras. Ink is typically a text-based game, with very limited artwork & game systems. Paper Engine's goal is to add in a lot more game elements to writing in Ink, without you ever having to actually leave Ink!
    It is also designed to be fulled moddable, allowing the player to create their own stories and games using all the supported features of Paper Engine. Features will initially support our own game, Lord Ragnavaldr and the Wishing Stone, and later to support our other game Away Mission with Paper Engine 2.0, but depending on demand may receive additional features inbetween.

    "Lord Ragnavaldr and the Wishing Stone"
    A story about an elderly knight at a time of endless civil war who goes on a delusional personal quest to find a magical stone based only on a legend, a peaceful dream, and a dark desire to end the hopelessness that has put him on the edge of total destitution of the mind. A story set in

    The World of Emergence

    Inbetween "Paper Engine" & our game "Lord Ragnavaldr and the Wishing Stone", is the World of Emergence. This is a large amount of generic content, world building, hextiles, characters, and story which help to create Emergent Gameplay. Ink is a scripting language which specializes in dynamic storytelling - weaving together bits and pieces of story in a very powerful way so no single encounter is ever the same.

    The Weaver's Loom

    To create our game, "Lord Ragnavaldr and the Wishing Stone", we use The Weaver's Loom, a set of Content Creation Tools which we will also release as Mod Tools. The Weaver is like a Game Master,

    Think of it this way:

    Ink is the Scripting Language. The book you write in to author your stories.
    Paper is the Gameplay (Hexmap, Scene, Dialogue Choices, Pathfinding, Dice Rolling) which you call in Ink.
    Emergence is a world of content which comes with the game. You can make your own stories in Emergence - a Medieval High Fantasy Post-Apocalyptic world of Knights, Magic, & Horror. You can edit the world, use just the artwork, or scrap it all and do your own worldbuilding by example.
    The Weaver's Loom is the Game Master's mod tools to help set up the Paper Engine components of the game. Tools such as Procedural Hexmaps, Scene Management, Character Creation, Emergent Gameplay Editing, and more. The result of work in The Weaver's Loom outputs .Ink files or Paper Engine Commands (in order) which you can copy/paste into your story.

    Paper Engine 1.0
    • Hexagonal Map Support
      Grasland Terrain check090519 ctrlY.png
    • Text-Driven Scenes
      Scene Mode.gif
    • Entirely Written in ink by Inkle
      Written in Ink.png
    • Polygonal Dice-Based Conflict Resolution
      Dice Example.png
    • Scene Management
    • Inventory Management (Manage your Items, Equipment, Consumeables, etc.)
    • Party Management (Manage your Characters in your Party)
    • Procedurally Generated Maps
    • Emergence - Medieval High Fantasy Content
      • Procedural Name Generation
      • Characters, NPC's, Monsters, Monster Groups, Bosses
      • Character Skills, Character Personality
      • Items, Equipment, Rewards, Debuffs
      • Procedural Encounters, Events, Story
      • Factions, Regions, HexMap Types, Character Types (Classes, Races, etc.), Locations
     
    Last edited: Sep 19, 2019
    xpxilom, TheKingOfTheRoad and Fer00m like this.
  2. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    I gotta goto bed. Might update some more tomorrow.

    But yes!
    I am still alive & back at it!
    lemongrab 1000 yrs dungeon.gif
     
    iamthwee likes this.
  3. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    The lead artist was not satisfied with how the old characters looked and wanted to something new.

    I have to say, I am very impressed with the results.

    Old or New 2.png

    And the hero, without helmet.

    LR05.png

    This was actually really fun for me, as I am the resident 'expert' on medieval realism, so we worked together to make sure it looked great (100% artist) and it was actually realistic (my only real input). You wouldn't believe how many fantasy armors and weapons are just so ridiculously unrealistic or make absolutely no sense whatsoever.



    One of the reasons for the upgrade is how we agreed the old style is a bit more simpler/happy/cartoony, and our story & game-feel is a lot more dark with more of a focus on hyper-realism. The old style didn't have the same weight as the story.

    We still aren't sure how much this increases scope per character drawn, but it is a necessity given how much more "weight" the characters give in the scene. Before, I felt like they were thin as paper moving them around in the scenes. Now, I can almost tangibly feel the weight of the character as I move them with the mouse. Almost like I'm playing with miniatures. If others feel the same during play (and they drag characters as part of input), this will be extremely important to helping give that tabletop roleplaying game "feel" that is one of my design goals. If not, that's okay too. At least it means (IMV) that the characters are more "miniature" than "piece of thin paper".

    Idk why, but I can "feel" the weight when moving the character, like it's physically heavier.​
    move ragnavaldr.gif

    I also feel like the new character style fits better with the Hexmap & Scene artwork.

    character-change.gif

    The scope increase doesn't just stop here though, with the graphics upgrade on the sprites. I've decided to do a massive change to the dice conflict system which I have never really been a fan of in the first place. I'll add that in the next post, but it includes the likely addition of slight animation and more sprites per character overall. Still, it should fit in with the smaller scope, especially since (if it works out) it'll be a change that'll help speed the project along due to some simplification with how dice are rolled. The change also opens up a lot more design possibilities with using items & consumables.
     
    Last edited: Sep 10, 2019
  4. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    We've completed our first character Idle set. Before, we just had the Idle & Combat poses. Now, we have 4 poses per character instead of the 2, and are using layers now.

    Since you spend most of your time traveling, I really wanted to emphasize character's traveling gear and traveling cloaks. Backpacks & hoods are removable layers, to separate when a character is traveling (movement) and when a character is at rest (such as at campfire or in a tavern).

    Soon we'll have our first animation with the "Combat - Attack" pose. More on that, and the new dice system, later! Soon!

    Poses bold are completed.

    • Travel - Idle
    • Backpack, Hood
    • Action - Idle
    • Action - Combat
    • Action - Combat - Attack


    New Female Knight

    LadyKnight 15.png

    Before & After

    upgrade.png

    Example scene of a small party traveling

    Travel.png
     
    Last edited: Sep 16, 2019
  5. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    I've been away for the week on vacation far away from home, without much access to the internet. Didn't know I could survive an entire week without my phone & computer.

    Sometimes you've got to unplug and recharge.
    homer relax.gif

    I actually came home last night & made homemade beer pretzels & beer cheese before bed at, lol, 5pm.
    Traveling is exhausting! Idk how medieval adventurers do it!

    Couldn't resist uploading these to facebook. Delicious! ;)
    pretzels.png
    I'm finally back to work today & getting ready for the next update!
     
    Last edited: Sep 19, 2019
    Martin_H likes this.
  6. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Thanks to a wonderful user on Scholagladitoria's youtube channel, named Maxim, as well as others, I have a lot of my questions answered about armored combat & travel.

    I won't go too in-depth here until I flesh out everything in terms of game mechanics, but I am almost certain now I should have a few different combat skills, rather than just having one skill called "Combat".

    • Armoured Combat
    • Unarmored Combat (or named to something else, like Dueling)
    • B̶a̶t̶t̶l̶e̶f̶i̶e̶l̶d̶ ̶C̶o̶m̶b̶a̶t̶ ̶(̶f̶o̶r̶ ̶h̶u̶g̶e̶ ̶b̶a̶t̶t̶l̶e̶s̶)̶
    • Monster Combat (fighting non-humanoids, like Dragons, Giants, etc.)
      This skill also might be "defaulted" with a penalty. So if a character has no experience against monsters, maybe the skill is Unarmored Combat - 2 or something.
    My original combat formula was something along the lines of...

    • [Combat Skill Dice Roll] + Armor Bonus + Weapon Modifier (vs Opponent Armor) + Reach Bonus + Other Modifiers (Character Traits, Environmental Bonuses, Exhaustion, Magical Buff/Debuff, Story-driven modifiers, Hope/Depression, etc.)
    • Possibly an Accumulating Exhaustion Penalty each round of combat -1, -2, -3, -4, etc. but with character traits to ignore or reduce the penalty (ex. Exhaustion Penalty every other round, instead of every round) or an Endurance value (A Penalty after endurance reaches < 0).

    GAME DESIGN
    It's a lot like making a PnP Game (which is great!)

    Combat Dice are not determined exclusively based on Skill, but are given based on the character as a whole. The type of dice will also be determine by these factors. For example,

    • Experienced Knight: 3D4 - 3D4 is like a 1D12, but much much more stable and reliable, to express the experience of the knight. They cannot really goof (minimum of 3) and will have a much more consistent medium (less likely to get a 12 than a 1D12).
    • Barbarian: 1D12 - Unlike the reliable 3D4, the 1D12 is more wild. This would be an extremely strong character with skill, but lacking the experience of someone trained their entire life for combat. They are just as capable of goofing up entirely getting themselves killed in the first round (1) as they are doing some exceptional feat of strength (12).
    • Untrained, Dumb Giant, but he's still a Giant: 1D20 - He is dumb but can smash you good if you're unlucky.

      And combining the two.
    • Experienced Barbarian: 1D4 + 1D12
    For wounds/health, I have dabbled between two designs. Both are very similar.
    Initially, every character has 2-3 health points. You can be hurt, wounded, hurt twice, and after that are dead.

    Wounds are given based on two factors
    1. Levels of Success - After success, additional levels are given by increments of 5.
    2. Determining the Victim - Since you can commit multiple characters to the same conflict and dice are totalled on both sides, the one wounded is the lowest individual skill roll, the lowest individual skill roll + armor bonus, or the lowest roll total with all modifiers included.
    What this means is the more experienced the character, the less risky it is for them to enter a conflict. In any conflict, the one most likely to make a mistake would be the one with the lowest skill. For example,

    SKILL: Stealth
    CHARACTERS: Thief (1D8), Assassin (1D12), Servant (1D4)
    Any of the 3 can have the lowest score. So the Assassin could be the loser in the conflict. Despite their experience, they were caught! However for the most part, the Servant is most often going to be the loser.

    This brings more strategy for the PLAYER when determining who they commit to a conflict. The more characters you commit, the more likely you'll succeed. However the more low skill characters will be risking much more than the higher skilled ones. Items also play an important role (both equipment & consumables). So you could send only one character and use a lot of gear & consumables, but if they fail they would be the only loser in the conflict. Items also are used pre & post rolling, as well as other things like possibly re-rolling, consuming items to boost a roll to succeed, automatic success, etc. Items can also allow you to roll an entirely different conflict (story snippet).

    This is why I believe it is appropriate to say the gameplay includes both Character Management & Item Management.
     
    Last edited: Sep 21, 2019
  7. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    The more I think about it, the more I like the whole idea of an Endurance value for all characters. Like a Stat (currently my game has no stat system, just skills).

    Endurance plays a big factor in a lot of things

    • Long-distance Travel
    • Encumbrance & Inventory Management
    • Overexertion (Traveling more than your daily rate)
    • Combat (How quickly do you get exhausted when combat doesn't end quickly)
    • Energy-consuming Actions (besides Combat, which is treated slightly differently than other skill rolls)
    • Rest & Recovery (Additional rest beyond the normal night's sleep to recover Endurance).
    It's hard to resist that becoming an important character value in our game.

    And since I'm really wanting to go into a bit of the whole insanity/cthulhu type stuff, as well as loving and being inspired by Darkest Dungeon,

    Stress value, which effects the personality & procedural storytelling events. A high stress character who fails a sanity save might steal your stuff and run off, or attempt to murder another party member.

    It is important to note that unlike Curious Expedition or Neo Scavenger, I will never have a story snippet event where character permadeath is instant. As a game designer I think that is absolutely horrible game design and as a gamer think it's really stupid and unfun. It deprives the player agency and choice. Instead, it will be determined by more dice rolling, conflict managing (commit characters / items), item sacrifice, etc. It will be treated like any other conflict.
     
    Last edited: Sep 21, 2019
  8. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Right now I'm designing the core gameplay of Lord Rangavaldr & the Wishing Stone.

    In large boxes are possible choices (Conflicts), general skills or actions you can always use, my first pass at how I might setup the GUI (drag & dropping character sprites onto conflict GUI objects).


    So before I started with my first Encounter, I wanted to come up with all the skills in the game (so I can write against them).

    This is literally just designing the PnP tabletop part of the game. Not much with video games, but that makes sense, as my design goal is for this game to be like bringing your tabletop rpg experiences to life. It took me the entire day of work (including working through lunch), looking at pretty much every possible skill I could find in all PnP games (GURPS is a big help here, heh) and although it probably needs some polish, I think I've got it down for the most part.



    I don't really think Attributes are all that valuable, when making a realistic game. Real life is more about Skills than anything else. However, I have generalized skills / abstract skills (Attributes) which reflect an overall sense or understanding of something, and then subskills or specializations (Skills) which are just another layer of skills.

    So the character will roll their dice for both Attribute + Skill.

    STEALTH DICE + STEALING DICE + Modifiers vs TN
    STEALTH DICE + STEALING DICE + Modifiers vs Opponent's PERCEPTION DICE + AWARENESS DICE + Modifiers.



    Then I wrote a prototype story. I just wanted to randomly get an idea for something - anything - that could happen in the game. First idea that came to mind, and I went with it. "You are about to enter a Wild Forest tile, from a civilization tile. You hear a scream. What do you do?"

    From there, the team artist (whose idea it was) came up with possible endings. From what idea, I began to think of how the Skills can interact with the Story, in a way where you "can do anything". I changed it to "A Party Member heard something in the distance, but you didn't." I liked this better than the player hearing the scream. Quickly I was able to link all that cool procedural ink content & scripting power together. It is really easy to write conditions for the originating character to get upset/feel confident based on the other character's reactions to the event, which is all based on the outcomes of their perception and knowledge rolls. Ink has a cool feature where you can check if a story bit has been accessed before or not - writing it all in the same line. If you're interested in that, just check out the Power of Ink by Inkle

    I think wrote possible interactions against the list of all Attributes.



    Then thought of maybe how I'd make a GUI to represent all the information & possible choices.




    My favorite part is in the Player having the autonomy to decide who, and if, they talk to. Just like I had in mind for Away Mission - including black boxed variables/traits (so a character could have a trait which makes you question the accuracy of their reported skill; meaning the chance of success isn't necessarily accurate).

    If the Player wants to only talk to their Elf, who has the highest perception, they can just click them, hear their opinion, and make a decision.

    If the Player doesn't even care about his party and knows he wants to dive into adventure, then he can just choose to Investigate, pick a skill, & assign characters.

    It's up to the Player how in-depth and strategic they want to be, in any given Encounter.

    I'm NOT sure if this will be similar in all cases though. While in Away Mission the player takes on the role of Captain, in this game the player takes on the role of...well....Captain too, basically. However instead of listening to all the officers based on the treky scientific roles, the player has procedurally generated character personalities & class archetypes.
     
    Last edited: Sep 28, 2019
  9. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    For procedural generating Characters, and giving them more depth at Character Creation, I like the idea of having predefined "life stages" which can impact the character's skills and traits.

    In GURPS - Goblins, when creating a character you randomly rolled what happened during adolescence, then chose what school you went to, and finally your apprenticeship. So you could be chewed up by dogs, boiled in tea, and then worn as a hat for several years, followed by attending religious school or school in someone's basement, and finally becoming a chimney sweep.

    In Shadowrun 5th Edition, I believe it was the character creation supplement that had additional rules to create characters based on what happened to them / what school they learned from, starting at childhood and well into adulthood. So you could grow up poor, then attend community college, and graduate in magery.

    For Emergence, I am loving this concept for the following reasons

    • It allows for hand-crafted content "chunks" in the procedural generation.
    • It gives not just Skill differentiation, but chances at specific Traits, as well as some Lore, which all fit together in a reasonably explained way. "Oh, he was a priest of Trickster God before he became a Scholar. That explains why his stealth is two ranks higher than other knights as well as having the trait Devotion: Trickster God & Personality trait: Prankster."
    • It provides personality, as well as commonality between characters of different archetypes. If all Priests went to religion school, and all Scientists went to logic school, and those had more conflicts than usual, it is a benefit and a defining story bit that Scientist4 used to be a Priest and gets along really well with them, receiving a bonus when grouped together! Something like that, anyway.
     
    JoeStrout likes this.
  10. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    I added another map function (which only took 1 minute) but the open source Unity UI extension I downloaded had a few problems I had to chase down. I probably should have just wrote my own code (and might when i polish the gui).

    I then added an "EXPORT" button which parses all the logic of the procgen map the user created, and puts it into INK function, which is as simple to call as

    ~CurrentWorldMapID = CartersBestMapEver_GenerateMap("Map_Adventure1")

    Cartographers Desk to Ink Code.png

    It's important to note Line 3 & 4.

    Line 3 is just a comment, written EXACTLY as the player writes their map name.
    Line 4, is the Function, and that has to have a legal name.

    Carter's Best map ever "!@##$^[][][]]]]

    This string does require a few things to happen to it, so the tool...
    • Eliminates illegal Spacing
    • Removes illegal characters
    • Capitalizes words where spacing is removed, for readability,
      "Carter's Best map ever" becomes "CartersBestMapEver"
    All of this allows the end user, a gamer, to create their own procgen maps using all Paper Engine's procgen methods, test out how it looks, and upon being satisfied, exporting it into an INK function which they can easily use. In the end it will export to an Ink file, which holds all procgen map types for a particular World Region. The player will never even need to open the file.

    Meaning... PLAYERS DON'T HAVE TO CODE! And they can't mess up their functions, because it's all safe as long as they use the Cartographer's Desk gamemaster tool.

    ----------------------------
    Next Episode:
    • Adding all the procgen methods I need, which is pretty quick & easy to do.
    • Create my own Adventure 1 Map, as I intend it (rough draft)
    • Start on the Scene/Story Tool, which allows content creators to create their own gameplay. Choosing backgrounds, adding props, setting character positions, adding conflicts, calling skill dice rolls, etc. Everything it takes to create an Encounter.
     
    Last edited: Sep 29, 2019
  11. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Procedural Map Generation takes a lot more effort than I really wish it did.

    Primarily because I have to do everything myself, figuring out the algorithms I need and exactly how to get things done. Websites I found on procgen algorithms were surprisingly....awful. Almost everything I could find was overdone roguelike dungeons (very simple stuff) or teleological based on heightmaps and temperature. Alot of stuff either already knew or didnt need.

    While heightmaps were interesting for river placement, it just didnt work out because my entire region is just hills and forest hills.

    It's okay I didnt find any cool techniques though. I already figured it out and worked step by step. I just need to now add all the algorithms/functions to my procgen map tool (shown in the above posts)

    Today I took a new approach to my map, and I am really loving the new results.

    Every black icon is a location of interest, and the map feels like it has a bunch of them - but none too close. Very happy, and very easy to adjust if in upcoming playtest I need to reduce/add more to get the right feel for exploration and adventure.

    Best Map Maybe 2 final.png

    EMERGENT STORY

    I am using alot of hex radius type stuff.

    • Place a town, fill in managed farmland around town; 3 hexes out
    • Place a village, same; 2 hexes out
    • Place Special Location 7+ hexes away from other locations. Grab all civilized locations (towns, villages, waypoint inns, castles - anywhere with ppl) within 10 radius, and add in special events based on location tags
    For example, if a Goblin Cave is in radius proximity to two villages, both villages will have a special encounter added to their location. The game then grabs an event which fits all the criteria (tags).

    Let's say I created a new story event. Goblins raid a Town.
    When the game asks for a story encounter, it searches for one based on the criteria TAGS.
    • GOBLIN
    • TOWN
    It finds 3 total events with both those tags, and randomly choose the "Goblins Raid Town" event.

    I might end up using tags to restrict some stories to specific "REGION" or only in parts of an "ADVENTURE"
    • Goblin
    • Town
    • KwaynosHills Region || GoblinSurgeCampaign
    This way ANY adventure in the "KwaynosHills" REGION can access this story || ANY adventure# in the "GoblinSurge" campaign (no matter the region).

    ENCOUNTERS:
    ALTERED BY LOCATIONS IN PROXIMITY

    Furthermore special locations can change the random encounter probability.

    Say you have a "KwaynosHills GRASSLANDS" tile, with universal 0% for goblin encounters. No goblins here!

    On top of that terrain, you add a Goblin Cave location. Within that hex is now 100% chance of goblins.
    Then it radiates outwards.

    • 1 hex away = +90% chance goblins
    • 2 hexes away = +80% chance goblins
    • X hexes away = +(100% - 10% * X) chance goblins

    I write events for every location pairing with every other location (and universal events for any location).

    This way, every run in an adventure is different. In the first play through the goblins might be raiding a village when the player arrives.
    In the second play through the goblins are summoning spirits in ancient ruins when the player arrives.
    In the third play through the goblins are just spying on a castle but otherwise docile & the player has to succeed in a Tracking or Stealth skill roll during the spying event to know the direction of the cave. Otherwise just gotta explore to find it (or ignore it bc goblins are too weak to attack a castle so nothing happens unless the player goes on the offensive).


    I dont update often so here is where I am at.

    CURRENTLY IN PROGRESS: Procedural Generation Algorithms & Beta Map Generations for Adventure 1

    TODO:
    • A few placeholder stories to test...
    • Random Encounter and a Story Director / TAG-based system to tie it all together to see if I can create emergent gameplay from procgen maps & locations interacting with each other.
    • Party Management GUI & System (with inventory system & GUI)
    • Camp / Rest stage (Movement on Map --> Camp / Rest for Night ---> Sleep ---> Loop). This is the stage where you assign tasks to your party members, such as Crafting, Hunting, Storytelling to raise morale, Cleaning Wounds, etc. Also where you consume resources (food, water, shelter).
    • CONFLICTS (Gameplay - Dice System & Decisionmaking GUI) + 1 placeholder story w/ 1 conflict. This is everything from combat to any skill roll or decision tree (Go Left or Right?)
    • Scene Creator Game Tool (to make placement of sprites & gui's coordinates easier)

    Alpha complete when I finally get to CONFLICTS (Dice Rolling & Strategic decisionmaking), which will still be awhile since the MapGen & algorithms are taking a good bit to complete bc of how much logic is in placement of all the locations.
     
    Last edited: Dec 6, 2019
    JoeStrout likes this.
  12. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Alright! I'm adding in all the procgen commands I've implemented in code, to the mapgen tool. Just finished adding the first one of many, filtering the noise to make clumps of tiles based on random noise.

    I've got most of the procgen commands already, but have to make GUI's for all of them like below.

    procgen more.gif

    Once I add in the ones I need to make the first map, I'm just gonna stop there. The map tool won't look like this later anyway, so no need to waste time building anything but the bare minimum I need to just tweek the maps to look exactly as I want for the first adventure.

    Not much more and I can finally start adding in the actual content (locations to visit, story bits, encounters), build a prototype Scene Builder for conflicts, and finally begin actual gameplay: prototyping the Conflict System (Dice Rolls, Item usage, Dialogue Choices, and strategy choice).

    Like shown earlier

     
    Martin_H and JoeStrout like this.
  13. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Messing around with noise & noise filters to figure out how I want forests to clump together.

    procgen maps.png

    Pretty awesome to be able to just adjust a slider and see the changes live.

    procgen tool.gif
     
  14. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Figured out just the right balance for how I wanted trees.


    I started out with very low noise and a strong filter.
    This resulted in bigger, round clumps of forest which were pretty uniform.
    forest large phat.png


    I wanted something different though, so I cranked up the noise to an ungodly amount (3000) and a very weak filter.
    I also added a function to clean up noise to eliminate solo and duo tiles, and used it strongly to kill smaller clumps.
    Extremely high noise & a weak filter resulted, combined with lots of cleanup, resulted in very thin but interesting shaped forests.
    forests long thin.png

    I liked both of these though. I liked the cool shapes of the thin forests, but the larger size of the more basic clumps.
    I went back to compare to my handcrafted map I made to try to achieve my goal.

    Best Map Maybe 2 final.png

    I liked having 1-2 larger forests, and a bunch of smaller ones.
    This meant high noise (to have lots of different forest clumps) but also a good filter to turn some of those clumps into big, long, interesting shaped forests.

    To clear up the map, I drew over it where the forests were suppose to be.

    Forest Sizes.png

    To get more clarity, I made the "Hills" (non forest) tiles also colored.
    And greyscale for my eyes.

    Forest vs Hills.png

    Now I knew what kind of shape, size, and quantity of forest clumps I wanted.
    It took awhile doing the fine tuning, but eventually I landed on the solution.


    Add Very Strong Noise (1350).
    The low noise (~200) gave simple, fat clumps. The extreme noise (~3000) gave extremely cool shapes but too thin. ~2000 was still too much, so I cut in half again to ~1000, then fine tuned to 1350.
    When fine tuning, it's best to go in huge chunks. If you're about to half/double things, you can more quickly find what you need.
    The two extremes (200 vs 3000) helped me find out what I wanted. It was very quick to cut the 3000 down by 1000 apiece, then back up by 500, down by 250, etc. Half/Doubling things works very well.
     
    Last edited: Dec 11, 2019
  15. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Then I cleaned up the noise BEFORE filtering it. This didn't occur to me as a possibility for quite awhile. I couldn't get it right until it dawned on me I could move one of the two cleanups I had to the beginning. Voila! I finally got what I wanted. Combined with a medium/strong filter to grow the noise out, do a final cleanup, and...


    move cleanup.gif


    8-14 good forest clumps; often ~12 I wanted, and a few small sprinkles of 3x clumps which I can keep or get rid of, later.

    Final Forest.gif


    This procgen map tool was invaluable when creating my map logic!

    By being able to reseed instantly like you see above, I could check to make sure the minimum / maximum were acceptable. It was also invaluable to be able to live reorder the function calls, and adjust the variables on the fly, see how things effected the map with instant refreshes, etc.
    I'd hate to have done this with a text file & then loading a script, even with an in-game command console. Bleh.
    It actually happened a lot that I'd finally think I got it how I wanted, then I'd reseed and see it was only for that one seed - and the logic was bad for some/most others.
    I very quickly learned to start just spamming the reseed button and looking for outliers. Either examples where a forest clump was way too big, or there were too few forest tiles on the map.

    Eventually I was satisfied with the above logic.

    I must say, mapgen is actually nowhere near as fun or interesting as other parts of the game. I will be very glad when it's over for Adventure1. It could be because I've had to work a lot with mapgen creating the map tool and aglorithms. Hopefully that is the case. I don't want to dread making future maps, especially if the first Campaign sells well.
     
    Last edited: Dec 11, 2019
  16. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,156
    Nice progress bro, my only critique would be I *think* the old style is better. The new characters don't jell well with the background IMHO. Also it is going to be way harder to animate, dunno if you've prototyped that in testing phases before you get too far down the rabbit hole?
     
    CarterG81 likes this.
  17. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Thanks for the input! I remember in discussion with our art lead that they want to redo the backgrounds as well. I will keep this in mind.

    For animations, at first we decided to have no animations ala Curious Expedition. To keep scope as low as possible. However I had wanted to go a step further and do some pose changes. Combat vs Idle, and then later adding Mounted Idle/Combat. I wanted more, but had to keep scope lower so any additional poses would be either polish or TBD based on speed of character art creation. If fast, it isnt an issue. If not, it becomes one.

    Although that doesn't change much, after the new design I realized I needed some way to indicate to the player whether or not the character has acted on the Turn or not. I thought about it awhile and I decided it would look significantly better if we were to do a style similar to Darkest Dungeon animation. That is... when the character does their primary action, their pose changes, some simple effects and audio happen, and maybe some camerawork.

    Darkest Dungeon just does a single pose change. The characters go from Combat Idle to Attack Pose in an instant, with no actual sprite animation, and then back. And it looks great. So I want to try something similar to that, but on a party-wide scale. DD does the subtle Spine-based animations too but I wont need those at all. Nothing of that nature.


    Same scoping issue applies to number of "animated" action poses though. I'd love to have several poses for several types of actions, but for now we plan on just a single action pose. So while a Soldier would have a combat action pose, a Scholar might have a reading open book action pose. Or perhaps a generic action + combat action (only 2). I just dont see it being feasible to have any more than the 2. I might also try a action specific effect which doesnt need a Sprite change. Like a rope effect and just teleporting the Idle Pose Sprite "Rogue climbed the wall successfully."

    So for animation we have little to none for Sprites. It'll all have to be cheaper effects and the like, or nothing at all.
     
  18. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Also a comment on prototyping before going ahead.

    That is extremely important to not just prototype things but also get an idea for how long things take to develop.

    If a story takes too long to be written due to a feature, that feature, although cool, may be removed due to scoping issues. We have to keep track of how long tasks take to complete, so we keep our scope under control.

    It all depends on the value it adds to the game vs the time it consumes in development (on scale). We already have all the content planned out. So we can multiply the average time it takes by the number of characters draw or stories to write, to get an estimate. So the difference between 4 hour per character and 16 hrs per character can mean the difference between 2 months and 1 Year.

    We have what we are willing to cut (ex. Extra Poses) and what we really dont want to but could (ex. New character design) but only time will tell. It takes a bit to really get a picture of the average, as the first time creating a new type of content always takes 10x+ longer than the subsequent content.

    So it isnt a big deal to spend a few extra days to try something out, drawing/writing 1 thing, but it is a big deal to commit to the new thing if it doesnt work on scale, drawing/writing 100+ things * avg time cost per thing.

    We also have what we absolutely cant cut (ex. theme, limitations of animating/rendering, scene, dialogue, & tilemap based gameplay, text based gameplay, etc) So while some things can be scrapped for scope or added for polish, the overall core gameplay cant really change much. I am confident it will all work out though. There is never a problem that cant have a solution. And this game must get finished, and soon.
     
    Last edited: Dec 12, 2019
  19. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,156
    It sounds and looks stunning. I like it a lot.
     
    CarterG81 likes this.
  20. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    TLDR: Skip all the pictures and skip all non-bold text. Just read the bold.

    I've done a lot of work on a lot of different commands recently.

    I never thought I'd make code like this with names like string STRING1, int INT1, bool BOOL1

    And I'll probably end up with one of those notorious 1000-case switch statements that all great games seem to have underneath ;)
    Really, it pretty much guarantees my game will be successful.



    SWITCH OH NO NO NO NO.png

    I made "Command Sets" which you can register, allowing for easy looping and wildcard parameters.

    Otherwise, you're just copy-pasting the same set of commands a bunch of times, which would make the code ridiculously long and repetitive. (4 Towns with 6 villages each, with around 5 commands each, would be something like 140+ lines. With Command Sets calling loops & changes in parameters, it's just 30 lines instead of 140+.)

    This is what the procgen map creation looks like.
    mapgen.png

    I added TileLists instead of specific commands for Black Lists & White Lists, so you can just do whatever you want more freely, collecting all Tiles in a Radius or TileType, to manipulate with map logic.

    Instead of marking tiles as "visited" or "isLocation", it made a lot more sense to just have my own tags, which I call Marks.
    This way you can "Mark" any tile for any reason, to then do logic on it later, such as Converting all Wild Hills & Wild Forests marked as "ManagedLand" into special farmland, animal pastures, civilized forests, or saving a generic tile by name to access later, since the TileLocation(x,y) is unknown due to randomness. In case it's of a generic TileType like "Forest" among 100's of others, but it's used for special logic later on.

    Marks are vital to a lot of deeper logic in game level design. With marks, I am able to block off certain tiles, radiuses, and anything important when placing locations. This allows new tile placement logic to make sure Towns & Villages are at least X tiles away from each other, don't replace another important location.

    For example, each Town tries to place 6 villages, but sometimes the 5th or 6th will fail, or even a town may only have 3 villages. However it works out well because this only happens when there is already a Village nearby. This was so nifty, I didn't even have to do any logic to place villages inbetween towns bc it naturally happens.

    Purple tiles are Villages. Colored are Towns.
    While there are suppose to always be 4 towns, there are a more random number of villages. Each town TRIES to place 6, but usually all 6 cannot fit so it gives a bit more than half that, like some maps having 15-19 villages instead of 24 (6 tries *4 towns).

    location placement map.gif


    It was difficult to begin engineering some of this, but after I got back into it, it became a lot better. I probably read RedBlob's hex page 50 times in a row and felt like it was all a foreign language even after the 50th time. There was like a "mental barrier" kindof suffocating my mind, clouding it or oppressing it. I had to just power through it, despite it feeling overwhelming, difficult, and incomprehensible. Then that barrier just "broke" and everything became easier to engineer and understand again. I genuinely thought I might have lost my abilities in my "older age", but I'm back to normal now, like my mind was unlocked.
    :eek:o_O:confused:

    It was fun engineering how to do "Integrity Checks", which required me to figure out how to take a bunch of logic I just did, and repeat it, but not all of it. IntegrityChecks let you check if a procgen map was successful based on your requirements or if it needs to loop repeatedly until it finishes (up to a max of 5, which then throws a user error telling them the map logic likely needs to be fixed).

    This way I can always make sure that all 4 Towns are successfully placed in the map. Villages don't matter, so they are supposed to fail if they do. Since Towns MUST be part of the game's map, I enable integrity checks for them. This is verging on becoming spaghetti code duct taped together, but it's probably the most complicated logic of any command since it touches the actual game loop (while most commands just do some math to a tilemap & that's it).

    intergrity checks.png
     
    Last edited: Jan 24, 2020
  21. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Adventure 1 Map - ALMOST COMPLETE!

    There really isn't much left to do for the ProcGen maps, until Adventure 1 Map is totally complete.

    • Logic: Pathfinding (Tiles & Edges)
      • CommandType: FindTilePath (TileA to TileB)
      • CommandType: FindEdgePath (TileEdgeA to TileEdgeB)
    • Logic: Rivers. Iterate over edge path, changing tiles (so I can link Lakes to Lakes, with Rivers which flow around the EDGE of Tiles)
    River Tile Canvasmock up.png

    • Logic: Bridges. Iterate over edge path, and if crossing a river, add a bridge (so rivers next to multiple Towns/Villages get bridges over them)
    Then it's just placing more locations (Caves, Ruins, etc.) which is the exact same logic as the Villages/Towns - and voila! I'm done and can begin with either Encounters (filling the map with triggers, events, random encounter chance, procedural story, etc.) or Scene Gameplay (rolling dice, conflict management, decisionmaking).

    This pathfinding is also required for gameplay, so it's really nice getting so close.



    MOD TOOLS - POSTPONED

    The Cartographer's Desk (Map Tool) is functional enough for me to get everything I need from it right now, so I'm not going to finish adding the extra features I've completed until much much later (before release or post release - whenever I release the toolset as an actual polished product).

    Remember that to build the game's Mod Tools, such as "Cartographer's Desk" (ProcGen Map Tool), I have to work backwards from the actual game logic. So when adding new functionality, I have to do things in this order:
    1. Write the syntax in INK (ex. >>Command, [EnableIntegrityChecks], >:TitleCard)
    2. Parse the INK line in Paper Engine (the game)
    3. Write the Logic in Paper Engine (Parse Text --> Actually Do Something)
    4. Update the same logic in The Weaver's Loom (Mod Toolset)'s shared script
    5. Figure out how to add the functionality so the end-user can use the tool to generate the INK line & export
    I've already done 1-4, but literally all the work on the mod tool is in step 5, just designing the GUI. It's not a pleasure to work with Unity UI anyway. I hate designing and engineering GUI stuff, I think it's my least favorite aspect of game design.

    Since I added TileLists, CommandSets, and IntegrityChecks, which required me to stop develop on the tool and work on the game, and really wanting to be done with all the procgen map stuff and work on actual gameplay, I decided to just postpone work on the Mod Tool's GUI, and just use it by manually calling the functions (in scripts) that I want to test. It's quicker and won't slow me down, and I can always come back (which I needed to anyway) to better create the tool and polish it for release.

    I also don't even know how I'd develop a GUI for those three features, and that's the last thing I want to do when I want/need actual gameplay & still have to develop a Scene Tool (which should prove to be more fun than the map tool. I got tired of the map stuff a lot faster than I thought I would since I am so desperate to play my game rather than just look at it.)
     
    Last edited: Jan 27, 2020
    JoeStrout likes this.
  22. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    8,479
    Looks like great progress! I have just a couple questions (this is what you get for putting yourself out there)...

    1. WHY all the variables like STRING1, INT1, etc.? Why not name them what they are? You'd only need to throw a var in front of each one, and maybe some curly braces around each case to keep them from conflicting...

    2. I haven't entirely followed what you're building there, but it sure looks like some sort of rudimentary scripting system. Would a full scripting language like MiniScript be useful to your efforts? (I'd be happy to score you a free copy, with tech support... the sooner to get Away Mission back on the front burner!)

    Cheers,
    - Joe
     
  23. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Honestly didn't even occur to me since I never use it. I've never even used var in C#. I've never looked into it simply bc I didn't want to have to learn something new and then goof it up not knowing how it works in full. Better safe than sorry, basically. In the years prior, I never liked the idea of using var when I always knew the type I needed. (Otherwise wouldnt everyone just use var exclusively? I figure there was a reason you don't?)
    In this case though, you're right, that makes way more sense. If I refractor later, I'll definitely look into fixing that.

    As to the question of
    I really just didn't want to have to name a ton of new unique variables in every single case in the switch, sticking to a convention. I initially did that, but naming each variable and making sure it kept to my convention was just mentally fatiguing even if it was only a few seconds of thought. Yet another rule/convention to follow. Easier to just write out some generic name and go with it. I got fatigued doing so much map procgen for so long, I just wanted to get it over with. My commenting suffered as well, I'm sure.

    If var is what I always figured it is, and just that simple, that would be a lot easier (var Parameter1, var Parameter2, etc.) but I didn't want to goof (cause some bug) by not understanding that feature in full.

    It's kindof a rudimentary scripting system. Since I'm using Ink by Inkle, which does so much already, I just have to parse a few game commands (which are mostly map procgen) which Ink doesn't handle. So I'm just adding in an extra few features to when I parse the Ink scripts, intercepting them if they begin with special syntax like >>

    Ink, being a scripting language of its own.

    I just didn't want to do all this in JSON, since I wanted the feature of my games/mods to be "Never even have to leave Ink!" (so the players can make their own games or adventures, with the power of Ink and some nifty extras).

    I am hoping the payoff will be when I actually start writing lots of content.

    Depending on the complexity of Away Mission and how I'll have to engineer everything, I may or may not use "Paper Engine" for it. I'd like to, so I can do a Maniac Mansion style writing of content,

    Move Fred to PinballMachine

    My goal with some of the animation and event handling in Away Mission was going to be letting an AI do almost all the work.
    That way I can simply write things like

    Story Story Story
    Move AwayTeam_Leader to Macguffin then Phaser_Stun at ScientistVillain
    Move AwayTeam to EnemyTeam and Phaser_Stun at EnemyTeam
    Move ScientistVillain to Macguffin then Move to EscapePod
    Story Story Story

    Depending on who gets to the Macguffin first, then divert to that Success/Failure story portion of the event.

    That way things can be procedural, with a deeper AI under the hook taking over some of the smaller details (move speed, phaser targeting/accuracy, etc.).

    That being kindof a necessity bc when I worked on Away Mission, handcrafting each scene was a tremendous time sink compared to if I had a smart AI and an easy way to tell it what to do.

    Like this scene

    cargobay.gif

    I actually handcrafted each path and animated it in a Timeline tool.

    events handcraft.png

    I remember afterwards thinking "Wow, I could have done all that with a single line of code after placing where each character started."

    Move All to Exits


    So I've always been interested in trying to get experience doing stuff like that (Maniac Mansion's SCUMM style scripting) in all my games.
     
    Last edited: Jan 25, 2020
    iamthwee and JoeStrout like this.
  24. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Just in case anyone is thinking of following but thinks "TLDR!", you're definitely right. It's mostly just me chronologizing everything I am doing. I'm not sure if anyone is even interested in some of these lulls in development.

    Look out for when I start posting gifs of actual gameplay. It should get a lot more interesting then.
     
  25. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    8,479
    Don't rworry about that; the updates are always interesting. You always have good (or at least reasonable-at-the-time) reasons for things that you do, and I learn and grow from that vicarious experience. I'm sure others do too.

    And yeah... I see your point about the pain of scripting those scenes. You need something that lets you do the same in a lot fewer, higher-level lines of code. Of course without losing the artistry — like that last crewman who stops and looks back for a moment, before proceeding out of the room. Absolutely brilliant. Don't let AI-driven motion lose that sort of touch and turn your people into pixely little robots!
     
    Martin_H, iamthwee and CarterG81 like this.
  26. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    I am really glad you shared that, thank you.



    I will definitely try to keep that in mind since I can see how one could easily forget those small touches and let robotics takeover.

    I cant wait to get some gameplay to share.
     
    Last edited: Jan 25, 2020
    Martin_H and JoeStrout like this.
  27. FancifulFox

    FancifulFox

    Joined:
    Jul 10, 2014
    Posts:
    17
    Travel Combat progression lg.png

    Hey there, I'm the artist for Lord Ragnavaldr and The Wishing Stone, and I wanted to make a little post about my process.

    Here's a shot of how I usually work on the sprites for the game. References are a godsend since I have no idea how to sword fight, and all my instincts for poses are usually dead wrong. Watching HEMA videos seems to be the best way to find authentic poses, nothing else really compares. I've changed the way her travel outfit looks by giving her darker leather pants and lighter boots since the legs were not very readable before. I also changed the little clasp on her pouch to match her colors more. I will probably add a variation to this with her hair up. Fighting with hair whipping in front of your eyes just doesn't make much sense, but it does look good.

    I've been gradually getting better at pixel art with every new sprite. Which is great bc who doesn't want to get better? The only downside is I have to go back and clean up the majority of the older ones. Regardless, I'm quite happy with the way this little knight came out. She's the same knight we've been uploading, just in different poses and levels of gear. I've been using her as a guinea pig for my ideas instead of Ragnavaldr since she's a more simple character. I'm thinking of nicknaming her since she's such a charming little scribble.

    Well, it's late where I am so I'm off to bed. I'll post more progress soon.
     
    JoeStrout likes this.
  28. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    RIVERS COMPLETE!!!!!!!!!!!



    rivers.png


    This was an enormous PITA to implement.
    I had a lot of trouble just figuring out how to do it.
    I made many different types of graphs.
    I had constantly wrong algorithms. I'd even sometimes have it right, mistakenly do some math to plugin, think it's wrong, refractor, then realize I was right originally bc ...ugh.

    Enormous amounts of debugging and unit test, as well as manual testing the logic bc I didnt really know what it was suppose to be (since I'm so bad at Hex Maths).

    I used this cheat sheet. Helped soooooooo much to figure out the logic.
    A single corner is always connected to three tiles. A single side/edge/face is always touching two, but its corners are touching 4.
    cheat sheet.png

    Then there was a nightmare of dependencies and "HOW DO I GET THAT DATA FROM THIS OBJECT?" Just insanity.
    My actual logic to just convert a single Pathfinding Path to change its Type is ludicrously complex.

    Two parameters are given: the two Corners of a HexTile. I use those to get the Direction of the Path, which is also the Edge/Side of the HexTile (NW, NE, E, SE, SW, or W side). But the HexTile is unknown because it can be multiple Hexes. Then I use the direction and corners, convert their coordinates to find the HexTile. Then I use the HexTile to find the Edge. Then I check to see if the Edge matches one of the two Corners (4 tiles are checked, only 2 are ever right, but which two is unknown until checked).

    Finally, I get the two edges of the two different tiles that a path's corner directions are, and change the tiletype to "River".

    My instincts tell me my brain turned into mush when working on this for the past few days, and this should have been way easier and simpler. Instead, it's complex bc Corners, HexTiles, and Edges are all different and I can only convert some things if I have all the other information. (ex. To find a Corner, I need both the HexTile data AND the Edge facing (NE, SW, etc.)
    I regret sleeping my way through Geometry in highschool.​
    hex geometry.png



    I originally had all the corner map assume the sides by going clockwise, and the corner map render and hold the graphics, but I failed to succeed there and it wouldn't render correctly. So the corner map is just data used to convert tile coordinates and sides/edges.


    I succeeded in my backup method, which I kept avoiding bc I couldn't figure out how to do it. Every Tile knows its own Edges/Sides. So once I find out WHICH Tile has the Edge/Side with the river, I can render it. But boy was that hard.

    This has to be the most Spaghetti I've ever written. I have no idea why, but my brain turned into mush trying to do any and all hex logic. Not the procedural generation logic. That's fun & easy for me. But any Hex Math, Hex Logic, Hex/Corner/Sides Geometry, just melted my brain into mush.

    spaghetti.png
     
    JoeStrout likes this.
  29. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    8,479
    Thanks for hanging in there and muscling through it!

    I've got a number of hex demos for my Mini Micro project (like this and this), but the hex logic code is sort of just baked into each one according to the specific needs of that game. I've thought about making a general-purpose hex utilities module, to help others get their hex games going easier. It sounds like I should probably do that — I don't want any brains melting! :p
     
    CarterG81 likes this.
  30. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    The Edges (often used for Rivers/Roads, or if you were trying to make a Catan-like game) gave me more trouble than the Hexes (which of course gave me trouble too), Pathfinding, and all procedural generation logic combined.

    all map mode vs edges only.png

    Pathfinding just took 4hrs, mostly learning how A* works. So...
    HexMap+Pathfinding+ProcGen = ~22hrs
    Edges alone = ~27.5

    Before I did any custom Hex or Pathfinding stuff, I checked out every single Hex & Pathfinding asset. They all disappointed bc they were all more for mesh generated hexes (real hexes) while my 2D hexes aren't actually true perfect hexagons. I mean, they are but they're not bc they're pixel art tiles sized 176x192. I either refunded them or gave up on them. So if there were a Hex map asset, which included edges, I'd have jumped to buy it asap as it would have saved me over 50 hours.
     
    JoeStrout likes this.
  31. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    I'm loving our new hero and the better iterations of characters as a whole.

    new ragnavaldr.gif

    It was so awesome seeing the first upgrade, and IMO the second one is even more as awesome. It's like going from NES to SNES to SNES Sequel graphics, lol.

    lord ragnavaldr iterations.gif

    It is really cool seeing an artist get the style down. It takes a bit at first, but once it's figured out and the content begins, it's just so awesome to see content start pumping out with that extra quality, having taken the time to make sure to get the first set of characters just right
    .
    I am so lucky to have such a talented artist on my team. My knight would look like this:

    ron knight.png
     
    JoeStrout likes this.
  32. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    BUG HELL

    Almost totally scrapped a feature (and really, I should have as soon as I realized the bug was in the feature).

    I was stubborn though. Intellectually, my mind demanded I find the source just to understand what was going on. Spent 8.5hrs straight chasing down a real nasty bug. No amount of debugging would tell me where it originated, and I had to recreate it and then go line by line backwards (and forwards) and even then clues were nonexistent. It turned out when I created a copy of a Map, each tile would get the old copy's map reference rather than the new one bc it was impossible to give it the new reference without passing the Map as a parameter to constructing a new Tille from a copy. To even figure out this was the problem I eventually had to make a copy of the Map and its Tiles, one line at a time, outside their constructors, to find the error was in the Tile's constructor.

    I knew... I absolutely knew making each individual Tile dependent on knowing its parent Map was a bad idea. That kind of backwards dependency isnt good and I suffered for it. And it only appeared when I implemented Rivers, and only messed up Rivers, but wasnt a bug in the Rivers, which made me chase the wrong feature for quite awhile. I also chased the wrong feature bc I thought my feature had the bug, when it was actually a minor method which reloaded the map from an older copy. Ugh!

    Would have been faster if I had just deleted all the code and rewritten it from scratch, doing unit tests along the way, than to try to find the bug.

    Better Rivers
    On a better note, I added a few features to make the rivers look a lot better. No more straight lines.

    [Will update with pictures in a moment]

    I actually found a nifty trick to give Towns/Villaged a negative cost to pathfinding algorithm, so the rivers magnet towards them if nearby. This only works on the first river I make though, due to a negative path cost making the second river go backwards following the first river, then looping back around its origin towards the destination. So I scrapped it for now.

    However it is interesting to play with negative path costs in A* to get some cool effects.

    For more natural rivers, I adjusted the costs.

    • Default 10
    • Farmland 5
    • Settlements 0
    • Rivers 0
    This makes the river greatly favor farmland, which is around settlements, so they flow through the settlement's farmland, around the settlement, as it makes its way towards the destination.

    Most dont connect with the river, but enough do along the way that it looks great.

    The negative path cost could be used to make sure a river goes directly toward a special location, unless it is just absurdly far away. You just have to be careful about using negative path costs as it can easily go haywire.

    I also changed how the two rivers flowed.

    Before,
    • Castle & Towns randomly placed around map, anywhere.
    • Castle ---> NorthEast border
    • Lake town ---> Northeast border
    Two separate rivers which eventually combined. Sometimes the river could be quite short if both locations were nearer the NE side.

    After,
    • Castle SouthWest corner of Map
    • Castle ---> Lake Town ---> NorthEast border
    This guarantees the river flows throughout most of the map.
    This now places the Castle, the "biggest location" at the opposite end of the Player's starting position.
    It also makes more sense, geographically, as the highest point (Castle) flows a river to the lowest point (Lake) and then overflows out of the Lake to a major river (in direction of the ocean on the worldmap)

    "Let me tell you a story..."
    Design - Procedural Generation

    While this is a Story Based Game, I still HAD to have procedural generation. Not just for replayability but for others to make their own games or extend them to remake roguelikes with my game/'engine'.

    I am approaching it as every playthrough being someone telling the story to others, like an elder telling a tale to children around a campfire.

    Verbal retelling of stories have the same overarching themes, but can differ in the details or even in big parts of the story.

    The characters, what they do, which made it to the end, new ones who joined, and even the items or locations they visited or things they encountered vary, but the overarching story and regions they travel in remain consistent.

    Not sure exactly how to convey this to the player at the start, but I hope I can get that sense.

    This is why I refractored my entire story to remove the first person tense "You are Lord Ragnavaldr." And instead am approaching it more similar to Tolkien (narrator in third person omniscient) or Game of Thrones (narrator through view of characters).
    So I'm writing with the Dungeon Master (narrator) in third person, revolving around the perspective of the hero (Ragnavaldr), alternating to other characters view when the hero is absent, but sometimes cutting off their story short to show the unknowns of the hero.

    Player's Party is Trapped in a Cave for days
    Action: Send out small party to sneak out and return with supplies
    Narration of Away Party party's adventure sneaking out
    Event: Away party gets into trouble. Dice roll. Shows Failure. Actual full results blackboxed. Fade away back to party in Cave.
    Player assumes failure. Doesnt know.
    If very successful, 0-3 turns later away party returns. Surprise!
    If failure, never hear from them again. Assumption correct.
    If barely successful, if the player backtracks and returns to town after scenario is over, they actually survived, but couldnt return to help. Surprise! You gain the characters back.

    Just as in some PnP games, the level of success/failure helps to write dynamic results for each encounter.

    So depending on what I feel like writing, event may play out entirely for player, or I may blackbox results of player's choice, imply success/failure (possibly lying), etc. Depends on my goals as a writer for that type of event.

    I am hoping this creates some interesting dynamic storytelling and more impactful decisionmaking for the player, who may not know the impact of their choices until later but keeps them in the unknown.

    And hopefully I will be able to allow the player to always, if they wish to spend the time and risk, find out what happened. That way the player gets to decide whether to try to find their missing party members or go on without them assuming theyre dead or missing. The investigation resulting in revealing the truth and then ending that story segment. So if they failed, Player Control deciding to investigate would end the quest with the player knowing theyre either dead or missing to the point where there isnt anything else to do.

    I would love to add in the piety system for this as well. With Prayer and Piety giving an increased chance for a miracle which changes the event from bad (they died) to good (they survived and you found them) at the end of investivation.

    Losing is Fun? No.
    Losing is Playing!

    Another favorite trick of mine is to log absolutely dead, different from assumed dead. This way 3 chapters later, a chapter 1 character might return to do a savings event, preventing the player from losing the game and rewarding them with regaining a lost hero or item.

    Low Enemy HP + 0 Ammo left ---> "You reach into your backpack to find something out of desperation and... AN ARROW! It must have been misplaced, or this is some sort of miracle!" ---> Fire Crossbow ---> Yay!

    My game design philisophy is that "Losing is Fun" is wrong wrong wrong. Losing isnt fun. My philosophy is "Losing is Playing." There shouldnt be game overs as much as there should be further adventure as a result of loss. Just like any good story.
     
    Last edited: Feb 13, 2020
    JoeStrout likes this.
  33. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,758
    Bridges Complete!
    river path to civilization, crosses river then bridge.png
    I made paths from all civilization to other civilization. If the path crossed a river edge, it got a bridge. Since there are a lot of bridges around towns, I am thinking of having some variety. Maybe some stone-stepping "bridges", rope bridges, wood, stone, etc. But for now, whatever the first bridge the team artist draws will be what we use until we get to that "extra art / variety polish" stage.


    Took 4 hours. Which was quite a bit more than I thought it would, but I needed to polish how they were generated, since they were too few and illogical in the beginning.

    bridges task.png

    And with that,

    I AM DONE WITH MAP MODE!

    dragon-ball-z-battle-of-gods-super-saiyan-vegeta-power-up.png
    And future adventure maps will likely consist of a lot of the same functionality. If I have to add a few extra methods, no problem. That's the easy part. All the core systems
    • Maps
    • Tiles
    • Edges (Rivers)
    • Edge Overlays (Bridges)
    • All ProcGen
    ARE COMPLETE!

    Map Mode Total Hours: 54 hours + 8.5 hrs for that nasty bug + 17.5 hours wasted with pathfinding assets + 54 hours in The Weaver's Loom (Map Tool) which probably included a lot of work + 19.5 hours with the old map mode, movement, etc (cloning Curious Expedition's map and movement, which I discarded for a better more appropriate design) = 153.5hours

    If you don't include the waste of time & old prototype
    : 62.5 to 116.5 hours (the latter including Weaver's Loom)
     
    Last edited: Feb 14, 2020
  34. FancifulFox

    FancifulFox

    Joined:
    Jul 10, 2014
    Posts:
    17
    I'm really happy with how Lord R. turned out. Progress is a good feeling Combat Action05.png
     
unityunity