Creating a Scriptables based environment

Greetings!

Welcome to another edition of Hippo Talks.

This blog is still in its very extremely early formatting stages, and I am not sure how to go about approaching blog writing as of this particular entry. So just a heads up, this is just me setting up the environment for you - the reader.

Stack Loading Panel for Recking Ball - Using Root System

I have been spending some time working out a proper game architecture system that would serve as a solid toolkit for future game development projects, including being the backbone of what will eventually get THOT shipped.

My Setup:

Alright, so as of now, I am running the webgl project. that's what I'm calling it for now, 'The WebGL Project' is the backbone for the "Reking Ball" game that is being used to demo my progress.
(Stylized as Reking Ball)

Go check out the web GL site to play the current build.

I've imported a folder "Scriptables" from Chads project, which is a nice and neat library of creating the different types of Scriptables; references and such. To think I never really organized my code in namespaces before, how primitive I am...

Just imported that entire folder. lol

The code works really well, there are tons of stuff in there that I haven't even got around to yet.
So go ahead and check it out on GitHub if you would like to!                                  

Touching and ranting on about the power of Scriptables and their capabilities is something for a completely different blog entry!

I am going to have to go on about that after I get a bit more mileage in and let the concepts saturate a bit.

The Objective:

So I'm totally not trying to overthink anything, at the same time im trying not to create a basic environment that won't do me any good. So how do I go about this, what do I actually need?

As far as my thinking goes, I'd you need a some of following components to help break down game organization and doing it so via scriptables:

1. Puppet Master
2. Game Environment


These components are the core of what makes a game title unique. This is where that title specific logic and management will take place.

You can say the puppet master may rely on the Game Environment to feed the level data in order to function. This is true for the most part, however with the structure of scriptables, objects may not need to interact with the game environment directly, objects can simply interact with other scriptable objects that the game environment may access and format according to its logic.

Puppet Master

The Puppet Master is the game logic; it can respond to events or trigger events.

Other components can be attached to the Puppet Master, so the specificities of the Puppet Master script only does the heavy lifting it needs to do. This should contain the focus of the Puppet Master script to just the particular game logic of a gameplay mode.

So the Puppet Master is the script that handles the game modes logic, responding and triggering events as designed.

In the use case of THOT, the Puppet Master would handle command of components such as loaders for spawn points, score tracking, and keep track of the game run state.

The Puppet Master should be able to just be thrown in a scene and do its work, or not because there won't be anything dependent on the existence of the Puppet Master.  No Puppet Master, No game logic, no referee. Just objects doing their thing.

Game Environment

The game environment is the directory interface for a title's content; formatting raw data into title specific sets.

The game environment will function like a system environment that formats handles loading content data from a disk or database, and loading them in containers optimized for access.

Directory Classes

• Root
• Functions as a list container. This is the base format that data will be store in. 
• Offers a bit of additional tag data for identification and categorization. 
• [List<Type>]
• [Tag:Info]
• Chunk
• Core Data, stores transform points and object type.
• [Transform] + [Type]
• File
• This is a whole item. Typically the format at which you would want to spawn waves and data by.
• THOT use case is the wave. Spawn waves, or like for Minecraft this would be a particular building or area. 
• [Root<Chunk>]
• Folder
• This is a set. Offers a container for the safe of grouping files together.
• [Root<File>]

* Root (List<Folder>)
* Folder (Library) (Phase)
* File (Stack) (Wave)
* Chunk (Block) (Spawner)

So when you break it down, a Game Environment will have a set of Roots as its input, and the Game Environment logic and scripts will parse and format the root data into relevant data structures that reflect the design of the game.

Example case:

Reking Ball -
This structure is used to mimmic the retro PC operating system directory browsing.

THOT -
The game environment will format the waves and their phases that accessible via Time Slots.
Additionally, the game environment is also now setup to handle storing reward information within the time slots, providing a universal interface accessing time slots in other areas of the game.

Wrap Up:

I am going to cut this blog off here, we are just going to have to continue this in another blog entry.

For now we should have a nice little picture of scriptables, and how I intend on approaching a universal game architecture using scriptables and reusable game components.

As I begin to wrap up these ideas and implement them, I can go ahead and return in a later blog entry to give review of how it works for the Reking Ball app, and what's going on with the THOT implementation.

For a further understanding on scriptables and how that functions, I am going to have to detail that over at Hippo Labs, where I can give a more of a white paper style breakdown on how it functions and how its being implemented in my projects.

Till then, lets hope that I dont fall off the wagon and stop making blog posts or updating the website. HA. Future reader (and present reader, :-P), take a moment to reflect progress, if any.

Toodles,