tables – TechNo Prisoners

The Android Invasion (Part Three)

Life gets complicated.

Building Random Lists turned out to be a simple procedure. Buttons to choose which Category. Pick Lists (and grammar). Display in Recycler View.

I added a few extras, such as One Button to choose “Furniture”, with a sub-menu for Kitchen, Lounge, Bedroom etc. Quests included a Reward built from the Treasure Lists. Shops called from the Names Lists.

For the Pay Versions, I added some extra Features:

NPCs. Names became clickable, and built a random Person, with Traits pulled from other Lists. Personality, Valued Possession (Treasure), Mundane Items (new List), etc.

Add Data. This was a tricky one. I added the capability to add to the existing Lists. This data is stored in Text Files on the user’s phone, and added to the Array when the App draws up the Lists. I had quite a job figuring out where these files are stored, how to call them, and how to add them to the Array. In the end it worked though.

But we’re just calling Lists, and combining results.

Rome Wasn’t Built In a Day

And neither were my Apps!

But I did build a City-Builder. Not, unfortunately, a map-creator, although I am working on that. This is another Random Lists app that call up traits and features for a Fantasy City, such as Government Type, Local Features, Main Export, etc.

Again, each Feature was called from a List (still working with XML String-Arrays). Some used combined-lists (such as Renown). The Export facility was also included, and as can be seen from this picture, Exporting also saves a screen-shot.

A new feature for this App was to allow the User to “re-roll” a Trait. Clicking on one of the results will call up a new Trait.

The City is an “Object” (or “Class”) that holds information about each Trait, and when a Trait is re-rolled, the Class is updated with the new information. (Only one City is held at any time. Creating a new one over-writes the old one).

The City Names are created from two sections. One is a list of predetermined Names, and the other a prefix-suffix combo. Here we see “Pen” + “dale”. It could have produced “Pen”+”wood”, “Pen”+”ford”, etc. (As an aside, I am working on a Planet Creator, and those names can pull from an algorithm similar to the one used in Elite, that combines some syllables to form a real-sounding word. The Starport names draw from combos that include a “mixer” between the prefix and suffix. “Hadley’s Hope” might be “Hadley’s New Hope”, or Hadley’s Last Hope”).

Next …

I am reaching the limits of my imagination, and what can be done with Random Lists. While there are many more “skins” I could put on them (Dungeon, Modern City, Monsters, Furniture, you name it …), I need something to allow me to learn more about programming. One area I have been meaning to investigate is Databases. While I did some simple work on them for my RPG pages, I need to know how to fit them into Android!

An idea soon brews up: Random Loots! D&D has always included random Treasure Tables, so I could write something inspired by the latest version, saving all the raw data in in tables, and calling it as needed!

It turns out that the worst part of this is typing in all of the data! As with all of these apps, there is a lot of information that needs storing.

The main structure of the database was easy enough to build, using “DB Browser for SQLite“, although I did have to keep adding more columns as I realised what code I needed.

There are two types of Treasure: Individuals and Hoard. Individuals just carry Cash, which is easy to define the range (dependant upon Challenge Level) and roll some dice. Hoards can include Gems or Artworks, and the chance of Magical Items (OOooh!!). Roll on the Table to determine what sort of thing is in the Loot Pile, and then on each sub-table to find the details.

A section of the Random Treasure Tables from the Dungeon Master's Guide — A section of the Random Treasure Tables from the Dungeon Master’s Guide

There are sub-tables for each Value of Gems and Artworks, and (as noted) multiple Magic Item tables. These are all easy to produce.

More difficult was deciding how much detail to display! Do the players want to know the full details of each gemstone, its exact value (for I introduced a randomiser for that!), what cut it has, etc, or just a Total Value for selling? I decided to include both! The App presents a Total, and clicks to present a list of details (using the previously-mentioned Recycler View).

New addition for Magic Item details was the Pop-Up window. This does not change what Activity you are in, but adds a new display over the top of it. Here I included Maker, Minor Power, and Quirks that the Item may have.

Finally the Export Code was added. Again, I used the Screenshot, but also looked at Formatting the Exported Text, so that it was easier to read. This mainly meant iterating the Treasure List and adding a few Line Breaks, with Section Titles.

With the addition of a few details to prettify the App (background Picture, Icons, nice buttons), it was ready to publish!

Finally

It may sound like a lot of this went smoothly, but I spent an inordinate amount of time struggling with sections of code, hunting typos, retyping functions and searching Google/StackOverflow for error-messages. Eventually, I have some workable Apps! You can download them here.

If you would like more detail about the actual Code I ended up with, or if you have ideas for new Apps you would like to see, ytou can contact me at:

admin@maddwarf.co.uk

Thank you.

The Android Invasion (Part Two)

Some details

Code: A Summary

I’m not going to publish my whole Code here, but I will present a short explanation of how my App is structured.

Main Files:

activity_main.xml – this displays a set of labelled Buttons, one for each Category of List.
Main Activity – this contains the control-code for the Buttons, chooses which Activity to launch, and what message to send to it.
Several Activities, for different types of List.
Several Adaptor (or “Helper”) files, for processing the Lists, and binding them to the Recycler view.
A “Class” file for each Category. These define an Object-Type, and show how each Object holds Data*.
activity_(category).xml files, with data about how to display each List type
(category)_list_row.xml files for showing how each Row of the List should display.

Why Multiple Category Files?

As this was my first real foray into Android Coding, I chose to split the Categories into two main types. Type The First were ones that could be express as “Names”. i.e. two pieces of Data. (Forename and Surname). This applied to Treasures (Type and Amount/Quality), Items (Alchemical, Mundane, Furniture all have Type and Material). Type The Second were ones that did not fit this structure, and each got it’s own set of Files/Classes/Activities/Helpers (Adaptors). e.g. Quests and Locations.

I could have piled up a single set of files with “IF <quest> then <do something different> else IF <Location> do <location code>”, but chose to separate them out for my ease of reading/maintaining.

What Objects Did You Use?

Each “category” was given it’s own Class (type of Object*).

<Deep breath …> Each time an item from a category was needed (each item on a list), I Instantiated a new Object of that Class:

To instantiate a new “Treasure” object:

Treasure thisTreasure = new Treasure();

This calls the Constructor of the Class, to create that instance of the Class (i.e. make that Object.)

e.g. Treasures are randomly chosen from “Coin”, “Art”, “Jewellery” and “Gem”. Each of these has a List of Types (Coins may be gold, silver or copper, Art may be a painting, a sculpture or a vase), and an Amount/Quality (Coins have a number, e.g. 20 Gold Crowns. A painting might be Elaborate or Exquisite, a Gem has a Cut).

Once instantiated, the Object has its set of Values, that can be called (e.g. by the Recycler Helper), to do something with (e.g. Display in a Recycler View).

Are you keeping up?

For the “Name”-type Objects (2 pieces of data each), they are all sent to the Name Adaptor to Display in the Name List (even if they are not names. It’s just what I called the 2-data section).

Quests and Locations got a little more complicated.

Each Quest Object holds several pieces of Data:

As you can see, each Quest is structured:

“You must <activity> the <descriptor> <item> before <time>. If you succeed, you will be rewarded with <reward>”

Each of these is called randomly from its String-Array. The Quest Adaptor must bind each part of this to the appropriate Recycler View.

As a complication, the Reward is called as a Treasure Object!

Locations were built in a similar manner.

Enough!

OK, that will do for today!

Let me know how much of that you understood, or if you would like some more explanations.

————-

*Java is an “Object Oriented Programming” (or “OOP”) language. Most things are “Objects”, that have “Methods” associated with them.

Whose Dice Is It Anyway?

(Inspired by This Thread)

Some GMs are masters of making things up as they go along. Winging it. Improvisation. They are never short of new, interesting locations, and characterful NPCs. Plot lines seem to grow organically as the game moves along.

I am not one of those GMs.

Players will, inevitably, come up with new and innovative ways to side-step challenges, derail story-lines, and chase tangent-bunnies. When they do, I tend to run into the GMing equivalent of writers’ block. Over my many years of GMing, I have come up with coping-strategies to keep the game flowing, rather than stumble through, uming and erring over details.

The first tactic I use is to try to keep the geographic scope of my campaigns quite small. This allows for locations to be reused many times, and detail to build up over time. The NorthHills sprawlzone that I used for my cyberpunk campaigns started as a rough map, and as we played, built up into a well-detailed area. The Mall had shops (with staff) noted, and was visited many times. I ran several adventures using The Crow Bar, and it has built up a history of its own. I particularly like Fates Worse Than Death for this, as it is set exclusively on Manhattan Island. Large enough to allow quite a lot of scope, but small enough to keep coming back to the same places, meeting the same people.

Another ploy is to keep sets of lists handy. People’s names. Business names. Emotions and attitudes. Some of these I pen myself, between sessions. Others I pull from many sources. Particular favourites are Lee’s Lists and Random Generator. Vajra have some good random creators, specifically for their FWTD setting, but it can easily be used for other games.

Some games produce very good source-books for this, and I particulalry like Shadowrun’s Sprawl Sites. Containing details on quite a few potential locations, plus a whole list of encounters, it provides useful inspiration should ideas dry up.

Also, keep a thesaurus handy. Treeware versions are fine, but nowadays I tend to rely on thesaurus.com for ~~getting good words~~ appropriating superior lexicons.

And, of course, I have my many years of experience to draw upon! I have been known to use ‘similar’ NPCs from game to game, even radically different settings, and tweak locations from one game to fit another. Even plots and adventures are lifted wholesale! Sometimes it is obvious, even highlighted, other times more subtle. (Notable example: When I ran an AD&D campaign many moons ago, one player created character sheets for the 30-40 NPCs in his care (the “We Hate The Dark Lord” club). As they, in turn, inevitably met their fates, they were handed to me, to re-use as ready-made NPCs for that, or any other, game. I still have that folder.)

With these tools at the ready, I tend to spread my preparation thinly, sketching several fledgling ideas, ready to develop the ones that the players interact with, adding detail as play progresses.

So, my improvisation is not about on-the-fly winging it. It is the result of much preparation. Roll a dice on this table. Choose an appropriate item from that list. Pull a character sheet from that folder. All prepped beforehand, ready to be improvised on-the-spot!