A proceduraly generated story game

Started by Ryex, September 17, 2014, 11:38:08 pm

Previous topic - Next topic

Ryex

Winkio, I want to thank you. You've been quite adept at asking exactly the right questions to get me thinking on the specifics of how the intricacies of this could work.

I though about your question on database construction for a fair bit but I only really came up with one solution.

my current plan for the game is for the vast majority of it's logic and game play to be handled by the server. the client for the game would be a thin client with only enough logic to render the data sent by the server. The server would take care of processing all user input for effect.

The database used for content would indeed be a massive undertaking if one were to enter all meta data by hand. While my examples so far have used english words as properties I'm not sure if this is the route I will go. If it IS is would be entirely unreasonable to expect every object added to the database to list the complete set of all properties it may have.

I believe the solution to my problem is a sort of tooled generation of the database. The database initially would consist of a structured set of files in a directory tree that described the bare minimum amount of information to describe them along with two to five words to describe the item. A tool would then collect and compile the items into a database. Use inference rules (would could also be defined as database items) to fill in additional properties of each item. For example an item might have a "Holly" property, the item could also be said to be "cleansing", "good", "pure", "sacred" etc. and the opposite of "evil", "corrupt" etc. if such rules were added to the database that described one property using sets of other properties then set theory could be applied to expand the three or so properties entered by hand into a complete set. care would need to be taken to avoid referential loop recursion and the properties would need to be defined in such a way that base cases could be found to etc. not a simple task to be sure. Additionally properties might be defined on an object with a level of separation from the original. eg the hand entered properties would have 0 levels of separation and properties found by expanding the originals would have 1 level of separation, properties found by expanding again would have 2 etc. Searches could be conducted limiting items returned by separation level. perhaps the engine would search for options using 1 level of separation first then expanding to 2, 3 etc to find the most relevant.

One all potential items have had their full set of properties indexes would need to be constructed to aid search speed, another task for the database generation tool. as the database does not need to be modified after the game has been distributed this would be a build time task.


Please continue to ask question and perhaps challenge me on my implementation ideas, just the task of thinking about this project is fun atm.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

This sounds a lot like most point-and-click RPGs do it (e.g. the Diablo series). They usually have certain attributes and then construct a name for the item by putting together properties. e.g. Holy Smashing Giant Sword of Burning Vigilant Agility. In that case you probably just want to decide first whether the item will have a certain attribute (e.g. holy element) and then decide the magnitude and for each magnitude you can use a different word. e.g. Cleansing < Virtuous < Pure < Sacred < Holy < Angelic < Godly
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

well.. yes and no. The idea is similar except it's being applied to every detail of the game right down to the pallets. and there isn't any hierarchical properties. "Holy" is composed of or related to those other properties
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Ryex

May 24, 2015, 11:56:09 pm #23 Last Edit: May 25, 2015, 03:13:58 am by Ryex
So, I haven't stopped thinking about this idea.


Lately my thought have been toward the technical parts of the problem. namely the base tech that will allow me to accomplish my goals.

One thing was immediately apparent. I need a simi specialized database. and while I done a fair bit of research nothing existing has presented me with even a majority of the tools I need.

My requirements are as follows:

  • FAST look up of a VERY large set of assets by ID. once the game world is created it will ecentialy be a large tree structure of material IDs that describe all the objects, the Game will have to not only look up the IDs but quickly find all properties
  • handle a absurd number of asset to tag associations. if there are N number of assets there will probably be at least N/10 different tags. and each object could have as many as 10 different tags that describe it. in other-words on the order of N^2 associations between assets and tags
  • Each asset could have a different structure,  a 3D modal, a texture, some generic item. ect. all have different properties and data that need to be stored
  • Storage efficiency, assets should support compression, ideally entire blocks of the database should support compression as the more data you have to work with the more repeated sections of bits there will be the more efficient the compression can be. TL;DR blocks will compress at a better ratio than individual objects.
  • Additions to the database do NOT need to be fast. while it would be nice while building the database from directories of assets, the database will be static while the game run, so performance on additions is unnecessary.
  • Library based local access. Like SQLite this database should be accessible directly form the game process not some server process with socket communication.
  • Thread safe, the Database should be able to be accessed from more than one thread at a time. as the database doesn't need to be appended to during run time this isn't exactly hard, more a matter of ensuring that the access library doesn't end up sharing a access buffer between threads or destructively modify a shared cache while another thread is reading.
  • Support for a very large data-set on the order of gigabytes

    My plans for dealing with this was to employ a simplistic key:value disk storage b-tree library and build around it
    using two separate databases, one for mapping ID's to an asset data structure. another database for making tags to a set of ID's with that tag. should allow for quick lockups with out the horror of maintaining indexes. Well actually the b-tree database of tags to ID's technically IS an index. it may be necessary to profile and maintain a third database as a cache of ID's with a common set of tags (Look, all theses assets have all three of the tags "spooky", "demon", and "plant").

    the currently watched Key:Value library that seems to fit my needs is LevelDB.



    Also, I had a thought while writing this post that I think may finally let me resolve the dialog issue.
    A programming language that I will here by dub ScreenPlay

    it would look something like this, WARNING ONLY A CONCEPT, SYNTAX CAN DEFINITELY CHANGE

    Eloquent.Angry(describe SUBJECT is ADJECTIVE):
       "That SUBJECT is demonstrably <ADJECTIVE>(Eloquent)!"


    That is a declaration of a sentence that describes some SUBJECT as ADJECTIVE, using angry and eloquent language where the engine can choose to substitute the passed ADJECTIVE for a synonym that is Eloquent.

    obviously this idea needs a great deal of refinement. but  then whoever was writing dialog for some type of event could write it like this
    {CHARACTER1}describe CHARACTER2 as (select PROPERTY from CHARACTER2 where PROPERTY is NEGATIVE) 

    meaning CHARACTER1 would describe CHARACTER2 useing one of CHARACTER2's negative properties.
    by the exact dialog would depend of CHARACTER1's speaking pattern and Emotional state.

    so lets say CHARACTER1 is an Eloquent speaker and is currently angry, and CHARACTER2 is named bob and has a sloppy appearance. the dialog generated might be

    "That Bob is demonstrably slovenly!"

    of course to have the intended effect the would need to be a great deal of sentence declarations. The nice thing though is that if the language is created correctly it lends it self to supporting translations quite well.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

If you use SQLlite and a local database, it will be thread-safe as far as I know. Quick access for all tags, etc. can be done via indices in SQL databases.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

the problem with SQLite is that it's a relational database, storing arbatray data structres would neither be easy nor performant. A relational database just isn't a good choice for this problem.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Soulshaker3

May 25, 2015, 10:09:25 am #26 Last Edit: May 25, 2015, 10:15:03 am by soulshaker3
I had a tought but quickly realised it wouldn't work. I was thinking of you using LINQ + Lists. The downside is that it would take up space in disk and in RAM and if you had loads of information it would take ages to load. So not a good idea

This was the way I designed my database for my XNA project, but it had just 5mb of info, so it just load up really fast, but in order to load GB's it would take a lot of time and as I said it was loaded to the RAM and I don't think all pcs have 32 GB of ram avaliable.
Hellow?