Check in updated docs before break

This commit is contained in:
Noah 2018-08-22 10:01:02 -07:00
parent 5434484b6e
commit 90a4859326
3 changed files with 67 additions and 3 deletions

View File

@ -141,6 +141,21 @@ Probably mostly DRM free. Will want some sort of account server early-on though.
representation before we go live. JSON support shall remain, but the
production application will not _write_ JSON files, only read them.
(This way we can ship drawings in the git repo as text files).
* The app will support reading three types of files:
* `.canvas` files are the lowest common denominator, raw drawing data. It
contains a Palette and a pixel grid and nothing more.
* `.map` files are level maps. They include a Canvas along with level
metadata, Doodad array, attached files, etc.
* `.doodad` files are for doodads. They include a Canvas along with
metadata, embedded JavaScript, attached files, etc.
* JSON versions will have `.json.<ext>` file suffixes, like `.json.canvas`
or `.json.map`
* The **production** app will be only be able to read the binary format of
the files. The JSON reading code is for dev builds only.
* Shareware/Demo builds will have even more restrictions on supported file
types. For example it won't be built with the code that allows it to
read _or_ write a Doodad from disk, as it will be limited only to built-in
Doodads and won't support authoring custom ones.
## Common Drawing Files

View File

@ -114,7 +114,7 @@ As a rough idea of the milestones needed for this game to work:
OpenGL or something later on.
* [x] Implement a command line shell in-game to ease development before a user
interface is created.
* [ ] Add support for the shell to pop itself open and ask the user for
* [x] Add support for the shell to pop itself open and ask the user for
input prompts.
## Alpha Platformer
@ -157,11 +157,11 @@ As a rough idea of the milestones needed for this game to work:
* [x] Create a "Main Menu" scene with buttons to enter a new Edit Mode,
play an existing map from disk, etc.
* [x] Add user interface Frames or Windows to the Edit Mode.
* [ ] A toolbar of buttons (New, Save, Open, Play) can be drawn at the top
* [x] A toolbar of buttons (New, Save, Open, Play) can be drawn at the top
before the UI toolkit gains a proper MenuBar widget.
* [x] Expand the Palette support in levels for solid vs. transparent, fire,
etc. with UI toolbar to choose palettes.
* [ ] Add a "Canvas" widget that will hold level drawing data and abstract it
* [x] Add a "Canvas" widget that will hold level drawing data and abstract it
out such that the Canvas can have a constrained width and height, position,
and "scrollable" viewport area that determines rendered pixels. Will be VERY
useful for Doodads and working on levels smaller than your window size (like

View File

@ -0,0 +1,49 @@
# Grid Data Structure Ideas
Ideas for managing level pixel grids.
## Chunks
Divide the grid into Chunks of an arbitrary size. The canvas metadata would
specify the chunk size (e.g. 1000x1000 pixels) so it's able to vary by the
drawing itself.
A `ChunkManager` structure would wrap around the chunks and give each one a
coordinate value. To convert an absolute pixel value into a chunk coordinate
you multiply it by the chunk size.
So a pixel coord of `123456` in a map with 1000x1000 chunk sizes would be
`(123456) / 1000 = 123.456 = 123` (rounded down). This would give you a chunk
index and then that chunk is responsible for knowing where the exact pixel is.
## Chunk Types
Each chunk could organize its pixels into two types of structures depending
on the density of the chunk:
1. A hash map for sparse chunks.
2. A 2D array of fixed size for dense chunks.
So if a chunk is <70% filled it would use a hash map and when it gets heavier
than that, switch to a 2D array.
Something like,
```go
type Chunk struct {
Type int `json:"type"` // map vs. 2D array
Map map[Point]int // map of (X,Y) points to Palette entry
Grid [][]int // 2D array of Palette entries
}
```
## External Chunks
For normal single-player maps that aren't infinite in size, all the chunks
are stored in the singular level file. Larger maps can start saving their
chunks to disk in external files.
Some internal threshhold can be used to decide when to start saving chunks
as external files. If the chunk size is 1000x1000 pixels it could start saving
external files after (say) 9 different chunks are allocated for the first time,
or some time/space tradeoff like that.