Holy shit. Alec Henry made a random Stay Frosty character generator. This is amazing.
Holy shit. Alec Henry made a random Stay Frosty character generator. This is amazing.
Originally shared by ****
Casey G. check it out.
I felt Stay Frosty needed some love with all the Traveller character gens floating around.
http://philome.la/lv1_librarian/garske-games
Originally shared by ****
Casey G. check it out.
I felt Stay Frosty needed some love with all the Traveller character gens floating around.
http://philome.la/lv1_librarian/garske-games
Pretty much the most intimidating character possible.
ReplyDeletehttps://lh3.googleusercontent.com/jSYdiv__kbPS82BkVPPG0geuPUI_VtBVHRVRqIPZ8aO7gqrhnblvVtEOm2zqcGtviaGrtqsf9vI
Deadly accurate with an area effect weapon. Nice.
ReplyDeleteYeah, you could weigh it if you want.
ReplyDeleteoh, built with twine. that's a great idea!
ReplyDeleteYour Brains are 7+
ReplyDeleteYour Brawn is 6+
Your Dexterity is 14+
Your Willpower is 10+
Your MOS is Infantry. You re-roll 1's on damage rolls for personal weapons. You've been issued Sniper Rifle
RANK: Sergeant - You have Advantage on Battles of Will. You've been issued a Swagger Stick.
Hit Points: 11
Stash
1 Ration
1 Ammo Die per Weapon
Swagger Stick
Sniper RifleScope
Satchel Charge
Armor
Back & Breast Armor
Helmet
That's hilarious.
ReplyDeleteNever applied themselves. Joined the military for some direction.
ReplyDeleteThe only change I would make, Alec, is maybe weighing Armor as less likely when you go totally rando. Since there's no requirement for it, you get as many Armor as Infantry results.
ReplyDeletei have yet to design my own game. but this thread has me wondering about proof of concepting stuff like this via twine as a play testing mechanic.
ReplyDeleteyou've got a somewhat interactive / branching process. as part of a game. such as character creation. is it useful to use something like twine to produce a simulation of a rough draft idea?
ReplyDeletei honestly don't know. i've never designed games. but i design software. and i know the value of early error detection in the design process. i assume that holds pretty true in the design of anything.
similar to setting up a random encounter table as some sort of app / program and spot checking 1000+ rolls against it. do the results "feel" right? do we need to tweak the probabilities? does one result stand out in context as not really as good a fit?
is twine useful for a similar sort of simulation? can we surface oddities and corner cases in twine based simulations before we get down to (valuable!) play testing with actual humans? does the nature of twine end up baking in too many assumptions of the process itself to work well as a play testing tool?
i seriously can't answer any of this shit. but that's what i'm thinking about.
i don't know how much if any traditional computer programming experience you may have. but library science has quite a bit of overlap. from the way content is organized in menus / web links to the way we lay out files in a project. that stuff is important and we could learn a lot from librarians. a small but significant number of programmers have been banging that drum since before i was born. but anyway…
ReplyDeleteboth the blog links in your profile are currently broken, by the way.
awareness of how many distinct data points a given process has available and which of those it requires access to is a vital part of software design too. and sometimes, even often, we can be tempted to turn a data point into a requirement for some process simply because it is available. but doing so can produce a big ball of mud.
ideally we want a modular design where any single element (such as character creation) can be swapped out with a total rewrite without needing to refactor other areas. the rewrite needs to follow certain rules as to how it interacts with the other elements (ie an "interface"). and the shorter the list of those rules are and the more clearly defined each is the better.
and hell, now you got me thinking about mocking up planning documents and process diagrams in twine. for software projects.
maybe i've drank too much coffee today?