A Fool's Errand, and Quantum Theory

It is my firm belief that every thought or idea that you or I have, has been had before. On the balance of statistics, the chances are that those that had these ideas handled it better, and have developed more powerful utilities to exploit these innovations. One therefore has a few possible options, when thinking of creating a solution to a problem. The first probably is to look for other published solutions and use them; these may be more mature, tried, tested and optimised. The second is to go ahead and implement another idea, foolishly perceived as an innovation, leading to a proliferation of methods duplicating, triplicating existing work, in the end producing a half-baked distraction.

Statistics indicate that someone will take that path of the fool. I am not going to argue with Quantum Programmodynamics; if it has to be someone, let it be me. Interaction in console applications may involve the ping-pong between a script and STDIN. It may be more sophisticated using Curses::UI. This is established, used for heavyweight applications and has a superb feature set. It could be more modern using Tickit by Perl's resident genius and author of over 235 Perl modules, Paul Evans; powerful, versatile, event-aware and handled in a Perlish way, Tickit is the API for the future of Perl console applications. Or one could try and invent something different. Not better, not more powerful, not more elegant. Just different. Why? Quantum, that's why.

There may be reasons other than pure bloody mindedness or foolishness for doing something differently. Indeed, perhaps the only way to learn to appreciate the right way, is to do the wrong thing. Honestly.

Interactive Applications with Term::Graille

Term::Graille offers pseudo-pixel graphics to the standard ANSI console, now is acquiring interaction tools. Interaction is handled primarily by the Term::Graille::Interact tries to to remain as "Pure Perl" as possible, and minimise reliance on external libraries. Interaction is via a keyboard, and thus uses Term::ReadKey. Rather than using libev/EVent, it relies on querying the keyboard every so often (default every 50 milliseconds) and dispatches predefined actions depending on the result...a rather old-fashioned way of doing things

One adds key-triggered actions, using addAction(), for each key of interest, passing it a subroutine reference and a description. One can also add various widget objects which temporarily override these actions when they are active using addObject(). There may be actions that occur when without a key press. These can also be added using updateAction().

The best way to demonstrate this is through game development. Term:: Graille's graphical capabilities combined with interaction equals a simple gaming platform. Games may need Sprites, and a Sprite Maker application can also demonstrate interacting capabilities. A glimpse of an early version of such an application was seen in a previous blog post, and discussed in more detail later.

Invading My Space

One simple game is Space Invaders. Shapes are loaded. Sprites are created with shape, location and velocity, and stored in an array. Some move by themselves, others move on user key-presses, others are generated, do their thing and vanish. Our defender's motion uses arrow keys. The aliens and the rockets move autonomously and the graille canvas is updated at regular intervals. (Fonts, Sound and collision detection can be subject of later scrutiny).

One creates an interaction object, adds actions addAction() triggered either by a key, or spontaneously every cycle (updateAction()), and then gets it running.

my $io=Term::Graille::Interact->new(); # a new Interact Object
$io->{debugCursor}=[22,45];            # output for debugging

$io->addAction(undef,"[D",{note=>"Move Left ",proc=>sub{
$defender->{x}=$defender->{x}>=1?$defender->{x}-1:1 }} );

$io->addAction(undef,"[C",{note=>"Move Right ",proc=>sub{
$defender->{x}=$defender->{x}<=65?$defender->{x}+1:65 }} );

$io->addAction(undef,"[A",{note=>"Fire      ",     proc=>sub{
push @missiles,{sprite=>"patriot",x=>$defender->{x}+4,y=>1,dy=>1};
$beep->playSound(undef,"A#1");}}  );

$io->addAction(undef,"p",{note=>"PAUSE ",     proc=>sub{
    $stopUpdates=$stopUpdates?0:1;}}    );

$io->updateAction(\&update);  # this action is executed every read key cycle
$io->run();              # this starts the interaction.

This can yields the interaction component of a simple test 1st game for the PerlayStation Terminal Games Console. There is prior art, of course: these are better than mine. Here is one by a Perl Monk called domm who also did a version using SDL and one in Tk by CECALA

Itchy fingers

A few reddit posts ago I saw an interesting article about maze generation and game written in Perl. Game development, I fully believe, is key to intellectual engagement, provides amusement to developers and non developers, and highlights the capabilities of a programming language. This led to an brief exploration of other Perl arcade/action games; Such games such as construdo and deliantra show how complex games can be created. Frozen Bubble is another addictive Perl classic. As a non-developer, I find these games only demonstrate the chasm between my lack of coding agility and the cleverness of others.

It's been done before

SDL and OpenGL seem like a way to go. A useful list of gaming libraries are provided by Debian Games Perl development packages and deliantra are examples of what can be achieved. Some interesting frameworks Quest3 are available although many with no recent updates e.g. this one.

But old dogs like me can't learn new tricks (or even old tricks for that matter), I figured the easy way to bridge this chasm between my capability / capacity to learn and that required to produce a respectable output requires a new framework. I hear groans all around, but wait, don't touch that dial,...imagine a framework that is simple enough for the newcomer or old timer, complex enough for a respectable game production, and accessible enough to be installed without needing a snowstorm of dependencies. Big ask? To have arcade games with moving sprites, collision detection, gravity, scrolling shooters, platformers, RPGs, and yes all these written in Pure Perl? Easily? Without being familiar with complex external libraries? Well I tried...I tried using GUIDeFATE ( a GUI designer) drawing sprites in SVG...it is clearly possible...but certainly not accessible.

Most people will have some difficulty installing GUIDeFATE (its current iteration on CPAN is near end-of-life, due shortly to be overhauled into version 0.15). Furthermore, I feel firstly that there are several components that I have yet to learn, including event handling, user interactions, etc. Secondly, for the code that is generated to useful and easily used in producing different games it needs to be consistent, and abstract out the complexities of the graphical and user interactions and thirdly that I will need a significant amount of third party help.

Consolation games

So, a radical step backwards, and look at game development as an abstractable process, with functions that can be extended to any interface/backend etc. Let's make console games that look like arcade games...a Perl games console, with games running in a console (i.e. a terminal window). Terminal games do exist, and some are even written in Perl, but the majority are made using "single use" code, i.e code that one cant borrow to develop one's own ideas easily.

Term::Graille is a step in that direction. You will have encountered it in one of my previous blogs. As a platform it includes pseudo-pixel graphics, with multiple graphical operations, and an Interaction module with Menus, Dialog boxes, Selectors etc. Later it will feature an Audio/Speech module, and Sprites. As a system its goals will be to have minimal dependencies, and key will be simplicity. Initial applications will be simpler tools that will enable game development that follows...text editors, sprite generators, graphics. All of these delivered through familiar, intuitive interactions, but all on the terminal window.