ras0219 / alphacomplex Goto Github PK

I'd really like to have an ncurses port.

I need to add more documentation about the actual architecture, specifically:

• The ECS
• The AIScript system
• The half-baked wish-it-was-MVC architecture I've been working towards
• High level overview of the dataflow

Takes forever to do a full build.. [X11+sdl+ncurses+webport]

The Renderable component along with the MapView and anywhere else appropriate should be switched to use a more general "Glyph" or "Tile" type so that we can support non-textual rendering more easily.

When in a text-based render mode, these would collapse to some set of extended ascii (maybe unicode?) characters.

When in a graphical-tile-based render mode, these could be associated with some actual graphic assets (with the text-mode as a fallback).

Feature Request

23:36 < heydabop> also have current job status?
23:37 < ras0219> ?
23:37 < ras0219> currently no current job status
23:37 < heydabop> like, once elf is executing job, is off list
23:37 < ras0219> yeah
23:37 < heydabop> TIME FOR GIT FEATURE REQUESTS
23:37 < ras0219> thas because elf needs to make sure the other elfs don't get it
23:37 < ras0219> DONT TELL HIM THEY ARENT REAL

i wanna know what elf is do. im not smart enough to remember the last thing i read on the job list

I think we have two logging systems now; maybe these two systems need to be consolidated?

i ran
it did this

Created city.
----------- Step 0
citysim: /home/ross/alphacomplex/city.hpp:45: virtual void City::render(Graphics&): Assertion `ent(x,y)->rawname() == SentinelEntity::RAWNAME' failed.
zsh: abort      ./citysim < ../city01.txt

Trying a big room slows games down too much, and we can't have locked doors :(

In pursuit of having a playable game instead of a tech demo, we need to have some sort of way for an uninformed player to learn the basics of the game. I think a neat idea would be based on VAL from Startopia (ep 1: http://www.youtube.com/watch?v=DMCdt_mDH5w).

We tried this in the past, but I think it'd be great to give it another go. Even if it is just for Linux, I think that would be great.

Any takers?

So we would have something like
WItemList
VItem (currently ItemView)
VMain (currently MainView)
WUnitListing
CFoodStuff
CFurniture
CPosition
SAI (currently AISystem)
SNeeds
SMovement
SStorage
SHydroponics
CRoom
CItem

A lot of classes have suffixes such as "System" or "View" to distinguish the type from a similarly named component (AISystem vs AI, NeedsSystem vs Needs, ItemView vs Item, etc). Also, in the case of certain components, they clash with the underlying struct providing their data (Position vs position, Clearance vs clearance).

A prefix system would fix all of these cases in a concise and forward-proof way.

pros: Fix class name conflicts. Concise. Reasonably intelligible?

cons: Not intuitive if you don't know the overall codebase architecture (not really a big deal). Copies inheritance information into the naming scheme (DRY!). Approaching Hungarian and all it's +/-s.

Thoughts?

HelpView/UnitView/AnnounceView/etc should be held in unique_ptr's so they get cleaned up if MainView is ever deleted.

In the current code, this shouldn't ever happen so it isn't really important, but we should (generally) avoid raw pointers when possible.