
Home Page
Latest News
Screenshots
Message Forum
Poll Questions
-- F A Q --

Latest News
04/29/2004
04/23/2004
04/11/2004
04/03/2004
03/30/2004
03/24/2004
03/20/2004
03/19/2004
03/14/2004
03/10/2004
03/06/2004
03/02/2004
02/28/2004
02/25/2004
02/22/2004
02/19/2004
02/15/2004
02/14/2004
02/10/2004
02/08/2004
02/03/2004
02/02/2004
01/31/2004
01/22/2004
From 2003
From 2002
From 2001
From 2000
From 1999

Home Page
Web Games

Development
Prowler Sales

MPOGD
TopWebGames
GamesDex
OGaming
HappyPuppy
|
  |
News from 2004
| | | | | | | |
Thursday, April 29th, 2004
| | | | | | | | |
Get Ready, Get Set...
The Beta Form is now offline, and after a couple hours of reading through
the applications, 118 new testers have been added to the 72 from before -
190 total, plus me. An initial email was sent tonight to everyone on the
list, although half a dozen did bounce back as undeliverable. Chapter one
opens for testing this Saturday, and if you were selected, you'll receive
a follow-up email then, with information and instructions on how and
where to sign up your character. Basically, the
starlock.com URL will go
live (as of today, it's still just a redirect to this news page), but
sign-ups will be restricted to the beta 1.1 members only.
One Week & Counting:
The StarLock beta is still on schedule for May 1st, and that's only one
week away. By this time next week, I'll be getting everything set up on
the server, for Saturday. The beta form
will be up for a few more days, and then I'll pick additional testers late
next week from the applications submitted.
Three Weeks & Counting...
until the closed beta begins! I've
been working harder than ever this month to finish the final Chapter 1
quest, polish the game up, mark more off the to-do list, and get StarLock
ready for an open launch (after the beta). Some great improvements have
come about this month, including automatic health recovery (30 minutes
for a full recharge, one minute faster each level), and automatic engine
energy recharge (several hours, but faster with better rigs). Until now,
HP could be recovered only by casting an aura, using a life elixir, or
finding a place to sleep. Auto health recovery isn't a substitute for any
of those, because it is purposely slow, but it does serve to help get a
player un-stuck if none of those options are available and a fight is
necessary to proceed. The same is true with auto energy recharging. Until
now, a rig's engine energy was fully recharged only during midnight
maintenance. But, in order to help a player get past a "stuck-in-space"
situation, engine energy can be slowly recharged for that added push. In
addition, after three cargo deliveries to any of the nine outposts,
players will now be able to recharge engine energy when visting that
particular outpost again later.
Other changes are too numerous and minor to list. Nothing new has been
added for the 11th quest, but I'm still very confident that Chapter One
will be wrapped up by the May 1st start of beta 1.1.
Inspiration:
Two or three weeks ago, I found Everquest Evolution (the basic game
and the first five expansions) at EB Games for $30. I've never played, and
decided I should. I haven't played much -- a few hours total so far --
but I can see why it's so addictive. Although being browser-based with a
text interface puts StarLock in a completely different genre, I may draw
inspiration from EQ
in the weeks to come.
I've also discovered that our cable company recently added
G4 to their digital cable
line-up. It's the video game channel, and even if it might get boring and
repetitive later, I'm really enjoying it so far. I watched a good interview
with Peter Molyneux, the creator of Populous, Black & White, the upcoming
Fable, etc.
| | | | | | | |
Saturday, April 3rd, 2004
| | | | | | | | |
Beta Sign-Ups:
The StarLock beta is scheduled to begin on May 1st. Of the 400+ Beta 1.0
testers, 70 responded to the prior probe email to continue in Beta 1.1,
and of those 70, even a few of today's email announcements bounced back.
The Beta Application
sign-up form is now online, to recruit more testers. If you would like to participate
in StarLock beta testing, fill out the form as completely and accurately
as you are able (especially the additional comments section). This
will be a closed beta - only those of you accepted from your applications
(plus those of you from Beta 1.0 who received todays confirmation email)
will be able to sign-up, log in, and help test when the beta opens in May.
I'm anticipating a fairly short beta period (most likely to run a month
or two, perhaps even less) before the game opens for live, public play.
| | | | | | | |
Tuesday, March 30th, 2004
| | | | | | | | |
Still On Schedule:
With plenty still to do before the beta, April is going to be a busy month.
The beta 1.1 sign-up page will be up maybe when the next news is
posted - early April, at any rate. We haven't decided whether to start the
beta on the Lunatix Online
server (restricted access and fewer players means a lesser load), or to
go ahead and arrange for the initial live server (I have my eye on a leased
2.4 GHz Dual Xeon system).
Auction Improvements:
Several things have started to take shape since the last news was posted.
More has been done on the eleventh quest, and part of a new "lotto" feature
for the Marizen Market was started. The most notable recent development
involves the auctions. I'm hoping to finish quite a few auction-related
items on my to-do list in the next couple of days, and much of it is
already done. In Beta 1.0, the minimum auction duration was 1 day, because
that would also determine the length of time the winning bidder had to pay
for the item. The reason for this was to be considerate of the different
play schedules of different players. But, this has been changed to allow
both a duration time and a max payment period to be set by the
seller, so bidders can pick auctions that suit their needs. This has
also allowed for more realistic and real-time auctions, and durations can
now be set as short as one hour for quick-end auctions, or as long
as five days. Maximum payment times can be set as short as six hours or
as long as three days, to accomodate your bidders.
Auctions can now be designated as being open to all bidders, only
open to newbies, or only open to "oldbies." Although I'm not satisfied
calling them "newbie" and "oldbie" auctions
(email me if you have a
better suggestion), it's working as-is. Some players may not want
potentially fickle newbies bidding in their auctions, while some might
prefer to sometimes offer auctions that the veteran players can't
dominate. Bidding will be automatically unavailable to players with too
many negative reputation points (negative rep points are given when not
paying for auctions, not finishing tugging jobs, and so forth - but one
negative point is erased each day so that a "bad" player can make good
after a few days).
Sorting and searching options are well on the way to being fully revamped
for Beta 1.1. Bidders can now add or remove auctions from a "watch" list,
prior to placing any bids. The auction list can now be filtered to show
only the auctions you (as a player) started, the ones you're bidding, the
ones you're watching, any eligible (based on your newbie status) for
bidding, and even the potentially massive full list of all auctions. They
can be further filtered to show only active auctions, new auctions, or
auctions that have already ended (a dilemma in beta 1.0 was that since all
the ended auctions appear first in the full list, with no way to filter,
it was difficult to find the active ones without starting on the last page).
Searching options, not yet added, are also on the way. I would like to
include a text search/filter, so players can locate certain items of
interest without paging through the full list (a pretty important feature
to make auctions fully useful, but difficult to do efficiently because
of how MySQL handles table indexes).
One last thing I plan to change -- and it was only done this way originally
for the added realism -- is to change the current method of having an item
delivered to the winning bidder in the same amount of time it took for
that bidder to pay for the item. It might not be realistic to pay for the
auction and receive the item(s) immediately, but it's one more thing to
really make the whole StarLock auction system more usable.
| | | | | | | |
Wednesday, March 24th, 2004
| | | | | | | | |
Beta 1.1 Soon!
In the next few days, I plan to open the Beta Test Sign-Up form again.
Those of you from the original Beta 1.0 who already replied to the probe
email a few weeks ago with your intention to help again will already be
on the list. Expect another confirmation when open sign-ups happen, just
so you're sure. I am expecting to open the game to beta testers on
Saturday, May 1st. The success of this testing phase will determine
how soon StarLock will be ready for public play.
Quest Development:
Significant progress on the last Chapter 1 quest was made over the past
few days. I don't really have many more details to give about it - only
that the next part requires quite a bit of scripting for an area on the planet
Graulor-Manisto.
I am also trying to inject preliminary portions of this quest at earlier
stages, to spread it out over more of Chapter 1 (as opposed to a single
linear quest at the end of the chapter).
More, More, More:
Several things from the "must-do" portion of the to-do list are finished.
StarBus #3 now makes stops between the Emmansa Village and the StarBus
Station (public transportation plays a role, even though as a player you
can borrow, rent, or even buy your own rig). The Apeville Chef's pies and
teas now have legitimate uses, for Health, Vitality, and Vigor recovory.
An item in the Preferences menu controls the space options overlay
opacity (un-jargonized, this means that the space graphics become more or
less dim when options are viewed). The need for this preference becomes
apparent when working with monitors of different brightness levels, such
as laptops, where a dimmer background is necessary for the superimposed text
to really stand out and be visible against the background.
Also, tugging job properties have been modified in a way that's much more
newbie-friendly. In Beta 1.0, there was very little leniency in this
aspect of the game. A 6-hour job might have a 2-hour grace period. An
18-hour job might have a 5-hour grace period. The "minimum pickup" and
"minimum delivery" times were removed from these low-level jobs shortly
after Beta 1.0, for these same reasons. Now, these initial Outpost supply
runs (the nine beginning jobs, assigned by contracting with Chuckle Tugging),
have long grace periods, ranging from 20 to 60 hours. Added to 5, 10, or
15 hour "max delivery" times, players will now have a day or two in which
to complete a delivery. Although this really only takes about an hour,
this will accomodate players who must unexpectedly leave, and resume
tomorrow. As a result, I've also lowered the pay for each job, in
preparation for additional freelance or contract tugging jobs that will
re-introduce the more difficult aspects (minimum pickup and delivery
times, shorter grace periods, etc). One of the important things I still
need to do for Beta 1.1 is to work in these more advanced (and higher
paying) jobs, perhaps by using a freelance job center and/or by adding
another contract tugging company (tentatively, Clark Industries).
| | | | | | | |
Saturday, March 20th, 2004
| | | | | | | | |
Major Update to the FAQ:
I spent several hours last night and early this morning updating the
FAQ. It's definitely worth reading!
Most notably are the revisions to the explanation of the three membership
"tiers," and especially the information on the background story that sets
the game in motion.
Spring Break Progress!:
Although I haven't been in school (college or otherwise) for more than a
decade now, I'm taking a Spring Break off work. Part of this time will be
used for StarLock development. I have worked some on the eleventh quest
(including four new "picture puzzles"), and right now I'm improving the
introduction portion of the game. When players begin (after several
paragraphs of intro story), they are in a private area (Gainden's StarCar).
This allows new players to get a feel for the game interface and the
options, learn a little about what to do first from the Gainden NPC, and
not simply start out totally clueless. This will also serve to filter out
players who lack the patience or the motivation to read. In addition to
adding a new intro topic or two, I'm making the intro links turn gray
after used, to better indicate what the player must finish to pass the
intro.
Your Rig Has Been Impounded:
Impounded rigs can now be retrieved at Outpost Prime. I believe I'm ready
now to move forward with the creation of the last Chapter 1 quest. And
that's all, for a brief news update!
| | | | | | | |
Wednesday, March 10th, 2004
| | | | | | | | |
Outpost Prime:
Nothing new for the next quest beyond laying out the maze floor plans,
but the "Impound Lot" at Outpost Prime has taken shape. It has been added
as a stop for StarBus 1, and citizen-owned rigs are now sent there upon
a player's arrest. The main thing to finish in regards to rig impounding
now is to provide a way to "release" the rig. After being released from
jail, a player should travel by StarBus to the outpost to claim the rig.
This will involve interaction with an NPC, or some other means of getting
the rig out of impound.
A Discussion - Text/Graphics Hybrid:
This is just an observation of mine - part concern, part comment. There
really is no way around it aside from severely complicating the graphics,
or else severely diluting the text. What I mean is, the constant and
necessary discrepency between the graphic scenes of each area and the
text descriptions for the same area. It's far too late now to
second-guess a decision that was made years ago, but maybe some day we'll
launch a "StarLock 2" that renders in real time and doesn't focus as
heavily (if at all) on a text interface. Speculation aside, what bothers
me a little, and what's likely to bother at least a few players,
is that none of the action described in the text is actually depicted in
the scenes. I shouldn't say none - there are some exceptions, such
as Chuckle coming and going on que at Chuckle's Pub (in the scene or not).
That's the exception, though - not the rule. It just isn't practical to
pre-render the thousands of combinations of every single scene that would
be necessary to accurately match the action going on in the text. It's
already a big job to render scenes for different times of day and in some
cases, seasons. Even if this was done, it would then restrict what could
happen in the text, because new versions of the affected scenes would be
required. So, the result is, the scenes are a starting point for the
player's imagination, but not a substitute for it. I think many (most?)
players are going to do well with the concept, but if the game has a
weakness, this is probably it. Unfortunately, as a browser-based game,
there really is no solution aside from removing the graphics altogether.
Scratch Variables:
Here's a lengthy technical note - skip it if you're not interested in this
sort of news, and especially if it hurts your head. :). If you've
worked with the Lunatix IGM "LunScript" language, you know about the
limitations of loading/saving variables, not to mention the confusion of
keeping all the numbers sorted out and defined. StarLock's version of
this scripting engine uses "named" variables, without the 50-string,
200-numeric limit. Still, the values are only workable when loaded into
VAL0-VAL9 or STRING1-STRING6. Granted, it's easier to load and save them
in StarLock scripts than in LunScript, but there was no easy way to
increase the "scratch" variable space. It could be done by saving/loading
as needed, but then there is overhead to check the variables database for
that value and flag it as deleted afterwards. So today, I improved this by
adding a specific variable prefix for temp variables, ones that are
neither loaded nor saved, and are valid only before the current script
exits. If you've never seen LunScript, the benefit probably isn't obvious,
but since StarLock will also allow player-made PPDs, it's going to make
programming easier for those who choose to do it.
For the morbidly curious among you, here is one example of how it all
fits together:
### Remember VAL2 and STRING1 as scratch space first.
/SETVAL:X_WhateverVar=|2; #Remember VAL2 as scratch.
/SETSTRING:X_WhateverStr=|N; #Remember STRING1 as scratch.
### Now load our working vars - "%" loads/initializes
/VAL1=%SomeDumbVar; #Normal User-Specific Variable
/VAL2=%G_AnotherVar; #A Global Variable starts with G_
/STRING1=%SomeString; #Normal User-Specific String
/STRING2=%G_AnotherString; #Global (shared by all) String
### Then, do whatever calculates are required.
/VAL1+|2; /VAL1*10; /VAL2=|1; #Just doing something here.
/IFVAL1>100; /STRING1=hello; /ELSEVAL1; /STRING1=goodbye; /ENDVAL1
/IFVAL2>25; /STRING2=morning; /ELSEVAL2; /STRING2=evening; /ENDVAL2
### Now, save whatever changes we made back out to the database.
/SETVAL:SomeDumbVar=|1; #Save User-Specific Variable
/SETVAL:G_AnotherVar=|2; #Save the Global Variable
/SETSTRING:SomeString=|N; #Save User-Specific String
/SETSTRING:G_AnotherString=|O; #Save Global String
### And finally, because we don't want to lose VAL2 and STRING1,
### load them both back out of the scratch space and we're done.
/VAL2=%X_WhateverVar; #Load from scratch-type "X" variable.
/STRING1=%X_WhateverStr; #Load from scratch-type "X" variable.
In practice, it doesn't have to be structured like that. You can load
and save variables (normal, global, or scratch) at any point in a script.
For really complicated routines, in which a large number of variables are
needed and the "working" VAL0-VAL9 and STRING1-STRING6 just won't do it,
it's easy to trade vars in and out on the fly. Because they're named,
it's less confusing to remember (or make note of) what the variables
actually mean. For player-made PPDs, there will probably be a limit on
"saved" (normal and global) variables, and a forced prefix will probably
be required to keep names unique across all PPD scripts, but for those of
you who plan to create StarLock content, you can see the flexibility. Also
notice that "/ELSE" conditions, not available in LunScript, have been
added to StarLock. That's only the beginning of the improvements. Full
instructions will be available when PPD-creation ability is added.
| | | | | | | |
Saturday, March 6th, 2004
| | | | | | | | |
Happy Birthday, StarLock!
Development of StarLock started on
March 6th, 1999... and the
news goes all the way back to the beginning. That's a long time to
be working on one game, especially without a public release! Although I'd
rather work than reminisce, it's interesting to think about
what all changed in that time. Originally, the character creation screen
had options for "race" (Angoran, Fraenic, etc). Once the story really
took shape, that became unnecessary. Most of the early graphics and
screenshots are no longer part of the game. Much of what was done in the
first year was eventually scrapped, when a first-person perspective
to the gameplay was established. At first, a "StarLock" was the term used
to refer to a tugging job. It sounds a little strange now, but the
original idea was primarily the "truck driving" angle - almost exclusively
that. When accepting a job, the player would have a "StarLock," meaning
the job was accepted and locked-in. Although this aspect of the game is
still integral to the design, "StarLock" is more meaningful. It's the
spherical energy barrier that surrounds and bounds the game galaxy. It's
the eventual focus of the story - a mystery that guides the story.
Moving Right Along:
I finished that mini-quest I mentioned in the
March 2nd news post. I've also decided
to use a problem with the rendered perspective of the Block #5 Marizen
Market graphics as inspiration for the eleventh quest. I don't mean to
type jargon - basically, I changed a property of the "camera" when I
created some of the Marizen Market graphics, way back years ago when they
were first created. I'm not sure why I did it (probably trying for an
artistic perspective for that scene), but the result is, the opposite
end of the market looks just as far away from any side as it does from
the middle. It's like one of those creepy camera effects in movies.
Anyway, as part of my touch-up efforts, I re-rendered the scene
correctly, but thought of an interesting "gravity disturbance"
explanation for the original pics, which will actually end up playing a
part in the story.
Part of the eleventh quest will involve labyrinths - mazes. Although the
mere mention of it can bring groans from modern gamers, the focus will be
on solving the puzzles, not mapping the maze. In fact, an auto-mapper
item that works similar to the
Gambit's Maze Factory
map display will help.
I also made an improvement to part of the script processor. It wouldn't
make much sense if I explained it, but the end result is improved speed
when doing loops/jumps. The need for it became clear when repeating the
auto-mapping code for 64 cells (for the new maze feature).
Coming Up Next:
This weekend, I hope to make good progress on the eleventh quest. I also
want to spend some time on some of the other things (for instance, I need
create an "impound" lot at Outpost Prime - it wasn't needed in Beta 1
because players could only rent and borrow rigs, never own one - rigs
were returned upon arrest, but that's not possible if you own one, hence an
"impound" lot).
Loose Ends:
Over the past few days, I've been working to wrap up the loose ends. Most
recently, for instance, I've almost finished a mini-quest that was started
weeks ago. It involves Banzen,
and ends with a pretty decent reward. I've also finished the "dream"
sequences for Chapter One, although some additional between-level
cut-scene text is still needed (these new cut-scenes weren't part of the
original beta, so it's going to be an interesting twist to those of you
who participated in phase 1).
One of the most difficult things at this point isn't any of the touch-ups
that will need to happen before the game goes live, and it isn't even the
last Chapter One quest -- it's the dilemma of how to handle a break/end
to Chapter One. The original concept was for twenty-five levels, not
five sets of five levels. It will be the same thing when all five
chapters are eventually completed, but in order to make it work, there
must be clear chapter endings that lead into a "coming soon" bit for the
next chapter. That alone isn't necessarily an issue. What could be a
problem is making sure the non-quest content is enough to fill the gap
between the Chapter One ending and the introduction of the next chapter.
Also, it's likely to have serious consequences for the economy. Items
priced appropriately for a Level 5 player at the end of Chapter 1 might
be far too cheap if players have spent weeks or months of wait-time just
earning and saving Galactic Credits. Will this lead to "twinking," where
the veteran players become super-rich simply because nothing requires
any spending at that point? What about skill-based experience? It's very
likely that weeks or months spent just waiting for the next phase of the
game's story will allow players to accumulate so much experience that
these new challenges will be too easy when they finally do arrive
in-game - not a problem if Chapter 2 was immediately available following
Chapter 1. Some of these things can be solved by temporary limits
(no extra experience for skills that are at the Chapter One max, taxes to
help curb the millionaire syndrome, etc). It may not be a good idea to
remove part of the appeal of playing between chapters, though. The
subscription model will make it do-able for players (play now, go idle
for a while, and come back to continue later), but it's better to keep
a player than to entice a player back.
| | | | | | | |
Saturday, February 28th, 2004
| | | | | | | | |
Emmansa Village Apartments:
I haven't started work on the final "Chapter 1" quest yet (which is meant
to wrap up the first part of the game's epic story). However, I have done
work to the Emmansa Apartment scripts. Something I have planned is to
introduce a new (more elite?) group of apartments in each chapter. The
Emmansa Village is the first. I already have graphics for the next
(village as well as interiors), and the village graphics for the third
(no interiors yet).
| | | | | | | |
Wednesday, February 25th, 2004
| | | | | | | | |
It's Finished!
The tenth quest, that is - not the whole game. I finished the last bits
of the tenth quest today, and I only need to give it a final run-through
before I move on to the last quest required for Chapter 1. This,
and a few more touch-up things, and it's going to be ready for Beta 1.2.
A little more to do with Emmansa apartments, more space location
descriptions are needed, more room entry/exit messages to map out, the
"cut-scene" text between some of the levels, and a few other things, and
it'll be ready to move forward. There are other features that will be
needed before the live launch, but those can probably be done during the
days or weeks of beta testing. I'm not ready to announce any definite
start dates yet. It still depends on whether or not the current rate of
progress can continue uninterrupted.
| | | | | | | |
Sunday, February 22nd, 2004
| | | | | | | | |
Weekend Work:
I finished a few touch-ups for the apartment invitations feature. In the
process, I found a pretty major flaw in the "auctions" feature, which
wasn't found in the first beta. If on the "bid" screen at the time an
auction ends, a player could actually submit a late bid, and it would
take! It's fixed now, but that kind of thing really emphasizes the need
for solid, pre-release beta testing.
I rendered a new scene inspired by a screenshot from the Dungeon Seige
game box (saw it at the store on Friday). It was a scene of a flat-topped
pyramid, with big leafy plants around it, misty green fog all around. My
version isn't as detailed, and I built it from memory (you'd probably be
unable to recognize one as being inspired by the other) -- but it did
turn out pretty well.
I also finished four new puzzle graphics, needed for the quest I've been
working on, and another graphic (with an icon) for an item in the same
quest. Development progress was a little slow this weekend, but I think
in general it's moving along at a rate that will see "Chapter 1" launched
this spring.

Pictured above are three of the “inspired” scenes - various seasons and times of day are shown.
| | | | | | | |
Thursday, February 19th, 2004
| | | | | | | | |
Be Our Guest, Be Our Guest...
The Press Buzzer feature is working! I still need to figure
out how/where apartment owners can buy or earn the ListMaster item, but
that's the easy part. If the “Primary Resident” is in the apartment
and you're on that citizen's list, you can press the appropriate
buzzer in the Emmansa Village to enter the apartment. If the “PR” leaves,
logs off, or removes you from the guest list, you'll automatically exit
back outside. Visitors have limitations. For instance, an invited guest
can't pick up items that have been dropped (except at the entrance), so
that a player (citizen) can safely use other areas of the room for item
storage. Secondary Residents (citizens who have been given a key to your
apartment) can come and go any time, although they can't host for guests.
It's all working very well!
Touch-Ups:
Something I noticed while testing the “Guest” feature is that many (most)
of the room links haven't been mapped to entry/exit text. What this means
is, when Player1 and Player2 are in a room, Player1 should see "Player2
just exited to the north" if Player2 leaves to the north. If Player3 is
in that room, then Player3 should see "Player2 just entered from
the south." Or, "Player2 just exited into an apartment" or whatever. It's
something that's patterned (like several features in StarLock) after
MUD style games. The messages appear in the chat area (see the
screenshots for examples). This is one
of those things that won't break the game - without the messages,
it'll just say "Player2 just appeared" or "Player2 just vanished" - but
it's just not as polished and realistic without it. The same is true for
most “space” location descriptions, and several other features.
Coming Up Next:
When all I have left to do are the touch-ups, the game will
probably be mere days away from beta 1.2. But, it's not there yet. Now
that the Guest List feature is working, I think I'm ready to move forward
with the final portions of the tenth quest. I'm really anxious to find
out how long the current content will keep player's occupied, before
hitting the Level-5 “Chapter 1” limit. Moreso than in the first beta, I
think the extra content added in the past 16 months will help keep
players busy - playing Cordwixal's booth games in the Marizen Market, or
Billiards in the Epso Gamma Sky Orb, or hosting parties in the Emmansa
Village!
| | | | | | | |
Sunday, February 15th, 2004
| | | | | | | | |
ListMaster 1.0:
The "guest list" option was added this weekend, and allows players to
create lists of other citizens, as explained in
yesterday's news. The beginnings of
the "knock on a door" (actually, it's the "press buzzer") option were
also done. This will facilitate social events (parties) for starters. An
apartment resident can create a guest list using the "ListMaster" in-game
item (can't actually be obtained yet, but soon), and those on the guest
list can enter the appropriate Emmansa Village apartment if the primary
or any secondary residents are home. A primary resident is the apartment
owner - a secondary one is an authorized user, who has been given a key.
Very soon, the whole guest list and visitors feature will come together.
| | | | | | | |
Saturday, Valentine's Day, 2004
| | | | | | | | |
Upcoming Work:
I finished another "optional" part of quest number ten (earning a clue, which
can be skipped by the more clever players). I'm also going to need to work
on an "invitation" list next. It will be used for several things, one of
which will be an "allow" list for inviting other citizens to an apartment
(perhaps for a party or something), so that each guest doesn't have to
carry a coded door key. Apartments have been done for months (needs some
script/text touch-up perhaps), but previously the only way to enter was
with a door key (which wouldn't really lend itself to the idea of social
events). An "invitation" list will be maintained by a citizen (sort like
the "Crazy Comrades" option in
Lunatix Online). This will
lead up to the "Knock on Door" options at the Emmansa Village (and maybe
elsewhere), as well as other uses, such as inviting another citizen to a
"date" at the Charello cafe (only in concept, right now). I've partially
worked out how this list is going to work, and with luck, I'll be able to
make headway this weekend.
Citizen-Made PPDs:
In StarLock, a "PPD" is a Portable Programmable Device.
Several are built-in game items (and more will come). A PPD is basically
a launcher (an entry point) for a custom script. The scripts can be
whatever and do whatever - for instance, a mini-game, or the StarBus
schedule. The interesting thing about a PPD, and what makes it a step
beyond the same type of thing in Lunatix (Elevator IGMs) is that the PPD
is Portable. Imagine carrying around The Psycho Scramble
with you, wherever you travel in the game world, to be used whenever you
find the time (or to pass the time). It's like that.
I decided this morning that I am going to allow player-made PPDs.
I had disregarded the idea early on in development, for several reasons.
StarLock scripting allows much more in-depth access than Lunatix
scripting, and this could easily lead to abuse. An "offline" kit would
need to be developed, which would be a big undertaking. The review
process before adding new PPDs, if StarLock proves more popular, would be
a full time job. But this morning, I think I've resolved all of that.
Citizen-made PPDs will only allow a subset of the StarLock script engine.
In other words, things that are a potential for abuse won't be available.
The developer's kit can be entirely virtual - inside StarLock -
fully created and tested in-game. PPD authors can then sell their creations
in-game. Inclusion wouldn't hinge on a review process, either, since an
"OFF" button can be added automatically to escape from any buggy script.
GCO law can dictate the DO's and DON'Ts of PPD design, so any offensive
or misrepresented ones can be reported by other citizens, leading to
steep consequences for the author. This is a pretty exciting idea,
really, since it could lead to quite a bit of cool stuff (a PPD review
community, maybe a "PPD Author" Class type, in-game income opportunities,
and more).
I don't plan to start working on the PPD authoring ability yet - maybe
not until Beta 1.2 is underway (or even later) - but I only expect it to
take around two solid weeks of work to implement.
| | | | | | | |
Tuesday, February 10th, 2004
| | | | | | | | |
The Tenth Quest:
I've done a little more over the past two days -- graphics for another new
NPC, some internal improvements including an easier way to allow "buy all"
options (automatically detect how many of an item can be held in inventory,
and use that as the default when buying things like Gems), and some work
on the tenth quest. Actually, that quest it's close to completion. It
deals with a radiation cloud on the planet Equadus.
Writing:
A big part of this is the text. When I'm writing NPC conversations, or
room descriptions, or quest log entries, or anything really, it's not
like programming. Writing code isn't really hard, and it's all behind the
scenes. The story isn't. More time is spent getting the text just right,
writing NPCs that don't seem so flat, being descriptive throughout all
the text. As an example, the five panels of text for one portion of the
tenth quest took three hours tonight, to write. Of course, I was
watching TV at the same time. I think maybe when StarLock is finished
and released, I'll try writing a novel or something. :)
| | | | | | | |
Sunday, February 8th, 2004
| | | | | | | | |
Moving Right Along...
Since the prior news, I have added two more topics to the information booth
(Marizen market, block 5) - information on Aura Casting, and information on
Classes. I've also finished the graphics for three new NPCs (not yet in the
game), and I'm realizing that many of my female aliens are somehow ending
up rendered with large breasts. Then, some other minor behind the scenes
changes (for instance, there was previously no Vitality usage required to
create an Aura, which could potentially have allowed a player to max out
Aura Casting experience quickly). I have also been thinking on the next
part of the tenth quest, as well as a side quest involving a monster in
Chuckle's Cave (and those of you might recall that in beta phase 1, no
such place even existed). Also, I briefly revisted balancing issues of
the difference Classes, which will probably need adjustments once they're
put into actual use.
Phase 2 Server:
For Phase 1, we leased a second server, exclusively for StarLock, with the
mistaken notion that live play would be launched soon. I actually kept
the server around for ten months (and it wasn't cheap), not wanting to let
it go simply because we will need one or more servers exclusively
for this game, and because I kept thinking the launch was just around the
corner. Back around August last year, that server, which was just sitting
idle and unused on a rack in Chicago, had a RAID-1 failure (if I recall
correctly), and my provider had difficulty in rebuilding it. So, we made
the decision to let it go, and work out hosting details later. Now, with
"Phase 1.2" testing closer, I need to decide if beta testing will be
small and controlled enough to share a temporary spot on the
Lunatix server, or if
we should go ahead then and finalize our deployment plans for the live
game. The idea is still to launch in chapters (five in all), where the
first chapter is really close to completion.
| | | | | | | |
Tuesday, February 3rd, 2004
| | | | | | | | |
Touch-Ups & Improvements:
Today's progress was centered around polishing up various aspects of the
game - minor improvements to the engine, etc. These things will probably
make more sense to those of you who participated in the first Beta, but
here's a rundown. A "Cast Aura" link is now provided immediately after
"creating" an Aura. Previously, you would return to the main menu and
cast the aura from there. Basically, it's a time-saver that eliminates
one extra click. Next, I added section numbers to the Apeville crops.
This is one of the early areas (early, as in, two or three years old),
and it wasn't consistent with newer parts of the game. Now it is. Third,
I made an internal change to the script processor, basically as a time
saver for scripting - basically a "is this variable's value a part of
the following list" instead of having to do multiple comparisons. This
was done as an aid for the next change, which involves "using" inventory
items. Previously, anything that has no use at the current location, at
the current time, would give a simple "you can't use that right now" kind
of message. I've begun to customize those messages, providing text that
better fits the item you've attempted to use. For instance, using a key
at the wrong place explains that it doesn't unlock anything here. Last,
and perhaps most embarassing, I was at a loss to come up with the right
word for "leaving" a StarBus, when that part of the game was originally
coded. I ended up with "deboard," as in "Deboard the StarBus" to exit.
YIKES! It wasn't "the word" and I didn't think of it until tonight. Call
me silly, but I finally updated all the "deboard" text, changing it to
"disembark." Much better. :) Apparently, "deboard" isn't even a
real word! I also figured out that "cemetery" has no "a" in it. I've been
putting off a full text spell-check for quite a while, since it involves
parsing the game scripts... but I'm going to have to get that done before
the game goes public.
| | | | | | | |
Monday, February 2nd, 2004
| | | | | | | | |
Just Updating the News...
I said I'd keep it current, so that's what I'm doing. I've been working
on a new NPC, sort-of inspired and prompted by a joke. He's Banzen the
Butt Peddler, found along the path between the Marizen Market and the
Marizen Cemetery. He's going to serve several purposes, one of which is
to provide a method by which players can convert Vitality to Vigor and
vice-versa. He's also part of a mini-quest.

Banzen the Butt Peddler - NPC Images
| | | | | | | |
Saturday, January 31st, 2004
| | | | | | | | |
Development & News:
I'm going to (try to) keep the StarLock news up to date. In recent development,
I have made a few minor improvements to the game code, dealing with inventory
items. One involves fixing a flaw in item "rolldowns." For example, A two
usage "tea" would start out as a full glass, then when used it rolls down
to a half glass, then when used again, an empty glass. Although this was
already working fine, the system wasn't factoring in these different
versions of the same item when calculating whether or not something can
be held in inventory. So, if you're able to hold 2 glasses of tea in
inventory, using each of them once (so they roll down to half glasses)
would actually have allowed you to hold two additional full glasses. It's
kind of difficult to explain, but will help keep game balancing on track.
I have also progressed in the tenth quest a little more. The first
"chapter" of the five planned (I have no better term for it yet) requires
eleven quests. With that finished, and with a few smaller filler/bonus
quests, the game will be ready (again) for beta testing.
Beta Test:
Sorry, no announcement yet. Of the 400+ testers from phase 1, I received 70
replies back from my November announcement (most of my emails bounced back, undeliverable).
Most likely, I'm going to open up public beta applications again when the
time comes, so if you've worried about missing out because you weren't
around the first time, chances are, you have a good chance to be included.
Because it's going to be chapter-based (5 parts total), I may not call
this "Beta Phase 2." It might be beta 1.2 (part 1, second phase). Same
thing, just makes it easier to distinguish plans for beta testing the
future chapters.
Speaking of beta, the upcoming StarLock beta was posted to
BetaWatcher -- if you're looking
to beta test games, it seems like a great place to start!
| | | | | | | |
Thursday, January 22nd, 2004
| | | | | | | | |
Woops!
Okay - no beta by the end of 2003. The largest, most original BBG ever
created seems to also be one that's never actually released. We're coming
up to the five year mark. Soon... soon... soon...
Free-Form Gaming - A Rant:
Online games thrive, in part, because players are able to distinguish
themselves from one another - "do their own thing" so to speak, and play
in a way that suits their wants and needs. What I've seen, though, is
more and more of a push towards a kind of gaming experience that attempts
to put everything into the hands of the players. When I've read
comments by other developers, they seem to be intent on one-upping each
other in this regard - leaving more and more up to the player, to the
point that massively multiplayer games are simply "worlds" attempting to
mimic with greater realism the physics and interactions of a simulated
life. Does this make the developers "God" of their own virtual worlds,
watching with (or without) interest as players strive to entertain
themselves?
I don't aspire to that. I'd rather tell a story, the way we used to do
it before we collectively decided that the most expendable and useless
part of a "roleplaying" game was the story. When did that
happen?
StarLock isn't going to appeal to everyone. In general, today's gamers
believe in the notion "the less text, the better." The industry feeds off
this, and likewise, the attitude of the mass market steers, guides, and
defines the mainstream itself. This certainly works for the big-budget
developers - those guys with $4 million on the line, eyeing potential
profits in the tens of millions. And they have a good thing going. Gamers
expect big-budget games. Anything less appears as an amateur effort.
Prowler Productions isn't a big-budget developer. Our games are created,
published, and marketed all in-house. This naturally makes the
"mainstream" a large, massive iron door than cannot be opened. But being
an "indie" developer opens other doors. We can offer this kind of game,
filling a niche the big devs can't, taking chances (and time) to create
what we believe will be a fresh, welcomed experience for gamers who
aren't satisfied with what the rest of the industry tells you to
enjoy. StarLock focuses on storytelling, yet delivers it to you in a
massively multiplayer browser-based adventure game, fleshed out in a
non-linear universe with unique but familiar RPG gameplay. This is a
game - not a free-form world merely masqerading as one - and a story.
StarLock Home Page |
Older News (2003)
|