spiveeworks / civil Goto Github PK

old C++ implementation of Civil. Spent most of my time implementing what turned out to be Rust's type system.

C++ 91.71% Makefile 5.98% Objective-C 2.31%

civil's Introduction

Civil

Text game engine that will turn into a multimedia game engine once the game part exists.

Civil is built around three concepts; hopefully these will work together to create an interactive environment with very strong customizability, and depth of simulation.

Programmable mechanics

Entities and their interactions will be driven by an event based scripting system, that should be easy to experiment and tinker with, to allow for easy modification of your and others' systems.

Behaviour through gameplay

Playable entities will all have optional features that allow you to build a behaviour tree to automate their actions, so that you can create an NPC to play in an environment as you simultaneously learn how to play in it yourself. The benefits of this range from making early-game etc. less boring, to allowing for large scale user made NPC environments, which leads to the third concept.

Deep social structures

By iteratively playing with your or community NPC civilisations, I'm hoping for it to be possible to create deep, immersive, simulated social structures for any set of game mechanics, and for this to be a strong foundation for interactive experiences centred around simulation, free decision making, and real consequences.

What have I got so far?

At the moment I am creating the architecture described above, and am testing it in a purely text console. Once I have implemented what I need from a scripting system, and NPC behaviour trees, I will consider developing a graphical interface, since that will be necessary eventually.

#What other ideas do I foolishly think I can achieve in this same project? Most of these ideas relate to things that I think will be necessary for the third concept "Deep social structures", but some relate to making more community oriented programming tools, etc.

None of these are being worked on in the forseeable future, I just suspect they will be important to do eventually.

Modular content

This would allow for powerfully customizable game environments without much end user modification. Modules would contain generic code, that can be duplicated and delegated by the end user to satisfy the needs of other modules. Then game templates can specify some needs, and the user can choose modules to achieve those needs, until a fully constructed game has been made, ready to compile.

Modules could also contain tools usable in NPC behaviour trees such as module dependant goals or actions; this would allow for portable NPCs that can react to modification of the game environment under certain conditions.

Presimulated gameplay

When game environments get large, lots of gameplay will be expensive for the user's experience, and yet unnecessary since the user doesn't directly experience most of the environment. Traditionally this is what the metagame is for, a shallow simulation to create the illusion of progress while the user isn't looking.

I am interested in ways of simulating an environment in advance, so that the user can do other things with their valuable time, and then play a fast, engaging game when the simulation is finished, without any losses in simulation fidelity.

Map makers could also presimulate their map before releasing so that interactions that occur outside the user's experience are only computed once before the map's release.

Economic calculation

Large scale economic activity is one of the appealing parts of the concept of "Deep social structures", but creating behaviour trees that can adapt flexibly to changing economic environments is difficult, potentially impossible. Creating supporting systems that deal with calculations related to path costs, risks, and foregone opportunities, would allow for more dynamic, market based environments, that can adapt and evolve naturally as situations change.

Construction planning

Possibly the least ambitious idea, or at least the least exciting. Creating a system that allows NPCs to plan and create buildings in new and unseen terrain, or further, that allows them to adapt plans to work around obstacles, would allow first of all, for NPCs to thrive in sandbox situations, but also for procedurally generated constructions with genuine and organic history.

civil's People

Contributors

Watchers

Forkers

lyneca

civil's Issues

make - variables instead of full paths

so give each file a variable specifying its prerequisites, and do something clever to make a single recipe for all of the header prerequisites (may depend on #19)

Immutable maps could be sorted vectors

e.g. (list will be edited)
PropertyFormat and its list of child formats

PropertyTemplate::branch_template isn't necessary

just typedefing the vector and then deducing the format/holding it on the stack would be fine

style - typedef vs using

it might be worth replacing all typedefs with alias declarations, since templated aliases are cool and I want them to feel at home

Spaces use indices

Spaces should become wrappers for a forward_list, (or maybe just list) and indices should instead be iterators.

Visual Changes reduntant

appearing, disappearing and changing need to be the same process, perhaps with an image before, image after scheme.

Eventually though specific parts of an image would need to be efficiently modifiable for small changes not to be overcompensated in data processing

Not Civil

RPGengine was a filler name, but I would now like to shift things over to the name I have decided: Civil.
This will occur as a new repo at some point, and this one will be archived and then deleted :-)

Property family lines could be sorted for optimization

if PropertyFormat::family_type was always sorted, i.e. format.family_lines[x] was a sorted sequence of child formats, then finding the child index of a format would be logarithmic as opposed to linear.

PropertyTemplate::operator() is hideous

operator() is what translates a base property into a derived/templated property, and it is hideous. It needs all of the encapsulation into subroutines.

Properties could use vector instead of iterators

since I now understand move semantics, the internal vector could just be passed back as is

Space-Entity entanglement

Currently Entities move and convey information in manners dependent on the implementation of space. I may be able to figure out an interface between entities and undefined realities, but maybe not.

EventQueue is dually responsible.

A "StaggeredQueue" template should be made to achieve EventQueue's container responsibility exactly as it does, then EventQueue should extend that privately and wrap GetNext with DoNext, and echo MoveOn and Empty

No standard for safe event scheduling

Infinite loops and unintuitive feedback are easy enough to design around, but if this project goes where I want it to, then there will be much more interesting things to think about.

Figuring out a complete standard would make me feel a lot more assured in my design decisions.

Templates need to shrink to fit

just a member in each stuct that calls shrink to fit on its data list and then on each element of that list

ObserveOrgan

Originally because sight isn't the only sense, but it turns out that every sense behaves completely differently, so sight is the only ObserveOrgan and shall be for a long time

Spaces could use unique_ptr

then I wouldn't need to worry about any standards with space deletion etc, I would just need to move-assign or swap the ptr objects.

Spaces are much too specialised

This is kind of dependent on more kinds of space being figured out.
Space needs its container protection responsibility to be separated from its visibility tracking processes.
Further specialization needs to be separated as well.
How would I even do that???

Property family lines could be sorted

see #16
but so that I don't make the same mistake again:
The list that associates bytes to specific possible child formats, could be sorted instead, so that when converting formats to bytes, (are formats converted to bytes yet?) a binary search can be used.

This is distinct from converting bytes to data about that element of the propertyformat, which is already a map in fact, since not all elements have data, and in the future not all of that data will be the same (e.g. components will be noted in a separate map to subformats, and in theory separate still from arrays)