Traveler's Tale - A Party-Based, Procedural Storytelling Travel Game

[ProfessorOFun]

Traveler’s Tale™ - Devlog
A Party-Based, Procedural Storytelling Travel Game
Paper Engine™ Devlog - Ink’s GitHub Page

(Screenshot below is entirely placeholder art except Character as portrayed above)

Inspired by The Hobbit, more than anything else. Also inspired by Lord of the Rings, D&D, Pen & Paper Gaming, Miniature Gaming, Board Gaming, Text Based Games of Old, Roguelikes, and some of my favorite indie games: Curious Expedition, FTL, Neo Scavenger, Darkest Dungeon. I can’t list everything which inspires my designs. I am personally a hardcore gamer, living & breathing video games for the last 20 years, most of which was all day, every day. Hardcore is an understatement. Gaming is my life, and I have a huge passion for Game Design.

As of now, the theme is Medieval High Fantasy. Knights, Dragons, Elves, Goblins. However, it isn’t out of the question to have other themes later on*.* As long as it’s always a Party-Based, Procedural Storytelling Travel Game.
Made With Unity. (We will be sure to include a list of Asset Store Assets used to help us complete this game. Credit where Credit is due. Love Unity & the Asset Store!)

All aspects of the Game are currently in the Prototyping Phase.
All input will be read & considered.

Notes on my view of the Game’s Design

• Simplicity. This is to be a game we can create in 1 - 3 months.

• Quick Playthrough. A single session should last 0 - 5 hours. Think the brief session time of Curious Expedition or FTL. Play. Replay.

• Focus on the interesting aspects of a story. Skip or Condense the tedium & boring components of Travel, and focus on the Fun pieces of the Journey. This doesn’t necessarily mean Epic encounters, but always Interesting ones. Run low on supplies, and your crew may have petty arguments with decimating consequences.

• “It’s the Journey, not the Destination.”

• Focus on Travel. Preparation, Weather, and maintaining your party’s Morale as you spend years away from home.

• “The rain pours on for days as the region has a world-ending flood. If you don’t make it to higher ground in the next week, you may not survive.”

• “The cold weather causes your sword to stick in its scabbard. Best be careful next time you find yourself in a conflict in such cold weather.”

• Focus on the perspective of the Player as the Leader of the Party. You will need to make tough decisions which will determine the life or death of your crew.

• Ultimately, you will make the hard choices along the way.

• Your crew might argue with your decision, make irrational demands, or poor decisions which require you to bail them out.*

• Focus on a period of Rest in Cities, following your Travels. You’ve made it to the city, and your party members will each go off to do their own thing. They will return not only refreshed, but bring with them potential rewards or troubles as they relieve the stress caused by your journey.

• This is the main part of the game where the personality of your crew get to shine.

• “Next time, maybe you shouldn’t bring with you a team full of Alcoholics.”*

• Focus on additional Non-Violent conflict resolution. Want to be a team full of Artists, Songwriters, and Scribes? This is your game - and it will be just as fun!

• Inspiration from my decades of love for Pen-n-Paper gaming. I want this game to be an expression of a good, free-flowing dungeon master taking your party on a realistic journey through a fantasy world as you choose each twist & turn.

• Dice-Based, Text-Based Conflict Resolution. Roll your dice & see the story unfold. (Combat may have a few additional, small components to it. Still in design.)

• Design inspired by my decades of love for all types of Gaming. PnP Games, Card Games, Board Games, and those Niche Video Games many of us love.

• Turn Based

What this game is NOT

• NOT a traditional JRPG

• NOT a traditional turn based combat system.
  Although combat is turn based…
  You don’t move your party around in a Tactics game.
  You don’t slash your sword back & forth lowering hit points until someone dies.
  You roll your dice, perhaps make a few choices, and then the story unfolds as to what happened.

• Combat is Chaotic.*

• Wounds are Lethal.* (When I PnP, I play Shadowrun with optional rules for deadlier combat).

• NOT a game only about Combat. Not only is non-violence an option, but even a soldier can handle conflict using their prowess without necessarily murdering everything for loot.

• NOT a dungeon crawler. The World Map is 1 hex per Day of travel. Dungeon encounters will be more of an abstract series of encounters in Scene Mode - unless the dungeon is so enormous it takes months to travel through.

---

Some additional Notes (Design is currently in progress. Scope may remove or change the following entirely.)

• (In Development Design) A variety of stories (Heroes with different Goals; A Beginning & Ending) splattered with procedural storytelling along the way. Multiple Endings with Procedural components, forming a unique twist to a Hero’s story. I thought this is a better path than purely random storytelling, as the more random a story the more stale & repetitious it becomes.

• Attempt to minimize repetition.

• “Oh…another village with a different adjective & randomized name? Um…okay…cool I guess?”*

• Additional Choice Endings based on who or what is in your party at the end of the story, if any remain. Pushing your way through to reach the destination as fast as possible, without any care for the lives of your crew, may change the results of your story quite dramatically.

• Endings mid-progress, such as the choice to end the game at the very beginning, in the middle, or push onward to the bitter end.

• (In Development Design) Hero Storytelling which focuses on the Alignment of the Hero.
  Neutral-Neutral stories would be very open with choices, freeing the player to play any way they want. There is no overall narrative for the Hero. This is more akin to an open world RPG, but with a goal.
  Lawful-Good or Unlawful-Evil stories would still attempt to give a variety of choices, but without hurting the overall narrative of the Hero. This is a bit more on-rails. An evil necromancer trying to do good is just as likely to result in more evil being done than less. Cause those ungrateful villagers deserved it.

• Not always an Epic Quest. You aren’t always going to be playing as a heroic Paladin out to rescue a princess or an epic Dragon conquering the lands. You may like to play a common hero. A Merchant out in pursuit of trade or a Peasant family trying to find somewhere to live. Possibly quests without end - a procedural generated world which continues until you either accomplish your goal or die trying.

• (Theoretical - Possible Post-Release) A theme beyond Medieval High Fantasy. With the name of the game & story telling focus, it isn’t out of the question to make heroes & questlines focused on a theme like a Jules Verne Steampunk space theme, “20,000 Lightyears Into Space” or a Western-style theme with lawmen, natives, and train robbers. It really depends on the scope (how long content takes for us to create) and the demands of the community. Or completely new games based on the same/similar engine.

• (Theoretical - Possible Post-Release) Customization & Modding. Create your own Hero, write your own story, change the balance of the game, and share with the community! We can’t recreate your favorite fantasy story, but I guess you’ll be able to, no matter how much we disapprove ;).

[ProfessorOFun]

I started this project a bit after giving quite a long “3-Part Epic Post” on reddit.

I was lurking as I sometimes do, and just felt really empathetic towards this user who expressed a sense of hopelessness as a gamedev. As much as I want to pursue my dream as a game developer, I also want everyone else to pursue their dream - and succeed. Especially in an industry I am so passionate about. My heart poured out those posts.

A few days after my attempt at pragmatic encouragement, I kept thinking…

“It is easy for me to say this to someone.” followed by “But I truly do believe this is all correct. I believe in what I said.” towarsd the end of those few days, it kept pressing on my mind, “You are in the same financial boat as he is. You are wanting to become a full time gamedev, but it’s difficult because you have a full time job. You could follow your own advice, find success in 1-3 months, and then go gamedev full time on your current project.”

So I paused development of my bigger scope game to pursue a very small, but still innovative, game. I admit the simpler I make my games, the less innovative they begin to feel. However, I am hoping to not let gamers like myself down. I am hoping to give something new, something fun, even more than I am hoping that it is a success.

If I am to find success with this game, I am hoping to push forward and lead the team to complete Beyond the Forest, a multiplayer COOP survival travel game set in a world of childlike imagination, and then Away Mission which had its home on these forums. I discussed things with the team, but we decided against making a simpler version of Away Mission, and I think we all agree in wanting to give that game the full scope it deserves.

[ProfessorOFun]

The programmer has a total of 25 work hours into the project so far.

The following has been completed:

• World Map

• Procedural Generate Region Maps (Prototype: Grasslands)

• Hexagonal Grid

• Terrain Type Data (Move Cost, Sight adjustment, Terrain Height, etc.)

• Player Movement

• Pathfinding - Hexagonal Grid (Find Cheapest Path to Hex)

• Tile Movement Cost

• Line of Sight

• Location Tiles

• Tile Movement Logic

• Reduce Morale by Cost

• 1 Game Day passes per Tile Moved

• Cancel Movement along Path

• Update Line of Sight

• Check for Random Event

Artist is currently working on first Scene View for Scene Mode. Scene Mode is what I call it when the game shows your party, displays the text encounter, asks for player input (dialogue choice, dice rolls), and informs you of the results.
Art requires a background piece to place behind characters during an event.

Programmer is currently working on the Inventory System.

Your party’s inventory is carried by each character. Lose a party member, and you lose the inventory in their backpack. Take this into consideration when you’re choosing whether or not to go back to rescue a foolish character.
“I don’t care about that [traitorous Rogue], but he has our [Cake]! We have to risk going back for him. This game…!!! ”

I am still working on the design for the game, but overall the style of art & things we are drawing will almost certainly remain even if things change slightly. Anything done programmatically is more likely to be refined than completely redone.

We’ve got a very solid general idea on the design. You just never know until it all comes together, whether or not it is fun.

[FancifulFox]

I’ve been working on the scene art for the game.

Here is a scene of a recent battlefield at sunset.

These “scenes” are of locations the player explores with their party. A lot of different encounters are possible here. Things like running into enemy or ally soldiers, rescuing wounded victims of battle, or just scavenging for some loot.

Tell me what you think! Does the scene invoke any emotion? Does it tell a story? Any feedback is appreciated.

[FancifulFox]

Here is our scene for the hills surrounding one of the largest cities in our game. It’s quite idyllic.

[FancifulFox]

Two Map Tiles done, now for a hundred more.

[ProfessorOFun]

It’s been a bit since I last posted, mainly because I have been very busy nailing down the foundation of the game and our content pipeline.

Shortly after my last post, I found Ink, by Inkle. This is IMO the next generation of indie game development technology.

INK - the Future of Indie Gaming

Ink is an extremely powerful scripting language, made with a strong focus on usability: Nearly all of it is written from the view of a writer, not a programmer. However it is a programming language! You can do some powerful things with it.

So much so, we should be able to achieve everything we wanted - and then some!

For the most part, I will be writing nearly the entire game in Ink! This includes game logic. What isn’t exposed by Ink will be exposed through JSON.

This is a huge deal. It means the entire game will be so moddable, it basically will become an engine for users to write their own stories or even their own games. Of course they will likely need to use the same world map (hexagon grid), the same GUI, and the same “physical” dice. This can be circumvented (the entire game in just text & images) but I doubt most would want this.

Even better, this is quite a new technology. Few games are being made with Ink from my knowledge, even fewer released (from what I can tell, just Inkle’s own games), and of those currently being made by other developers besides Inkle - it seems they’re mostly pure text games.

I will likely talk more on Ink & how we’ll be using it in a later post. I know I wasn’t very convincing that this new technology will change gaming, but if you watch the GDC you can definitely see how. Simply amazing technology.

GDC VIDEO

---

With that said, I’ve been hard at work doing the writing for our first chunk of content, working on the game’s design, and nailing down the conflict resolution & combat system.

[CarterG81]

INK & PAPER ENGINE

As I help develop Traveler’s Tale, an Ink & Unity game, I am writing what is in essence an “engine”. It is (C#) code which parses Ink content, interprets Commands via Ink #Tags, and outputs using Unity.

Since Traveler’s Tale is our attempt at creating a type of “Pen & Paper” influenced game, and my intentions are for it to be highly or fully moddable, I thought that since Ink is already the Pen, we should just call this middleware “Paper”. I intend for it to be separated into three parts: Ink (compiled JSON), C# code separate from Unity combined with JSON & some game tools, and then UnityEngine for input/output. This way someone could replace Unity with Godot or a custom engine while maintaining all the logic (or simply translating the C# code into C++ or whatever). The game tools output JSON and Ink #Tags, so those tools are made with Unity but could he used for any engine.

Paper Engine is a combination of a Command API & Unity, with data in Ink & JSON, as well as likely some Game Tools made with Unity (to make it very easy for any user to setup how their scene should look by setting up background images & additional images or dynamic positioning, exporting the correct tags & positions of sprites within their scene, etc.)

I hope to implement Paper Engine 1.0 with basic commands - Backgrounds, Sprites (Positioning, Flipped; No-Animation), and a few “Game Modes” such as Hexagonal Map & player movement, an inventory system, a combat positioning system, and Polyhedral Dice system (Coin, D4, D6, D8, D10, D12, D20).

The idea is to be able to just “Write” a scene & automatically see it come to life without much work on the programming side. I want my gamers to be able to take Traveler’s Tale and to make & share fan-fiction of their own.

-------------------------------------------------------------
So I sell our game as game content
-------------------------------------------------------------

But consumers can create their own stories or fan fiction of whatever, like, by writing in Ink & creating images

-------------------------------------------------------------
Custom Moddable Fan Fiction Example
-------------------------------------------------------------

#GAMEMODE:SCENE
#BACKGROUND:AlienWorld.png
#CreateSprite(FutureGuy, FuturePerson1.png, 40, 54)
#CreateSprite(Name2, FuturePerson2.png, 70, 53)
#CreateSprite(Name3, FuturePerson3.png, 50, 50)
#CreateSprite(Name4, FuturePerson4.png, 60 ,51)
#CreateSprite(Name5, FuturePerson5.png, 30, 52)
FutureGuy: The future is awesome!

------------------------------------------------------------
Paper Engine™
adds Art & Game Systems to Ink Writing
-------------------------------------------------------------

Commands & are written as shown (normal for INK):

#BACKGROUND:COLOR(Black)
"Lord Ragnavaldr and the Kwaynosian Civil War" #TITLE

#BACKGROUND:KwaynosIntro.png
In the center of all civilization dwell the flourishing citizens of Kwaynos, the largest city in the world. Not a filthy city filled with thieves and beggars, but a beacon of unity and prosperity. The Kwaynosian Humans dwell with unapologetic acceptance alongside the multitude of Half Elves and minority of Halflings which they have always welcomed as kin. All are welcome in Kwaynos, but few foreigners stay long before returning to their homeland with luxuries and wealth. Culturally, the enormous population of Humans, Half Elves, and Halflings drown out and overwhelm any foreign influence - not through force or religious zeal, but by the jovial farm-fed laziness of the region which does not give even one care for any change to their easy lifestyle.

#BACKGROUND:KwaynosianLighthouse.png
#AddSprite(Lighthouse.png, 50, 500, false)
#ContinueMaximally
The Great Kwaynosian Lighthouse shines as a beacon of trade and prosperity for both dock workers and foreign merchants alike. Rivers flow from many directions towards the Kwaynos Docks. The City's citizens are well fed, well payed, and fully unionized. It might be worth mentioning that Kwaynos is not ruled by a single King, nor an oligarchy of merchants, but by a Democratic Counsel of its citizens. But it wasn't always this way.

I hope to implement Paper Engine 2.0 with advance commands - Animation, Intelligent AI Commands, etc. The idea of Away Mission is to simply set up a Scene, give commands to AI entities, and then have the engine run the simulation with dynamic results. Dynamic AI combined with Ink’s Dynamic Writing.

#AI_Action_Combat_ProtectEntity(SecurityTeam1, PeacefulCivilians)
#AI_Action_Combat_Combat(SecurityTeam2, Rebels, Stun)
#AI_Action_Movement(SecurityOfficerLead, RebelLeader, Kill)
Your Security Team attempts to protect the civilians while knocking the violent Rebels unconscious. {SecurityOfficerLeadName} however sets his Phaser on the Kill setting, with full intention of disintegrating {RebelLeaderName}.
*[Approve the plan.]
#UnpauseSimulationOnContinue
*[Command {SecurityOfficerLeadName} to set his Phaser on Stun]
-> Roll(SecurityOfficerLeadName, Loyalty, 20)
//On Failure #UnpauseSimulationOnContinue
*EngineerOfficer: We only have enough time to beam up {SecurityOfficerLeadName, so if we do so you will have to trust {NextHighestRankSecurityOfficer} to take charge and perform his own plan.]
-> HostageSituation(NextHighestRankSecurityOfficer)

This way it results in animated scenes playing out, with story text displayed & player choices influencing what happens before, during, and after the scenes play out.

-------------------------------------------------------------
So earlier versions would be simpler.
-------------------------------------------------------------

#GAMEMODE:Scene
#BACKGROUND:Ship_Bridge
#DIALOGUE:GloobGlopsOfBloob(GenerateRandom_Battleship_Gloobs, Mood_Adversarial)
We are the Gloob glops of Bloob! Bow down before us......
*We are not intimidated ...
-> StandStrong
*Do not destroy us! ...
-> BegForMercy
*Crew, what do you think? ...
-> CrewConsultation

-------------------------------------------------------------

#GAMEMODE:SCENE
#Background:CurrentPlanet
#DIALOGUE:GloobGlopsOfBloob(GenerateRandomTeam_Science, Mood_Friendly)
#SkillCheck(Translation)
//On Success
We are the Gloobs. We welcome you to our home world. ...
//On Failure
-> GloobGlobLanguageFailText //Gloob Gloob Glob Gloob Glob Gloob.
*[Attempt to Translate Again]
//Loop, or whatever

-------------------------------------------------------------

#GAMEMODE:Map
//This is done in JSON & with Ink variables
//HexTiles.json
{
"Space":{"TagValue":0,"Sprite":"Space"},
"Stars":{"TagValue":2,"Sprite":"Star"},
"SolarSystem":{"TagValue":15,"Sprite":"SolarSystem"},
"Earth":{"TagValue":1,"Sprite":"Earth2"},
"Sun":{"TagValue":18,"Sprite":"Sun3"}
//Whatever - example over
}

-------------------------------------------------------------
Later versions would be more complex.
-------------------------------------------------------------

#GAMEMODE:Scene
#BACKGROUND:Ship_CargoBay
#SpawnCrew(CommunicationTeam, Communications, 9, CargoBay_RandomCrewPositions.json)
#SpawnCrew(SpecialCrew, Communications, 1, CargoBay_SpecialCrewPosition12.json)
#AI_Action_Movement(CommunicationTeam, FinishWork_ExitRoom, Queue0)
#AI_Action_Movement(SpecialCrew, CargoBay_RandomExitPosition.json, Queue0)
#AI_Action_Facing(SpecialCrew, Up, Queue1)
#Delay 2
#AI_Action_Facing(SpecialCrew, Down, Queue3)
#AI_Action_Movement(ExitRoom, SpecialCrew)
//This results in the below.

-------------------------------------------------------------

Something like that, anyway. Obviously the latter is way more complex, and very far away. It also will only happen if it is the easiest / more feasible way to handle this content. Obviously if there’s a better way to write content for Away Mission other than Ink & Tag parsing, I will likely do that instead. It’s too far away to really be concrete right now.

Traveler’s Tale uses the basic commands though - art change, text displayed, maybe some audio effects & music playing at certain times, Dice Conflict Resolution, etc.

[CarterG81]

I’ve written the first batch of commands, and am now working to parse Ink content alongside user input (mouse click) calling CONTINUE(). Then test all the commands.

Commands include

• #CreateSprite(SceneID,ImageName,PosX,PosY,Flipped)
• #SetSprite(SceneID,ImageName)
• #MoveSprite(SceneID,PosX,PosY,Flipped)
• #FlipSprite(SceneID,Flipped)
• #DestroySprite(SceneID)
• #SetBackgroundImage(ImageName)

Everything is referenced by its SceneID. Once you create the object, you then reference it for any future changes.

The SceneID shares the Name of any characters, which is important if you want dialogue to appear above the character or with their portrait like in a JRPG or Comic book.

For special dialogue, you simply write content in the syntax of “CharacterName:”
This includes special functions like Titles (bigger font, centered on screen, bolded).

Title: The Future Game //Displays Title
FutureGuy: The Future is Awesome! //Dialogue box above the FutureGuy object

I should have results in my next update showing off the command by playing through the prologue story. Text displayed alongside the (placeholder) prologue artwork.

[ProfessorOFun]

----------------------------------------------------
Time Scale - Lowered Significantly
----------------------------------------------------

Awhile back we decided to scrap the idea of 1 tile = 1 day travel. The world is much smaller than this, and we liked the idea of adventures lasting about 10-30+ days rather than months-years. (With 1 tile per day, there couldn’t be a day/night cycle, season change, etc.)

I changed the design to focus more on the Camping aspect of gameplay. So now the game loop is

• Travel / Exploration (Player Movement - Map)

• Rest (Character Skills & Action)

• Sleep (Brief Conclusion & Show Results of Rest success/failure)

Random encounters, events, and story can happen during any of these phases.

TRAVEL / EXPLORATION
This is the majority of gameplay.
The player moves their party across the HexMap. This includes visiting locations, entering & interacting when visiting locations, random encounters along the way, dynamic events occurring due to party stats or item shortage, and general exploration of the world.
This consumes 8 hours of game-world time.

REST
When the player is running out of movement points, they know to begin looking for a good HexTile to make camp. Once the Player runs out of movement points or stops early, they set up camp.
The Player assigns his Party Members to various tasks based on Character Skill, Terrain, and Items.
For example, a Player may assign 2 party members to gather firewood & setup or create shelter, 1 party member assigned to the Hunting (Skill) in a nearby Forest hextile, and 1 party member assigned to the Crafting (Skill) to make more rope.
The results of these tasks can be dice based (Success/Failure) or can trigger random encounters / dynamic events which happen to only the assigned characters. For example the 2 party members assigned to gather firewood could be ambushed by some goblins or blessed by a fairy.
This consumes 8 hours of game-world time.

SLEEP
This is mostly just a time to trigger random encounters or dynamic events based on the quality of shelter, food, etc.
If no event is triggered, it simply passes, the player’s movement points are restored, and the loop begins again.
This consumes the remaining 8 hours of a day.
POST-RELEASE: We may add a Day/Night cycle & Forced-March feature, allowing the player to travel (move) & rest at any time they wish, or move past their movement points (suffering negative consequences).

--------------------------
Tile Size Increase
--------------------------

After some discussion, we decided to greatly enlarge the tile size. Since the game is pixel art & pixel perfect, this led to a decision between two paths:

• Shrink the Line of Sight the player sees at any point in time

• Create a 50% scaled down version of all tiles (HD & SD versions of every tile).

Both are feasible, but after some discussion we liked the idea of making the view more realistic. Not actually for the sake of realism (the eye can’t see past the horizon, where the Earth curves about 3 miles out; and 1 tile represents 1sq mile). I initially wanted the player to be able to determine their entire day’s trek before embarking a single time. However movement rates can vary from 10-30 tiles (miles) of travel in a single day. Since the first adventure is only about 40x40 tilemap, that would require insane line of sight.

Instead, the main reason for the change was to give the game a more “Exploration” feel to it. We are reminded of the first few turns of the Civilization series where revealing every tile is interesting and finding special tiles exciting. The added realism is just a bonus.

This means that the player moves several times during a single day. You’re moving 1-3 tiles at a time, with 10-20 movement points. You will explore a lot before having to Rest/Sleep.

--------------------------
GUI - DESIGN
--------------------------

I redesigned the size of the player’s GUI, taking into account the limited 3-Tile Line of Sight. I was thinking of having the GUI cover both sides of the screen - all remaining parts outside of the limited Map View.

ALL PROTOTYPE

On the left, will be the player’s party member information. The boxes are prototype spots for “things”. Icons, Skills, Inventory, Stats, etc. Most likely we’ll have the portrait/name/text on the left half (Image, Lord Ragnar, Nobleman, etc.) and on the right (with the 12 boxes) will most likely change based on whatever icon/button pressed.
Display the entire party’s inventory/backpack, Display their Skills, Stats, Details, or even short quips in speech.

On the right, will be the Party stats & anything else that we’ll need to add to the game. Morale, Food/Supply numbers, and any other relevant game information related to the PARTY. Also buttons for game options, setup camp early, quit, dismiss party members, etc.

I liked the general idea of maybe having the GUI speak a bit of “Retro”, although that is also up to our Artist.

While we are going to prioritize 2018 Usability & Accessibility, and a good looking GUI over anything else, I’d love it if we could do a 2018 version of retro game GUI. If it fits the game.

While I always hit F10 ASAP for practical reasons, I still liked the original boxed-in Stone GUI.

I love my old school classic games.

I was also thinking of doing a Simplified (Small) version of the classic box inventory like seen in games like Diablo or NeoScavenger. Maybe combined with a backpack image background, reminiscent of Ultima.

It’s the only system I know of that can simulate both Weight and Size.
I’d like a system which represents real life carry capacity best. A weight-based system doesn’t suffice. Sometimes things aren’t heavy but are long or wide or awkward.

ex. A spear doesn’t weigh much, but is extremely awful to carry - especially through interior rooms.

[CarterG81]

Ink & Paper really remind me of SCUMM games. Ink reminds me of SCUMM itself.

It amazes me that between 1987 (SCUMM) and 2014 (Ink/80-Days) there wasnt much inbetween. Nearly 3 decades between SCUMM & INK.

Ink & Paper remind me of SCUMM because of how in SCUMM you would write

Walk DrFred to LaboratoryDoor

And that is what would result.

Future games made in Ink really get me wondering what the future holds. I cant wait to see Inkle’s next game Heaven’s Vault.

INK is far more elegant though, and infinitely more powerful. I definitely think gamers are up for gamedev revolution in the related genres because of how awesome Ink is. Afterall, 80 days has glowing reviews. Things like “I played 30 times and never once read the same story twice.” Amazing praise.

I am excited to begin work today, further developing Paper so I can combine it with Ink to make “Ink & Paper” which to me feels like 2018 SCUMM.

[CarterG81]

Unfortunately Ink doesn’t support variables in #Tags. So I’ll have to change the syntax to use plain text rather than #Tags. Not a big deal, but it will set me back a few hours.

I also ran into a bit of an issue with character image names. Right now for simplicity we just output sprites with all the different variants of dress or hair color using a particular naming convention.

//Race_Class_Gender_HairColor_FactionColor_variantExtra_Pose.png

Half_Elf_Knight_Male_vBrownHair_Orange_Combat.png

Kwaynosian_Knight_Male_vBrownHair_Green_Scene.png

Kwaynosian_Knight_Female_vRoseHair_Green_Scene.png

I am thinking we will need to change this to be based on character variables, so it’s easier to reference the imageName by just grabbing a character’s variables.

VAR Race = "Half Elf"
VAR Class = "Knight"
VAR Gender = "Female"
VAR Variant = "vBrownHair_Green"
VAR CurrentPose = "Scene"
VAR ImageName = {Race}_{Class}_{Gender}_{Variant}_{CurrentPose}

Then reference image in Ink, like so:

>> CreateSprite(Sir Leon, {ImageName}, 50, 50, false)

Then just change Pose before rendering.

>> CurrentPose = "Combat"
>> CreateSprite(Sir Leon, {ImageName}, 50, 50, false)

This also gives me more flexibility for dynamic generation within Ink language itself.

=== Greenskin_Ambush ===
{RandomGreenskinCharacter(1)}
RandomNPC1_Pose = "Combat"
//If dialogue attempted
>>CreateSprite(GreenSkin1, RandomNPC1_ImageName , 50, 50, false) //Render to screen
//If straight to Combat
>>GAMEMODE(COMBAT, GreenSkin1) //Start combat

=== RandomGreenskinCharacter(1) ===
RandomNPC1_Race = {~ Orc | HalfOrc | Goblin | Troll} //Random Greenskin Race
RandomNPC1_Class = {~Warrior | Priest | WargRider | Peasant } //Random Class
RandomNPC1_Gender {~ Male | Female} //Random Gender
RandomNPC1_Variant {~ BrownHair | Ponytail | BlueHair | Bald } //Random Look
RandomNPC1_Pose = "Scene" //Default Pose

I think I will replace the colon : with the parenthesis (). A bit more work, but might as well have the best syntax, which I’m thinking should be exactly the same as the function being called.

>> CreateSprite(SceneID, ImageName, PosX, PosY, Flipped) //INK text
public void CreateSprite(string SceneID, string ImageName, int PosX, int PosY, bool Flipped) //C# command

[CarterG81]

Just finished updating for the new syntax.

Replaced

#Command:Parameters

With

>>Command(Parameters)

Tested the commands, and everything works perfectly; now with Ink variables!

Also added commonly used commands. but in Ink “Theads” rather than in C# functions.

When generating new NPC’s, I’ll have to keep track of NPC’s in the same way as Party Members. This means limited slots with names like NPC_1, NPC_2, NPC_3, but as prefixes for all variables.

So one character is

NPC_1_Name = ""
NPC_1_Faction = ""
NPC_1_Class = ""
NPC_1_Race = ""
NPC_1_Variant = ""
NPC_1_Pose = ""
NPC_1_Etc = ""

It’s times like this that I wish INK supported custom classes and dictionaries. That way I could just have a “Character” class and store them in some data container. Character Ogre5 = new Character(). ActiveCharacters.Add(Ogre5);

Oh well. I’ll live. There aren’t that many characters needed in any scene, and the max can always be easily extended via Copy/Paste.

[ProfessorOFun]

--------------------------
RANDOM NAME GENERATOR
--------------------------

It was surprisingly difficult to find a name dictionary. I found a wonderful Medieval Europe dictionary, but it wasn’t sorted by Gender & Surname, just a huge list of names. Eventually I found one though.

In INK, I wrote up some functions to get a random name from these dictionarys of hundreds of names.

=== function GetRandomNameFromDictionary_Medieval_Surname() ===
~return "{~Aarland|Aartse|Abalardi|Abaroa|Abbado|Abduvaliyev|Abeille|Aberasturi|Abineri|About|Abrahamse|Abrao|Abrassart|Abruzzi|Abse|Abt|Aburto|Accardo|Accola|Accornero|Achard|Acker|Ackermann|Acklin|Acquaviva|Acuna|Adam|Addinell|Adelung|Adenauer|Adeney|Adler|Adriaens|Adriaenssens|Adrianszen|Advocat|Aehrenthal|Aertsen|Afiata|Agafitei|Agani|Agarand|Agare|Agassiz|Ageet|Ager|Agina|Aginaga|Agirre|Aglietti|Agnelli|Agnolutto|Agosti|Aguerre|Aguilar|Aguilon|Aguzzi|Ahlmann|Ahmetaj|Ahmeti|Aiello|Aigner|Aixpuru|Aiza|Aizkibel|Ajello|Ajeti|Ajkler|Akaregi|Akordagoitia|Akutain|Alacoque|Aladár|Alagna|Alard|Alasia|Albani|Albarello|Albelin|Albergati|Alberigo|Alberro|Albers|Albert|Albertazzi|Alberti|Albertini|Albertoni|Albertrani|Albertse|Albertszen|Albertz|Alboreto|Albouraie|Albrup|Albusel|Aldair|Aldape|Aldobrandini|Alembert|Alessi|Alevi|Alexandre|Alexopolous|Alexopoulos|Alfieri|Alger|Alhmann|Alia|Alibali|Alicata|Aliee|Alighero|Alighieri|Alii|Alikaj|Alis|Aliti|Aliu|Aljie|Allard|Allaro|Allbach|Alloncle|Allori|Allucingoli|Allut|Alphand|Altabani|Altaner|Altard|Althape|Althusser|Alti|Altichiero|Altichioro|Altieri|Altmann|Aluztiza|Alvares|Alves|Alvintzi|Alyea|Alzate|Alzen|Amable|Amanar|Amann|Amati|Amato|Amberezzio|Ambre|Ambrogi|Ambrogiani|Ameche|Amélineau|Amelotte|Amendola|Amerman|Amestoy|Ametxazurra|Amici|Amicis|Amico|Amiel|Amient|Amiez|Amiot|Amiti|Amlinger|Ammacapane|Ammanati|Amocacci|Amore|Amoruso|Amoudry|Ampère|Amstadter|Anagyrou|Anasagasti|Anastassiou|Ancel|Ancellotti|Anchia|Anciaux|Andikoetxea|Andrade|Andraka|Andras|Andrássy|Andreadis|Andreou|Andretta|Andretti|Andretto|Andreu|Andreucci|Andriani|Andries|Andrieux|Andriolo|Andriopoulos|Andronikos|Andros|Androuchelli|Androupolos|Androutsos|Anelka|Anganuzzi|Angelico|Angelis|Angelomatis|Angelou
... //A-Z Names

Problem

Ink’s Shuffle function is awesome in keeping track of usage. So in that function, it will never choose the same name twice until it is completely through the list. That’s fantastic for First names. Not good for Surnames.
I want the player to be able to run into characters with the same surnames.

Solution!

Just roll a random number to get an already used Surname INSTEAD of a new random one.

~ temp ranNum = RANDOM(1,10) //100% chance in 10% increments
{
-ranNum == 1: //10% chance for the new character to be a Cousin of Someone
~return {GetSurNameOfCurrentPartyMember}
-else: //Unrelated. New Unique Surname entirely.
~return {GetRandomSurName()}
}

This way the Player has good probability (10%) to actually see blood relatives with duplicate Surname. Instead of a ridiculously low probability (Shuffling a single name twice in a list of hundred’s/thousand’s), which is something like <0.1%.

Works great!

[CarterG81]

MORE NAME PROBLEMS

We’ve decided to temporarily use a Name list, but ultimately want to make our own Random Name Generator using name pieces (Prefix + MaybeMiddle + Suffix) so as to be more “Roguelike” and “Fantasy Game”. These will create names that never actually existed, but we think it’ll be a lot better.

I also shrunk the name list to just a few names. Having over 10,000 names in a Shuffle caused Ink to take forever (around a minute) to compile. We can still use this, but you’d want to remove the list for testing purposes.

A lot of the historical names we found just don’t sound very appealing & are too varied. Our designer would like there to be more cohesion, such as giving a certain race more Irish sounding names, giving Elves more “Elven” style names, etc. Rather than everyone sharing from a huge bucket list of historical names which sound strangely out of place for a fantasy game.

However that is a bit of work that I have to do to create our own random name generator, so we’ll postpone that until later.

SPECIAL CHARACTERS
I added in “Special Characters”.
These are part of your Party, but they aren’t involved in the normal party game rules. They don’t trigger random events, they don’t get chosen during an event, they don’t have their own GUI or inventory, and they might not participate in combat (but will be displayed in the Scene - likely towards the back or behind certain characters).

Currently we are using the “Special Character” to be the Hero’s Squire. Their inventory is rolled into the Hero’s inventory capacity (so the Hero’s backpack space is boosted by the Squire’s existence). The Squire can’t be killed (unless the Hero is killed, which is game over), etc.

Originally the Squire was part of the Hero - they even shared the same image.

However, we wanted the ability to have the Hero or Squire to be rendered alone or apart.

We’ll add in options for Special Characters as needed. For example we may later allow them to be part of combat by having a bool option.

SpecialCharacter1_ParticipatesCombat = true
SpecialCharacter1_ConsumesFood = true
SpecialCharacter1_ParticipatesEvents = false
SpecialCharacter1_TriggersEncounters = false

Other examples of characters would be people you saved, like a Noble who is near useless but travels alongside the party, consuming food & appearing in Scenes, but otherwise being nothing but a quest token.

[CarterG81]

INK TEXT RENDERED
SCENE MODE NEARLY FINISHED (ALPHA)

I am nearly finished parsing all the content.

• Commands all work great & are documented.
• Text is now parsed
• Titles are parsed
• Character-Specific Dialogue Text is prepped (need a prototype UI & dynamic positioning for these)
• Player Dialogue Choice system still needs to be implemented, but after that I should be able to move on to the inventory system / travel Map Mode interface.
• Just 4 more systems to add, and I should be finished programming the Alpha. In this order: Inventory System, Merchant/Trade System, Dice System, Combat Positioning System. Then I’ll be able to go back through & polish everything. Hopefully with real art for all the GUI’s by then.

Also fixed some bugs, naming convention tweaks, & did a thorough test of everything we’ve got so far!

All of this is prototype obviously so no polish, but the functions all work.

Write story text in Ink

TITLE>:The Centered Big Black Text

Produces titles, which are displayed differently than Narration Text.
Character sprites can be rendered, moved, changed, flipped, deleting, etc. All with written commands in the story. Backgrounds changed. etc.

Player’s starting Party is also procedurally generated. So the Name, Race, Gender, and variant graphic (Hair Color, Hoods, etc.) changes every time. We may also randomize the party’s starting items and character skills, sins (ex. Alcoholic, Sexist), and virtues (Charitable, Intelligent).

[ProfessorOFun]

Updated the OP to include a link to the Paper Engine™ Devlog.

Paper Engine is what Traveler’s Tale uses, so they are one & the same. Later usage of Paper Engine will likely include Away Mission (which will also be fully moddable).

The difference though is that Traveler’s Tale is our own game, while Paper Engine is a fully moddable, featured set of tools, command API, and middleware that anyone can use to make their own games with “Ink & Paper”. It’s explained in the Paper Engine Devlog- first two posts.

[Ceciphar]

Hey Great game!
Just wondering, what do you use to draw and animate your pixel art.

[FancifulFox]

@Ceciphar

Hey Great game!
Just wondering, what do you use to draw and animate your pixel art.

I’m currently using photoshop. Carter, however, thinks MS Paint is the superior tool. To each their own lol

[CarterG81]

I’m stuck in my ways, having used MS PAINT since the days of old.

Photoshop…pfft!