Wednesday, November 22, 2017

Posts Delayed

With the holiday and some personal things I'm not going to be posting this week, but I'll pick everything up again next week :)

Wednesday, November 15, 2017

The Elemental Empire - part 4 - What is Magic?

    One of the biggest things I have to consider for the Elemental Empire setting is, what is magic?  Magic is a big, wonderful, pain-in-the-***.  I love magic, I love playing wizards.  From a design standpoint however, I hate magic.  Magic is one of those things that is so hard to do well, it can easily become too over- or under-powered and destroy everything else you've created.  Just do a Google search on "wizards vs fighters" (ah, the liner fighter and quadratic wizard, I've read so many of those posts) and see the never-ending arguments about magic and how it works in the game.  Any game, while this is a favorite past-time of D&D players, any game with magic has the same potential problems.  So magic is something that needs to be carefully weighed and purposefully designed.  And it starts with a  simple question: what is magic?
    Well, there are so many ways to answer that question, but let me posit there is one fundamental core to any definition of magic: the ability to do super-human things.  Yeah, this covers a lot of things that are not considered "magic" per se, like super-powers and psionics and super-science.  Anything that is beyond the human normal is "magic" by this definition - but I think it's a vital starting point.  There is the famous Arthur C Clark quote that "any sufficiently advanced technology is indistinguishable from magic" which hits it on the head.  The thing that makes magic such a nightmare to design is that it allows the players to do things beyond the normal for humans - which means that the world we all know and expect and make decisions based on gets thrown out the window.  Highly advanced technology and comic book powers are magic for all intents and purposes, because they all take you out of the familiar and predictable world and take you somewhere else.  They break reality, and breaking reality is a tricky thing.  While choosing the Roman Empire for an inspiration is going to take players out of the world they know (if I do it right, of course) adding magic is an even bigger shift.  Changing how people act and think is a lot smaller than changing the definition of reality itself.
    Since I'm creating a setting with magic, I'm allowing reality to be broken, then how do I want it to break?  Having some good, strong, logical and consistent rules is going to be vital here.  Since this is a story first, it is a setting after all and all RPGs are Interactive Narratives at heart, then it might be good to ask: what story purpose does magic serve?  And that is a very interesting question.

    I've always thought that the D&D system of magic, typically called "Vancian magic" was a great and terrible fit for a role-playing game.  For the few who might not know, D&D magic is very similar (I've never heard that it was directly adapted, just similar) to magic in the "Dying Earth" stories by Jack Vance.  In this system, fundamentally, mages can only know a limited number of spells and they lose the spell when it is cast.  Think of spells as grenades: they are very powerful, they take skill to use properly, you can only carry so many, there are multiple types, and after you use one it's gone- but you can get more if you have the right supply.  Yeah, spells are grenades, I had never thought of that metaphor until just now but it actually works really well.  This feels like a great fit for D&D because of it's war-gaming roots.  Spells are artillery, fighters are infantry, it works.  But it feels like a bad choice to me for a role-playing game for one reason: in the RPG magic is common, but in the stories and the system itself, magic is rare.  Vance's stories are called the "Dying Earth" for a reason.  This is a far-far-far-future Earth of magic and super-technology, and both of those are being completely lost.  The spellbooks that hold magic have vanished, and once a wizard casts a spell it's gone, so magic has mostly disappeared from the world.  Nobody remembers how to use technology.  The world is decaying, and the "fire-and-forget" style of magic fits that theme perfectly.  If magic was a renewable resource then it wouldn't be dying, it would still be around and viable.  Which would kill the theme that Vance had set up.  So it's odd to fit that system into a world where magic is common, or like in the Eberron setting (which I like by the way) where it is literally everywhere in civilization.  The narratives don't quite seem to line up.  Want more proof of that, try playing the old computer games like the "Gold Box" SSI games Pool of Radiance or Neverwinter Nights and count just how many days really pass while you play.  Mages have to sleep to refresh their grenade supply, so there is a lot of sleeping in those games that faithfully reproduce the system.  Thank god there's no real time limit to defeat the evil dragon.  In the 4th Edition of D&D or the Neverwinter MMO they dropped the whole memorizing thing altogether to facilitate a more active style of play.  The mechanics of magic, the definition of how it operates, encourages a certain style of narrative.
    So I ask myself, what kind of narrative do I want?  Why is magic in the game, what kind of stories is it designed to tell?
    For me, magic is human emotion made real.
    While we often take it personally, Nature is impersonal.  There is no such thing as "Mother Earth."  Mothers have feelings, they care for their progeny because they feel love and nurturing.  While Nature does provide for us (would suck to not have food and air and stuff) it does not do this out of any feeling or desire, it just does it.  It would do it even if we didn't exist.  It, the world and the laws that drive it, doesn't care about us.  If you say it does, then you've just created magic - the literal existence of human emotion.  Emotions drive us, sometimes when we wish they wouldn't.  There is no such thing really as anger, because emotions are not things, they are movement.  You are angry at something, you feel fear towards or away from something.  Having an emotion pretty much by definition moves you, being hungry drives you towards food, being afraid of spiders drives you away from them, feeling angry provokes certain actions.  Emotions are dynamic, and they are targeted.  People often say they would "work any job" or "eat anything" but those statements are pretty much never true.  Would you work as a human crash test dummy?  Or a roller-coaser mechanic if you're afraid of heights?  Would you eat a human being?  Odds are not.  With that emotion comes the target, the thing we want to have or do to fully satisfy that emotion, though we might settle for something else if we can't get what we want.
    So why is magic in my game?  To tell the stories of when someone's emotions change the world.
    This happens anyways, right?  I mean the dictator's desire for power leads him to take over the country and create a repressive regime instead of a land of milk and honey.  Yeah, it does.  The only reason we change the world is because of some feeling to do so.  Because we want to do so.  But the nice thing about magic is how quickly we can show that impact, and how broadly we can create connections.  How many unexpected and unfamiliar ways we can change reality.  Because while taking people out of the world can be dangerous from a design standpoint, it can be great for creating feelings of wonder.

    Okay, with that really broad starting point let's start refining magic.  Another key question to ask is: what's the difference between magic and technology?
    As I mentioned above, it's quite possible to push technology into the realm of magic, so what's the fundamental difference between them?  I have some strong ideas about this.  While the "magic grenades" analogy works for D&D magic, I really wish it didn't.  If magic and technology work in the same ways, then why bother calling them different things?  Why bother having both of them?  There needs to be some fundamental differences between the two.  What do I want to be different?
    Technology is impersonal - it's possible to accidentally shoot someone with a gun, it's impossible to accidentally cast a fireball.
    Technology is repetitive/ mass produced - there are a million swords, there is only one Excalibur.
    Technology is stable, reliable and repeatable - a hammer always acts like a hammer, a spell changes depending on the caster's identity and emotional state.
    Technology is governed by scarcity, magic is governed by cost.
    That last one deserves more explanation.  A gun shoots until you run out of bullets.  You cast fireballs as long as you're willing to pay the price.  This is the biggest thing I think is missing in RPG magic.  In the Vancian system magic is governed by scarcity, you have so many spell slots/ grenades that you can use.  But there is no cost.  You automatically gain those slots and they automatically replenish.  I don't like that model because I think all the best stories about magic focus on the cost of using magic.  Just think about Faust and the "selling your soul to the devil" theme.  If magic is emotion, then what price are you willing to pay for your emotions?  So magic needs to be governed by price, by cost.  There has to be a cost to gain it, and a cost to use it.  And you have to be able to do anything as long as you can pay the price.  I think that's the most critical thing to bake into the system.

    Here's the thing that really ties my brain in knots though: does everyone need magic?
    If magic is emotion made real, then doesn't that make non-magical classes or characters somehow lesser, or more restricted?  It is possible to say that all player characters/ classes use magic, the Earthdawn game does that just fine.  And you could say that the fighter-types just use a more limited or less-cost system of magic compared to full wizards/ casters.  And that would make sense, not everyone wants to sell their soul, maybe just lease it, with an option to buy :)  If magic comes with a price, then some might want to only pay for a sensible, small car and not a full-blown luxury yacht.  And since I'm defining my Humins to be innately magical (to justify the half-breeds) then saying they all use magic to a lesser or greater degree works.  And the other races may not have the same flexibility in using magic, but might still have innate magic, more like limited super-powers instead of the "can do anything I imagine" of a caster.

    Okay, I think that gives me a good foundation for thinking about magic.  Well, to start with.  So let me wrap this up and let those ideas percolate though my unconscious, and next week we'll take a look at the other side if the coin: what kinds of technology do I want in this world?  Until then!

Tuesday, November 14, 2017

Limiting Results To Represent Experience

    In most games a character's growing experience and skill are presented by an increasing modifier.  So in the 5e SRD I've been looking at there is the "proficiency bonus" that starts at +2 for a beginning level 1 character and goes to +6 for the supreme level 20 character.  In addition the 5e SRD, like many other games, adds a die roll to represent uncertainty and randomness to that modifier.  In this case it's the d20.  This is a pretty common system, though the size of the dice and modifiers varies.
    But I had a thought- what if instead of adding a modifier for experience/ skill we just changed the dice?
    The idea came from another thought.  I believe that one of the key differences between the amateur and the professional is reliability.  An amateur is unpredictable, they may perform wonderfully one day and terribly the next.  By contrast the master is consistent, they regularly perform at a high level.  They may have bad days, like anybody, but they will not swing as wildly as the beginner.  This can be represented easily in dice.  A single d20 is wild, it has the same odds (5%) of rolling a 1 as it does of rolling a 20.  Add in dice however, make it 2d10, and things change.  With 2d10 you lose the lowest result, the 1.  But at the new extremes, 2 and 20, you only have a 1% chance of rolling either.  But in the middle, at 11, you have a 5% chance of rolling that on a d20 but a 10% chance on 2d10.  This can be easily seen at the great website Anydice...

    So by changing from 1d20 to 2d10 for being "skilled" (let's call it) we've changed the odds quite a bit.  Our less skilled character has a 10% chance of rolling a 1 or 2, while the more skilled as a 1% chance of rolling a 2 and can't roll a 1.  So the more skilled has less critical failure than the less skilled.  That works.  On the opposite end, the less skilled has a 10% chance of rolling a 19 or 20, while the more skilled has a 3% chance - whoa, wait a minute, the more skilled has less opportunity for critical success?  That doesn't seem right.  Well, okay, but let's look at overall success.  The less skilled has a 50% chance of rolling an 11+, while the more skilled has a 55% chance.  So while they get fewer critical successes, they also get fewer critical failures and a slightly better overall chance of success.

    Those results are not terrible, but also not great, just changing the dice doesn't really give the kind of results I'd had in mind.  But then something else came to me: what if we changed the dice a lot?  Let's say we had 6 different skill levels: d20, d12+8, d10+10, d8+12, d6+14 and d4+16.  That's a lot, likely more than we'd want to use, but it gives us a good spread to choose from and just uses the typical RPG dice.  Let's compare these rolls to target numbers.  Let's see the odds of success for each against a DC: 10, 15 and 20...

d20:        55%  30%  5%
d12+8:    92%  50%  8%
d10+10:  100%  60%  10%
d8+12:   100%  75%  13%
d6+14:   100%  100%  17%
d4+16 :  100%  100%  25%

    There are a couple of things I like about this system, and a concern.  the biggest concern is working with only a few target numbers, like I did above.  I think for something like this I'd use more and closer target numbers like 12, 14, 16, 18 and 20.  Which would give:

d20:       45%  35%  25%  15%  5%
d12+8:  75%  58%  42%  25%  8%
d10+10:  90%  70%  50%  30%  10%
d8+12:  100%  88%  63%  38%  13%
d6+14:  100%  100%  83%  50%  17%
d4+16:  100%  100%  100%  75%  25%

    The extra granularity would help I believe.  I do like how higher levels of skill remove the possibility of lower results, in a way.  The idea that a master will never fumble or do something requiring a low roll has a good feeling of accomplishment, even though it eliminates some dramatic possibilities.
    Another thing that I think would be good about this system is modifiers.  Since the different dice create different possibilities I don't think you'd need many modifiers, and the ones you used would have a different effect.  With a +1 modifier the numbers would change like this (a partial table for brevity's sake):

unskilled- d20+1:  50%  40%  30%  20%  10%  (+5% to each)
medium skill- d10+11:  100%  80%  60%  40%  20%  (+10% to each)
high skill- d6+15:  100%  100%  100%  67%  33%  (+17% to each)

    So as you can see modifiers become more important at higher levels, which has the right feel to me.  I think the more skilled should have more draws, that every little thing should be more vital.  This also means that the +1 sword you got at first level (when you were unskilled) is literally 3 times more useful at 20th level, so again you can keep the modifiers down and make your equipment more valuable.  That will hopefully encourage players to hang on to their early items and grow with them instead of discarding them for some new shiny.

    I'm not sure if this is a worthwhile at all, but I think it has potential.

Monday, November 13, 2017

Looking at the 5th Edition SRD - part 9 - Feats and Final Thoughts on Classes

    Since part 4 of this series started on classes and we're at part 9, I've been thinking about classes for a while now.  I want to wrap up this section and move on to other mechanics, even though I could write tons more picking apart all 20 levels of all 12 classes (that's 240+ abilities).  This post is going to hop-and-skip around a few different topics.

Ability Score Increases
    Every class gains an ability score boost every 4 levels.  This is weird to me.  The 3.5e SRD gave these on character levels, independent of class, so the shift is interesting - why did they change it?  I'm not sure.  It seems like it would punish multiclass characters, making a full level essentially worth nothing.  Which is point number two, even with the flat math of the game, this does not seem like it would feel very impressive to get as a level-up reward.  I don't agree with this one, this is something that logically should be in the background, not a specific character ability (the fact that every single class gets it exactly the same way and on the same schedule seems like it would suggest this is not really a class-based effect, just a part of growing older and wiser regardless of class).

Multiclassing and Leveling Up
    I am not a fan of counting XP, or gold either for that matter.  I think it adds a lot of book-keeping for little to no return.  What exactly is so dramatic about being 1 orc short of level 5?  What does the game gain from trying (and typically failing) to create an economy?  Along, in a way, with that I hate multiclassing in every class-based game I've ever read.  So, I'm not going to be taking a close look at how the 5e SRD handles either of these two topics because I already know I'm going to make something of my own (or steal from another game).  Again, this look is to help me prepare to create my own game, not because I want to pass the rules lawyer bar exam ;)

Static vs Dynamic Abilities
    This is something about how class abilities are created that eats at me.  Generally each class has one dynamic ability, a single ability that will gain extra options (not just extra power) as the class advances.  All the other class abilities are static, a single bonus to a single thing, which may "level up" by being a +2 bonus at the level one and a +3 bonus at level 3 and so on.  The thing is, static abilities are the least interesting.  They add one cool new thing, but often to only one circumstance, so while while getting a new ability feels good, how much you'll actually use it is another matter.  Second, increasing modifiers are evil, they lead to the dreaded numbers bloat.
    Dynamic abilities are the real magic, they let you do new and interesting stuff as you progress.  Having 3 ways to deal with a monster at level 1 and 50 ways to deal with a monster at level 20 feels like you've actually grown.  Because you have.  Increasing a modifier means you've progressed, being able to do something you couldn't, or having a new way to do something means you've grown.  But the game does not handle dynamic abilities very well.  In particular the fighter classes don't get any or very strong dynamic abilities.  Look at the Fighter's "Fighting Style" ability, which they can choose only once (in the straight class, not counting the archetype I'll go over later).  That's it.  Compare that to the Wizard's Spellcasting ability.  The classes with weak or no dynamic abilities need to be shored up.  But also, it feels kind of funny that at most every class only ever gets 1 dynamic ability.  Most of those are gained at 1st level, and the following 19 levels are just static abilities.  It seems to me that there should be 2 or 3 more dynamic abilities that are milestones of growth, adding a lot of options and more future options to the character as a sign of their growth through adversity.  I also think that higher-level monsters need more options and abilities than lower-level ones, so having more options as a character is necessary to find the more limited weaknesses of the monsters and/or resist the more frequent monster abilities.
     Along with this static vs dynamic thing is something that was huge in the 3.5e SRD, but deprecated in the 5e SRD, feats.
    If you ever played D&D 3.5 or Pathfinder then you have likely had many nightmares about feats; tracking the extremely complicated prerequisite chains and trying to pick out the handful for feats you got over your career from the hundreds to thousands (depending on how many books you bought) available.  Feats sucked.  There, I said it, they sucked.  They still suck big time in Pathfinder.  They suck because everybody and every book has to include two dozen new feats and there are no solid guidelines for what a feat is or how powerful it should be - so they vary hugely, wildly, and ridiculously in power.  I can easily think of several feats that should be abilities anybody could do, more that should be skill checks and several that are wickedly overpowered in the right combination (which I know from the players who've discovered those combinations).  They add way, way too much complexity and system knowledge and pre-planning to the game, which again gets worse with every new book.
    And I rant about another game to set up the fact that the designers of the 5e SRD knew all this about feats, so they totally changed the system.  In the 5e feats are optional, you can take a feat instead of an ability score increase if your GM is using this optional rule.  And as for power, the SRD has only one feat, again a sickening lack of guidance, and that feat is Grappling.  Grappling is arguably something that anybody should be able to do, though the feat does give you Advantage on it, so there's something.  The feat also lets you attempt to pin someone you have grappled, which again kind of seems like something anybody should be able to do.  I totally know how to grab you and wrap my arms around you to try and keep you from acting, I can see in my head how to do it - I'm sure you can too if you've ever been in a grade-school fight or watched an action movie.  I might not be any good at doing it, and I would get my backside kicked by a professional fighter, but it is an option.  This feat does not seem to add any really significant new options or dynamic abilities to the character.  So, sadly, the feat system in the SRD is useless.  No guidelines for what a feat should and should not do or how powerful they should be.  That's sad.  The total lack of feats and backgrounds makes me wish they had just left them out of the SRD altogether.  I think no system would be better than a system with bad or non-existent guidelines.
    I also started this feat discussion/rant with another game because I think a different game got feats right - and it's an OGL game too thank goodness.  In 13th Age you get a feat every level, and every class ability (even spells if I remember right) has 3-5 feat options - so you pick what ability you want to apply the feat to, and now that ability can do something new.  Perfect.  A nice dynamic expanding of your static abilities, and a system that helps make two identical classes grow in different directions.  I hate the 5e SRD's feats, but I will totally steal 13th Age's system.

Class Archetypes
    Speaking of static vs dynamic (which apparently this post turned into, huh) there are the class archetypes.  Every class has one of these, by some name.  It is the "Primal Path" for the Barbarian, the Cleric's "Domain" and the Warlock's "Patron".  At some intervals each archetype gives specific bonuses.  This makes two characters of the same class different, assuming they took different archetypes.  Each class gains/ chooses its archetype at a different point, either 1st, 2nd or 3rd level, and the archetype abilities are gained at different levels for each class.
    Like feats this is one of those systems that sounds good in practice, but can easily spiral out of control.  Again, each class has only 1 archetype listed, and no guidelines on what the power range should be.  Easy to make too many archetypes, to make them over- or under-powered, and you also need to balance archetypes against multiclassing, should an "arcane warrior" be a Fighter archetype, and Wizard archetype or a multiclass Fighter/Wizard?  That'll make your head hurt :)

    Class abilities are a complex subject.  I fully know that, and even trying to review and think about them is an invitation to insanity.  It would be great if there was some developer's guide somewhere that explained the thinking for each ability.  Why this one, at that power level for that class?  Those are thing that the designers had to think about when making the game - sadly I don't know of any game that had the designers' thoughts included with the rules.  And with something like an OGL game, that is an invitation for other people to design around, it would be priceless.  So I have a lot to think about when I go to make my own game off the SRD.  What abilities do I keep, which ones do I change, how do I balance the growth of the classes and the challenges they face.  And sadly there is little guidance from the developers so I'm going to have to answer a lot of questions on my own.  Can't say I'm looking forward to those hard decisions.

    And that's a wrap on classes.  Time to move on.  Since classes are one of the central parts of a character, let's move on to the central part of the game: the core mechanic of d20+stuff.  I see math in our future :)  Until next week!

Saturday, November 11, 2017

Open2 Engine: Bookworm - part 5 - Changing Themes

    Okay, so the last post took an unexpected turn.  I was blissfully unaware of how tricky it would be to change the look (or "theme") of Bookworm.  It wouldn't be so bad if it was a simple HTML application, but since I'm also using jQuery UI that means I need to go through some extra work.  I like the styling of the jQuery UI widgets, you could create the same, or at least very similar, widgets in plain HTML and CSS - but I also like the experience of working with a JavaScript library.  You need to look at your code differently when you're adding someone else's library - case in point how I didn't consider that jQuery UI would have it's own stylesheet.  And it turns out that the JQUI stylesheet is kind of complicated.  So let's look at how it handles themes...

    There is a great place to go for JQUI themes, a site called ThemeRoller...

Here you can change everything about how JQUI looks.  When you get done and click on the link to download your theme though, it gets a little weird.  You get taken to this download page....

And there are a lot of checkbox options...

At the bottom of the page it actually mentions something about themes...

What you download is a zip archive with a lot of files in it...

 If you leave everything checked, like I did, you get quite a few files and directories.  You get a lot more than just the theme you were working on; you end up with the jQuery UI JavaScript file, the jQuery JavaScript file, a package.json for your package manager, some other stuff, and several CSS files.  The first thing to note are the jquery-ui.css and the jquery-ui.min.css files...

These are the JQUI stylesheets, both of them, but the second is the "minified" version.  You get this with things that go over the web.  Just like a zip archive is a compressed format to reduce the time a download takes, a minified file has extra whitespace removed and usually names for variables and functions have been shortened.  It makes for a smaller file, but at the cost of something that is difficult if not impossible for a person to read.  Here is a screenshot of the full and minified files side-by-side in Notepad++...

So those are two of the files, basically the same information just in different formats.  Which happens again...

The jquery-ui.css is the full stylesheet, but there are also jquery-ui.structure.css and jquery-ui.theme.css files.  These last two (and their minified versions) are just two halves of the full stylesheet.  The 'structure' file has the CSS elements for positioning and size, the structural elements; while the 'theme' file has the colors and appearance elements.  This could be useful to split up in some cases, and I think I'll use these for my theme switcher - I'm not changing any of the structure, just the appearance, so why load anything bigger than I have to?
    Another thing I want to point out is the way JQUI uses icons...

 JQUI can display its icons in different colors, it does that by loading from a different image file.  If you look at the filenames you can see that each has the 6 digit hex color code after the "ui-icons_" beginning.  So I need all these files to be together in a folder called "images" that's in the same folder as the css files.

Changing Themes, done right this time
    Now that I know how the JQUI themes are created, and what files to load, and have a site to create new themes - now I can actually impliment the theme-switcher.  So this is going to be in two parts.  First there is the background color which is my basic CSS, located in my own bookworm.css file.  The second part is the JQUI theme.  I'm making two versions of each JQUI theme, both will have the same primary color, like blue, but one will be designed for a white background and the other for a dark background (I'm going to soften it to a dark grey instead of the pure black I did before).  So when I swtich themes I need to change two things.  I wasn't sure about how hard it was going to be to change the themes, I had a picture in my head of some complicated coding - I even found a special theme switcher widget.  Thankfully I was wrong, because I found another site that has a wonderfully simple solution.  Niklas Tech Blog has a great way to switch JQUI themes with a simple drop-down.  All I need to do is add a line of JavaScript to also change the background CSS at the same time and I'll have a winner.  Hopefully :)  So let me whip up the code and see what happens.
    So here's my revised code...

The first thing I did was remove the extra stylesheet links.  I didn't understand about the full and minified versions of the CSS, so I had linked them both (always read the documentation! though that is a little hard with something as complex as JQUI).
    Once I removed the bad link I added the good one.  I'm using the 'structure' and 'theme' files, and I renamed the 'theme' files into something more descriptive.  I've added an id to the <link> for the stylesheet, to make it easier to target later (per the blog I referenced).

With the <head> stuff fixed, time to add the <select> for the theme changer.  Now, I'm not just changing the JQUI theme, I'm also changing the background CSS, so each <option> has a value attribute for the stylesheet link, and also a data-background attribute that is going to change the general CSS.

I'm going to make the <select> a JQUI widget as well, so I've added the code to initialize it in the function that handles all the JQUI setup.  To trigger the theme switch when the user selects an option means setting an event listener for the "change" and not the "click" you use for buttons.  The function does 3 things: it takes the path from the value attribute and changes the stylesheet link the the head section, it clears any light or dark CSS classes, and it applies either the light or dark from the data-background attribute.  I did find something when playing with this, I had originally only set the light/dark on the <body> element - but that didn't change the <textarea> for the notes.  So I'd set the background for the page dark and then have the notes still be white.  That was an oopsie, so I fixed it to change both.
    The last change I made was to set the "dark" CSS class to a dark grey instead of pure black, I just think the grey is a little easier on the eyes...

Here's the drop-down...

Which changes the way everything looks, including the textarea...

Woo hoo!!! We've got themes and they work this time :)

    Okay, that actually took a lot of time to figure out.  These posts may not look like much, but between researching, coding, screenshotting, and posting they usually take 4 hours.  Same with this, it took a while to research how JQUI handled themes and how to change themes in general, play with ThemeRoller to get all the colors something I liked, write the code, fix my mistakes when writing the code, take screenshots, and then write and upload the post, images and Google Drive files.  That said, here's the Google Drive link.  So while this did not add a lot of functionality to my little app, it's taken enough of my life to call it a day (in an already busy day, hence my posting this late).  So I'm going to stop here.  Next week I'm moving on to what I expect to be one of the hardest and longest parts, adding an editor that will let the user create their own documents.  Until then!

Thursday, November 9, 2017

Character Viewer: How To Save User Input - part 1 - Fun With Forms

    In our last tutorial we looked at how to write JavaScript data to an HTML table. This lets us populate a table dynamically instead of having to hand-code it. Except it doesn't really, after all we had to hand-code the objects we used to populate the table. So we need a truly dynamic way to fill our table, by letting the user create the data. So for this tutorial we're going to add to our app the ability to read and save user input. Let's take another quick look at what we've got...

    So this is still what we want it to look like at the end, a table with information about our Pathfinder characters. We're just going to add a few things.

Collecting User Input- Form Controls
    HTML has several elements that are designed to gather input, they're called form controls. A <form> tag defines a group of controls that are all going to be collected together. So we'll to start our section with that. We don't have to, but it's convenient. I'm going to add a border to the form and a margin to make it stand out, plus an <h3> header and some padding since the header looked a little funny. Here's what it looks like and my code...

    Okay, so now that I've set aside the space for my form I need to put in the controls to actually collect all the data. There are a lot of form controls and I'm going to try to use a variety of them for this project so you can get to know them all (kinda like Pokemon :). The most basic control is the textbox, a box that the user can type text into. It's built from a core element <input> and given the attribute type="text" and should work great for our character's name...

     The default textbox is about 15 characters long, we could change that with CSS, but I'm leaving it for now since it works for me. If you've ever looked at the code for a form (or if you do later) you'll notice that most form controls have a name="something" attribute. The name attribute is used when sending the form's data (called "submitting" the form). I'm not going to be sending this form anywhere, I'm going to collect the data with JavaScript, so I'm using the typical id="" attribute to track everything instead.
    So we have a field that the user can type in general text, numbers or letters. Let's look at another form control. For the character's race let's say we want them to choose from a limited list. This is a tutorial and not a working program so we'll try some different things out, even if they might not be ideal for the finished (or "production") app. Let's put in a drop-down list, this will let the user select an option from a list that we provide. This has the advantage that you can prevent the user from entering invalid data (since they're limited to the list) or from mis-typing/spelling the data. The downside is that you're limiting the user to the options you provide, so you need something that is complete and unchanging, like a list of the USA's state abbrevations. So this is not the ideal control for a character's race, since there are way too many Pathfinder races to list here, but like I said we're just doing it to play with the control.
    What we need is a <select> tag that's going to wrap a bunch of <option> tags. Each option is going to have a value="" attribute that's going to be the data we save (for JavaScript to read), and the text inside the option is going to be what the user sees. Since these are going to be the same thing, we want the user to see exactly what we're going to save, it's going to look a little funny but it makes it easier for Javascript to read later.
    I'm going to add options for only a few races, and here's what my finished control looks like...

    Okay, we've got the first two things down, lets go ahead and use another new control. A character can have more than one class, so let's use a set of checkboxes. The <input type="checkbox"> creates an element with a name and a box the user can click on. This lets the user choose multiple options. So I'm going to make a checkbox for some of the basic classes, but I want to show that they all go together, so I'm going to wrap them in a <fieldset>. This element is just going to draw a border around all the checkboxes, to show they're related...

Note that in my HTML code I have each checkbox on a separate line, but I didn't put in any <br> tags so they are displaying in the page as being on a single line. That's for my sake, it's easier for me to read my own code if I put each element on a separate line - and I mention it as a reminder that how your code looks and how it displays are two different things. Use whatever look is easiest for you. Speaking of looks, I'm not a fan of how crowded this table is getting. Each element seems to be smashed against the others. I want to add some spacing. I'm going to do that by adding a some CSS to the <form> element, a line-height: 200% will space things out a bit. I'm also making the fieldset a little shorter...

That's a bit better. Good enough for now at least.
    Let's keep adding stuff to our form. Next is the character's level. So far I used the textbox, which allows the user to type in anything, numbers or letters. But a character's level is only a number, so let's use a new control that will prevent the user from accidently putting any letters in there. This is a new -input type="number"- that was added in HTML 5, so older browsers might not be able to show it, but my up-to-date Chrome will do fine. It doesn't look like much at first...

But put the mouse over it and you'll see the little up and down arrows to change the number...

    So let's put a starting value in there. I'm going to add the value="1" attribute, and levels don't go below 1, so let's also add a min="1" attribute to keep it in the right range. Also, the box is pretty long, so in CSS I'm going to set it's width to just a few characters. Here's the final look and code...

    Wow, so we finally finished the first cell of our table :)  We've done pretty good at going through all the different form elements.  So I'm going to use those same number fields for all of the attributes.  Now, I'm going to have the user input the value of the attribute, not the modifier.  The modifier is a formula, so I can have JavaScript calculate it.  This will help me avoid any mistakes or funny math from the user.  This is a general practice when you're making forms, called "validation."  You want to make sure that you're getting the right data from your form.  So you start by limiting the potential mistakes as much as you can, and then you validate your data to make sure it's what you expect.  Users make mistakes, not because people are bad and lie (though some few do) but because people are people and they make mistakes.  So you want to structure your forms in a way that minimizes those mistakes and keeps an eye out for them.
   Another thing is that my form is looking a little thin.  So far it's just one row of inputs on the left of the screen.  That means there's a lot of wasted whitespace.  I'm not going to worry about this being seen on a mobile device or other small screen - that could be a tutorial of it's own.  So I'm also going to make 3 columns, by using <div>s and setting them to float in CSS.  So with the attribute inputs and column layout here's what the form will look like and it's code...

To make columns you can set a <div> to position: relative and float: left but those need to be inside a container with position: absolute which I set the <form> to.  Take that out the absolute container and you get a mess...

    The absolute element is like a fixed reference for the relative ones to move around. And float: left was described to me like a balloon: that element will float to the top of it's container and then drift to the left. It makes the div's align at the top and sit side-by-side. So I've got 3 columns of content in the form. I had to remove the width attribute I had added to the fieldset, now that I've got the columns I don't need to artificially shorten the fieldset.
    We're almost there. For the next two cells of our table, the weapons and armor, let's go ahead and use one other type of form control: the radio button. A radio button is like a checkbox, but it is round instead of square and the user can only select one option out of the group. It's an <input type="radio"> but each one in the set needs the same name="" attribute so the browser knows they all go together. Again this would not be a great choice for a production app, but we're learning and playing. So here are a few weapons as radio button options...

    I set the "none" radio button to be checked by default, so that something would be selected. Pretty easy. I also centered the attributes since I thought they looked better that way. Let's finish the form and add the last few controls. I'm putting in a number field for the base attack bonus, I'll have JavaScript add the Str or Dex mod depending on the weapon. Then another set of radio buttons for armor. Lastly another number field for hit points. And that will give us everything that goes into our table...

    Not bad, just a final finishing touch and we'll be done with our form. First, we need some way to add the character, so I'm going to add another <input> element with the type="button" that will be used to launch a JavaScript function to read the form and add it to the table. Another thing to consider though is if the user wants to clear the whole form, say they change their mind about what they put in? Well, in that case let's add a button to reset the form, of course it's <input type="reset">...

    And that makes our form. Go team us! ;) You can download the code from my Google Drive here and play with it yourself. Now that we've created a form all we need to do is make it work. That's going to take some JavaScript to read our form, format it, and then add it to the table - all of which we'll get into next week. Until then!

Wednesday, November 8, 2017

Site Navigation

    With only 80 posts my blog is not that big, but since I try to post different content each day of the week it can be a little tricky to keep up with the multi-part projects.  So, I thought it would be a good idea to call out the not-so-descriptive navigation bar under my logo.  There are 7 pages that consolidate the posts by recurring topic:

Mechanical Monday covers my deep dive into a single OGL game - currently my 8 part look at the 5th edition SRD.

Topical Tuesday is when I post something random related to RPGs.  Mostly my ideas for house rules that I can't playtest (since I don't have a group) but I'd love for any brave soul out there to try and comment on.

World-building Wednesday is my ongoing series where I create my own fantasy setting, which is going to be released under a Creative Commons Attribution license, so anyone can use it, and I'm thinking of how I can make it compatible with multiple OGL games.

Thursday Tutorials I use to post links to technical tutorials written by other people that I've learned from, or a few I've made of my own.  This is focused on HTML, CSS and JavaScript - since those are the only things I know how to code in.

Frustrating Friday is my developers journal as I work on my Open2 Engine project, which is going to be a tool for creating Interactive Narrative and Role-Playing Games - someday, it's a big project for one amateur programmer.

Sat-Sun Stuff has random posts with computer wallpaper, bands I like, YouTube videos I like and other such stuff.  Nothing world-shattering, but maybe you can find something you'll like and hadn't seen before.

And lastly I have a few Downloads, a Notepad++ language definition file for Twine/SugarCube, my Quick-N-Dirty Quest system (a very mechanically light system you can build on) and links to my other projects if you want to play with any of my code.