SketchyMaze/doodle
SketchyMaze/doodle
1
0
Fork 0
Code Issues 41 Pull Requests 1 Releases Wiki Activity
9e4f34864d
doodle/pkg/balance/numbers.go

98 lines
2.2 KiB
Go
Raw Normal View History

Abstract Drawing Canvas into Reusable Widget The `level.Canvas` is a widget that holds onto its Palette and Grid and has interactions to allow scrolling and editing the grid using the swatches available on the palette. Thus all of the logic in the Editor Mode for drawing directly onto the root SDL surface are now handled inside a level.Canvas instance. The `level.Canvas` widget has the following properties: * Like any widget it has an X,Y position and a width/height. * It has a Scroll position to control which slice of its drawing will be visible inside its bounding box. * It supports levels having negative coordinates for their pixels. It doesn't care. The default Scroll position is (0,0) at the top left corner of the widget but you can scroll into the negatives and see the negative pixels. * Keyboard keys will scroll the viewport inside the canvas. * The canvas draws only the pixels that are visible inside its bounding box. This feature will eventually pave the way toward: * Doodads being dropped on top of your map, each Doodad being its own Canvas widget. * Using drawings as button icons for the user interface, as the Canvas is a normal widget.
2018-08-17 03:37:19 +00:00
package balance
Touch Screen Controls for Play Mode! The game can now be played using only a touch screen! The left mouse click (Button1) can now move and control the player character. * A box in the very middle of the screen is the "Use" button and a deadzone for directional inputs. * Anywhere outside the middle and to the left registers a Left button, to the right a Right button, above the top of the middle is a Jump button, and below the bottom of the middle is a down input (for antigravity mode). * Tight platforming is possible: above and below the middle box, the left/right split is tight in the middle of the window. You can get tight jumps if jumping or go below if you don't want to jump. The left/right deadzone is only over the space of the Use button. If the player is idle for a while with no controller inputs, some hints will fade in about the touch controls. Note: the ScrollboxOffset to track the player character is changed to 60,60 from 60,100 so the camera will track tighter to the player and so the player will mostly be over the Use button on touch controls as long as he's away from a level boundary.
2021-10-05 02:51:31 +00:00
import (
"time"
"git.kirsle.net/go/render"
)
Fix Scroll-Follow-Actor Behavior * The scrollbox by which the game follows the player character has been revised, it is now an offset away from the window's center instead of fixed pixel distances from the window's edges. * Mobile form-factor (Pinephone) now scrolls OK instead of jerking back and forth rapidly when moving left.
2021-06-14 03:25:42 +00:00
Abstract Drawing Canvas into Reusable Widget The `level.Canvas` is a widget that holds onto its Palette and Grid and has interactions to allow scrolling and editing the grid using the swatches available on the palette. Thus all of the logic in the Editor Mode for drawing directly onto the root SDL surface are now handled inside a level.Canvas instance. The `level.Canvas` widget has the following properties: * Like any widget it has an X,Y position and a width/height. * It has a Scroll position to control which slice of its drawing will be visible inside its bounding box. * It supports levels having negative coordinates for their pixels. It doesn't care. The default Scroll position is (0,0) at the top left corner of the widget but you can scroll into the negatives and see the negative pixels. * Keyboard keys will scroll the viewport inside the canvas. * The canvas draws only the pixels that are visible inside its bounding box. This feature will eventually pave the way toward: * Doodads being dropped on top of your map, each Doodad being its own Canvas widget. * Using drawings as button icons for the user interface, as the Canvas is a normal widget.
2018-08-17 03:37:19 +00:00
// Numbers.
var (
Move Editor Canvas Into UI + UI Improvements * Increase the default window size from 800x600 to 1024x768. * Move the drawing canvas in EditorMode to inside the EditorUI where it can be better managed with the other widgets it shares the screen with. * Slightly fix Frame packing bug (with East orientation) that was causing right-aligned statusbar items to be partially cropped off-screen. Moved a couple statusbar labels in EditorMode to the right. * Add `Parent()` and `Adopt()` methods to widgets for when they're managed by containers like the Frame. * Add utility functions to UI toolkit for computing a widget's Absolute Position and Absolute Rect, by crawling all parent widgets and summing them up. * Add `lib/debugging` package with useful stack tracing utilities. * Add `make guitest` to launch the program into the GUI Test. The command line flag is: `doodle -guitest` * Console: add a `close` command which returns to the MainScene. * Initialize the font cache directory (~/.cache/doodle/fonts) but don't extract the fonts there yet.
2018-10-08 17:38:49 +00:00
// Window dimensions.
Width = 1024
Height = 768
WIP LevelPack UI + Landscape Mode Title Screen The title screen is now responsive to landscape mode. If the window is not tall enough to show all the menu buttons (~600px) it will switch to a horizontal layout with the title on the left and buttons on the right. WIP "Story Mode" button that brings up a Level Packs selection window.
2021-12-24 05:11:45 +00:00
// Title screen height needed for the main menu. Phones in landscape
// mode will switch to the horizontal layout if less than this height.
TitleScreenResponsiveHeight = 600
Abstract Drawing Canvas into Reusable Widget The `level.Canvas` is a widget that holds onto its Palette and Grid and has interactions to allow scrolling and editing the grid using the swatches available on the palette. Thus all of the logic in the Editor Mode for drawing directly onto the root SDL surface are now handled inside a level.Canvas instance. The `level.Canvas` widget has the following properties: * Like any widget it has an X,Y position and a width/height. * It has a Scroll position to control which slice of its drawing will be visible inside its bounding box. * It supports levels having negative coordinates for their pixels. It doesn't care. The default Scroll position is (0,0) at the top left corner of the widget but you can scroll into the negatives and see the negative pixels. * Keyboard keys will scroll the viewport inside the canvas. * The canvas draws only the pixels that are visible inside its bounding box. This feature will eventually pave the way toward: * Doodads being dropped on top of your map, each Doodad being its own Canvas widget. * Using drawings as button icons for the user interface, as the Canvas is a normal widget.
2018-08-17 03:37:19 +00:00
// Speed to scroll a canvas with arrow keys in Edit Mode.
Checkpoint Flag & Retry from Checkpoint * New Doodad: Checkpoint Flag. They update the player's spawn point whenever the player passes one. The most recently activated checkpoint is rendered brighter than the others. * End Level Modal: the fake alert box window drawn by the Play Mode is replaced with a fancy modal widget (similar to Alert and Confirm). It handles level victory or failure conditions and can show or hide all the buttons as needed. * Gameplay: There is a "Retry from Checkpoint" option added, which appears in the level failure modal. It will teleport you back to the Start Flag or the last Checkpoint Flag you had touched, without resetting the level -- your keys, unlocked doors, etc. will be preserved so you can retry. * Set a maximum speed on the "Camera Follows Actor" logic of 64 pixels per tick. This results in a smoother scrolling transition when the player jumps to a new location on the map, such as by a Warp Door. * Update the default color palettes: * All: Add a "hint" magenta color. * Colored Pencil: Add a "darkstone" solid color. Updates to the Doodads JavaScript API: * SetCheckpoint(Point(x, y)): set the player character's spawn position. Giving it Self.Position() is an easy way to set the player spawn to your doodad's location.
2021-08-16 03:17:53 +00:00
CanvasScrollSpeed = 8
FollowActorMaxScrollSpeed = 64
Implement Chunk System for Pixel Data Starts the implementation of the chunk-based pixel storage system for levels and drawings. Previously the levels had a Pixels structure which was just an array of X,Y and palette index triplets. The new chunk system divides the map up into square chunks, and lets each chunk manage its own memory layout. The "MapAccessor" layout is implemented first which is a map of X,Y coordinates to their Swatches (pointer to an index of the palette). When serialized the MapAccessor maps the "X,Y": "index" similarly to the old Pixels array. The object hierarchy for the chunk system is like: * Chunker: the manager of the chunks who keeps track of the ChunkSize and a map of "chunk coordinates" to the chunk in charge of it. * Chunk: a part of the drawing ChunkSize length square. A chunk has a Type (of how it stores its data, 0 being a map[Point]Swatch and 1 being a [][]Swatch 2D array), and the chunk has an Accessor which implements the underlying type. * Accessor: an interface for a Chunk to provide access to its pixels. * MapAccessor: a "sparse map" of coordinates to their Swatches. * GridAccessor: TBD, will be a "dense" 2D grid of Swatches. The JSON files are loaded in two passes: 1. The chunks only load their swatch indexes from disk. 2. With the palette also loaded, the chunks are "inflated" and linked to their swatch pointers. Misc changes: * The `level.Canvas` UI widget switches from the old Grid data type to being able to directly use a `level.Chunker` * The Chunker is a shared data type between the on-disk level format and the actual renderer (level.Canvas), so saving the level is easy because you can just pull the Chunker out from the canvas. * ChunkSize is stored inside the level file and the default value is at balance/numbers.go: 1000
2018-09-23 22:20:45 +00:00
Improvements to the Debug Overlay Feature * Scenes can insert custom key/value labels to the debug overlay and track string variables in real time * Added ability to unthrottle FPS in main loop
2019-04-10 01:28:08 +00:00
// Window scrolling behavior in Play Mode.
Fix Scroll-Follow-Actor Behavior * The scrollbox by which the game follows the player character has been revised, it is now an offset away from the window's center instead of fixed pixel distances from the window's edges. * Mobile form-factor (Pinephone) now scrolls OK instead of jerking back and forth rapidly when moving left.
2021-06-14 03:25:42 +00:00
ScrollboxOffset = render.Point{ // from center of screen
Link Start Flags to Change Characters New feature: link a Start Flag to another doodad in your level and you will play as that doodad instead of Boy. All Creatures are designed to be playable. Playing as "other" doodads leads to interesting effects, like not being able to activate buttons, switches, or warp doors and not having an inventory to pick up keys. The Anvil is fun: it can destroy other mobile doodads by jumping on them. If the actor does not specify that it has gravity, the gameplay starts in antigravity mode. This will be the vast majority of non-mobile doodads and the Bird. Other changes: * The Blue and Red Azulians now share a doodad script. * The Azulians AI is still to walk back and forth, pickup keys and press buttons. The Blue Azulian walks slower than the red one. * The Blue Azulian is no longer hidden from the doodads list. * Actor UUID values in levels are now V1 UUIDs (time-ordered). This will help to reliably resolve conflicts in draw order of overlapping doodads (newest added to level wins). * Link Tool: clicking on a pair of already-linked doodads will now unlink them, so you don't have to delete one to delete the link. * Actor Tool: deleting an actor immediately calls PruneLinks() to clean up any links that the deleted doodad might have.
2021-08-12 03:40:31 +00:00
X: 60,
Touch Screen Controls for Play Mode! The game can now be played using only a touch screen! The left mouse click (Button1) can now move and control the player character. * A box in the very middle of the screen is the "Use" button and a deadzone for directional inputs. * Anywhere outside the middle and to the left registers a Left button, to the right a Right button, above the top of the middle is a Jump button, and below the bottom of the middle is a down input (for antigravity mode). * Tight platforming is possible: above and below the middle box, the left/right split is tight in the middle of the window. You can get tight jumps if jumping or go below if you don't want to jump. The left/right deadzone is only over the space of the Use button. If the player is idle for a while with no controller inputs, some hints will fade in about the touch controls. Note: the ScrollboxOffset to track the player character is changed to 60,60 from 60,100 so the camera will track tighter to the player and so the player will mostly be over the Use button on touch controls as long as he's away from a level boundary.
2021-10-05 02:51:31 +00:00
Y: 60,
Fix Scroll-Follow-Actor Behavior * The scrollbox by which the game follows the player character has been revised, it is now an offset away from the window's center instead of fixed pixel distances from the window's edges. * Mobile form-factor (Pinephone) now scrolls OK instead of jerking back and forth rapidly when moving left.
2021-06-14 03:25:42 +00:00
}
Improvements to the Debug Overlay Feature * Scenes can insert custom key/value labels to the debug overlay and track string variables in real time * Added ability to unthrottle FPS in main loop
2019-04-10 01:28:08 +00:00
// Player speeds
Async Giant Screenshot, Player Physics and UI Polish * The "Giant Screenshot" feature takes a very long time, so it is made asynchronous. If you try and run a second one while the first is busy, you get an error flash. You can continue editing the level, even playtest it, or load a different level, and it will continue crunching on the Giant Screenshot and flash when it's finished. * Updated the player physics to use proper Velocity to jump off the ground rather than the hacky timer-based fixed speed approach. * FlashError() function to flash "error level" messages to the screen. They appear in orange text instead of the usual blue, and most error messages in the game use this now. The dev console "error <msg>" command can simulate an error message. * Flashed message fonts are updated. The blue font now uses softer stroke and shadow colors and the same algorithm applies to the orange error flashes. Some other changes to player physics: * Max velocity, acceleration speed, and gravity have been tweaked. * Fast turn-around if you are moving right and then need to go left. Your velocity resets to zero at the transition so you quickly get going the way you want to go. Some levels that need a bit of love for the new platforming physics: * Tutorial 3.level
2021-10-08 01:24:18 +00:00
PlayerMaxVelocity float64 = 7
Various minor tweaks and changes * Recolor some of the region doodads * Add command: `doodad edit-level --remove-actor` to remove actors from your level. * Tweak the player jump velocity from playtesting levels.
2021-10-08 03:50:24 +00:00
PlayerJumpVelocity float64 = -23
Async Giant Screenshot, Player Physics and UI Polish * The "Giant Screenshot" feature takes a very long time, so it is made asynchronous. If you try and run a second one while the first is busy, you get an error flash. You can continue editing the level, even playtest it, or load a different level, and it will continue crunching on the Giant Screenshot and flash when it's finished. * Updated the player physics to use proper Velocity to jump off the ground rather than the hacky timer-based fixed speed approach. * FlashError() function to flash "error level" messages to the screen. They appear in orange text instead of the usual blue, and most error messages in the game use this now. The dev console "error <msg>" command can simulate an error message. * Flashed message fonts are updated. The blue font now uses softer stroke and shadow colors and the same algorithm applies to the orange error flashes. Some other changes to player physics: * Max velocity, acceleration speed, and gravity have been tweaked. * Fast turn-around if you are moving right and then need to go left. Your velocity resets to zero at the transition so you quickly get going the way you want to go. Some levels that need a bit of love for the new platforming physics: * Tutorial 3.level
2021-10-08 01:24:18 +00:00
PlayerAcceleration float64 = 0.12
Adjust Gravity and Prevent Moonwalking * Tweak max gravity speed to match player max velocity. * Boy's script watches for his velocity to flip suddenly and stops animations, limiting the moonwalking a bit. * JS API: Self.GetVelocity() added.
2021-10-08 01:49:09 +00:00
Gravity float64 = 7
Async Giant Screenshot, Player Physics and UI Polish * The "Giant Screenshot" feature takes a very long time, so it is made asynchronous. If you try and run a second one while the first is busy, you get an error flash. You can continue editing the level, even playtest it, or load a different level, and it will continue crunching on the Giant Screenshot and flash when it's finished. * Updated the player physics to use proper Velocity to jump off the ground rather than the hacky timer-based fixed speed approach. * FlashError() function to flash "error level" messages to the screen. They appear in orange text instead of the usual blue, and most error messages in the game use this now. The dev console "error <msg>" command can simulate an error message. * Flashed message fonts are updated. The blue font now uses softer stroke and shadow colors and the same algorithm applies to the orange error flashes. Some other changes to player physics: * Max velocity, acceleration speed, and gravity have been tweaked. * Fast turn-around if you are moving right and then need to go left. Your velocity resets to zero at the transition so you quickly get going the way you want to go. Some levels that need a bit of love for the new platforming physics: * Tutorial 3.level
2021-10-08 01:24:18 +00:00
GravityAcceleration float64 = 0.1
Embeddable Doodads In Levels * The Publisher is all hooked up. No native Save File dialogs yet, so uses the dev shell Prompt() to ask for output filename. * Custom-only or builtin doodads too can be stored in the level's file data, at "assets/doodads/*.doodad" * When loading the embedded level in the Editor: it gets its custom doodads out of its file, and you can drag and drop them elsehwere, link them, Play Mode can use them, etc. but they won't appear in the Doodad Dropper if they are not installed in your local doodads directory. * Fleshed out serialization API for the Doodad files: - LoadFromEmbeddable() looks to load a doodad from embeddable file data in addition to the usual places. - Serialize() returns the doodad in bytes, for easy access to embed into level data. - Deserialize() to parse and return from bytes. * When loading a level that references doodads not found in its embedded data or the filesystem: an Alert modal appears listing the missing doodads. The rest of the level loads fine, but the actors referenced by these doodads don't load.
2021-06-13 21:53:21 +00:00
SlopeMaxHeight = 8 // max pixel height for player to walk up a slope
Improvements to the Debug Overlay Feature * Scenes can insert custom key/value labels to the debug overlay and track string variables in real time * Added ability to unthrottle FPS in main loop
2019-04-10 01:28:08 +00:00
Implement Chunk System for Pixel Data Starts the implementation of the chunk-based pixel storage system for levels and drawings. Previously the levels had a Pixels structure which was just an array of X,Y and palette index triplets. The new chunk system divides the map up into square chunks, and lets each chunk manage its own memory layout. The "MapAccessor" layout is implemented first which is a map of X,Y coordinates to their Swatches (pointer to an index of the palette). When serialized the MapAccessor maps the "X,Y": "index" similarly to the old Pixels array. The object hierarchy for the chunk system is like: * Chunker: the manager of the chunks who keeps track of the ChunkSize and a map of "chunk coordinates" to the chunk in charge of it. * Chunk: a part of the drawing ChunkSize length square. A chunk has a Type (of how it stores its data, 0 being a map[Point]Swatch and 1 being a [][]Swatch 2D array), and the chunk has an Accessor which implements the underlying type. * Accessor: an interface for a Chunk to provide access to its pixels. * MapAccessor: a "sparse map" of coordinates to their Swatches. * GridAccessor: TBD, will be a "dense" 2D grid of Swatches. The JSON files are loaded in two passes: 1. The chunks only load their swatch indexes from disk. 2. With the palette also loaded, the chunks are "inflated" and linked to their swatch pointers. Misc changes: * The `level.Canvas` UI widget switches from the old Grid data type to being able to directly use a `level.Chunker` * The Chunker is a shared data type between the on-disk level format and the actual renderer (level.Canvas), so saving the level is easy because you can just pull the Chunker out from the canvas. * ChunkSize is stored inside the level file and the default value is at balance/numbers.go: 1000
2018-09-23 22:20:45 +00:00
// Default chunk size for canvases.
WIP Finishing Up Texture Caching System Apart from putting the cached bitmaps in a better place, this about finishes up the texture caching optimization and IT IS FAST! When I spam drag a lot of pixels around the FPS may drop to the 40's but once the caches are warmed up the FPS returns to 60 and stays there, even if the screen is very busy with pixels. An undocumented debug feature: set the environment variable DEBUG_CHUNK_COLOR='#00FFFF' to set a bitmap background color besides white to be used when caching the chunks. It helps to visualize where on the screen the bitmaps are being used. May go away in the future. Changes: - Found that the old default chunk size of 1000 was slow to generate bitmap images to cache. The 100px test size was fast and 128 sounds like a good middle ground number to pick for now. - Fixed all the problems with scroll behavior and offset by inverting the sign of the scroll behavior. Scrolling to the Right and Down actually subtracts X,Y values instead of adds them.
2018-10-18 06:01:21 +00:00
ChunkSize = 128
Doodad Edit Mode: Saving and Loading From Disk Adds the first features to Edit Mode to support creation of Doodad files! The "New Doodad" button pops up a prompt for a Doodad size (default 100px) and configures the Canvas widget and makes a Doodad struct instead of a Level to manage. * Move the custom Canvas widget from `level.Canvas` to `uix.Canvas` (the uix package is for our custom UI widgets now) * Rename the `doodads.Doodad` interface (for runtime instances of Doodads) to `doodads.Actor` and make `doodads.Doodad` describe the file format and JSON schema instead. * Rename the `EditLevel()` method to `EditDrawing()` and it inspects the file extension to know whether to launch the Edit Mode for a Level or for a Doodad drawing. * Doodads can be edited by using the `-edit` CLI flag or using the in-game file open features (including `edit` command of dev console). * Add a `Scrollable` boolean to uix.Canvas to restrict the keyboard being able to scroll the level, for editing Doodads which have a fixed size.
2018-09-26 17:04:46 +00:00
// Default size for a new Doodad.
DoodadSize = 100
Drawing Strokes and Undo/Redo Functionality * Add new pkg/drawtool with utilities to abstract away drawing actions into Strokes and track undo/redo History for them. * The freehand Pencil tool in EditorMode has been refactored to create a Stroke of Shape=Freehand and queue up its world pixels there instead of directly modifying the level chunker in real time. When the mouse button is released, the freehand Stroke is committed to the level chunker and added to the UndoHistory. * UndoHistory is (temporarily) stored with the level.Level so it can survive trips to PlayScene and back, but is not stored as JSON on disk. * Ctrl-Z and Ctrl-Y in EditorMode for undo and redo, respectively.
2019-07-03 23:22:30 +00:00
// Size of Undo/Redo history for map editor.
UndoHistory = 20
Eraser Tool, Brush Sizes * Implement Brush Sizes for drawtool.Stroke and add a UI to the tools panel to control the brush size. * Brush sizes: 1, 2, 4, 8, 16, 24, 32, 48, 64 * Add the Eraser Tool to editor mode. It uses a default brush size of 16 and a max size of 32 due to some performance issues. * The Undo/Redo system now remembers the original color of pixels when you change them, so that Undo will set them back how they were instead of deleting the pixel entirely. Due to performance issues, this only happens when your Brush Size is 0 (drawing single-pixel shapes). * UI: Add an IntVariable option to ui.Label to bind showing the value of an int reference. Aforementioned performance issues: * When we try to remember whole rects of pixels for drawing thick shapes, it requires a ton of scanning for each step of the shape. Even de-duplicating pixel checks, tons of extra reads are constantly checked. * The Eraser is the only tool that absolutely needs to be able to remember wiped pixels AND have large brush sizes. The performance sucks and lags a bit if you erase a lot all at once, but it's a trade-off for now. * So pixels aren't remembered when drawing lines in your level with thick brushes, so the Undo action will simply delete your pixels and not reset them. Only the Eraser can bring back pixels.
2019-07-12 02:07:46 +00:00
// Options for brush size.
BrushSizeOptions = []int{
0,
1,
2,
4,
8,
16,
24,
32,
48,
64,
}
DefaultEraserBrushSize = 8
MaxEraserBrushSize = 32 // the bigger, the slower
Add Player Character Sprites * Added initial walking sprites for the player character, "Boy." * Player doodad filename and title screen level are now configurable in the balance/numbers.go package.
2020-09-19 05:35:43 +00:00
Spit and polish * New doodad: Invisible Warp Door * All warp doors require the player to be grounded (if affected by gravity) to open them. No jumping or falling thru and opening a warp door mid-air! * Title Screen now randomly selects from a couple of levels. * Title Screen: if it fails to load a level it sets up a basic blank level with a wallpaper instead. * New developer shell command: titlescreen <level> Opens the MainScene with a custom user level as the background. * Add Auto-save to the Editor to save your drawing every 5 minutes * Add a MenuBar to the Play Scene for easier navigation to other features of the game. * Doodad JS API: time.Since() now available.
2022-01-03 06:36:32 +00:00
// Interval for auto-save in the editor
AutoSaveInterval = 5 * time.Minute
Add Player Character Sprites * Added initial walking sprites for the player character, "Boy." * Player doodad filename and title screen level are now configurable in the balance/numbers.go package.
2020-09-19 05:35:43 +00:00
// Default player character doodad in Play Mode.
PlayerCharacterDoodad = "boy.doodad"
Spit and polish * New doodad: Invisible Warp Door * All warp doors require the player to be grounded (if affected by gravity) to open them. No jumping or falling thru and opening a warp door mid-air! * Title Screen now randomly selects from a couple of levels. * Title Screen: if it fails to load a level it sets up a basic blank level with a wallpaper instead. * New developer shell command: titlescreen <level> Opens the MainScene with a custom user level as the background. * Add Auto-save to the Editor to save your drawing every 5 minutes * Add a MenuBar to the Play Scene for easier navigation to other features of the game. * Doodad JS API: time.Since() now available.
2022-01-03 06:36:32 +00:00
// Level names for the title screen.
DemoLevelName = []string{
"Tutorial 1.level",
"Tutorial 2.level",
"Tutorial 3.level",
}
Custom Wallpapers for Levels * You can now browse for a custom wallpaper image to use with your levels. A platform-native file picker dialog is used (no WASM support) * In the New/Edit Level Properties dialog, the Wallpaper drop-down includes an option to browse for a custom map. * When editing an existing level: the wallpaper takes effect immediately in your level once the file is picked. For NEW levels, the wallpaper will appear once the "Continue" button is pressed. * All common image types supported: png, jpeg, gif. * The wallpaper is embedded in the level using the filepath "assets/wallpapers/custom.b64img" as a Base64-encoded blob of the image data. * The `doodad show` command will list the names and sizes of files embedded in levels. `doodad show --attachment <name>` will get an attachment and print it to the console window. * To extract a wallpaper image from a level: `doodad show -a assets/wallpapers/custom.b64img | base64 -d > out.png`
2021-06-07 01:59:04 +00:00
// Level attachment filename for the custom wallpaper.
// NOTE: due to hard-coded "assets/wallpapers/" prefix in uix/canvas.go#LoadLevel.
Embeddable Doodads In Levels * The Publisher is all hooked up. No native Save File dialogs yet, so uses the dev shell Prompt() to ask for output filename. * Custom-only or builtin doodads too can be stored in the level's file data, at "assets/doodads/*.doodad" * When loading the embedded level in the Editor: it gets its custom doodads out of its file, and you can drag and drop them elsehwere, link them, Play Mode can use them, etc. but they won't appear in the Doodad Dropper if they are not installed in your local doodads directory. * Fleshed out serialization API for the Doodad files: - LoadFromEmbeddable() looks to load a doodad from embeddable file data in addition to the usual places. - Serialize() returns the doodad in bytes, for easy access to embed into level data. - Deserialize() to parse and return from bytes. * When loading a level that references doodads not found in its embedded data or the filesystem: an Alert modal appears listing the missing doodads. The rest of the level loads fine, but the actors referenced by these doodads don't load.
2021-06-13 21:53:21 +00:00
CustomWallpaperFilename = "custom.b64img"
Custom Wallpapers for Levels * You can now browse for a custom wallpaper image to use with your levels. A platform-native file picker dialog is used (no WASM support) * In the New/Edit Level Properties dialog, the Wallpaper drop-down includes an option to browse for a custom map. * When editing an existing level: the wallpaper takes effect immediately in your level once the file is picked. For NEW levels, the wallpaper will appear once the "Continue" button is pressed. * All common image types supported: png, jpeg, gif. * The wallpaper is embedded in the level using the filepath "assets/wallpapers/custom.b64img" as a Base64-encoded blob of the image data. * The `doodad show` command will list the names and sizes of files embedded in levels. `doodad show --attachment <name>` will get an attachment and print it to the console window. * To extract a wallpaper image from a level: `doodad show -a assets/wallpapers/custom.b64img | base64 -d > out.png`
2021-06-07 01:59:04 +00:00
CustomWallpaperEmbedPath = "assets/wallpapers/custom.b64img"
Embeddable Doodads In Levels * The Publisher is all hooked up. No native Save File dialogs yet, so uses the dev shell Prompt() to ask for output filename. * Custom-only or builtin doodads too can be stored in the level's file data, at "assets/doodads/*.doodad" * When loading the embedded level in the Editor: it gets its custom doodads out of its file, and you can drag and drop them elsehwere, link them, Play Mode can use them, etc. but they won't appear in the Doodad Dropper if they are not installed in your local doodads directory. * Fleshed out serialization API for the Doodad files: - LoadFromEmbeddable() looks to load a doodad from embeddable file data in addition to the usual places. - Serialize() returns the doodad in bytes, for easy access to embed into level data. - Deserialize() to parse and return from bytes. * When loading a level that references doodads not found in its embedded data or the filesystem: an Alert modal appears listing the missing doodads. The rest of the level loads fine, but the actors referenced by these doodads don't load.
2021-06-13 21:53:21 +00:00
// Publishing: Doodads-embedded-within-levels.
EmbeddedDoodadsBasePath = "assets/doodads/"
EmbeddedWallpaperBasePath = "assets/wallpapers/"
Gzip Compression for Levels and Doodads * Levels and Doodad files will be written in gzip-compressed JSON format * `boolProp compress-drawings false` to disable compression and save as classic JSON format directly * The game can still read uncompressed JSON files The file size savings on some built-in assets: * Tutorial 2.level: 2.2M -> 414K (82% smaller) * warp-door-orange.doodad: 105K -> 17K (84% smaller)
2021-07-14 02:23:09 +00:00
// File formats: save new levels and doodads gzip compressed
CompressDrawings = true
Touch Screen Controls for Play Mode! The game can now be played using only a touch screen! The left mouse click (Button1) can now move and control the player character. * A box in the very middle of the screen is the "Use" button and a deadzone for directional inputs. * Anywhere outside the middle and to the left registers a Left button, to the right a Right button, above the top of the middle is a Jump button, and below the bottom of the middle is a down input (for antigravity mode). * Tight platforming is possible: above and below the middle box, the left/right split is tight in the middle of the window. You can get tight jumps if jumping or go below if you don't want to jump. The left/right deadzone is only over the space of the Use button. If the player is idle for a while with no controller inputs, some hints will fade in about the touch controls. Note: the ScrollboxOffset to track the player character is changed to 60,60 from 60,100 so the camera will track tighter to the player and so the player will mostly be over the Use button on touch controls as long as he's away from a level boundary.
2021-10-05 02:51:31 +00:00
// Play Mode Touchscreen controls.
PlayModeIdleTimeout = 2200 * time.Millisecond
PlayModeAlphaStep = 8 // 0-255 alpha, steps per tick for fade in
PlayModeAlphaMax = 220
Abstract Drawing Canvas into Reusable Widget The `level.Canvas` is a widget that holds onto its Palette and Grid and has interactions to allow scrolling and editing the grid using the swatches available on the palette. Thus all of the logic in the Editor Mode for drawing directly onto the root SDL surface are now handled inside a level.Canvas instance. The `level.Canvas` widget has the following properties: * Like any widget it has an X,Y position and a width/height. * It has a Scroll position to control which slice of its drawing will be visible inside its bounding box. * It supports levels having negative coordinates for their pixels. It doesn't care. The default Scroll position is (0,0) at the top left corner of the widget but you can scroll into the negatives and see the negative pixels. * Keyboard keys will scroll the viewport inside the canvas. * The canvas draws only the pixels that are visible inside its bounding box. This feature will eventually pave the way toward: * Doodads being dropped on top of your map, each Doodad being its own Canvas widget. * Using drawings as button icons for the user interface, as the Canvas is a normal widget.
2018-08-17 03:37:19 +00:00
)
Drag Doodads Onto Levels in Edit Mode Add the ability to drag and drop Doodads onto the level. The Doodad buttons on the palette now trigger a Drag/Drop behavior when clicked, and a "blueprint colored" version of the Doodad follows your cursor, centered on it. Actors are assigned a random UUID ID when they are placed into a level. The Canvas gained a MaskColor property that forces all pixels in the drawing to render as the same color. This is a visual-only effect, and is used when dragging Doodads in so they render as "blueprints" instead of their actual colors until they are dropped. Fix the chunk bitmap cache system so it saves in the $XDG_CACHE_FOLDER instead of /tmp and has better names. They go into `~/.config/doodle/chunks/` and have UUID file names -- but they disappear quickly! As soon as they are cached into SDL2 they are removed from disk. Other changes: - UI: Add Hovering() method that returns the widgets that are beneath a point (your cursor) and those that are not, for easy querying for event propagation. - UI: Add ability to return an ErrStopPropagation to tell the master Scene (outside the UI) not to continue sending events to other parts of the code, so that you don't draw pixels during a drag event.
2018-10-20 22:42:49 +00:00
// Edit Mode Values
var (
// Number of Doodads per row in the palette.
UIDoodadsPerRow = 2
)
Reference in New Issue Copy Permalink