Workshops & Blueprints/Schematics

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Splitting out Workshops from bloating the Blocks thread to do some more brainstorming.

Idea is that one line of workshops will do the whole block shrinking thing which is the primary way players make custom blocks. If the player approves then a custom block can be saved in a "schematic" (don't store any unless the player likes it - no harm in using a few more bytes for the display of the pending block). Blueprints on the other hand are made up by multiple normal-sized blocks, which could perhaps include schematic-made blocks.

Blueprints are defined in the world simply by building something, then designating the construction somehow (say a tiny simple cottage). Place a blueprint in the world to get a wireframe representation or something that minions would be able to help create. The easiest approach would be to only allow square designations, made up by everything inside it. But then it would be nice to also be able to use designations to dig - which would mean you'd want to save a blueprint of "empty space" (like a 5x5x5 room with 2x1x1 doors) and have minions help dig.

A schematic workshop would consist of a work surface of a specific size (2x2, 3x3, 5x5, 10x10, etc), a container to hold material, a display of some sort to show the target block (either a "screen" on a wall which is sneakily a UI element, or an output work surface the object will appear on top of), a product output spot (could be the output work surface, or perhaps the end of a machine, an advanced version of which could be a conveyer belt pushing out the constructed blocks physics-style), and input/output for actual schematic objects (probably just a floating 2D "sheet of paper").

An original schematic would be stored inside the workshop it was created in, while you could generate copies to take elsewhere, give to friends, etc. You could even do like in EVE and allow research on the original schematic to increase its material efficiency (via minion researchers!), then let the copies be limited run so you have a commercial sort of advantage to having built a specific schematic ;)

Have lots more thoughts on the details, but am irked by how exactly to tie it closer to technical specifications on how we can pull that off in code. I might need to tinker with blocks a whole lot more before it is worth going in-depth on concepts like this.

In short though it would take the following:

* Ability to create custom blocks made up (in theory) by smaller versions of normal blocks - I can design the backing system left and right but in practice I'm not sure what the best way to render such blocks would be if they're not solid on the outside.
* Ability to create "selections" in-game. That would be like the current black framing of a block you're pointing at, but persisted in a different color and connected to other selected blocks
** This would also require the ability to change "mode" in-game, akin to switching tools.
* Ability to save off block definitions for the custom blocks and pull them up in some sort of UI
* Minion stuff (definitely a later thing, need a mob system first!)

Easiest way to start on this would probably be just hard coding the location of a "workbench" that will replicate a smaller block on a different hard coded location to tinker with the tech. Or do the mode thing.

Needs more thinking and better understanding of the code on my part.
 

begla

Project Founder and Lead Developer
Contributor
Architecture
Logistics
I really like the idea of those custom blocks. The good thing is, that the game can take its time to optimize the meshes in comparison to the world generation, where time and efficiency is everything. A tiny progress bar indicating that the custom block is being solidified (or what not) should be no annoyance for the players.

Thinking of the blueprint concept the current architecture should already support the basics. The player could define a 3D rectangle using two blocks and every block inside this rectangle is copied to a chunk-like array (which will be stored a bit more efficiently in the end). From there on things like a rotating preview should be no problem. The process will need some tweaks here and there but it should be absolutely doable.

Basic physics for mobs is there. There are also some "slimes" hidden in the source code at the moment. They currently walk around randomly, jump if they hit a wall and follow the player if he's in close proximity. They also make sound (even surround sound) relativ to the players position. Every mob can be created using the class "MovableEntity" (which also provides all the physics that the "Player" class utilizes).
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Nifty. I saw the slime references in code, but wasn't sure if it was done, active, or what not. Haven't run into any :)
 

begla

Project Founder and Lead Developer
Contributor
Architecture
Logistics
Cervator said:
Nifty. I saw the slime references in code, but wasn't sure if it was done, active, or what not. Haven't run into any :)
There are none since the spawning part is missing. :) Maybe I should add some rudimentary spawning to start building upon the entity/mob architecture.
 
Top