y.st./source/pages/en/weblog/2015/08-August/01.xhtml

<?php
/**
 * <https://y.st./>
 * Copyright © 2015 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => 'Compromise',
	'body' => <<<END
<p>
	Sadly, I cannot get my dungeon to spawn intact any more.
	For that matter, the other dungeon in the area that usually spawns mostly-intact is also getting leveled by the map generator.
	If I can&apos;t get the dungeon to spawn its above-ground room on the finalize map, I&apos;ll have to give it up.
	Honestly, it&apos;s got a nice inside on the lower levels that isn&apos;t getting trashed, but it just isn&apos;t what I&apos;m looking for.
	It&apos;s further from the spawn area than I would like, but because of it&apos;s awesome bunker look, which requires the above-ground room more than any other part, it was worth it.
</p>
<p>
	As Minetyst draws closer to being complete enough to go live, I&apos;ve been thinking more and more about compatibility.
	There is a chance that someone will want to use my subgame in combination with modules someone else developed or want to take modules out of my game to use with someone else&apos;s game.
	I want to write the subgame purely in Esperanto, but Minetest&apos;s $a[API] is in English so parts of my code are in English so the machine knows what to do.
	This is inevitable and I haven&apos;t given any further thought to it.
	However, parts of the game are not hard coded into the engine, yet other module developers depend on knowing how they are set up.
	An example of this is the standardized, group-based digging system.
	If someone has picks that digs nodes in the <code>cracky</code> group but my stones are instead in the <code>kraki</code> group, my stones are undiggable, making them both useless and dangerous.
	My game is built to be used as a whole, it will be internally self-consistent, and if no one tries to mix and match modules, everything will work.
	But should I not make reasonable efforts to insure my code isn&apos;t needlessly limiting people? I&apos;ve come to the conclusion that in cases in which responsibility for compatibility lies with me (such as standardized digging groups), I will make the effort despite it requiring more English being used in my game.
	In cases in which I set the standard (such as when people want to take advantage of group-based &quot;active block modifiers&quot; or crafting recipes I set up), I will use Esperanto words instead.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
END
);