Check in updated docs before break
This commit is contained in:
parent
5434484b6e
commit
90a4859326
15
Ideas.md
15
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.<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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
49
docs/Grid Data Structure.md
Normal file
49
docs/Grid Data Structure.md
Normal 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.
|
Loading…
Reference in New Issue
Block a user