Finalizing Fixes

After last week's semi-successful debug launch, I'm working today on finishing up the revised version with updated...everything! So far, the changes include:

- new hp/mp calculations

- new spell system

- consumables now work

- sacrificing to a geosid now triggers an "event" every of geonite. generating consumables on this event is currently implemented

- redesigned chaos effects

- new design equations for how agility/intelligence/strength affect magic speed/damage and physical speed/damage

Before the release tomorrow, I still need to finish up a few things:

- allow town geosids to create a portal when they are triggered

- make gold look like gold on the ground

- make town geosids act like safe zones (good players can't be killed) and wild geosids act like pvp arenas (players don't lose exp for dying, don't drop items when killed, etc)

- add an npc type for town guard that attacks evil

- revise special effects for all of the spells

- create the hunter/warrior spell spread

- generate the new map

1430

Looking good so far:

- town guard has been added

- hunter spell spread is nearly complete (it seems really cool!)

Wow! What a crazy release

Pulling in to the Station

This release is looking good! We will almost certainly have it out on time.

New Experimental Design Feature: PVP Damage Adjustment

Erich and I discussed this mechanic I came up with this morning, and we're really excited about it! Let's just jump in:

PVP damage is multiplied by a factor based on the ratio of the attacked to attacker's level

So here's an example: a level 20 attacks a level 40 and does 2x base damage. A level 40 attacks a level 20 and does 1/2 base damage.

The actual formula is: damage defender takes = (5 + defender's level) / (5 + attacker's level)

The 5+... ensures that a level 1 attacking a level 100 doesn't do 100x damage, only 20x damage. In fact, it's for this reason that the "introductory levels" were all collected into 1 set: from levels 1-5, you will not drop any items on death and your PVP damage doesn't work this way--it works normally. So level 4 attacking level 80 does a level 4's damage (nothin'). A level 10, however, can be killed by the level 80--but will do 85/15 = 560% normal damage.

Now here's where the magic works: that ratio seems huge, right? Well, if you use the actual DPS numbers we came up with, that amount is only 30% of the dps a level 80 does to another level 80--so it's significantly weaker, but not so much so that a level 80 could just sit around not caring that a whole guild of level 10's are attacking him! (In the reverse case--80 attacking 10--the level 80 does about 350% of a normal level 10's DPS, so he's still much stronger. However, he's not impossibly strong)

So, this also affects our defense equations: the "correct" amount of armor at any level now gives 20% damage reduction to attacks *from* any level. A level 100 with 2k armor gets the same damage reduction as a level 20 does with 400 armor.

What are the results of all this?

1. Guilds are now even more important: having a band of friends that know how to fight together is better than having a band that is high level
2. PVPing isn't limited just to high levels: you can PVP within a *much* larger level range, and enjoy doing so at any level. If you don't want to grind your character, you can participate in guild events without any problems.
3. PVE combat is still based on level: you need to be higher level to explore harder dungeons. Since monster damage isn't level-adjusted in the same way, low level players will still get pwned by high-level dungeons.
4. Levels give you access to cool new stuff, but they don't matter as much as how you build your character
5. Epic items are truly *epic*. If an epic item does 200% of the dps that it should for the minimum level that can equip it, that player will be uber powerful when using that item. Think of our level 10 going after the level 80--he will be doing nearly 70% of the level 80's dps, and will be a force to be reckoned with.

Phew! I hope this mechanic works, it could really unlock a lot of potential in this game.

Now, for a list of stuff I've done:

• enchantments work
• items can now have on-death effects (such as a resurrecting heal!)
• resurrection commands should work
• added "wishing" property to items: wishing ring = add 20% to chance not to drop equipment on death. if player wears 5 wishing rings, they will never drop items--but they're filling 5 ring slots with something that doesn't add to their hp/mp/dps/defense

Bug Fixin', Feature Makin'

Nuked:

- items don't show up on map

- sometimes geosid owner isn't retrieved

- spawn point effect lasts 1000 seconds instead of 1000 milliseconds

- changing to overhead viewpoint revealed the backs of walls weren't drawn correctly

- enable use-geosid magic

- g/home and g/sethome don't work

- need a targeted portal type

- add guild command: g/abandon [geosid name] to voluntarily give up a geosid (usually so you can take over another; leader-only)

- add party commands, including p/close

- compile enchantment types

Noticed:

- gold needs scenery

- something causes geosid burst to stop working until logoff/login

- add type to spin: bow or weapon, weapon only, bow only

- after a geosid-based trans, player is locked in place until another magic is used

Hooray Geosids!

Geosids are in the game now, and a guild can take over/own a geosid. Their name will display below the geosid's name on the map. Now--on to adding other geonite-based effects and testing.

1500

Hooray! I've got two geosids up and running--a white one and a red one. You can take them over, effects display and it uses geonite. Sacrificing works great. Now to be sure the bonuses are working and everything saves correctly.

1700

Ironed out some bugs, seems to work fine. I think it's time to see what the "real" game feels like--time to design some maps tomorrow with Erich and get this content all imported!

You'd be surprised \ There's so much to be done

It seems sometimes like no matter how much we accomplish, more tasks turn up that are still unfinished. Since we have to release pre-beta next week, it really is crunch time now. There's not much choice in this matter--if it doesn't go out, we won't have enough time to test everything before school starts, all of our time will be consumed by classes and the summer will end without a release. That I'm starting to feel a little burned out doesn't help me worry less. However, this is going to happen. It has to. This just means the mantra "what's the simplest thing that could possibly work" is even more important now than ever, given the number of tasks left to complete.

To help organize my thoughts, I'm going to list all of the biggest things (no details, like in the document we've been maintaining) that need to be implemented before pre-beta can go out:

- Spells
- Monster AI
- Treasure
- Geosid item-sacrifice & portaling system
- Merchants (bazaar, geosid, storage)
- Design & Implementation w/ Editor...this is where all the content gets implemented and the world is built.

I think the most immediately important thing is to get monsters alive, interacting and dropping loot. Since most of the melee stuff is implemented, the next most important thing would be to get the merchants back online (this is prerequisite for the geosid system). Finally, filling out the rest of the spells, finishing up the design and implementing all the content with the editor, and taking care of the miscellaneous stuff (like logging server data).

Ah! Here's a breakthough--I think I just figured out how to do the geosid portals: give players a "spell" that allows them to use geonite to create a portal. The different levels of spell are only available when they can be used--i.e. near a geosid with a portal configured for that amount of geonite--and when the player is both high enough level to have that spell and has enough geonite.

For example, players get a Geosid Portal I spell at level 1. The description indicates "Use this ability to have a nearby Geosid consume 10 of your Geonite and create a portal to another nearby Geosid. This ability is not strong enough to move you beyond the Chaos."

Geosid Portal II, a higher-level ability (say 10) could say "Use this ability to have a nearby Geosid create a portal. This consumes 1000 Geonite ." As you gain more levels, you can consume ever more geonite creating portals to more remote areas.


Ok, well that makes me feel better. I can implement that. First, though, I need to solve the monster problem. The basic melee monster is in the editor, but doesn't attack. That's first on my list to fix.


-

So I had to backtrack a bit. I noticed monsters weren't disappearing from the client when they died, so I fixed that first. There is no need now for a destroy-actor message, since all clients will remove an actor from the world at a maximum of 300 + lag milliseconds (max ~500), which is short enough that players shouldn't even notice. Instead of basing it purely on a time delay, it is now based on a sync--this has the added benefit of not nuking all of a client's on-screen data just because their network had a lag spike.

Lights, Camera, ... months of work... action?

Since my last post, many new systems have been implemented and we're on the final stretch before pre-beta release. The design side of things has been particularly challenging lately, since we don't really know how these numbers are going to behave once we get them in-game. I'm starting to have a nagging feeling that our damages are too high, but I think we can remedy our situation simply by stretching everything to give us a buffer. Once all of our equations are set, slash damage in half, reduce xp to 25% of what we think it should be, make armor half as good as it is supposed to be, and so on.


For the record, here's what happened since my last post (simply copied from the pre-beta document):

Triggers

Display zone names & zone effects (background sound)

Display player names, player name toggle

Item attachment points - preview in editor

Arena - no PK consequences created "zone rules"

Attach VisualFX to actor type no support for attaching to anything other than feet currently; also, might not look right when geonans die (effect might stay vertical) -Karlgluck 7/22/09 5:50 PM

Special FX bindings - be sure hidden scenery bindings are hidden

framework

implementation

tools

compilation

Mouse-over-actor

Equip Items

Make client actor manager detect swimming/wading/falling/visibility correctly
All equations

HP, MP

Movement Speed, Action Speed

Alignment

Melee Damage/Defense, Spell Damage/Defense

EXP: from party, xp to level, xp from monster

Pits & falling into them

Melee System

Fix client-server request interaction

swimming

Event System

Framework
projectile
targeted special effect
manager
Create "projectile" that compiles an event, embed object for ranged weapons
resulted in necessity of extracting old projectiles -> magic -> spells...
dynamic event compiler
Integrate framework & types into editor
this actually became unnecessary! all types that require events actually contain the events themselves, and integrate them using the dynamic compiler
Add preview dialog
since the types are dynamic, any preview dialog would have to be container-specific; for example, a preview dialog for ranged weapons, one for spells, etc. so this is unnecessary work
Enable compilation of events
Enable compilation of projectiles in server item description
Integrate event framework into client
acquireResources
disable old projectile/magicfx/magic/spells code
done by assigning 0 to number of array entries in each, assert(false) in loader
benchmark test: do server and client start up and work normally?
passed!!!
create network messages for projectile event management
create projectile event
destroy event
pass messages client-side to the event framework
enable ranged weapon combat on the server
client to send create projectile/destroy event packets
detect ranged weapon in processAttackRequest
updateRangedAttack
processProjectiles
add 'range' to item description
remove old scenery renderer from client

Goal: finished on Thursday, July 30
Test: ability to kill monsters with shots from ranged weapons
Completed: 3:00 PM

extra time spent applying new combat profiles, including swimming profile, and debugging the event framework; all item types are now in the game and should compile into their specializations correctly (added: crossbow, javelin, thrown and spear)

Magic System - I

finish framework outline
integrate types into editor
shared/magic
shared/magic/tools
write header for dynamic compiler for magic
add spells framework:
mp cost, listed in classes, casting action, CONTAIN magic
action delay is specified by magic, not by spell--this lets spells' delay go down noticeably at a level-threshold if that is appropriate for a given magic (beam, for ex)
shared/spell
shared/spell/tools
write tool actions
complete-editor/spell/spellactions
complete-editor/magic/magicactions
write source file for Tools::MagicCompiler
compile types
magic list for server
spells list for client & server
load spell list in client
get rid of old spell descriptions
load magic & spells in server
game-file manager
processCastRequest
updateUsingMagic

Goal: finished on Friday, July 31
Test: can kill a monster using direct-damage flame attack
Completed: July 31 at 11 pm

remove old projectile/magicfx/magic/spells/enchantments code
sanity check: can 2 players still see each other online? yep, looks good so far
code cleanup - clean out all old stuff that has been replaced so far

Magic System - II

direct damage
validate distance before applying damage
AOE spells
handle request type
fix parameters in editor
packet event types (p->p, p->l, l->l, l->l+p, p->l+p)
updateUsingMagic
create spell of each type in editor & recompile (save creating & recompiling multiple times later!)
had to change the avatar spells to make referencing work correctly
instead of creating each by hand, write "create spell of each type" method
after recompiling, I noticed that I had to fix the spell availability mask update code
AOE spells work!
teleport
projectiles
handle request type
updateUsingMagic
portals
processCastRequest
incrementMagicStage
advancePortals
add chaos effects to opening a portal to an invalid map
write code for raytrace-validating teleports (needed for dimension doors)
fix portal description in editor
rebuild (fix syntax errors), compile new game file with editor
test: dimension door - passed!
mark system
set via text ("mark1" thru "mark0"), handle in Client netmsg
test: self port to mark 1 - passed!
give maps a hashed unique ID
save marks to database on logout
load marks from database at login
invalid map -> chaos
spin attack
editor type
processCastRequest
incrementMagicStage
recompile & test
remove radius from spin attack (it's taken from the weapon)
attack run
editor type
processCastRequest
incrementMagicStage - (shouldn't get here--assert!)
updateAttackRun
recompile & test
leap
editor type
processCastRequest
incrementMagicStage - (shouldn't get here--assert!)
updateAttackRun
update client to move character vertically when leaping
recompile & test
heal
editor type
processCastRequest
incrementMagicStage
cure
remove from -hp regen
its just a buff
buff
configurable buff icons in editor
mutations (including flying, levitating)
enchantment - armor
make enchantments show up in character descriptions
enchantment - shield
enchantment - reactive healing
enchantment - thorns
add # limit to all AOEs (bow-spin included)
separate threshold levels

DOT/AOE cloud
aoe-buff
dot-aoe-buff
branching
summon
trap - dimension door
trap - black hole
disenchant
invisibility


Notes along the way:
- terrain blending rules aren't compiled!
need jumping animation

Swimming/javelin profiles
Add javelin & other ranged weapons to item types
Need to fix the swimming profile so that it is applied at first entrance to the water (instead of after first action)

Quite a lot, in other words! I broke off from doing the spells today in favor of implementing the treasure system. Although I haven't created the editing utility yet...it's quite a pain to design...the limited testing I've done indicates that the categorized weighting system works quite well.

We're going to make it!

It's amazing what a little plan can do

Last night I was pretty tired even though it was only 10:30, so instead of trying to hammer out the event system I added a copious amount of detail to some of the more vague entries in the pre-beta document.

Can't talk now - good things are happening!

The new client-interaction system is in place and working. You can walk around and melee just fine, and the system feels really smooth. All of the new equations are also in place. The action delay numbers need to be tweaked as attacking is a bit too slow right now and the fastest movement could stand to be about 25% faster.

Oh, equipping items and changing combat styles specializations also works.

There are a few things I'm going to code today before I can get started on the Event system, which is what controls projectiles and instantiates magic effects. I'm going to write the falling-down-a-pit, swimming and flying code. They're pretty straightforward.

900

Swimming works. That was easy! I also added the delayed-logoff code so that you have to stand still for 3 seconds before the game will log you out. Now on to falling...

1600

Falling and swimming both work beautifully. Melee combat works in the right situations, logging off doesn't cause problems, respawning is super simple--and to top it all off, I just deleted about 8000 lines of old code (15 files) that were replaced by this new, better-thought-out 3500 line system that does about 10x more.

I need something to activate flying before I can really test that out, so it's on to the spell system. I don't want to get ahead of myself...but I think we're going to make the deadline for pre-beta next week!!!

Ugh. Not looking forward to VS 2010

http://blogs.ijw.co.nz/chris/index.php/2009/07/visual-studio-2010-10-is-the-new-6-but-not-the-way-they-wanted/

Taking it further

The revamped client code is one of those rare moments where something gets about 10x better and twice as simple in one shot. I'm incredibly happy with the design! I've figured out how to handle the rest of the core features this afternoon--p2p trading, bazaar, storage, inventory stuff, equipping items--and I am pleased to say they fit in quite elegantly.

Well, back to it. I have to start filling in this framework at some point, but I'd like to make sure all the fringe cases are nailed down first.

Launching into Spells

It's time. I'm about to start the framework code for the biggest modification needed before pre-beta: fixing spells and the client-server interaction. Wish me luck.

1651

Finally! I think I've laid out a system that can handle some pretty sweet stuff:

Flying - gas form, flying mounts--you name it.

Falling down a pit

Swimming

Casting single spells, multi-stage spells (teleport to projectile, create wall from A to B, etc), multi-part spells (shoot off multiple waves of fireballs), periodic AOEs (poison gas cloud) and portals

Attack Run

Leap - jump from your point to somewhere else, over any pits/obstacles in the way

Charge - run at target coordinates and bash people out of the way, doing damage with your shield

Dying / resurrecting

On-death effects - recharge HP/MP, return to primary mark, etc.

Changing form into something else - a kind of monster or imitating another player, for example

Enchantments and Buffs - I made a distinction here that an enchantment is something permanent with a visualization and an icon that expires via timeout, replacement or disenchantment only and has the same strength throughout, whereas a buff is something that you can cast multiple times on a single actor, has no visualization other than the casting one, does have an icon and decays down to nothing in all cases.

Examples:

Poison - buff

Armor - buff or enchantment, depending on type

Weapon damage - buff

turn to fireball - enchantment

add melee damage - buff

increase hp regen - buff

Special FX Emitters -- the final step

I adjusted the way that I'm doing special effects to make them finalized. Yesterday I was 90% of the way there--just a few tweaks today and we'll have absolutely amazing special effects. It already looks really good, but this will allow some stuff that will really blow the players' minds the first time they see it. I'll post a screenshot of the portal spell once I have the rest of this wrangled together.

After that, I write the compiler, integrate with the client, add a configuration field for mouse-over, recompile and see what happens.

1330

Well, the emitter system is in place. There's only one kind right now but it works exactly like it should. Time to send this stuff to the client.

1530

Done! Fixed a few bugs along the way and also implemented the mouse-over-actor effect. Please ignore the stupid looking brick-rock that's crushing one of the crawlers...it's a stand-in for all items right now.

Good news, everyone!

20 or so files and a lot of thoughtful code later... the special effects framework and all bindings are finished! I'm about to start testing some of the configuration for it. Unfortunately there's no previewer yet--it's almost 5 and I've just gotten the basic stuff working--but that should be a snap since it's almost identical to the visual FX previewer.

Although I've also planned out the MagicFX system (which is considerably smaller, and just creates special bindings for projectiles and whirling chain balls and such) I'm not going to code it yet--I can get to the next milestone without it. That system interfaces directly with the spell system, so I'd like to update those two together anyway.

I should have a pretty smooth day tomorrow.

---

Something I wanted to talk over by writing it down: where should special effects be attached to actors--at the client actor, actor profile, skinned mesh or animated mesh level? Well animated mesh is not right, that would be like attaching visual effects to the mesh instead of to the scenery. Skinned mesh would be the scenery-equivalent, but there is no way to uniquely reference a skinned mesh (actors have an ID number...but only at the client level). Then again, bindings are pushed not pulled so that doesn't matter--if you have the client actor, you have the whole chain. So I guess it really matters where you want the transform to go and what else makes sense with it. The transform is pushed into the skinned mesh from the actor. But only in the updateAnimation, and updateAnimation doesn't seem like a place where the visual fx would go. So...I'll leave them attached to the actor profile for now. This does makes sense because all forms should have the same effect if it's always attached. That way I could also configure effects to be attached in different ways--such as to hands or feet (instead of just body), if I wanted to make a flaming daemon or something.

BUT WAIT! If I want to be able to attach effects to armors those have to go on the skinned mesh forms, since that is how armor is defined. ...ah, but what I'm looking for is a way to define effects that are racial (i.e. they exist for all forms). Then again what if some forms would override or hide the racial effect...well, those shouldn't exist actually so I think I'm fine. Thanks to this system's modularity I can add and remove stuff like this without much fuss.

Progress progressing

We had a great meeting yesterday and outlined the rest of development from pre-beta through beta. I started early today and have made great progress on the list so far:

server-side map triggers are now enabled (they don't *quite* work right--you can teleport on a square without tripping the trigger) but it's like 95% of the way there, that's a simple fix that will come when i rework request interaction a bit

Zone names display and one of the possible zone effects (changing the background sounds/music) is enabled.

Names for all characters can be toggled on/off

Item attachment points can be modified in real-time in the editor. FINALLY! =D I tested it out by making a character dual-wield weapons...and it looks amazing. All attachment points work great, we could even attach belts, capes, boots, and miscillaneous character-unique items (pendants and stuff) if we wanted :D

I've added a new "Zone Rules" type that lets us specify which set of game mechanics to apply in a given region. This allows for a more sensible town safety type, as well as the ability to create a pvp arena.

DAY/NIGHT

I've found that it must be accomplished using coordinated fog and lighting settings. There is pretty much no way around this in the FVF pipeline...makes me wish I could use shaders :/ Maybe I'll release a version with shaders once I get some time to play. Well, it'll look really good anyway so its not a big deal.

===================

I'm spending the rest of today working on the special fx manager. I'm going to do it RIGHT.

Special FX manager and bindings are a go. Tomorrow should wrap that all up.

Another long day of development.

And I'm going to sleep. Here's my to-do list for tomorrow. Release is so close I can almost taste it. Clients can connect, walk around, talk, fight, cast spells, kill monsters, pick up/drop items, recall...all that good stuff.

- fix special fx bindings...why don't they work?? :( probably because its using a super old hack of a system instead of writing a good one, which would take a while longer

- create the border map-layer type: should +chaos for a good distance, +triggers for wrapping the map

- add solid-chaos type

- enable chaos effect on client

- enable triggers on the server

- finish filling out swarm spawn's update method

- re-enable consumable items

- fill out equip-item code

- figure out why clients in water don't sink correctly

- check out spell-casting targeting (add mouse-over-actor indicator to test?)

- preview & edit actor attachment points

finally:

- get all the media for this update from erich

- assign scenery for items

- put spells back together (effects + items)

- rebuild the game's map

- add monsters back in

stuff that probably won't make it:

quests

enchantments

portals

The Perils of #pragma( pack )

I just spent the last 3 hours buried in heap corruption errors, data alignment problems and a game file that seemed to compile fine but was incomprehensible by both client and server. All because I added a #pragma pack (push, 1) and followed it NOT by #pragma pack(pop) but by a seemingly innocuous variant: #pragma pack(pop, 1)

Turns out, that completely changes the behavior of the compiler directive, causing everything to become 1-byte aligned. This seriously screws up...well...just about everything. Any library not compiled with the same alignment becomes corrupted if you try to typecast virtual classes...sometimes. Random methods fail even if you know their implementation and that, just before the method is called, it has what appears to be perfectly normal data inside. And the compiler generates NOT A SINGLE WARNING about this TOTALLY INSANE behavior. GWARRAR!

Good news is Erich's meshes look amazing, and this update is nearing completion.

Client, Server Online

We're finally back! I've got the client loading its game file, the server loading its game file...and I've never been so glad to see the "no connection" screen.

Also: to reduce the download time for the game, I should use bsdiff to create & apply patches.

1140

The client is starting up again, and I've gotten all the way into the world before hitting one of those asserts. Looks like I gotta write the client's actor manager now. Not too much longer!

1600

Actor manager is written, and I'm about to install it. Client maps are now loading and should render just fine once I manage to log in.

Raising the Server

Server game file is loading just fine; server is starting to get back on its feet. I might have it done today!

1500

Server starts up. Crippled; has no ai/treasure or quests. The rest seems to be fine.

Phases of a Very Large Conversion

Principles:

1. Maintain Buildability - Recompile after every change; don't make sweeping changes until you're sure you can rebuild afterward (don't run blindly down an alley hoping to come out the other side)

Process:

1. One unit at a time, convert elements that have new equivalents and delete the old elements.
2. If, during conversion, maintaining principle #1 requires fixing a class that is going to be erased, fix it now as long as the change is relatively minor (even though the fix will be deleted later).
3. Remove elements that have no new equivalents as far up the call-chain as possible; assert(false) areas that are incomplete or for which extraction would incur a lot of unbuildable changes (don't violate principle #1)
4. Use preprocessor guards and #include replacement files from within old ones. #if FALSE ... #endif the old content. This separates the step of finding all the places a given file is #included and updating the references.

Push to Release

From yesterday, implemented:

Client-side

- race/class descriptions

- items

Server-side

- level-up experience

- races/classes

- ai lifeforms: need to re-add NPC lifeforms

Today:

Projectiles/enchantments/spells/magic/specialfx will be implemented exactly the same way they were in the old version. The code isn't pretty, but it should work with minimal changes.

Then:

- gut the client of all of its current subsystems

- place sparkly new systems in

- write game file loader

- write client actor instance controller

Next, server:

- rewrite game file loader- integrate new map form, incl. triggers

Finally, reenable:

- reserved names

- quests

- inhabitants (NPCs)

1320

Finished bringing in spells, magic, magic fx, and treasure. Now I have to make them compile.

1500

Well, they compile. I think I'm there. Time to load into the server...goodbye, v2 code. This is going to be epic.

Tying up loose ends

The server and client now both compile their game files properly, and with a bit of tweaking I've managed to get a 30 MB data file down to 7 MB on disk for the client--this should really help out with the download times!

I need to make a list of what has to be tackled before this update, so here it goes.

Client-side

- race/class descriptions (easy, 15 minutes max)

- quests (easy, only task is to re-import into project & compile them)

- client actor instance controller; this handles rendering text, parsing actor IDs and handing out sync packets. I have the idea for this one pretty much formed.

- projectiles/enchantments/spells/magic/specialfx

- items

- gut the client of all of its current subsystems

- place sparkly new systems in

- write game file loader

Server-side

- rewrite game file loader

- reserved names

- races/classes

- level-up experience

- projectiles/spells/magic

- ai lifeforms: need to re-add NPC lifeforms

- quests

- integrate new map form, incl. triggers

- inhabitants (NPCs)

- treasure ... ???

Misc

- add ability to preview equipped item attachment points

- add ability to attach items to avatars

- HAVE to fill in mutate() methods

1340

avatars are re-implemented, minus spell list for classes (will add when spells are added)

interactive npc is added, minus quest-text

filled in mutate() for actor renderer, but it's a hack that takes more memory than it should. better method is to check for same skinned mesh and do a mutate() on that.

found a dumb linking problem with vc++: apparently the compiler/linker doesn't save the path of a file when building, so "project\a.cpp" is the same file as "project\subpath\anotherfolder\xyz\a.cpp". intellisense doesn't reveal this problem, though--it separates them just fine. whoo, now I've gotta come up with a convolution to my otherwise awesome naming scheme =/

had a random idea for race-specific abilities: dantalian can wear shield w/ 2h weapons; geonans get reditus; volucris can fly (over pits/short walls/water) and dual-wield; lucans get "bloodlust", which makes them do more damage as they take more damage, and take less damage as they do more damage

1600: Items are re-integrated. Needs food and break.

-0

I <3 my serializer class

Working more on the compiler today. I've created a new specialization of the serializer class to handle reading and writing to the game file. It has made my life SO much easier! No more fwrite array size, fwrite array elements or loop through array elements, fwrite sub-arrays...it handles it all for me. All I have to do is provide template arguments--and both the writer and reader is generated automatically! Plus, it's HELLA fast and handles compression (and encryption) automatically.

I think I could release this serializer class as a very useful library at some point. There are only a few extensions I can think of right now that would really round it out: a Copy type so that an individual element can be memcpy-ed instead of copied via copy constructor (for large elements), a way to support arrays of arrays...or serializers of serializers...for complex hierarchies, and a serializer "scanner" that lets you look forward and pull out only the array sizes from the next chunk to be deserialized.

noon

time to write the compilation code for the most complex game object: the map.

five

Client-side map compilation is nearly complete. It collects, sorts and tabulates all of the locations correctly and I'm about to implement my special compression trick.

...and it's done! from the debug output:

testing map is 512 x 512

testing map is now 511528 bytes; compression ratio = 4.4348%

Triggers & Compilation

I realized yesterday that the map needed triggers added to it, so I am working on that this morning. I wrote the compiler framework last night, and its implementation should be straightforward (if dull).

1600

Compilation code is going quite well. Far easier now that everything is well organized; however, I'm using a couple of very large (50+ line) #define-s to parse the data lists into straight arrays. Whatev, it saves me typing out for loops and stl iterators over and over...

Spawning is BACK!

It's fully functional in the editor now, and looks great. Spawns can be previewed in the map editor, and placed with a click of a button. Onward, to importing old stuff! Items & spells to start...

Oh: randf() and its friends have made my coding life so much easier. Never again will I have to type (rand()/float(RAND_MAX)) * SCALE or (rand()-RAND_MAX/2)/float(RAND_MAX)...these are now just randf() and randfSymmetric(). I can also do randfAngleRadians(), randf(scale), and could easily implement randfGaussian and randfCenterWeighted if I needed them.

Ok, one more thing before I get to importing: I should describe how the spawning system works so that I have notes on it other than in the code.

Step 1: add swarm spawn target level layers. These define to which level of player the spawns at each location on the map should be configured.

Step 2: add a swarm spawning layer. This layer is masked to affect a defined area on the map. Attributes include the ability to clear all existing swarm spawns (default behavior is to simply add more options), and limit the number that this layer adds (the layer can have 32 specified spawns, each with an independent probability of occurring, and the layer can add all of them--but they'll overwrite each other once the maximum is reached.

In the list of swarm references, each swarm has a min/max level and only adds itself to locations that are within this level range. There is also a % chance to be added, so some monster spawns can be very rare. Finally, there is a list of AI types that can be added at the location. Want to spawn 3 kinds of 15 types of rogues? Just stick 'em all in a single reference, set the thing to 100% spawn probability, set the # of monsters to spawn to be 3 and bam! whenever the spawn is triggered, one of three of a random selection of those 15 kinds will be created.

Finally, step 3: There is a boolean mask that triggers whether or not something is spawned on the location at all. This is how you configure spawn points: simply turn it on or off and the configured monsters will show up or go away.

Actors Acting and Time Trackers Tracking

Good article on time tracking: http://www.swaroopch.com/blog/why-i-do-time-tracking/

This puts the vague feelings I've had about work and productivity into a very concise list of words. It seems like this is exactly the sort of thing I should do. Maybe I'll take a look at that once I feel like I've gotten back to where I need to be.

On another note, actors are basically done and the dialog to test them is finished. I'm cranking it up this morning, and will leave it in whatever state (as long as it's working) by noon, latest. Next up is spawning and AI, which I hope to have finished this evening since they are fairly simple.

Midnight, on the dot

Actors are finished & working, they'll be a snap to plug into the full version. They look REALLY good now (tested with Volucris model). Includes features such as automatically estimating the speed of action (attack/spin) animations by how quickly the actor repeats them--all it takes is 1 repeat to judge the true speed! No more overlapping animations for Evidyon.

AI lifeforms are implemented, as is attaching skinned meshes to the map. The meshes don't update though...and attaching them in the way I did doesn't seem *quite* right for some reason. Maybe it's because there is so much data to store alongside them. I'd rather have a "scenery type" for each location with either "animated scenery" or "scenery", where animated scenery is a new type that is like a skinned mesh, but only has 1 form and references a particular animation. Oh well, this works for now.

Got distracted, made some progress

I decided yesterday while working on the actor stuff that I wanted to add the flickering light effect that I had in mind for torches n' stuff for so long. Well, it took all afternoon to implement correctly (!) but I finally got something that looks pretty darn good. Lighting looks really swanky overall, and renders in just 1 step.

To make things look even better, I can increase the contrast of all ground textures and make them darker but this is something we can tweak later. Onward, to the actors!

1320

Actors are going extremely well. This new system supports swimming, different weapon types (bows, 2h weapons, dual wielding, staves and more), different attack types and speeds, and it also manages to take up less packet-space than the old version did. Hooray!

Not having compiled the game for so long is making me really antsy. But I'm plowing forward anyway and I'm sure it will be worth it in the very near future--I only need to implement lifeforms & spawning before I can get a playable game again, as long as I pull in the old spell and item systems. Those can be gutted later.

Back in Action!

Well, it's been a while since I've really been able to get down to a solid day of development but I have now returned to Ithaca and am going to get working hard on Evidyon. On today's schedule:

1. Get the skinned / animated mesh editor to a point where it can be used effectively (test by importing what I have of Erich's human models)
2. Get Actor framework working (with combat profiles)
3. Add new ArtificialLifeform framework for monsters/inhabitants
4. Set up new swarm-spawning method and associated map layers
5. Enable previews & modifications in the map editor

#1 done, Erich's meshes look GREAT! Working on #2.

Animated Meshes and PNGOut

Animated meshes are rendering, but not animated. Animations will be working in the next hour.

Found a great utility this morning via Y-Combinator's Hacker News. Called "pngout", this tool compresses PNG files while maintaining all information they contain. I tested it on some of the stuff for the new website and found it made the files on average 10% smaller. It might be worth integrating this tool into the game editor to reduce the size of the compiled images... http://advsys.net/ken/utils.htm

Slogging through the animated mesh /skinned mesh renderers. It's always annoying when things require so much code before I have anything to show. Right now I can't actually tell if the last few thousand lines I wrote even do what I intended. They compile OK and run through without error, but I can't see anything on the screen because the part that does the drawing isn't quite done. Today, hopefully, that will change.

Sounds & Special FX

Sound manger is in and working again, sounds seem to work fine.

Next up is the special FX manager which lets you do the really cool spell effects--combining sounds and patterning multiple visual effects together.

Ah, still so much to integrate. Going smoothly though.

Aaand, we're back

Vacation was great! I'm really recharged and am ready to head back into Evidyon again for the rest of the summer.

While on the 10 hours+ of plane-time, I managed to solve a couple of pressing problems:

1. How portals work
2. Making AI navigate easily

Both solutions are pretty elegant. Hopefully we'll have a dev meeting soon to discuss them.

For now I'm going into the editor and am finishing up the visual FX engine. Cool stuff going on there, screenshots soon. After that I need to work on the map a bit more--adding triggers and spawn points is a big priority.

Also, a formula I need to remember: (1/2*screen dimension) + 2*overlap border <>

More pics from the new editor

I'm getting tons of work done--so much I can't really stop to blog about it! Brand new features of the editor that work very well:

- Intuitive scenery editor that lets you rescale, move, rotate, retexture and compare side-by-side all scenery in the game. Lets you automatically create variations on scenery, too! Completely WYSIWYG: it uses *exactly* the same renderer as both the map editor and (soon) the actual game client. Includes a semitransparent ground-plane and wireframe tile renderers to give you a feel for the scale.

- VERY cool map editor. Lets you draw on different map masks directly and can update those masks to disk--no more going back-and-forth drawing in two colors in Paint or exporting from Photoshop every time you want to see how something would look. Also provides a very snazzy-looking overlay for navigability types (impassable wall, water, safe zone...)

I like this graph!

Day 30

So yesterday sometime around 2 or 3 pm the code started to crawl because my damn right-hand keyboard's up arrow stopped working. I verified the keyboard was working by disassembling it and making sure the arrow worked when I connected the circuit on the printed sheet, but I just couldn't get the thing working again. My momentum was broken and sleepiness finally started muddling my brain...as a result I gave up for the time being and packed for my trip home and cleaned the house. Looks pretty good now.

My goal is to have this editor working and integrated into the game by Friday night. This is going to be a lot of work because there is SO MUCH new stuff, but if I can do that then we're pretty much golden for Beta.

I do have to say though, a single keyboard just isn't doing it for me anymore. It's so cramped I feel carpel tunnel setting in just using this laptop keyboard. Ugh. I wish that stupid other keyboard were working.

2330

Leaving on a plane in the morning. Editor WORKS! The map system integrated *perfectly*. It does exactly what I want it to do and it's really easy to set up. I haven't tested all the features yet, I'm going to get some sleep tonight so I can knock all that out tomorrow. Score one for the home team.

I should also mention its REALLY slick--smooth, intuitive, and fun to use!

28++

Hour 25, still going strong.  Going to get through this and roll out an update like never before.  Finished:

1. New map engine
2. Unified map layer masks (can use any # of colors)
3. Made layer masks even more awesome to use by allowing multiple references to the same mask
4. Layers can even reference each other, and the system is very flexible & extensible.  Triggers, npc spawn points, etc. are going to be a breeze.  You'll also be able to see all of this stuff in the editor instead of just guessing at where it might be.
5. Blending between layers is significantly more simple, more powerful and FAR faster.  Not tested yet, working up to it....
6. Rebuilding editor tool to use all up-to-date code, which will significantly speed things up and make it easier to use.
7. Wrote mesh converter from D3DX to unified format
8. Finished all images & implementation, added preview functionality to test new rendering method
9. Finished all textures & implementation--integrated new scene manager so that game will now run not only the same behavior but the same actual module of code.  Before two modules were emulating one-another.

Phew!  Gotta keep going....

10. Meshes, mesh renderer added...
11. Scenery, scenery renderer added..

Things are looking good!  Next up is the map in all its new glory.  *crossing fingers*... err ... *uncrossing fingers to type*

28 Erlang

I read an article on DevMaster.net this morning on how straightforward it is to code an MMO server with Erlang.  I haven't even started looking at issues of scaleability yet, but if it's really as effective as he claims, this could be a good choice should Evidyon become extremely popular (like we hope ;)

Coding is going very well--I'm looking forward to having the new map engine integrated with the editor, client, server and new map editor by Tuesday.  This will be a huge step forward since we'll be able to build a massive, interesting world with minimal pain.

--

It's technically day 29 now, but this is like 28++ because Im not going to sleep tonight.  Good stuff happening, gotta get it while it's hot!

3>../bin/sandbox/\sandbox_d.exe : fatal error LNK1120: 158 unresolved externals

3>Build log was saved at "file://c:\Unseen\Projects\Evidyon\apps\build\sandbox\Debug\BuildLog.htm"

3>sandbox - 1331 error(s), 0 warning(s)

Whoops.  That's ok I'll be there by morning.

Has it really been 27 days?

I'm amazed the time has passed so quickly.  Fortunatey, plenty has gotten done and more is on the way.

Today's white noise:  Myth of the Genius Programmer

Map renderer does its job perfectly--occlusion, lighting, fluids, pits, walls...you name it.  I'll add new features as time allows (corner walls is on this list), but the framework to support them is solid and will let me get on with integrating this into Evidyon's client and editor either today or tomorrow without jeopardizing future functionality.

I've coded up improved scenery and mesh renderers too.  Scenery renderer takes over the job of its predecessor from the client application (drawing items on players and drops on the map) as well as some of the burden from the old map renderer (drawing trees/bushes/lamps/etc).  This should make the client HUGELY more efficient, and hopefully solve that nasty BSOD bug.

Also, the new scenery renderer is buit to have special effects attached.  Sparkly swords, flaming torches, and dazzling armor--here we come!

Day 26, T minus 9 and counting

I go home for vacation in 9 days, and Evidyon needs to be in a mostly-compete state by then.  It's time to get down to business (again)!

Today:

1. Map editor

2. Map editor

3. Map editor?

2300

Shabam!  I can't do the new map editor without this new format, and boy am I glad I waited on finishing it.  I found a much more efficient way of doing what I was doing before, and I've made huge strides today.  I should be abe to have a basic working editor up tomorrow if all goes well, followed by a reasonably usable one on Sunday.

25% = 1/4

Creative, I know.

Anyway I fixed some stuff with the questing this morning and they seem to be working just fine now.  In the future I'd really like to support group quests--they could be a lot of fun!

I'm going to work on the map editor today.

2035

Well, I ended up taking a personal day instead.  Went to the store, cleaned, etc.  Two things to report on from this front that aren't strictly Evidyon or Unseen-related, but are cool enough to mention:

1.  For the most enjoyable coffee I've had in a while from beans I had thought were a bust, mix 2 tbsp sugar with 1/3 cup grounds and brew (small flat-bottom).  It comes out so mild and delicious that I don't even add any sugar and only a splash of milk.  I think putting some sugar in the grounds separates them and allows them to steep differently, because the difference is like night and day--not even comparable to brewing then adding sugar.

2.  This is the first thing that I'm writing on a pair of keyboards that I hacked up to allow me one keyboard for each hand*.  Using two USB keyboards, I cut each such that I can sit in a chair, rest my hands on the arms and without moving them, type on the computer quite comfortably.  It's a somewhat unnerving effect because typing like this is so comfortable and natural that it almost seems wrong.  Now if only I could control the mouse by looking I would have a perfect interface!  Hehe.  Geeky, no?

Anyway, tomorrow I'll need to do some more cleaning around here (using a hacksaw on the keyboards created a lot of plastic dust and it's late enough I can't spot it all) but I'm going to start, quite comfortably, on the map editor coding tonight.

*Hooray!  No more RSI effects :D

twentyfour - show quests on client

Ok, so all I have to do is get quests showing up on the client and I can finally release this quest update.  The big decision here is how much info to give the client: should the client be told how much they've progressed on a given quest?  The description says they have to kill 230 orcs to complete this quest and bring back a golden rapier from one of their corpses.  Should the quest display "210/230 orcs killed"?  This seems a bit...well, artificial.  It would seem to me that would make the game seem less pure.  Plus it's not fun to code and puts a burden on the server...

So unless players ask for it, I'm going only to display timers (and names)!

1315

Quests are sent to clients and there is now a display panel for them accessible via right-clicking one's own player.  It also displays tooltips (compiling this to test right now) with the description in them.  Move the text-wrapping method to the font...finally...so it doesn't run on forever.  Can probably use exactly the same thing for the chat log.  Super cool.

Last thing I need to test:  being able to give up on a quest by clicking it in the quest log.

1415

IT IS DONE!  Time to make some quests that people can actually test out.

Microsoft's "Natal" is like a Wii times 23

If the "Natal" project from this video by Microsoft Research is really as good as it looks...it will completely revolutionize the world.  No kidding.  From the post by Johnny Lee on his blog, the 3d pointcloud scanning ability already far exceeds the ability of even the most state-of-the-art ragefinders.  Not only is the density hugely impressive, it's behaving in friggin real-time!  That's incredible!

Anyway, quests are nearly complete!  I'm coding the last two database methods now and am about to test :D

1715

SWEEEEET!!!! The Aurelian Blade quest works great.  Doesn't save quest history to DB yet, will add that in now.  Left to do:

1. set up day/week/month quest offer times
2. saving quests to db
3. load quests from db
4. log kill count (specific & qualified)/pk count/death count/map change/etc.
5. instantly fail quests w/ that parameter enabled
6. show quests on client, allow quest failure
7. competitive quests

1730

BAM time finished.  Going to test taking items from players on quest complete.  Already tested and confirmed that only items generated *after* a quest starts qualify to complete that quest.

1800

2, 3 done; fixed bug with % showing up in speech log.

1830

4 done .. dinner ... 4 tested & works!

2330

Moved 56k of data off the stack in the client, maybe this will solve login issues since windows won't have to allocate such a big amount of stack memory.  Did some code reorganization, too.  Also...quests might not be working quite as well as i thought, looks like I can repeat the blade quest as many times as i want on an alternate character.  hrm.

22 Quests

Questing is going GREAT!  I've coded all the behavioral stuff into the NPC (the different phrases) and I'm about to test him out.  Gotta recompile because I added another phrase, though:  accepted quest but can't pay.

Here's my list for today:

1. Test NPC dialogue for various situations with hard-coded quest parameters (half an hour)
2. Implement quest proposal display on client with accept/decline buttons (1 hour)
3. Write quest interaction code that checks to see if you qualify for a quest, have completed a quest, etc
4. Save questing data between sessions and ensure consistency

6 pm already?!?!?!!?!?!!?

Well that was crazy, I woke up at 7...had some food...took a shower...wrote this post around 8:30 and started coding.  I forgot lunch, whoops!  I guess that's what happens when you're having a BLAST doing something you're really interested in.  Quick accomplishment list then I'm going to work out:

1. NPCs speak to the player and can have very long phrases that don't interfere with one-another.  Situation:  two players both trigger an NPC to say a different set of phrases at the same time.  Whose phrases win?  Well, in this system BOTH do!  The NPC sends out the entire phrase at once to all clients when it is generated, along with the actor to whom he is speaking.  If a client realizes that the NPC is speaking to its avatar, it will lock the NPC's speech as "persistent" and only display that NPC's phrases, even if the NPC is triggered to say something else by another client.  This also makes it so that the client is entirely responsible for rolling through the NPC's spoken phrases, which takes a lot of burden off of the server.
   REALIZATION: This is why I love this blog!  I just realized that because of this system I don't even have to sprintf the actor's names into the spoken text anymore, I can just leave the %'s and do a straight-up send on the text!  Since the clients know which actor is being spoken to, they know that actor's name implicitly!!!!!!  (minus the no-name bug....guess I'm gonna have to fix that one before quests go out)
2. The quest accept/decline panel works great
3. All methods for quest states are stubbed out

ten

phew, I've implemented the prerequisite method stubs.  tomorrow i should be able to do more coding, then actually be able to try out a quest or two!  Wednesday looks good for release =D

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.