Still Not Dead

Still not dead.  I've been working on another project with another person.  Hopefully having a partner would keep me on track and avoid feature creep.  I have been working on SJ sporadically, but nothing worth writing about... yet.

There is some bad news.  The project I've been working on isn't related to the games I make here.  So don't expect much if and when the project is completed.  Though, the silver lining is if this project pans out, I will have more time to work on games here.

Wish me luck!

Busy

Been busy lately.  Couldn't find much time to do actual work on my games.  Fret not, they are still on my mind and I plan to continue working on them when I find the time.

Update on Seraphim's Javelin

Good news, everybody.  All major content should finally be in the rework and it is completely playable to some degree.  I am still doing a bit of bug squashing, but the majority of it is there.  The parts that aren't there are either pictures or really easy to do parts (like descriptions) or things I plan to change (so no point in adding them in now).

The bad news is... man, a lot of content's incomplete.  Now I need to work on actually finishing up what should've already been done.  But that means, I'm officially working on new content!

Starting Mission Finished*

Starting Mission should be all done*.  Game play should all be there.  Only thing left should be finish adding images for all the items.  Need to play through a few more times to make sure everything's right.

Started working on the game play for the first side mission.

Two steps forward, One step back

One of the big things for Seraphim's Javelin is converting it back to Rags version 2.4.0, the latest stable version.  Opening the game in a beta designer actually messes up the file and 2.4.0 has problems.

Recently, I accidentally opened the latest rework using the 2.4.14 which messed it up enough that I couldn't save.  Had to use a backup and redo some work.  Wasn't too hard to redo the work, but I am unsure if I redid everything.  There's probably some section of the game I think is completed that is completely untouched.

800 x 530

Got around to adding some images back in for Seraphim's Javelin last night.  For some reason that I can't think of right now, I standardized a bunch of images to 800 x 530.  Absolutely no clue why.

I clearly picked it for a reason.  Oh well /shrug...  Standards must be followed!

I also spent some time converting images for the opening mission to 800 x 530.  Played through the opening mission a bunch.  I'd say it's about 90% complete.

Got some work in on Seraphim's Javelin

It's been a while since I worked on Seraphim's Javelin.  So long I couldn't even remember where I was and what I wanted to change.  I briefly thought about starting over from scratch.  Only briefly.

Wish I could give you a progress update like 95% complete on Mission 1, but I'm doing everything piecemeal.  I'm fixing things as soon as I see them.  This is made harder since I know I wanted to rework some of the structure, but I don't remember HOW I wanted to rework it.

For those interested in Seraphim's Javelin, this is just a friendly "Hey, I'm working on it!"

Working on the new project (and Reference Variable demo)

Right now, I'm putting in some time on my new project and thought I'd share some of the game's structure and point out how I'm using some reference variables.

A bit of my game structure, the player get X actions before the world continues on.  The thing is I want to continue the storyline after the player finishes taking their actions.  But those actions are not unique to that point in the storyline.  Furthermore, some actions (such as Examine) will not count for the passage of time.

So the question is how to set it up so the storyline will continue smoothly.  I'm using timers to break out the story blocks from the rest of the game.  But then how do I run that specific timer after an action.  How will the action know to run StoryTimerA or StoryTimerB?

This is where reference variables come into play.  I created a new variable called NextStoryTimer.  This just holds the name of the timer I want to run when the story continues.  When it's time to continue the story, I execute the timer [v: NextStoryTimer].  After running StoryTimerA, the next story block will be StoryTimerB.  To set that up, I just change the NextStoryTimer variable to StoryTimerB within the StoryTimerA code.


Two things though.  First, NextStoryTimer needs to be initially set to an actual timer.  RAGS will be annoyed if it's not.  Second, there's no error checking on the NextStoryTimer variable.  If you change the variable to something else that's not a timer, RAGS won't find the problem.  That bug will only be noticeable when it's actually played.

A quick demo.

Yet another new project

Wow, it's been a while.  Real life has kept me busy with a lot on my mind.

Starting yet another project... It began in Twine but I switched it over to RAGS.  Not sure if anything will come of it.  If history is any indicator, probably not then.  Wish me luck on getting something done.

Hard drive problems - April Fools Contest

Sigh.  Having some problems with a hard drive.  My game for the April Fools Contest is on that hard drive.  Right now I have two options: try to fix the hard drive or restart from scratch.

I'm not exactly sure where it's failing at but I'm running into two different problems.

The hard drive is encrypted and there's a problem with the decrypting.  So I can't seem to access the hard drive.  The other problem is some boot files from that encrypted hard drive is messed up.  So I can't boot from that hard drive.  I'm not sure how I can start booting from an encrypted hard drive that doesn't decrypt.

Recovery
I looked around on the web and I think it's recoverable according to people with the same problem.  Some forums list step by step fixes but I run into errors halfway through those fixes.  It will take time to fix this and I don't know how long it will take.

Restarting
Restarting isn't as bad as it seems.  I already know how the layout is going to be and in general where everything is going.  Game structure isn't that hard.  The hardest part is the text.  Retyping the passages are going to be a pain and will not be the same regardless of how much I work at it.

Right now I'm leaning to restarting from scratch.  Recovery is an unknown both in time and of success.

April Fools Contest Game

Working on the April Fools Contest game.  Messing around with twine to see how it goes.  There are a bunch of great twine games so I want to see it goes.

Masculine Mystique by barabbas is the definitive game using the Twine engine.
Devious World by Skooma is an extremely promising game in it's own right.

Twine is an html choose your own adventure type engine.  All you need is a browser.  Players do not need to downloading anything except the game file itself.

A Contest Appears! - "April Fools Day"

New Contest over at TFGamesSite!

"April Fools Day"
Theme is Practical Jokes.

Plan on doing something for it.

Small update on everything else.  Real life recently ate up some of my time.  Projects are getting delay, sadly.  I'll try to get some time in at some point.

RAGS Tips and Tricks #2: Variable Experiments

RAGS Tips and Tricks #2: Variable Experiments

Download here.

For this installment, I'll be focusing on some of the experiments I have done when messing around with variables.

Variables are the backbone of many games.  Any game engine needs to allow for variables and variable manipulations.  Rags has an interesting way to deal with it.

The basic variable call is [v: variable_name].  Rags will replace that text with whatever is in the variable, variable_name.  Very straight forward stuff.  If you followed the official tutorial, this shouldn't be new.

Test 1: Testing variable names with special characters.

Test 1 focuses on the special characters.  Basically Rags check for [v: something] and replaces it with whatever is something.  What if the something resembles [v: something_else].

Right click on the player portrait and select Test 1.  You should see the following.

Base variable: Test1.  Initial Value = This is "Test 1".
Second variable: [v: Test1].  Initial Value = This is "v: Test1".

Calling base variable:
[v: Test1] = This is "Test1"

Calling second variable
[v: [v: Test1]] = 

The second variable is the call for Test1.  Some of engines typically restrict the usage of special characters.  For Rags, these would be the square brackets, [ and ].  Surprisingly, you can still name the variable using those.

The first call, [v: Test1], results in displaying the first variable.  This works as expected.

The second call, [v: [v: Test1]], however didn't work.  In fact, it displays nothing.  My guess is this is because the engine scans the inner [v: Test1] and replaces it with 'This is "Test1"'.  The resulting command is then [v: This is "Test1"]!  Since there's no variable called This is "Test1", it displays nothing.  A side effect means it's difficult to call the second variable.  No big loss though, I can't think of a reason why you would name a variable like the second one.

With my guess in mind, that brings us to Test 2...

Test 2: Reference Variables.

I'm not sure of the actual terminology, but I've been calling it a reference variable (if someone knows the actual term, please let me know and I'll update this).  The point of the reference variable isn't to hold the data you want, but instead holds a reference to the variable with the data you want.

Anyways, right click on the player portrait and select Test 2.

3 variables:
Test2a = Test2c
Test2b = v: Test2c
Test2c = Success

[v: [v: Test2a]] = Success
[[v: Test2b]] = Success

In Test 2, we have three variables.  The final variable, Test2c, holds the data we want.  In this case, it's just "Success".  The other two variables are tests for referencing the Test2c variable.

In Test2a, it just duplicates the pattern from Test1.  With Test2b, it includes some of the variable call (the v: part).

The first part of the test is [v: [v: Test2a]].  The inner part, [v: Test2a], gets replaces with the contents of Test2a (Test2c), resulting in [v: Test2c].  This is the standard variable call and gets replaced with "Success."  In other words, reference variables work.  Reference variables work!  You can store variables instead of variables!

The second part is [[v: Test2b]].  This in particular does not have the first v: as it is part of the Test2b.  Interestingly enough, it also results in "Success" meaning that the beginning [v: isn't a special order but something that can be constructed.

At this point, my guess is the Rags engine goes through all text and searches for any [v: and tries to replace them with variables starting with the innermost nested call.

The difference between Test2a and Test2b is a very interesting one.  Test2b is only missing the [ and ] for the variable call.  This brings us to our final test.

Test 3: Setting up Reference Variables.

Right click on the player portrait and select Test 3.  You'll see:

3 variables:
Test3a: [v: Test3c]
Test3b:
Test3c: Success

Set Test3b to "[v: Test3c]"
Variable: Set: Test3b, Success
[v: Test3a] = Success
[v: Test3b] = Success

Change Test3c to "Reference Success"
Variable: Set: Test3c, Reference Success

[v: Test3a] = Reference Success
[v: Test3b] = Success

The Variable: Set: ... things are just the commands taking place between the display texts.

In this test, we have two variables (Test3a and Test3b) trying to reference Test3c.  Test3a has the initial value of [v: Test3c] while Test3b is assigned that value as you run this test.  Afterwards, we change Test3c to a different value.  If the referencing works, then Test3a and Test3b should result in the new value of Test3c.

Only Test3a passed while Test3b failed.

This is perhaps the hardest part with Reference variables.  The engine will automatically replace any variable calls with the actual data.  When you set a variable with a variable call (Test3b), you are only putting the contents of Test3c into Test3b, not the actual variable call.

At the end of the test, the Debug Data will have...
Test3a: [v: Test3c]
Test3b: Success
Test3c: Reference Success

Test3b is not the same as Test3a.  The command to change Test3b to "[v: Test3c]" automatically treated it like a variable call and Rags didn't set Test3b to "[v: Test3c]" but instead set it to "Success".  This means Due to the natural of the Rags Engine, you can not set up Reference Variables in game.  They must be set as initial values!

Arguably, you do not need to include the [ and ] for Test3b and just use [[v: Test3b]] for everything.  However this requires very careful planning since if you fail to include the brackets, the call will fail.

Note: If you want to run test 3 again, you need to restart.

TL;DR Section

RAGS Tips and Tricks #2 - Variables download
Rags engine looks for the text: [v: variable_name] and replaces it with the variable context.  You can build parts of this text from other variables.
You can have variables hold other variables or reference other variables.
Setting up Reference Variables are tricky.  You need to do it as the initial set up.