Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
RPG experiments on Android
Java
branch: master

fix file modes

latest commit 27a54ab8c4
@demonview authored default_git_name committed

README

COMPILATION:
	./make
	./install
	./remake  # ./make even if Java source has not been updated

--

The following remarks are historical.  These iterations on a theme have been
folded into a single Maze+TileView+Actor architecture.

--

empty/EmptyActivity + Maze:
	move a @ around in a small, irritating room.

	Uses a TextView and monospace text for display
	
	Uses swipes (touch and drag in a direction) for movement
		- doesn't distinguish between a simple screen tap and a
		  deliberate swipe in a direction
	
	Ignores Android lifecycle; boring; ugly; etc.

emptyquiet/MazeActivity:
	like EmptyActivity, but with a button that makes the room slightly
	less irritating.

	introduces Maze.CharHandler

gadgets/:
	more 'buttons', plus an after-move hook that checks for hidden lasers

	introduces Maze.EventReceiver , which has the 'afterMove' method

	push * around to navigate the lasers.

The above are all based on Forth experiments in forth-garden/wizardry

sokoban/:
	the classic game of Sokoban, with one level.  Uses CharHandler and
	EventReceiver rather than pattern-matching.

	sokoban/Maze:
		test for ' ' handler before assuming that it's a move

sokoban2:
	like sokoban/, but with bitmaps for each tile instead of monospace
	text.

	technically there are no sprites involved, as the 'background' is
	modified with each move, just as in sokoban/.
	
	this is all done about as least-efficiently as imaginable, and... it's
	OK.  We're not even using hardware acceleration, as Terminal IDE's
	tools don't seem to support it.

tunnel:
	like sokoban2/, but the level has two giant corridors attached to it
	that actually test the engine's ability to scroll correctly.  Very few
	changes to the code were necessary.

sokoban3:
	uses a background for the level and then only draws the 'sprites' on
	top of it

	background scrolling is breathtakingly slow - so there's a lot of room
	for improvement.

	Also, I'm pretty sure that the 'sprites' are surrounded by black
	(rather than transparent) squares.

	EDIT: background scrolling is now fast!

	Originally I had a separate ImageView for the background (placed under
	the TileView in a FrameLayout), and I (erroneously) wrote to it more
	than once per TileView#onDraw .  Now, it's once per onDraw, and
	loadBackground() uses the same canvas that's received by onDraw
Something went wrong with that request. Please try again.