Truly Tiny Gods was an idea I came up with years ago. A sort of automated story driven by code and user interactions. I never finished it and still think about creating it. I even registered a Facebook app that I never developed. Life got in the way.
This is what went through my head when I recently thought about re-doing Truly Tiny Gods. I went back over it and added some comments as quotes and titles to break the text up. Mostly that was to explain myself. My head rarely has to explain itself to anyone else.
Imagine if big brother met DnD pantheons and a bunch of truly minor gods had to live out their life on an island to compete for power. What if that was a blog or twitter account and users could “pray” to the gods to influence the outcome. It could be quite fun.
My stream of nerd thinking
This would be some form of a plugin that runs in one blog. You give it some “gods”, and following some pseudo-random system influenced by comments or such, it tracks the followers, powers, and relationships of the gods.
User interactions could influence the outcome of the god’s day. They could say, vote, in some way, to attach a portfolio (says lakes, or something) to a god. Votes could be in the form of comments or some other user desirable behaviour.
Some posts could be tagged for one or more gods using custom fields. That is assuming you can “SELECT * FROM posts WHERE custom field X is Y”. That could be used to allow user interactions with the gods.
I often express ideas in the form of SQL. It is a database language. SQL is just good for expressing the data I want and the form I want it in. If magic was real and cast in accordance to the mind of the caster my magic would look like SQL.
Each day, each god would do a thing. That thing would be reported using a randomly selected pattern for the thing. The pattern would be filled out using words from that god’s flavour words lists. The thing might change god stats, attitudes, and stuff.
I guess that means gods have flavour words lists. Guess I better think about what they are – stuff they are for, and stuff they are against. Yeah, that sounds cool. How about favoured animals, weapons, plants, etc… Yeah, that seems reasonable.
I have a whole theory of things and stuff. Ask me about it sometime. Basicly, things are useful and well defined and stuff is not.
Time to think about data
I guess the gods will need a table each for all that data. Better think about some stats to track. Followers, power, smite, anger, love… That sort of thing. It’d be nice to add new ones as I think them up but that means two new tables. One for the stats definition and one to carry the actual stats. Hang on, the things affect the stats (and stuff) it would save a huge amount of headaches to know them ahead of time. I know, I’ll define them in classes. No, wait, then the database would have to carry a deserialised object blob. Yuck.
I’ll come back to that.
It might be fun to have the gods fall in love. I’ve already said that I want to track their attitudes. We could use some scale from -100 to 100. Although romance would be a different thing. Hmm… Maybe a flag? A flag dependant on the attitude scale? Are we using flags then? Do we need unlimited flags or a limited pre-defined set? I have not figured that out yet. Bother.
Come back to that too.
I mark things “come back to that later” a lot.
So what have we got so far? Some gods that have stats in a table and may or may not have stats and flags. That’s not much to go on. Other than some ideas about what I want, I have no ideas about how to make it work.
Let’s revisit the whole flag thing. If we made “is in love with” a stat, then we don’t much need flags. Maybe gods have really short memories? Yeah, that sorts that out. As we are working with WordPress, maybe gods could have taxonomies. Maybe gods are custom content types. That’d save a whole lot of dicking about with tables. Not sure if this is a great idea or a really bad one.
Better read up on custom content types.
Apparently, the only known way to deal with custom fields is the plugin Advanced Custom Fields. Everyone just defaults to it. What if I want to write my own UI?
The taxonomy idea seems sound but the development reading is a bit lacking. Toys with the idea of filling that space…
Well, okay. It looks like post meta (custom fields) could carry the stats and that I could define them as I go. That’s good. Add stuff as I figure it out. Things could be an array of class types with defined templates for “doing the thing” and conditions before the thing can be done.
More about things
Things would either act on the god’s own followers and stats or include another god and act on both. I guess that means the thing would need a get_god and get_other_god method. Perhaps all things could affect another god. Maybe things have the potential to pull followers from all the other gods? No, that seems like too much work.
As things change the gods, I’d have to be careful about the execution order in the code.
Talking of methods and code and such, I should probably set up a developer install somewhere to test my code. Breaking a production site would be bad.
This is suddenly looking like a lot of work for a “quick” diversion.
This is often the part where I stop. If I can get past it with the thought that I can keep it simple and get it done, well, maybe it will happen.
More ideas pop into my head
Oooh, what about wars? Wars would be great. It could cost the two gods followers but earn them “smite”. As a ready calculation, a war could cost each side 10% of the total opposition follower count. Thus, a god with lots of followers could wipe out a smaller god and take their stuff. That’d be awesome. If I make that a “thing” it would not need me to track “war” as a meta on both gods.
Another interesting idea might be the “did a thing in secret” thing. The other god could be the one that secretly sees it. That could get old fast without enough variety. Maybe secretly witnessed could be a theme that runs throughout the things? Again, that seems like hard work.
Oh, I have a funny idea. Add a report on a god detailing prayers answered vs prayers ignored. Something like that anyway. Perhaps also add, minor righteous smitings, fantastic dreams given, vague portents shown, doctrinal disputes among clerics, and so forth. Use a DNA based pseudo-random system so each god tends towards consistency.
DNA based pseudo-random system is where you take a string – the “DNA” – which you pull from and use as a seed for randomising. This gives consistant results which differ from one example to another. I use them for games but they are used for system generated avatars on blogs (among other things).
Didn’t TTG v1.0 use DNA? Yeah, I think it did. The whole god was generated from it. Hmm, that seems like a good idea. 32 hexadecimal digits seem enough. That’s the output of an MD5 hash. A specific set of say four digits could be converted back into a number and used as a seed. There is no cryptographic security needed, so this should be fine.
I could even use an avatar image program to create an “icon” for each god. Children of two gods would have similar icons…
Hmm… I like that. I don’t fancy the work it would require. I wonder if there is an open source library?
Any project that I end up thinking about will, eventually, have me think, “I wonder if there is an open source library.”
I need the loo.
Also, I want a cup of tea.
I might watch an episode of X-Files.
I indeed paused for ages. I also watch some of season one of X-Files. It has aged rather well.
The main class should have a “register of things”. “Thing” extends “abstract thing”. That seems sensible…
I got distracted. Like for ages. The way I just stopped typing means that someone probably decided that it was a good time to visit me. After all, writers and geeks are never “busy with anything important”.
This post was just sort of hanging about in my drafts. My headspace is not in the right palce to do this development anymore. However, if I post this now it sort of has no point. On the other hand if I don’t post it, I’d have wasted all that lovely research. Hmm… to post wierd rubbish or not, that is the question.