Thursday, July 30, 2009

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.

Wednesday, July 29, 2009

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!!!

Sunday, July 26, 2009

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.

Friday, July 24, 2009

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

Thursday, July 23, 2009

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.



Wednesday, July 22, 2009

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.



Monday, July 20, 2009

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.

Saturday, July 18, 2009

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

Friday, July 17, 2009

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.

Thursday, July 16, 2009

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.

Wednesday, July 15, 2009

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.

Tuesday, July 14, 2009

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.

Monday, July 13, 2009

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

Sunday, July 12, 2009

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%

Saturday, July 11, 2009

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...

Friday, July 10, 2009

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.

Thursday, July 9, 2009

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.

Monday, July 6, 2009

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.

Sunday, July 5, 2009

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.