321 lines
14 KiB
Markdown
321 lines
14 KiB
Markdown
---
|
|
title: "Frequently Asked Questions"
|
|
draft: false
|
|
toc: true
|
|
---
|
|
About Sketchy Maze.
|
|
|
|
# General
|
|
|
|
## What is _Sketchy Maze?_
|
|
|
|
It is a "drawing-based maze game" themed around hand-drawn maps on paper.
|
|
It's one part 'yet another 2D platformer game', one part 'Mario Maker but you can
|
|
make whatever you want', and part educational game in that it might help teach
|
|
someone to code so they can program their own custom doodads.
|
|
|
|
With Sketchy Maze, you can draw your own levels and then play them as a
|
|
side-scrolling platformer game. You can draw maps freehand or with some basic
|
|
drawing tools (like rectangles and ellipses), specify which color lines are
|
|
"solid" and which behave like "fire" or "water," and then drag and drop various
|
|
"doodads" such as buttons and doors onto your map to add some interactive elements.
|
|
|
|
If you're not much of a level designer, fear not! The game will also feature some
|
|
built-in levels that you can play and get some inspiration from. You will
|
|
also be able to play custom maps created by others, possibly with custom
|
|
doodads included in them depending on your version of the game.
|
|
|
|
## What devices can I play it on?
|
|
|
|
_Sketchy Maze_ is first and foremost a videogame for **desktop operating systems.**
|
|
It should run on any GNU/Linux, Microsoft Windows or Apple macOS computer.
|
|
|
|
I currently package releases of the game for:
|
|
|
|
* **Windows** (64-bit and 32-bit)
|
|
* **Mac OS** (Intel 64-bit only for now!)
|
|
* **GNU/Linux**
|
|
* x86_64, i386, and aarch64 release on Fedora-likes (.rpm) and Debian-likes (.deb) and .tar.gz
|
|
* x86_64 and aarch64 Flatpak packages.
|
|
* Works on Linux smartphones like the Pinephone and Librem 5!
|
|
|
|
Some places I could see it going in the future:
|
|
|
|
* **Android:** I saw an [example app](https://github.com/veandco/go-sdl2-examples/tree/master/examples/android)
|
|
how to run a Go SDL2 program like mine on Android but its documentation seems outdated and I haven't
|
|
figured it out yet. I'm using my Pinephone to plan a mobile/touch friendly UI but Android is a
|
|
likely target at some point.
|
|
* The **[Steam Deck](https://store.steampowered.com/steamdeck/):** for _Sketchy Maze_ I just need joypad
|
|
controls so you can navigate the UI and play the game without a mouse or keyboard, and this
|
|
Nintendo Switch-like device would be an amazing host to my game!
|
|
|
|
## What are "doodads?"
|
|
|
|
Doodads are the dynamic objects you drag and drop into your level to make
|
|
it "do" things. They are the Buttons, Switches, Trapdoors, and other traps
|
|
and hazards to create puzzles and perilous platforming sections of your
|
|
level.
|
|
|
|
The game ships with a handful of [built-in doodads](/guidebook/doodads.html)
|
|
and players may also create their own, and program their behavior using
|
|
JavaScript.
|
|
|
|
## Do I need to learn how to program?
|
|
|
|
Nope! You can just draw some levels and use pre-made doodads in them. The "1.0"
|
|
version of the game is expected to include a proper set of single player levels
|
|
that can simply be _played_ so you don't even need to draw your own level if
|
|
you're not feeling creative.
|
|
|
|
You can also create some useful custom doodads in-game by selecting from a
|
|
"generic script" to drive its behavior. For example, you could draw a "spikes"
|
|
doodad and choose the "Generic Fire" script and it will act as a hazard to
|
|
the player in-game: "Watch out for spikes!"
|
|
|
|
You can use these generic scripts as a base and program your own logic and
|
|
behavior in JavaScript. There are some
|
|
[full example doodads](https://code.sketchymaze.com/declassified/doodads)
|
|
that you can learn from as well for creating your own custom Warp Doors
|
|
or playable characters.
|
|
|
|
## The user interface is ugly!
|
|
|
|
I find the "Windows 95" look charming.
|
|
|
|
Along with this game I'm also developing my own user interface toolkit from
|
|
scratch, with a simple API inspired by the [Tk toolkit](https://www.tcl.tk/).
|
|
It happens that the "Windows 95" look is easy to draw programmatically, as
|
|
a button is just a few rectangles overlapped to draw shadows and highlights.
|
|
|
|
The user interface toolkit is released as a
|
|
[free and open source](#is-this-game-open-source) module that other Go
|
|
developers can use to draw buttons, menus and other UI controls into a
|
|
graphical application. One day, the UI toolkit will support fancy theming
|
|
of widgets, and _Sketchy Maze_ will very easily look better (or have
|
|
user-configurable themes available to choose from).
|
|
|
|
---
|
|
|
|
# Known Issues
|
|
|
|
While the game is still in beta, it's bound to have some bugs. Tell me about
|
|
any you find at <a href="mailto:support@sketchymaze.com">support@sketchymaze.com</a>.
|
|
|
|
Some current known issues and work-arounds are as follows:
|
|
|
|
## Zoom in/out bugs
|
|
|
|
If you draw onto your level while zoomed in or out, the pixels that get committed
|
|
to the level may be offset from where the preview was on-screen. Draw some test
|
|
lines to find out the offset or else avoid drawing while zoomed. The 1 (one) key
|
|
restores the zoom level to default 100%.
|
|
|
|
## Player shouldn't be able to climb walls
|
|
|
|
There is currently a bug where holding the Jump button allows the player to climb
|
|
walls to their right (but not to their left). This is not intended behavior and
|
|
will be fixed eventually. For a work-around, draw overhangs at the tops of walls
|
|
that you don't want the player to climb over. Levels that rely on the climbing
|
|
behavior will break in future versions of the game.
|
|
|
|
# Pricing and Distribution
|
|
|
|
## Is this game free?
|
|
|
|
Yes!
|
|
|
|
While the game is in beta, all releases are **100% free and fully functional.**
|
|
|
|
After the game reaches "1.0" it will have a free version and a paid one
|
|
which unlocks additional modding capabilities, like the ability to embed
|
|
custom doodads in your levels. I like Minecraft's model of "buy the game
|
|
once, free updates forever" and will do similar.
|
|
|
|
The full version would mainly add quality-of-life improvements supporting
|
|
custom user content, such as the ability to play a custom level which
|
|
_comes with_ all of its custom doodads, wallpaper, and other assets
|
|
embedded directly inside the level file.
|
|
|
|
The free versions of the game would include:
|
|
|
|
* One chapter of built-in single player levels.
|
|
* The level editor where you can create and share your own custom maps, using
|
|
the [built-in doodads](/guidebook/doodads.html) that the game shipped with.
|
|
You can also play levels created by other players as long as they use the
|
|
built-in doodads only, or uses custom doodads the player has installed
|
|
locally.
|
|
|
|
Paid versions of the game will include _additional_ features such as:
|
|
|
|
* Additional chapters of built-in single player levels.
|
|
* Better support for **custom doodads**: when sharing your level with others,
|
|
you may embed all custom doodads _inside_ of the level so that it can be
|
|
easily played on a different computer, and the ability to play such
|
|
levels (the free version won't use embedded custom doodads).
|
|
* Possibly some access to online account features (in-game UI to share and
|
|
download levels and doodads made by others, etc.)
|
|
|
|
It is expected that the full set of built-in doodads will be equally available
|
|
in free versions of the game. And these doodads should be varied and featureful
|
|
enough to create all sorts of custom and creative levels, which can be shared
|
|
with other players.
|
|
|
|
## Will the game feature any form of Digital Rights Management (DRM)?
|
|
|
|
I hate DRM, so I don't expect so.
|
|
|
|
Likely, the same program .exe will use "free version" features by default
|
|
until registered as a paid version, with any of these options:
|
|
|
|
* With a license key file for offline activation.
|
|
* If it gets online services, by logging into an account associated with your
|
|
purchased copy of the game (provable by the license key file).
|
|
* If released on Steam or other managed store, a check with the store's API
|
|
following their standard procedure.
|
|
|
|
But the plan is that the "license key file for offline activation" _always_
|
|
be available. You get a proof file that you can keep forever and any version
|
|
of the game that accepted it before will always do so. That way even if I got
|
|
hit by a bus or you lost your Steam account, the game can still be played to
|
|
its full potential.
|
|
|
|
## What about piracy?
|
|
|
|
When I start to discover license keys which have leaked online to game piracy
|
|
websites, _future_ releases of Sketchy Maze will begin to include license
|
|
revocation lists and will cease honoring the compromised license key.
|
|
|
|
The compromised license key would still work on all _older_ versions of the game,
|
|
but would be barred from newer releases; and while the game is still being
|
|
actively worked on and gaining new features, these leaked keys would become less
|
|
interesting over time, as custom user content made for newer versions of the game
|
|
would become incompatible with the older versions.
|
|
|
|
If the game gets online services in the future (e.g. for seamless in-game
|
|
sharing of custom levels and doodads), players would need a valid signed
|
|
license key to log on and these leaked keys would be excluded.
|
|
|
|
---
|
|
|
|
# Level Creators
|
|
|
|
## Future planned features vs. levels created today
|
|
|
|
While in beta, this game is sort of evolving as it goes and some features added
|
|
later may break or affect custom levels created today. As a general rule of
|
|
thumb: the game's built-in levels are expected to _mostly_ keep working as the
|
|
game is developed further as I don't want to create too much more work for
|
|
myself revisiting old levels to fix them up.
|
|
|
|
Here are a few current quirks in the game and how they're going to be handled
|
|
in the future:
|
|
|
|
### Enemy mobs being invulnerable to fire pixels
|
|
|
|
Currently, fire pixels only kill the player character but enemy mobs can walk
|
|
through them unscathed.
|
|
|
|
Eventually, fire pixels will be able to destroy enemy mobs and the mobs will
|
|
_try_ and avoid walking into fire but if they fall into it on accident they'll
|
|
be destroyed.
|
|
|
|
Planned feature: a "Fireproof Mobs" Game Rule, so existing maps that have lava
|
|
pits and dumb mobs (like Azulian Tag, where the Azulians chase the player to
|
|
Hell and back) will be able to gain backwards compatibility by toggling a
|
|
game rule on.
|
|
|
|
### Jump height and reach
|
|
|
|
The platforming physics and player controls may be tweaked still but generally
|
|
the player's jump height and reach will be kept close to its current state.
|
|
Use the built-in levels for inspiration.
|
|
|
|
### Multiplayer features
|
|
|
|
The game may eventually have multiplayer features where you can design a map
|
|
meant to be played by two or more players. Doodad Script functions such as
|
|
`Actors.FindPlayer()` will operate on the _nearest_ player character and try
|
|
and maintain backwards compatibility for maps made today.
|
|
|
|
### Player is not meant to climb walls
|
|
|
|
See [above](#player-shouldnt-be-able-to-climb-walls). Currently there is a bug
|
|
where the player can climb some vertical walls. Built-in levels avoid the issue
|
|
by drawing overhangs at the tops of walls or slant the wall back towards the
|
|
player. Do not rely on the ability to climb walls for custom levels - they will
|
|
break on a future update.
|
|
|
|
---
|
|
|
|
# Technicals
|
|
|
|
## What is this game built with?
|
|
|
|
_Sketchy Maze_ runs on a custom game engine, built from the ground up, in the
|
|
[Go](https://golang.org) programming language using [SDL2](https://www.libsdl.org/) for graphics via [veandco/go-sdl2](https://github.com/veandco/go-sdl2) bindings for Go.
|
|
|
|
While the game itself is not open source, some of its critical components are released as free and open source projects that other developers can use in their projects.
|
|
|
|
## Is this game open source?
|
|
|
|
Parts of it are!
|
|
|
|
_Sketchy Maze_ was built from the ground up using little more than
|
|
[SDL2](https://www.libsdl.org/) which lets you plot pixels on a screen. While
|
|
I was designing the game, I thought it'd be a good idea to write an abstraction
|
|
layer between low-level SDL2 functions and give me a clean, Go-like API to work
|
|
with that keeps my code from either _depending_ too much on SDL or for my Go
|
|
code to be written too C-like to work with it.
|
|
|
|
So I built my own [render](https://git.kirsle.net/go/render) library that
|
|
abstracts around SDL2 for desktops and HTML5 Canvas elements for WebAssembly,
|
|
and my game needed UI buttons so I wrote a [UI toolkit](https://git.kirsle.net/go/ui)
|
|
which provides Labels, Buttons, Menus, Windows, and all sorts of useful widgets
|
|
to draw my user interface with. The render engine can be extended to target
|
|
other APIs, such as OpenGL or Vulkan, in the future as needs arise.
|
|
|
|
Here are a list of open source projects created **as a part of** development of
|
|
_Sketchy Maze_ which should be generally useful to any Go developers for making
|
|
some simple graphical applications.
|
|
|
|
* [go/render](https://git.kirsle.net/go/render): Render engine supporting SDL2
|
|
(native apps) and HTML Canvas (WebAssembly) targets.
|
|
* [go/ui](https://git.kirsle.net/go/ui): Go UI toolkit for adding labels, buttons,
|
|
windows, menus, and more widgets and arranging them sanely in frames with an
|
|
API like Tcl/Tk. It uses go/render so can also target WebAssembly.
|
|
* [go/audio](https://git.kirsle.net/go/audio): Simple audio abstraction which can load and play music or sound effects, currently only SDL2 supported.
|
|
|
|
GitHub mirrors of the above:
|
|
|
|
* [go/render](https://github.com/kirsle/render)
|
|
* [go/ui](https://github.com/kirsle/ui)
|
|
|
|
Also this website, the user guidebook, and other things with the game are
|
|
readable as open source code, at https://code.sketchymaze.com/
|
|
|
|
## Wait, does _Sketchy Maze_ have a WebAssembly port?
|
|
|
|
Sure does! But performance isn't great yet, and I'm not sure whether WebAssembly
|
|
support in web browsers needs to get better or if I need to tighten up my code.
|
|
There _is_ a lot of room for optimization in my UI toolkit, to minimize the number
|
|
of draw calls per tick.
|
|
|
|
One day I might have a "demo this game right in your web browser" feature with a
|
|
(probably stripped-down) version of the game built for WebAssembly. So far, though,
|
|
it just freezes web browsers frequently and I'm not letting you see it yet.
|
|
|
|
## Is it coming to Android or iOS?
|
|
|
|
These are relatively low on the priority list; maybe after the 1.0 release is
|
|
feature-complete I'll work on making the game work on mobile phones.
|
|
|
|
Already the game _sort of_ functions on GNU/Linux smartphones such as the
|
|
Pinephone. This phone has a 720x1280 pixel display and _most_ of the UI buttons
|
|
are usable in the level editor, doodads can be dragged onto levels, etc.; its
|
|
current biggest issue is with the on-screen keyboard app not being able to press
|
|
two keys simultaneously (like to move and jump at the same time).
|
|
|
|
An Android port would likely be the first one _after_ testing on the Pinephone
|
|
to get a touch-friendly user interface going. This game mainly just uses SDL2
|
|
which is good for portability!
|