-
Notifications
You must be signed in to change notification settings - Fork 0
Improving on sid
This is a very rough draft plan for a shiny new version of Sleep Is Death. It will probably come to nothing and is to be considered as a thought experiment for the foreseeable future, rather than something that will ever come to fruition.
Sleep is Death is a game of great ideas and average implementation. We’ve learned a lot of what is great and terrible in using Jason Rohrer’s experimental Sleep Is Death, but hopefully it is only the first step towards a greater game.
Sleep Is Death clearly had a lot of fundamental design ideals. Some it managed to follow, but others it didn’t quite live up to.
- Interface should be as simple as it possibly can be.
- The controller interface should be both powerful enough to create interesting stories and streamlined enough to make real-time changes.
- Anyone should have the potential to be a controller; no specialist knowledge or skills should be required.
- SiD should not dictate the type of game to be played.
- The game should be playable at 640×480 resolution.
- Increase the number of hot-keys for actions, as well as allowing them to be user-defined.
- Allow wide-screen users to have a larger, perhaps more detailed, interface.
- Action label less limited (e.g. to 25 characters). I know plenty of verbs of greater than 10 letters in length!
- Perhaps use a regular OS GUI system, in part or in whole, to save having to make a bespoke GUI for everything.
- By default, place all objects on the standard 16×16 grid, but allow snap-to-grid to be turned off so that you can arbitrarily place objects. I waste a lot of time creating variations of the same object to be placed on tables or in non-repeating patterns.
- Tab to skip through each non-background object (useful particularly when in speech mode).
- Allow chess-timer style turns, rather than rigid turn time limits (as an option).
- Allow pausing of the game.
- Allow saving of a game in progress.
- Allow staggered play-by-email style of play (if not necessarily via email itself).
The resources have a number of artificial limits imposed, which makes creating, modifying and altering considerably more cumbersome than they need to be.
- Sprites of any size (e.g. 16×16, 32×32, 64×64, 128×128, 256×256. Force them to be square just to keep it simple and, if possible, make the user entirely unaware of what size the sprite is actually being stored as).
- Objects can contain objects as well as sprites (this makes managing moving/adding/removing them a lot easier).
- Any changes to resources updates all times they are used. This means you need a “copy” action, so that you can create something similar, but unconnected.
- Resource names considerably less limited (e.g. limited to 50 characters).
- Resource tags (e.g. “author: Spooner”; “type: torso”; “pack: Spooner Japan”), for improved sorting, filtering and searching.
- Import/export room/tile/sprite/object from png image. If people want to use external tools, they should be allowed to.
- Easily convert sprites to tiles and vica versa.
- Should import SiD .pak files.
- Story: A collection of scenes.
- Flip-books can be exported to YouTube as a movie.
- Flip-books contain music data, so that if reading with another copy of SiD (in the way that Flipped does) it will play.
- Player can be the host.
- Central server to remove need for either controller or player to host.
- Central server provides matchmaking.
- Spectators should be able to watch a story unfold as it is being played.
- Incorporate a simple chat system.
- Either implement in a high level OOP language (e.g. Ruby) or in a web browser (e.g. Ruby on Rails with lots of Ajax and JS).
- Use a full database (SQLite) for asset management.