{"author_link":"\/users\/triplefox","author_name":"triplefox","author_uid":"triplefox","comments":[],"epoch":1543554016,"event":"LD43","format":"md","ldjam_node_id":126685,"likes":3,"metadata":{"p_key":"122701","p_author":"triplefox","p_authorkey":"1108401","p_urlkey":"338765","p_title":"Coming in for Round 43","p_cat":"LDJam ","p_event":"LD43","p_time":"1543554016","p_likes":"3","p_comments":"0","p_status":"WAYBACK","us_key":"1108401","us_name":"triplefox","us_username":"triplefox","event_start":"1543536000","event_key":"71","event_name":"LD 43"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD43","removed_author":false},"_superparent":120415,"_trust":4,"author":108401,"body":"I had a fairly successful LD 42 - I haven't finished the game I started for that one yet, but I actually pulled it out and did a little bit of work this morning as a way of getting my brain started for the day.\n\nLast time around I did a very detailed blog with all my game making wisdom. If you'd like the short version of that, I wrote up a separate article on my personal blog that deals with the basic idea: [Coherency](http:\/\/ludamix.com\/dive\/coherency\/). The article gives you a framework for testing your game ideas(or any other creative things) before you get into the weeds of making it, and I have gotten a lot of positive feedback about it.\n\nIn my last game I used PICO-8, and had a good experience with it. But I am actually starting on my own fantasy console now, *Galapagos*. It is early enough in the going that I have nothing released and only a few locked down specs, but LD is an unmissable opportunity to give it a workout. Here's what I would call a pre-announcement announcement to give you an idea, though half of this stuff I haven't even gotten to yet or is littered across little prototypes and not in the working codebase:\n\n* Based on three broad principles to set goals and constraints: \n  * Sustainable design: what would a lasting, energy efficient console look like? How could I make it so that tooling made for the console is reusable by others?\n  * Linear paradigms: make the workflow very directed start-to-finish instead of jumping around, with visual metaphors to match, use list data structures, etc. Aim for linear expansion of game scope, instead of Moore's law doublings.\n  * Evolutionary tradeoffs - you can install \"modules\" to add a degree of customization, but instead of being able to \"max out\" the system, you have a total constraint on how many modules\/which types of modules you can use, hence the name \"Galapagos\" - explore different evolutionary tradeoffs along a spectrum.\n* Coding:\n  * Both Javascript and Web Assembly programs are supported. I haven't gotten to the latter yet.\n  * Some APIs for the requisite matrix\/vector math etc. included\n  * Various CPU, memory, and program size limits will be enforced(still unspecified) to meet the sustainability principle. Modules can be used to expand these limits.\n  * Galapagos runtime is implemented in Go, using \"raylib-go\" for most I\/O and \"beep\" for audio.\n* Graphics:\n  * Smallest mode: 480x320, 4 colors palette in classic \"amber monochrome\" style (I might add more modes with wider and smaller aspect ratios)\n  * Biggest mode: 640x480, 16 colors palette(customizable RGB; extends the 4-color default to green\/amber with some additional hues) with built-in support for color fades. A size that is comfy for 80-column coding and lets you make [PC-98 style graphics](http:\/\/www.blockfort.com\/game-lists\/pc98\/).\n  * 40 and 80 column monospace bitmap fonts using UTF-8 codepoints between 0-255, i.e. enough to edit Unicode documents while not necessarily rendering them properly.\n  * Some support for immediate mode drawing functions and common geometry operations - 2D and 3D shapes, scaled sprites, and others. More like a scenegraph than a traditional framebuffer system. (These APIs might be pushed into modules, so that you can experience more \"from scratch\" and \"weird hack\" coding.)\n* Audio:\n  * A small \"beeper\" style oscillator by default, with a few preset timbres. Spend modules to get more voices.\n  * PCM sample oscillator module so that the game can announce \"YOU WIN\" and play orchestra hits\n  * [Plaits macro-oscillator module](https:\/\/mutable-instruments.net\/modules\/plaits\/) for high fidelity and experimental sounds, voice synthesis, etc.\n  * Programmable synth envelopes, advanced modulation possibilities etc. - design still WIP\n  * Music Macro Language for small tunes and SFX, in the future most likely a music tracker\n* Tools\/Formats\/IDE:\n  * Built-in code editor and JS REPL.\n  * \"Softcard\" system that stores everything in a sectioned UTF-8 document. Cards can contain arbitrary(textual) data.\n  * Additional editors can be written as softcard programs, and broadcast their compatibility with softcard chunks for automatic usage.\n  * Softcard programs can communicate with each other with a Plan-9 style \"expose everything as files\" strategy. This will appear in visual form as a set of cards progressing left to right, with the earlier ones able to send to the later ones.\n\n![palette.png](\/\/\/raw\/177\/a1\/z\/1b06b.png)\n*palette tests*\n\n![gal40.png](\/\/\/raw\/177\/a1\/z\/1b071.png)\n*WIP 40-column font based on [Hack](https:\/\/sourcefoundry.org\/hack\/)*\n\nAnyway, what I do during LD will probably be extremely simple, more like a tech demo than a fully designed game, and only use a fraction of all these features. But it'll be good to try to get to a first release.","comments":4,"comments-timestamp":"2018-11-30T06:37:09Z","created":"2018-11-30T03:44:37Z","files":[],"files-timestamp":0,"id":126685,"love":3,"love-timestamp":"2018-11-30T10:32:31Z","meta":[],"modified":"2018-11-30T10:32:31Z","name":"Coming in for Round 43","node-timestamp":"2018-11-30T05:00:16Z","parent":126684,"parents":[1,5,9,120415,126684],"path":"\/events\/ludum-dare\/43\/vees-village\/coming-in-for-round-43","published":"2018-11-30T05:00:16Z","scope":"public","slug":"coming-in-for-round-43","subsubtype":"","subtype":"","type":"post","version":368662},"node_metadata":{"n_key":"126685","n_urlkey":"338765","n_parent":"126684","n_path":"\/events\/ludum-dare\/43\/vees-village\/coming-in-for-round-43","n_slug":"coming-in-for-round-43","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"108401","n_created":"1543549477","n_modified":"1543573951","n_version":"368662","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/43\/vees-village\/coming-in-for-round-43","text":"I had a fairly successful LD 42 - I haven't finished the game I started for that one yet, but I actually pulled it out and did a little bit of work this morning as a way of getting my brain started for the day.\n\nLast time around I did a very detailed blog with all my game making wisdom. If you'd like the short version of that, I wrote up a separate article on my personal blog that deals with the basic idea: [Coherency](http:\/\/ludamix.com\/dive\/coherency\/). The article gives you a framework for testing your game ideas(or any other creative things) before you get into the weeds of making it, and I have gotten a lot of positive feedback about it.\n\nIn my last game I used PICO-8, and had a good experience with it. But I am actually starting on my own fantasy console now, *Galapagos*. It is early enough in the going that I have nothing released and only a few locked down specs, but LD is an unmissable opportunity to give it a workout. Here's what I would call a pre-announcement announcement to give you an idea, though half of this stuff I haven't even gotten to yet or is littered across little prototypes and not in the working codebase:\n\n* Based on three broad principles to set goals and constraints: \n  * Sustainable design: what would a lasting, energy efficient console look like? How could I make it so that tooling made for the console is reusable by others?\n  * Linear paradigms: make the workflow very directed start-to-finish instead of jumping around, with visual metaphors to match, use list data structures, etc. Aim for linear expansion of game scope, instead of Moore's law doublings.\n  * Evolutionary tradeoffs - you can install \"modules\" to add a degree of customization, but instead of being able to \"max out\" the system, you have a total constraint on how many modules\/which types of modules you can use, hence the name \"Galapagos\" - explore different evolutionary tradeoffs along a spectrum.\n* Coding:\n  * Both Javascript and Web Assembly programs are supported. I haven't gotten to the latter yet.\n  * Some APIs for the requisite matrix\/vector math etc. included\n  * Various CPU, memory, and program size limits will be enforced(still unspecified) to meet the sustainability principle. Modules can be used to expand these limits.\n  * Galapagos runtime is implemented in Go, using \"raylib-go\" for most I\/O and \"beep\" for audio.\n* Graphics:\n  * Smallest mode: 480x320, 4 colors palette in classic \"amber monochrome\" style (I might add more modes with wider and smaller aspect ratios)\n  * Biggest mode: 640x480, 16 colors palette(customizable RGB; extends the 4-color default to green\/amber with some additional hues) with built-in support for color fades. A size that is comfy for 80-column coding and lets you make [PC-98 style graphics](http:\/\/www.blockfort.com\/game-lists\/pc98\/).\n  * 40 and 80 column monospace bitmap fonts using UTF-8 codepoints between 0-255, i.e. enough to edit Unicode documents while not necessarily rendering them properly.\n  * Some support for immediate mode drawing functions and common geometry operations - 2D and 3D shapes, scaled sprites, and others. More like a scenegraph than a traditional framebuffer system. (These APIs might be pushed into modules, so that you can experience more \"from scratch\" and \"weird hack\" coding.)\n* Audio:\n  * A small \"beeper\" style oscillator by default, with a few preset timbres. Spend modules to get more voices.\n  * PCM sample oscillator module so that the game can announce \"YOU WIN\" and play orchestra hits\n  * [Plaits macro-oscillator module](https:\/\/mutable-instruments.net\/modules\/plaits\/) for high fidelity and experimental sounds, voice synthesis, etc.\n  * Programmable synth envelopes, advanced modulation possibilities etc. - design still WIP\n  * Music Macro Language for small tunes and SFX, in the future most likely a music tracker\n* Tools\/Formats\/IDE:\n  * Built-in code editor and JS REPL.\n  * \"Softcard\" system that stores everything in a sectioned UTF-8 document. Cards can contain arbitrary(textual) data.\n  * Additional editors can be written as softcard programs, and broadcast their compatibility with softcard chunks for automatic usage.\n  * Softcard programs can communicate with each other with a Plan-9 style \"expose everything as files\" strategy. This will appear in visual form as a set of cards progressing left to right, with the earlier ones able to send to the later ones.\n\n![palette.png](\/\/\/raw\/177\/a1\/z\/1b06b.png)\n*palette tests*\n\n![gal40.png](\/\/\/raw\/177\/a1\/z\/1b071.png)\n*WIP 40-column font based on [Hack](https:\/\/sourcefoundry.org\/hack\/)*\n\nAnyway, what I do during LD will probably be extremely simple, more like a tech demo than a fully designed game, and only use a fraction of all these features. But it'll be good to try to get to a first release.","title":"Coming in for Round 43","wayback_source":[]}