planning our game

	We will be making a text game, also known as interactive fiction. The game will feature a minimum of ten rooms with some type of graphical representation for most, if not all, of them.

	The interface will split the screen in half (roughly) with the image of the room consuming the top half with the bottom half being reserved for text. Each room can have background music playing or ambiance in the form of audio effects.

	Since I have absolutely zero musical talent I will be using either classical, or free, music where I simply enter the notes in an amiga application. If I end up using a tracker I might use samples to make the music sound unique.

	The game will have at least an hour of gameplay, with a minimum of "puzzles". There will be logical challenges but not the classical adventure game style puzzles. Instead more of what you might encounter if you were actually there.

	Which leads us on to the story. It will be sci-fi, that much is certain. Possibly we'll land, or wake up, outside a remote outpost and explore it to survive or get off the planet.

game mechanics

	There's a handful of modern conveniences that I must have. An auto-mapper being a large part. Something I always wished all interface fiction featured but few actually did. 
	
	Secondly there will be no text parser (heresy!). All items and actions will be contextual. If you can use an item in a room it will be plainly obvious through the contextual menus.

	I'm also hoping to make audio a more integral part of the experience. Where instead of them just being relegated to the background you'll need to actively analyze them to progress. We'll see.	

technical aspects

	The game's data files need a structured format of some kind. Whichever I pick will have to be implemented by hand in amos since things like JSON simply wasn't a thing back then. But since amos doesn't seem to have data structures, in the classical sense, I might opt for something lighter since I just don't need all the features of JSON.

	TOML comes to mind but maybe something even simpler is a better choice. I could opt for something as simple as a KEY=VALUE store, line by line in the data files.

	There's many aspects of amos / basic that puzzle me, so I'm still uncertain how I'll implement the technical aspects of graphics + audio. The one (major) benefit is that amos was designed to make games, so all such eventualities are covered by the language itself with no need for external libraries or toolkits.

next video

	In the next video we'll actually start coding. I'm going to go through the easy amos manual with you guys and show you why I decided to implement things the way I did. My hope is to implement a basic skeleton of functions that handle the usual video + audio init routines. Most likely I'll leave a lot of the functions empty and we'll flesh them out as we go along.

	I might not have time for it in the first video but I also want to begin working on the actual data format, which will require implementing a data parser. This will then lead on to a test room which I'll fill with all the functions I want the game to have.