From 90a48593265e06d5aff69664d622bc99c6e5af4b Mon Sep 17 00:00:00 2001 From: Noah Petherbridge Date: Wed, 22 Aug 2018 10:01:02 -0700 Subject: [PATCH] Check in updated docs before break --- Ideas.md | 15 ++++++++++++ README.md | 6 ++--- docs/Grid Data Structure.md | 49 +++++++++++++++++++++++++++++++++++++ 3 files changed, 67 insertions(+), 3 deletions(-) create mode 100644 docs/Grid Data Structure.md diff --git a/Ideas.md b/Ideas.md index 87961fe..3e4ca85 100644 --- a/Ideas.md +++ b/Ideas.md @@ -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.` 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 diff --git a/README.md b/README.md index 7c439b7..0b24457 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/docs/Grid Data Structure.md b/docs/Grid Data Structure.md new file mode 100644 index 0000000..db3cf07 --- /dev/null +++ b/docs/Grid Data Structure.md @@ -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.