Close

Fast pace development

A project log for Retro style Star Trek action adventure game

Using my collection of tools and function to build a action/adventure game.

timescaleTimescale 04/20/2020 at 15:370 Comments

The time and effort I put into build my arsenal of methods for game structure and thinking in terms of game machines are really paying off in this project. The scripting and compositing functions make it a breeze to implement functionality without much breakage or logic bombs. 

I have been adding to and removing from the adventure script "language", some of which will find their way back to the other engines I'm sure. I have added waitForInput, JS function calls, labels, direct dialogue functions and a tween command that I'm not 100% happy with.

Apart from the "action logic", most of the game can be written in this form. Lets see a demo of the current state of affairs and then look at the script that drives it.

After some short splash graphics, the introduction text is displayed. These text/dialogue functions set the system in a waitForInput state. This means that the script interpreter stops at that line and only continues after any button is pressed.

After user input, the script continues. More assets are activated and Captain Nog has some things to say. There is a "goto" label test (Yes, I have included the evil that is goto) and then all game assets are in place and can be controlled by either keyboard or joypad.

Here is an annotated version of the script.

main
    // Define the in game object
    def logo mediaObject=logo;x=260;y=140;
    def planet mediaObject=earth;x=410;y=202;rotate=20;scale=1;scatter=50
    def crosshair mediaObject=crosshair;x=200;y=130;active=false
    def defiant1 mediaObject=defiant1;x=200;y=190;scale=.4;active=false
    def gui mediaObject=LCARS1;x=2;y=2;active=true;layer=gui;active=false
    def textBox mediaObject=TextBoxBuff;x=20;y=5;layer=gui
    def dialog mediaObject=DialogBoxBuff;x=39;y=22;layer=gui
    def nog mediaObject=nog;x=324;y=202;frameCount=3
label intro
    exec warpSpeed=1 //execute a JS function
    set logo scatter=100;
    set logo active=true;
    play transporter
    tween logo scatter=0@-1
		
    wait 5
    set logo active=false;
    wait 1
label game

    textbox Intoduction "The year 2400. 25 years after the ending of the dominion war. In order to celebrate this event after a quater of a century, there is a symposium planned on Bajor                                               The historical ship The Defiant has been refubished in space dock for the event and has been handed to Captain Nog who will pick up some of the old crew from DS9" 
    set textBox active=false
    exec warpSpeed=0
    set planet active=true
    tween planet scatter=0@-1
    wait 5

    set gui active=true
    set defiant1 active=true
    wait 2

    play soundfx1
    charSay nog "Lets see what this old wardog has got left. Start reenactment pattern delta"
    play soundfx1
    charSay nog "this is a wait for input test"
    endDialog nog
    goto test
    break // without the goto test, this would stop the script

label test
    play soundfx1
    charSay nog "We jumped to a label"
    endDialog nog
    set crosshair active=true
    break	

There is a fair bit going on here and if you read the piece on the HTML5 adventure engine scripting log, then you might see some familiar and some new stuff.

The main difference is the "def" command. This command simply defines a "thing" to be used in game. It can be a GUI element, a NPC, a planet or the ship itself. These elements can have their own functions. They are processed in the order they are defined.

The "tween" function at this moment can tween multiple numerical values by setting a target and a step. This is less then ideal for various reasons so I intend to rewrite this so it can be timed by frames.

"Exec" starts a JS function. This way I can control the actual game code from the script. The "label" and "goto" command speak for themselves and the "textBox" and "charSay" control the methods to display text context.

The "endDialog" statement is simply a lazy helper function so the code remains cleaner. I suspect a lot more of these statements will appear as elements become more complex.

I'm especially chuffed with the textbox functionality. It fits neatly and effortlessly in the game mechanics.

Discussions