The Symbiosis of Software and Hardware

I've long thought that more can be achieved through greater cross-pollenation between discipline domains, that people should specialise in a little more than one area, that we should explore the possibilities of mixing techniques together in creative and interesting ways, and do it through the play that using highly interactive tools and flexible, modular architecture allows.

Sunday, 30 April 2017

The
Story So Far

Exactly one year ago
Lionhead Studios closed its doors.
Whilst a sad occasion, this set many people on journeys of opportunity,
branching out, putting ideas into action, and creating new things of their own. For me this was the chance to fully apply
myself to fleshing out Apparance. I knew
that I wouldn't have time to finish a game built around it nor would I reach
the point of self-sustainability, but there were several key things I could
achieve during that time. First I needed
to finish proving some of the core technical premises (predominantly around
detail management and scale), I wanted to build a showcase technical
demonstration, and also I wanted to collect together all sorts of information
about the project into a web-site.
Ten-or-so months later and I have pretty-much achieved this and it's time
to take stock of the situation, get it out there, get some feedback, and decide
on the next step.

Hobby
Mode

It's a lofty goal to
build a complete, standalone game engine, especially when there are many
off-the-shelf ones available. There was
always a justification for this though in the unique approaches needed to
support the various goals; entirely procedural assets, runtime generation, wide
detail ranges, visual editing, etc.
Unfortunately financial pressures aren't kind to this sort of academic
adventuring and it's not something I can sustain any longer full-time. I'm now back in paid employment (contracting)
so we can pay the bills, which reverts me once more to spare-time development,
or 'hobby mode'.

I originally spent a long time
in this state, gradually digging away at the project, so I need to adopt a very
deliberate and careful route forward as before.
I found being constrained by time focusses your development effort a
lot. Any work has to be the most useful
work possible to move the project forward, any detours, diversions, or
misjudgements are costly.

This
Island Apparance

Given the
all-encompassing goals and experimental nature of the project it isn't
surprising this has led to an isolated system.
Whilst this has kept dependencies low and the necessary control over the
architecture high, it is costly to develop.
I have built an island paradise of procedural generation, rich with
potential and enticing to others in an idealistic way. However, the practical consequence of this is
that it is a lot to ask of people to set sail towards for its fertile
shores. To encourage a community to
settle around Apparance (and stretch this metaphor further), I really need to
build bridges to other more established lands.

Building
Bridges

There are several
obvious places I could reach out to, each with their own advocates to entice,
and communities to tap into. These are:

Commercial engines (Unity,
Unreal, …)

Assorted 3rd party engines
and projects (Irrlicht, OGRE…)

Independent developers with
own engines

Targeting Unity or
Unreal would connect with a lot of people as these are very popular platforms
for building games. Integration into
other engines or code-bases would involve similar work and allow anyone to
'bolt on' procedural generation to their project. The more fully formed and proven game engines
are attractive because they can provide the missing parts of Apparance and make
it a viable procedural generation platform sooner.

I've long doubted
how well 'conventional' game engines would support the novel requirements of
Apparance, but over the last month or so I've been thinking about the reality
of this. Rather than just seeing the
major objections and sticking points as blockers, I've been trying to consider
it as just another set of technical problems that need solving. I'm sure there are compromises that need to
be made, and changes to the way some of the Apparance systems work, but I think
there is still a lot of value in attempting this. Some important opportunities include:

Accessibility - proc-gen
tools for people within a familiar engine and tool-set

Exposure - an opportunity to
raise the profile of the project among developers

Commercial viability -
potentially an opportunity to generate some revenue

Modularisation - a useful
exercise in tidying up the code-base

Expansion - groundwork will
make it far easier to then port to other engines

Acceleration - This could be
a good way to get my first game built more quickly

Where
To Start

My personal
experience with third-party engines is by far strongest with Unreal, in fact quite a lot of the
time I spent building foliage tools for Fable Legends I was working in exactly
the areas of the engine I would need to work to incorporate Apparance into it. Unreal also has a liberal developer model,
making all the source code easily accessible.
It makes sense then for this to be my starting point and where I should
focus my efforts next.

Requirements

To create a
professional grade integration with Unreal it's important to consider the
workflow and user experience of a developer wanting to use procedural
techniques. I would like to consider the
following scenarios:

Taking a few pre-made
procedural assets a dropping them into your game.

Building game worlds from
lots of pre-made and custom procedural assets.

Using procedural assets to
create large parts of game environment.

Using procedural techniques
to place conventional assets.

Creating massive continuous
expanses of procedural game world.

This means quite a
thorough integration is needed to play to both systems strengths. I will look into this more in a future post.

Sunday, 26 February 2017

Sorry for the lull,
it's been a bit of a mixed-up month and this will be a similarly mixed up blog
post. Having reached the deadline for
demo, web site, and release preparations at the end January things have changed
pace and direction a little. I've rolled
an Alpha build to a few people, the web-site has gone live, and I've been out
job hunting too!

Goals

The end of January
was my deadline for a number of aspects of the project, and this has meant
February has been a bit of a flurry of activity releasing things and talking to
lots of people about the project (and work prospects).

Demo

As with most things,
you never get as much done as you'd like to.
No exception with Future City, but I am mostly happy with how it
looks. It demonstrates the core premises
of the project; large environments, varied content, wide-scale
parameterisation, high detail, smooth blending, and powerful modelling system.

I'm pleased with how the demo "Future City" has developed

I will continue to
develop the city as there are many things I'd like to do with it, but it is
also going to be the basis for the first Apparance game. It will be taking a back seat to other
development for now though.

Web
Site

The Apparance
website, bringing together information about all aspects of the project, is now
live at www.apparance.uk.

The new Apparance web-site (procedurally generated too!)

I'm pleased with how it's come out, and the
procedural generation aspect is proving very powerful. A good test of this sort of thing is how easy
you find maintenance on returning to it after a while away. I've extended the site a bit, added new
templates and image features with ease.
Updating content is just a question of editing the markdown documents
and running the Apparance Processor. I'm
enjoying working with it this way, and looking forward to adding new pages and
features as needed.

Release

The 1st of February
saw the start of the Alpha release of the project. The first time anyone has got their hands on
Apparance for a couple of years. It's
really been too long coming, but I wanted to get to a particular point and
combine it with the website and the city demo.

Apparance editor, currently in (closed) Alpha

It's not a huge
audience, and only some of my more technical friends, but I've been getting
some solid feedback. Plenty to go on and
lots to talk about. I've been working a
bit of it back into the editor, and site, ready for the closed beta due to
start in a few days. The beta is a
larger group, and taken from a wider circle of acquaintances (mostly via
Twitter). This group contains a higher
concentration of people who are specifically interested in procedural
generation, and should provide a deeper level of feedback. I can't wait to hear how you folks get on.

Project

So, where does this
find us now?

Status

The current set of
goals, largely based around proving the more unique aspects of the project, has
been proven (in my eyes at least). Now I
have people starting to experiment with, and explore the tools I have a source
of objective information to use to potentially steer and drive the
project. I'd like to see a variety of
outcomes from the project, but now is time to discuss these and investigate the
options.

Support

As an authoring
tool, and one with some pretty unusual concepts to learn, support for Apparance
users is going to be important at this stage.
This is especially true if I want to nurture a community and have people
join me in this adventure.
Documentation, tutorials, and two-way communication are all important
parts of this, and typically under provided so I need to be careful to keep
feeding this. I've been asked for a
variety of support, from examples, tutorials, videos, features, and improved
documentation.

Games

Apparance is a
realisation of my vision for building games, and as such needs to continue to
move towards an actual game. I need to
show that this is viable, and with the ambitious technical goals too. I have some exciting game ideas brewing at
the moment (several sleepless nights spent designing game-play and story). Unfortunately, the next step with regard to
games (entities, behaviours, and interaction) is quite a hefty piece of
work. This is going to need to be spread
out.

Product

I have also begun
thinking about the more practical aspects of the project, and other ways the
technology could be used. By creating
additional types of product out of the engine and tools it might provide a way
to broaden the potential audience (and hence market) and provide a model to
generate revenue that isn't game based.
Yes, I am actually considering how Apparance could be modularised so
that elements of the technology could be plugged or integrated into other
engines, including Unity and Unreal. I
know I haven't been supportive of this approach, but economic pressures do make
you think about your options, and there might be ways to do this without
compromising the vision of the project.
Again though, this isn't an insignificant amount of work, and requiring
a lot of research and ongoing development and then support.

Next

I've really enjoyed
the luxury of working full-time on Apparance for (nearly) the past year, but
financial pressures are starting to rear their head. I don't believe I am in a position to pitch
what I have technology-wise, and certainly not game-wise, to a third party for
funding. There is too much still to do
and I don't have the resources to continue full-time. As a result I am in the process of
negotiating a more traditional source of income so I can continue to support my
family properly.

Apparance is most
definitely up and running and I'm pleased with what I have achieved so
far. I will continue to support the
alpha/beta, blog about the project, work on updates, and start on some of the bigger features over the
coming months, but in my spare time (again).

Thank-you for
sailing with me through this exciting year of Apparance development. I look forward to seeing where the wind blows
us over the next year.

Monday, 30 January 2017

Progress on Future
City has been slowed by web-site and release preparation work at the
moment. I've split my time about 2:2:1
between Web site, Future City, and Alpha Release preparations.

January push towards Web Site, City demo, and Alpha Release.

This split in
attention as well as the pressure of the approaching alpha release means blog
posts have been slower forming. Let's
just squeeze out a quick update on the Future City progress...

Future
City

At the moment I've
been focusing on the support of variable elevation across the city, with each
city block having its own height.

Example of blocks with shared connectivity but height discontinuities

This
feature results in rather complicated requirements at the interfaces between blocks
as well as complicating the process of sub-dividing up the space within
them. As such, it's been quite slow
progress working out (a) exactly what is required, (b) how to perform this, and
(c) how to implement this.

Requirements

Based on the previous connectivity work which sub-divided the city up into districts/zones
and finally blocks, we have already decided on what the connectivity between
each block looks like.

Now we need to
decide on what the content of the block should be such that it is possible to
guarantee that adjacent, separately generated content aligns properly,
functions as a seamless transition, and looks plausible.

Inputs

We have the
following information about each block boundary:

Block location/bounds/size.

Access along each side
(left/right of opening within any barrier present).

Follow the underlying
landscape shape, or both share flat ground level at a given height.

Connectivity via each side
(to the outer most city sides).

Variation seed to drive
arbitrary design decisions.

Outputs

From this we need to
populate the block with rectangular sub regions. The main problem we are trying to solve here
is to transition from a boundary with zero, one, or two accessibility
transitions along each side into spaces for content to go that all have single
accessibility along each side, these being simpler requirements to
satisfy. Thus the outputs are of the
form of Content Spaces with the following properties:

Bounds size, orientation and
location

Surface height within the
space (or if we are to follow the landscape)

Is it an interfacing piece,
i.e. responsible for handling transition to neighbouring block interface? (Edge - one interface along
block boundary, Corner - two interfaces
along block boundary, Side - three interfaces
along block boundary)

If not an interface, then an
interior piece, with same type all round (flat or landscape)

For each boundary interface: Specific flat elevation or
landscape following. Do we 'own' this side (are
responsible for interfacing geometry). Is this a barrier, i.e. will
access be blocked? Is there a barrier to the
left/right that we may need to provide transition geometry for?

Test
Rig

Since there are a
lot of combinations to test in forming this system it is worth generating a set
of 'unit tests' with clear visualisation of the inputs and outputs. By creating a hierarchy of test procedures we
can quickly generate tests for all the major side and access combinations.

Ownership - all, none,
adjacent, opposite

Surfaces - all landscape, all
flat, mixture

Access - Closed corners, all
open, all closed (bar one), some on left, some narrow, mixture

Unit tests for a lot of the block interfacing cases

For cases where a
specific issue is being resolved there is the option to switch out all but one
test scenario.

Example test rig showing corner results produced

Algorithms

I spent a lot of time in Excel playing with block boundary examples and possible approaches.

Playing with block algorithm ideas in Excel

From this I've come up with a lot of ideas, but they seem to be heading
towards this sequence of calculations:

First pass at the content space and interfacing algorithm

There are bound to
be some changes as implementation proceeds, but this is a good starting point.

Lists

Structured
Data

The amount of
structured information and variability in generated output finally became too
much and I had to stop to add some functionality to help support this. Previously where several properties about a
single thing needed to be conveyed through several procedures it had to be
passed individually, and explicitly.
This leads to this specific flavour of spaghetti:

A specific flavour of spaghetti: arrays of connections

The algorithms that
were forming to perform the interfacing and content-space generation were
heading towards an awful lot of this.
From the requirement analysis above we can see each block has at least
seven properties that go together, and each potential output content space has
at least six.

Traditionally these
would be encapsulated in structures, where a single type is used to express an
explicit collection of typed data. This
is something that Apparance will natively support in the future, but it's quite
a lot of work, especially on the tooling side where composition/decomposition
of structures needs to be handled elegantly.

Variable
Quantities

Another aspect of
the block interfacing implementation problem is that there are several places
where we need to pass a variable number
of structures. At the moment there is no
concept of this and we would have to pass a fixed (maximum) number of
structures (as individual properties) along with an additional flag expressing
whether it was in use. This forms a
very, very unwieldy situation where all sorts of operations, such as combining
two variable sized collections, become incredibly complicated, expensive and
error prone. We really need some form of
list or array to handle this.

Solution

Both these prospects
are really going to cause too much of a headache to work on the already complex
problem, so we need support to help this.

Looking at other
language for inspiration, we find that both these problems can be addressed by
using lists of dynamically typed objects.
If a list happens to contain all the same type, then it is effectively a
traditional list or array, i.e. a variable sized collection. If a list happens to contain a fixed number,
of different typed elements then it can be used as a structure. Adding support for lists as just another base
data-type to Apparance is fairly straight-forward and then means we can have
lists of lists, or put another way, lists of structures.

Implementation

The List data type
was added along with an initial set of basic operators to support what we would
need, as follows:

Append - take a list and add
another element (any type).

Get - index a list, returning
the element value (any type).

Set - replace a value at a
specific index with a new value (any type).

Count - query how many
elements are in the list.

Part of the
implementation that took a bit of effort was that I wanted type information to
be maintained with them as the lists are constructed. With this, a lot of validation can be
performed during synthesis that would catch problems that would otherwise be
very difficult to diagnose and have potential to crash the engine.

Whilst a bit tricky
to implement, lists are proving very useful so far and make a lot of the block
interfacing problem much more pleasant to work with.

Passing structures and collections around as lists

I am even now using them in the web site
building procedures for all sorts of things.

Progress

I'm about half way
through the Block Boundary -to- Content Space processing system and have
promising results so far.

Some of the content space generation results so far

I'll post more
results as I progress. In the mean-time
I have an Alpha Release to get out!

Monday, 16 January 2017

Recap

In Part 1 we
proposed using Apparance as a text processor and tool automation controller to
build our web-site. So, how exactly
would we go building about this?

The Apparance web site prototype.

Page
Structure

Browsing a few basic
web tutorials on how to set up a fairly standard CSS styled HTML page we are
looking at this:

Title banner and
logo

Site navigation bar

Page content,
different for each page

Footer with a few
common links and note.

We can encapsulate
the shared and custom element construction in a top-level page procedure. This wraps a procedure for emitting the
standard HTML page sections and any extra bits all pages need (metadata, etc). This is the point that the CSS for the page
and the body HTML are passed in as parameters.

The top-level page generation procedures.

This provides a
single procedure that can be re-used on each site page, with the page specifics
and customisations passed in as parameters.
For example, here it is used on the homepage.

All that is needed for a top level, text content based page.

All that is needed for a page like this is the content source and a couple of constant values.

Title

I wanted the title to
use the Apparance logo, and have a background that hinted at both what you can
make with Apparance, and how you make it.
This is a combination of background image banner and centred logo.

Title banner background (transparency shown as checker-board)

Title logo (transparency shown as checker-board)

Both of these are
images that are prepared by hand (at the moment) and just need to be copied
across if they are updated or missing, this is handled by the Image Fetch
procedure (see below).

Header background (CSS) and logo (HTML) generating procedures

There is a bit of styling to apply the background, and the logo is an image HTML element over the top.

Navigation

The navigation bar
should be a simple row of buttons with hover highlighting and current page
indication. These provide the top-level
site choices, the leftmost one being the main homepage and site entry-point.

The main navigation bar. Current tab and hover highlighting shown.

To do this properly,
the idea is to have the items expressed in a simple a way as possible in the
HTML and leave the funky appearance to the CSS.
The best of conventional wisdom points at using an un-ordered list (UL
tag) with list items (LI tag) for each menu option. With the appropriate tagging, this can then
be 'skinned' into a row of buttons using only CSS.

Again, this can be a
single procedure that gets re-used on each page. In fact, some of the pages will require a
second row of buttons to navigate sub-pages (too many pages to have them all in
one row). We can build this procedure
(and the CSS) to support this.

The bar and button creation procedures.

The CSS generation procedure for the navigation bar and buttons.

The procedure to
generate the CSS is designed to be applied twice, with the menu level as a
parameter. This allows the styling to be
slightly different and provide a raked appearance to the menus as they
transition into each other and the page content.

Example of a double level navigation bar.

To get the to show the correct selected page in each place it's used, the page it is on is passed as a
parameter which causes that button to have the selection highlight styling
applied.

Footer

The page footer is
very simple, just a few links and some text.

Simple page footer

It is included in
the general page procedure as it appears at the foot of every page.

Common footer procedure and where it fits in.

We may need to
include some customisation later so that when on pages it actually links to,
those links are disabled (for neatness).
There are other cool things we could do with the footer later I'm sure.

Content

Markdown

The main part of
every page is the content and comes, for most of them, from external markdown
files. This allows the content to be
written in a form that can be transformed into HTML as well as other forms if
we need (see later). Here is an example
of what the content looks like in raw markdown and on the actual page.

Markdown source document compared to resulting HTML page output.

Custom

Some pages warrant
custom generation and rely on special procedures to generate their
content. A good example of this is with
the online user documentation pages I want to include. Here, instead of hand-writing simple textual
descriptions to appear on the Operators manual page, we can build it
automatically from the operator definitions that the editor already dumps out
on start-up (a simple form of user doc that was added ages ago). This is in the following form:

Source operator description format generated by the editor

By loading this in
with the file read operator, applying some recursive scanning of the content
(using find and split operators to parse each section), we can generate web
page content for it. With some HTML
table and a sprinkle of CSS magic we can generate fairly good facsimiles of the
actual operators in the editor.

Resulting operator documentation example

These have
hover-tips for extra detail where available, such as the internal operator name
and the IO connection descriptions.
There is also a summary section that appears at the top of the page with
links to each section.

Summary section for the operator documentation

Code
Generation

The page
construction process is broken down into various modular parts, split between
the HTML generation and the CSS generation as well as being split into generic
(re-usable) operations and ones specific to our site or page.

I've found that by
wrapping even the simplest tags with procedures, it keeps the graphs readable,
and also allows for site-wide fixes and additions to any of the HTML or CSS
constructs.

It's even worth wrapping the simplest of tags.

Most code output
(CSS or HTML) is actually just text string concatenation, for example, the
heading tag just prepends the opening tag and appends the closing tag:

The heading procedure, parameterised by level (and ID)

HTML
& CSS

A library of HTML
element procedures and CSS constructs have been accumulated as the site
constructed.

Reusable HTML and CSS procedures

The HTML ones are
mainly for the tag types that can be used, with a few attribute types to help
build them. The CSS ones are containers
for the styling of each section, and a load of property helpers. Here you can see them in use on the common
content styling:

CSS property helpers in use

Procedures

Some of the
re-usable building blocks, specifically for handling files are described in
more detail here.

Image
Fetch

Using the new file
operators, the paths can be prepared, the timestamps checked, and the copy
performed if required. On success we
pass out the relative path to the image file, ready for use in the HTML or CSS
code.

Image fetching procedures.

Document
Read

The markdown
documents are read in by invoking Pandoc with the source file as a parameter
and accumulating the text output by it to the console stream. If the return value indicates an error we
report a suitable error message.

Document reading and processing procedures.

Some additional
document processing is done here to achieve two things:

Image tags are parsed and
used to drive image thumbnail generation, propagate the main file, and
replace the image element with the thumbnail and a link to the full image.

Lists have a little bit of
formatting added to turn "Title - Description…" into "Title - Description…" to make
the headings stand out a bit more.
This is styled and can be updated globally.

Thumbnail
Generation

Where image tags are
included in any content the processing step applied on load (if enabled)
generates the thumbnail automatically.
There are a number of things going on here.

Processing of all image tags in the document using recursion

The document is
searched (using recursion) for all image tags.

The tag is parsed
and broken open into its constituants.

The image file is
located and propagated to the output folder.

A name for the
thumbnail is generated based on the image name.

A thumbnail version
of the image is generated in the output folder (using Image Magick).

A new image tag is
constructed (around the thumbnail file).

The image tag is
wrapped in a hyperlink tag pointing at the full image.

The document around
the image tag is re-combined.

There is a lot going
on here, but it can all be laid out nicely and the flow of information is clear
from the procedure construction.

Viewing
the Results

Now we have this all
up and running, as changes are made to the procedures the top-level page
procedure we are 'viewing' is re-built for us.
This is an HTML page with the required images nearby that can readily be viewed
in a browser.

Live
Page

One additional
requirement to be able to see changes in real-time is for us to get the browser
to refresh as pages change. This could
be done with the auto-refresh timer you can add to a web page, but this is
rather crude as it will a) be updating all the time, and b) have to be doing so
rapidly to get a decent response time to changes.

A bit of digging
turned up a lovely little Chrome extension called LivePage. After setting a few options up, you can click
on the icon alongside any page and have it watch the source file for
changes. On detecting one the page is
reloaded.

LivePage browser extension in Chrome

It is proving really
good for working interactively and has options to track changes to HTML,
embedded CSS, and even source image files (experimental, but seems good).

Content

By adding a quick
directory watcher feature into the editor I was able to also have generation
happen when the source content (markdown) documents or source images
changed. This nicely rounded off the
editing experience.

Interaction
Examples

The best way to see
all this working together is a video, so here you are.

So far this has been
a really fun way to develop the web site, and I'm certainly going to continue
along this vein. I hope you liked this
slightly tangential application of the technology, I expect there will be more
of this sort of thing in the future.

Next

Next time I should
be ready to give you an update on height work on Future City and a long overdue
engine feature I added to help support it.

Monday, 9 January 2017

Web
Site Needed

Apparance is at the
stage now where it needs a proper web-site to bring together all the
information accumulating around the project and provide a hub for people to
find out all about it. It's going to
need all the usual stuff; summary pages, a gallery, detailed project information, feature lists,
technical information, contact information, blog, documentation, and contact
information. Something like this:

A prototype Apparance homepage.

There are many ways
to approach creating a web site. It
could be out-sourced, built using an online web-site maker, using offline
tools, crafting from the many kits and examples available, or writing it all by
hand in notepad.

Not having huge
resources available and having hand crafted a few pages in my time I figured it
would be best, at least in the short term to code it up myself. So, given that I'm 'living and breathing procedural' right now, is there any reason not to try and do this procedurally, with Apparance?

I can't see anyone else making websites procedurally! Am I crazy?

Approach

I'm not familiar
with all that is trendy in web development and I'd like to keep things simple
so I'm thinking static HTML pages with CSS styling. I'd like to be able to author page content in
some sort of simple format and not have to be editing html or using any web
design tools to make changes. Any image
manipulation should preferably be handled automatically or with little
interaction. Given this, some
process will be needed to effectively compile the content, images, structure,
and styling together into each page.

Utilities

Content
Processing

Simple format text
files with basic formatting information you say? Sounds like mark-down to me. A bit of digging found a rather impressive command line
utility called Pandoc which actually will convert a plethora of document
formats. By default though passing in
simple markdown text it will spit out an HTML fragment.

Pandoc, by default converts markdown into HTML

Perfect for
injecting into the structure needed around it to form a complete page.

Image
Processing

The most common need
for image preparation on a web page has to be scaling to generate thumbnail
previews, something we're going to need to show off all the visual goodness of Apparance. A well know tool that handles
this adequately is Image Magick. Again a
command line tools with a huge number of features and functions, it comes with
an command specifically designed for generating thumbnails.

Image Magick, great for quickly handling thumbnail generation

Perfect to add to the arsenal of tools for
building my pages.

Automation

Now to the question
of automation; how best to take all this and build pages out of it? Let's look at the requirements.

Generate the common page HTML
and CSS according to the page design.

Launch Pandoc to turn the
page content into HTML.

Launch Image Magick to
generate thumbnails for the images.

Combine the HTML into pages.

Assemble it all in a suitable
file/folder structure for serving as a web-site.

Doing
it wrong

There are existing static web page compilers available (e.g. Hugo) I could use. I could write a program to do it, or come up with something in python or similar scripting languages. But thinking about
Apparance and some of the philosophies behind it I realised that these
approaches went against it on several levels.

First, there was the baking process, the page needed to be compiled
before it could be viewed. Now, whilst any process of assembling a page
requires time to complete, with scripts and command line tools there are still
several steps involved in getting from making a change to seeing the
results. You lose the immediacy of a
truly interactive editing experience.

Second, committing anything to script or code goes against the
data-driven approach, and again, you lose the direct connection between your
design and the results.

We've
seen this before

Having already
worked on interactive editing and text based processing with the material and
shader system in Apparance it seemed like a similar approach could be applied here. Why not use procedures in Apparance to handle
the HTML composition, the control of command line utilities, and the
manipulation of files and the directory structure? It would mean any part of the web-site
could be editing and you would get to see the results in real-time! This was clearly the path to follow.

And So; To Procedural

A few things would
be needed to be added to Apparance's capabilities for us to be able to support
this though:

Extra string handling
functions - we are going to be doing more fancy things than we did with
shader building.

File handling operations - we
are actually going outside the application, to work with files.

An operator for spawning
processes and collecting their output - to allow us to use other tools to
do our bidding.

With all this in
place, we are in a position to start building the site by creating procedures and letting Apparance do the work. Next time we'll have a look at how this went and what it's like to work with. Here's a sneak peek at the editor with the procedure for writing out the HTMLpages.

Tuesday, 13 December 2016

Not many words
today, just a quick rundown of the new and improved aspects of the city.

Aerospace

A quick
space-port/airport cobbled together from other city parts to just get rid of
the last placeholder zones.

First pass aerospace district, the black will be landing areas for ships.

Parks

Time for some low
level detailing, quickly knocked up and assembled a variety of simple
small-scale park features; benches, bins, flowerbeds, huts, and a stepped
plinth. I even added a simple tree model
that can be refined later.

Parks and recreation, now with 'furniture'

More green space in our cities

City
Green Spaces

Plugging the park
'furniture' into the business district open spaces instantly improved the sense
of scale.

Business district park areas, a nice spot for lunch

Adding a sense of scale to the large skyscrapers

Residential

My multi-celled
apartment complexes and various street/terrace configurations lends to a nice
residential area feel.

Residential areas, lots of apartments, terraces, and streets

Example street layout, with variable back-yard spaces

Detail
Boost

Some time spent
tweaking parameters and diagnosing detail problems has seen a nice boost in
detail levels, meaning we can start to see the promise of the system even more.

Overview of various city zone types, now in even more detail

10 kilometres of city in view from on high

Next

Now I'm finally
going to get on to height variation and simple terrain modelling for the
surroundings and green areas of the city…

Coming from a technical and practical upbringing I've always been passionate about computers and electronics; writing programs and building contraptions from primary school age upwards. Studied electronics at university, and working in games development since 1995.