21 Things Evidyon Should Watch Out For

Well, I needed to use a number so it might not be 21...but the guy reviewing Darkfall Online, a game I read about today and thought "crap! they did what we're doing" sure made me feel good about our project.  It looks like they went to release, several years late, with problems that we've already solved or are in the process of solving:

http://www.eurogamer.net/articles/darkfall-online-review

As one commenter put it, "I thought I'd stumbled into a re-re-review of Age of Conan."  Ouch.

I feel fantastic!

Steps remaining to implement quests:

- Generate action-trigger UserEvent on alt-click

- on action-trigger UserEvent, check until one succeeds:

nonself actor - if valid:

if npc: send quest trigger to server

if player/monster: show name instantly

self actor - if valid, pull up stats menu

location: ??? if location has items, examine the stack???

send location quest-trigger to server

- on server, on for quest trigger :

validate distance to target

if actor, get actor's list of quest triggers.  break after the first trigger that activates.

if not actor or not triggered, check location's trigger(s)

Quest trigger flags:

preconditions:

currently on quest (quest)

not on quest (quest)

then action:

check end quest (quest)

OR give quest (quest) -- must check to be sure client isn't on too many quests...

NPCs can each give 2 quests and end 2 quests.  They don't necessairily have to end the same quests that they begin--this allows for delivery quests.  They are given 2 quest commentary slots where they can say something when a player is on a quest (to give hints, etc.  again it doesn't have to be the same quests that they give or end!)

For giving quests:

- it is implied that a player cannot be given a quest that they already undertook

- a player can only be on one quest that an NPC gives at a time (the npc won't give you a second quest)

- if an NPC gives 1 or more quests but the triggering avatar doesn't qualify for any of them, the NPC has a phrase for both if the actor could qualify for one in the future, and one for if the actor could never qualify

- if a triggering avatar qualifies for a quest, but is on too many quests already the NPC says something

- the NPC has a phrase for if an avatar qualifies for a quest.  when spoken, the server will cause the quest description box to pop up on the client's screen.  this will also display the quest (and the ability to cancel the quest) in the player's UI

- NPC has text both for avatar accepting and declining a quest.

For ending quests:

when triggered, if the NPC will cause the client's quest-state to be checked:

- if the time limit has not been reached:

- if the client succeeded, say something and do success action

- if the quest's time-limit has been exceeded:

- if client failed by time limit, say the time failure phrase & do failure action

- if the client succeeded at the quest, say something & do success-over-limit action

- if quest not terminated (has not succeeded or failed):

- if client failed by an irreversible reason, say the reason text and do failure action.  ex. irreversible reasons are are lost competition, too many deaths, changing map and too many pks

- if still not terminated, check the in-progress quest commentary

For in-progress quest commentary:

- if the player is on a referenced quest and trigger-clicks the npc, the npc says something to them about the quest based on how much time is left:  just getting  started (<5>, in-progress (> 5 minutes, <50%), half-expired (>50% expired but more than 5 minutes left), nearly out of time (<5>

Locations can end quests too, but without all of the fancy phrases.  This is to be used for ending quests at a location.  For instance, you are given a quest and teleported into a shrine where reaching the end will give you 1 point added to strength.  If you change maps (i.e. leave the shrine) the quest is failed.  The quest has no requirements to complete it, so anything that triggers termination of the quest results in a success.  For this, each location just has the index of a quest for which it examines termination and performs the quest-configured success/failure actions.

Phew!  Welp, now I feel like I have something better specified to implement.

Do be doo...8 pm and it's time for the Simpsons

Also, SCORE quests can be compiled & triggered XD

I'm still 20 for another three weeks

You know your code project is huge when you can start a recompile, get some coffee, take a shower, return, write a blog post, start up your SVN server computer, commit the changes and it's still goi...oh wait it just finished :D

I gave Unseen Studios a file-header and added it to a bunch of files.  Anywho, I'll be implementing quests today so let's see how that goes.

Wow, it's eleven already?

Implementing quests is genuinely hard!  It's quite an interesting challenge though--there are lots of things to paramaterize.  For instance, we should be able to define competitive quests where a certain number of people succeeding at the quest causes the rest to fail (i.e. frontiering).  Another flag specifies whether meeting criteria for termination causes an instant or delayed effect.  For frontier quests, when the time limit is up everyone fails and they are teleported to a given location.  For delivery quests with a time limit, if the limit is succeeded the quest isn't failed until the player talks to someone involved with the quest and they inform them of the fact.  Also, some quests are succeeded by simply arriving at a given location or talking to an NPC--these external triggers force a quest to succeed, so it's not even necessary for a quest to be innately competeable.

Somewhere along the way I lost my list-of-three.  Gotta keep it going!

1. Finish building the quest server format
2. Create the quest client format
3. Integrate quests into the game compiler
   

Played a bit today and noticed a bug with the auto-refresher in the bazaar.  Fixed it, will release change with next update.  Also reducing timer to 10 seconds instead of 15 so there are 3 refreshes per cycle.

(I'm just talking myself through this and organizing my thoughts)

It's possible that I could be trying to be a bit too general with the quest system.  I was doing some mental simulation on how to format competitive quests, and I think competitive quests might better be modeled as a different kind of quest altogether.  Quests of the natural type are independent of each other:  multiple players can get the "kill bugs" quest at different points in time (or simultaneously) and complete it without any affect on one another.

Competitions, however, are generally launched simultaneously, can have a limit on participation, have an end-trigger that affects all involved parties, and when terminated ranks participants and performs an action on each based on their placement.

For instance, a frontering quest could be a competition whose end is triggered either by time limit (5 minutes) or by a participant finding 10 Red Charms.  When either of these is triggered, all players are ranked and given prizes: an individual succeeding at the quest (finding all 10 before the time limit) gets the success prize.  Others could get a ranking prize.  All participants are teleported back to the frontiering geosid where they started.

Ranking prizes would be difficult to hand out properly, however, since a frontier could begin with only 2 participants, which would make 2nd place accessible with zero effort.  Perhaps it's better not to have these at all.

The Unemployed Developer - A Tale with Expected End

Aha!  Just had an awesome idea:  since action-click (right-click for a RH mouse) will be used to activate information about NPCs/locations for quests and stuff, why not use it for the player too?  I'll make it so that right-clicking yourself brings up the central avatar menu.  This should make it really intuitive to navigate the world since everything's consistent!

Se7en

That's how you do that right?  Still working.  Do be doo.  Compiling code has been written, stubbed out the encryption stuff.  Time to add it to the main editor...w00t!

eleven again...sigh

Watchin' hockey.  Sa-weet.  Editor compiles quests correctly for both client and server, double-sweet.  Both client and server can load!  Working on GlobalQuestManager.  Recognized need for being able to specify the creation of indices in database.cfg, have been wanting to do this for a while so I finally got it working.  Just add a * in front of the name and suddenly a linear search turns into a binary or even hash-speed query.  Will be very helpful once more queries are being executed. ...tested, works perfectly!

Yawn!  No bed until 11:30.  That's my schedule:  7 AM to 11:30 PM.  YEAH!  I'm sleepy though so I'm going to work on the new website's layout.

Nineteen

Articles!

1. http://chrishecker.com/Do_Your_Job_Well,_Please
   
2. http://chrishecker.com/Kurt_Gödel_is_Laughing_His_Ass_Off_Right_Now
   
3. http://www.uwlax.edu/faculty/will/svd/index.html
   
4. http://somethinbeautiful.blogspot.com/2009/05/cool-art-with-folded-paper-paper.html
   

When I got right down to it, designing the questing system wasn't all that difficult.  I'm implementing a quest creator tool now that, thanks to the way I redesigned the editor's save format, will be the first tool that's separate from the main game-file compiler and should let Joe/Erich build quests that can be easily merged with the main game.

Four

Wow, it's 4 already?  I've been hard at work on the quest editor, and things are going great.  I created an Evidyon tool-project template so that the next tool can be created much more quickly, and have finished writing out all of the quest data structures.  I'm just implementing some actions then I'll crank this thing up and see what happens.

One of the tricky problems I had to solve was how to get a localized editor (i.e. an editor for quests) that references data outside of that which it loads (such as items) to be able to edit those references.  Long story short, I added a "recursive" flag to the load method of the sql database resource storage so that these other resources can be loaded in name-only generic format.  Then, I made it so that references could be set simply using path-names.  I haven't tested it yet (later tonight) but this should allow the editor to save into the main game file without the need to actually know how it works--so even if the data format or structure types of the rest of the file change completely, an out-of-date local editor should still work fine.

I've decided not to include quest initiation or termination NPCs or locations inside of the quest definition itself.  Why?  Lots of reasons:

1. The manner in which quests are given is more flexible--you can get one automatically by entering a dungeon, for example
   
2. We can have several NPCs give the same quest but have different dialogue for doing so
3. The termination points for a given quest can also be edited independently of the quest itself.  Since changing the map and NPCs are events that occur outside of the quest editor (and the quest editor can't "see" the map or edit the NPCs)
   
4. This could allow for a quest to have multiple endpoints!
   

Another interesting quest item: there are now 3 termination methods.  Success, success over time limit and failure.  This is an effect of the time limit possibly not being a failure-condition.  We can have quests that give different rewards based on whether or not you met the time allotted.

2235

Quest editor done--tool template complete, will be refined as I make more tools.  Note to self:  when item are required to finish a quest, they must have been generated after the quest was initiated.  So store the ID # of the next item to be generated and be sure only items created after that point qualify.

What's the Simplest Thing that Could Possibly Work?

After much coding this evening, a break reading YCombinator News has come through for me again.  When designing my code tomorrow, this is the thought to keep in mind.

Day 18

The walls are kindof annoying, but definitely necessary.  I'm going to work on those some more this morning, then maybe do some quest stuff since that's more engaging.

Ten

I'm EVEN MORE officially a business--I've got my own Employer Identification Number!  =D

Eleven

I found a very useful DX FAQ here:  http://tomsdxfaq.blogspot.com/

This DX development has made me realize that writing a new map engine is going to take a LOT more work than I had anticipated.  Although the basic standalone system is fairly straightforward, integrating it into the game is going to be much harder.  First, if I change the map renderer then the map format is going to have to change on the client to support the new information on visibility/occlusion and walls, which means rewriting the editor's mapping component (both the compilation part and the visualization part).  Since the editor changes, the server will also have to change to read the new format.  Add in debugging time for all of this, and this project will probably take two weeks before it settles down into something useful--but in that time, I could have coded a significant number of other features.

Since the game does work without this map update and I'm not 100% sure it will fix the major bug I'm trying to nail down (BSOD), I think it would be best to develop in parallel:  work both on the map and on features that the game doesn't have at all, splitting my days between them.  Comparing the time I've spent working on the map so far (3 days) with its results (nothing new) with the time I spent working on gameplay updates (1 day) with its results (massive), I'm afraid I'll tinker away all my time with the map, mid-June will roll around and the game will still be lacking major features.

It's effective (if sometimes tedious) to fix and/or unify components that has been implemented, since you know how they are supposed to work--but unless they're fundamentally broken, it may not be the best use of time.  I'd say the map is at 80% right now, and I could get it to 95% with a week of work.  Quests and frontiering are at 0%, and I could pull them up to 50% in a few days.

Three

Fixed the installer and significantly updated it.  Added a very basic license agreement and rules.  Also put in a nice lookin' Evidyon banner at the top!  Also, I found that all I need to do in order to have the installer overwrite previous version is remember to update the version number each release.  I wish there were a way to make that automatic... Looks like it hasn't been updated since 2.5.0

Going to work on Vista file-permissions bug.

330

I'm now a file-permissions guru.  Basically, the Program Files directory has moved for programs that actually need to update themselves.  Unless you want to splay your program over multiple folders, it's now the Common Files directory.  Also, you can use the following function to find configured folders so I'm using it to put screenshots into "My Pictures" instead of the Evidyon install directory.

http://msdn.microsoft.com/en-us/library/bb762181.aspx

Four

Found AppVerifier from Microsoft.  Using it to test Evidyon for errors--let's see if it helps find BSOD!

...bummer.  That was a waste of time.  Oh well.

Installer works great now, tested the new version.  Also completetely revamped the instructions document, complete with fun Evidyon ASCII text.  Woot.

sixthirty

I now know Python, as well as how to write Excel spreadsheets with it.  It would be very powerful to write quest scripts with Python--my only reservation is the sensitive execution time of the server.

floor(exp(2.84))

Fixed some problems with the last release.  Item drops now work properly, and order of equipped items doesn't affect their chance to drop (so you can't protect items by equipping them last, for example).  Also fixed going evil too rapidly--if you took 6 hits to kill someone, it would count you as 6 pks instead of 1.

Alignment now regenerates more quickly.  +1 unit per day seemed very slow--it's upped to 4/24 hours.  However, the first 20 hours after your last pk counts as a day so players who log in often regenerate a bit faster.  Also, after 48 hours the rate drops to 2/day and is capped at 30 so that inactive characters don't gain a huge amount of alignment.

Two

tweak tweak tweak!

Three

The living room has been reorganized.  I've got my double-strength green tea with honey.  Time to pwn some code.

Seven

Lots of code done.  Working on quest system since I got bored of messing with walls.  Nobody has any good articles, looks like I'm on my own again.

Eleven

Skype rocks my socks.

Sixteen Candles

After our group meeting yesterday, I worked hard on the alignment & PK system for Evidyon and churned out a bunch of new code.  The only things left to do before I can release this update are (1) implement the "Evil Town" where players who go evil and are killed spawn, and (2) do a bunch of testing to make sure everything works.

Eleven

Evil spawn point is implemented.  Rebuilding the editor and going to get started testing.

Whoops, forgot that actor templates need to have an alignment parameter.

Noon

After much testing, the system works great!  The hour counter was more difficult than I anticipated but using GetSystemTime, SystemTimeToFileTime and some hints from RtlTimeToSecondsSince1970, I managed to make it work.  I can use this same system for handling account time, too!

One more thing to do before I release:  put alignment on the player's stats screen.

Four

Back from a long lunch.  Alignment is on the stats screen.  I'd like to add race/class display to the screen also (temporary hack for now, this screen is going to be redone anyway).  Fixed a small bug I found in the server code that caused evil players to register as PKs.

Another cool idea for PKers I wanted to write down:  after a PK, you get a glowing red effect around you for a few minutes (so you're easily identified as a killer!)