Zer's Programming Page

Visibility code and garbage collection

Sun, 04 Feb 2007 23:55:24 -0500

Last week I was doing the visibility code, such that the server will send only what it needs to and players won't know about anything else. It seems to work, so I'll find out when I begin to seriously use it. One problem with the code as I did it was that creatures can see each other, but the creatures being seen may very well be able to see the ones that are seeing.

That gives us circular references. Not fun. Reference counting won't work, but I didn't want to use ordinary pointers since that'd complicate everything. So, I switched all of the game's memory management over to garbage collection. I rolled my own since I thought it'd be fun, and what a pain it was. However, now the game's working fine with that, except the client crashes on exit. All that's left to do is to debug and integrate Squirrel's garbage collector with my own. That'll let scripts safely keep references to objects, and objects to script objects, etc. Pathfinding doesn't get along with the new visibility system yet, so that's another bit of work.

However, *after those* (the above issues are minor), here's what we've got, in (roughly) the order I think I'll implement them.

To-Do:

* Sight radii for creatures
It remains to be seen if the visibility system can be made efficient enough that monsters won't have to cheat. While it's clean, speed, well...
Anyway, if I give a creature a sight radius, and attach a client relay to it as a viewer, the client will be able to see everything the creature sees. This is so we can do pets *right* and perhaps play RTS style.

* Serialization within the map for more complex objects
There's no technical reason I can't serialize any object within the map, but I want to keep it limited to those it makes sense for.
Monster spawners come to mind.

* Monster AI
As I mentioned before, creatures already have 'goals', but those are only actions for an AI to use. We still need general behavior.
I'm going to try for 100% scripted.

* Chat channels
While chat is operational, I don't have any default channels decided on. Keep broadcast? Yell? What. I'd like your opinions.

* An understanding of 'maps' on the client
Presently the client has no clue what a map is. This is fine for now, but if we're going to be watching pets on multiple maps at once, the client'll have to know not to show map 2 tiles when we've got a map 1 creature highlighted, even if it knows about the tiles.

* Mouse-based map scrolling (like Starcraft)
Only for RTS mode, but once all of the above are done... For GMs I'll have it attach a viewer to the camera, so that we can watch over anywhere on any map at any time.

* Completely rewritten pathfinding
The pathfinding code is an impenetrable mess. Now that I have proper restrictions in place, it should be easier to write cleanly, and will probably take about an evening. The current code tries to do too much, and does it badly. Along with this I'll introduce stairs, since we need them.

* Accounts
Everyone's named Test right now. :)

Suggestions, comments, etc. are welcome. Pretty soon I'll need to be thinking about stat systems, game mechanics and what have you. That's the part I actually enjoy, so this'll be picking up speed.

Happy Thanksgiving

Thu, 23 Nov 2006 12:44:24 -0500

Happy Thanksgiving to all of you. I figure it's been a long enough delay that I should write a status update. Progress is slow but I've been working on it when I get free time, mostly on weekends.

The pathfinding works (except for one bug - objects register as obstacles, grr). The scripting language has quite a lot more features now, and can be executed for spells, skills, and weapon attacks. Says work (other than says the chat framework is game-independent, though it's simple at present so that's not very exciting). Goals are new (well, about a month old, but I haven't done updates for a while...). You know how in Starcraft you can tell characters to Move, Patrol, etc., and if you hold Shift down you can queue those up? Well, I put that in. It's accessible to script also, and 'Say' is a goal, so you can for example write:

creature.AddGoal(Goals.Bow());
creature.AddGoal(Goals.Say("Hi! Follow me to some tile!"));
creature.AddGoal(Goals.MoveTo(tile));

Lately I've been working on serialization (saving/loading from disk). It sounds easy but because I'm trying to make map objects inheritable from each other it actually has a lot of non-obvious issues I'm having to tackle. Of course, given a good 20 hours of free time I could finish it, but I rarely have that much time all at once these days. The nice thing about the setup I'm coding right now is that once it works it'll be able
to store everything, with little to no special casing.

Once serialization is done there'll be remoting code to do. Specifically, code to filter what each client actually knows. For simplicity I have every client knowing everything going on in the game right now, but what needs to happen is clients only knowing about what their characters are able to see (...and a little extra so it's not laggy), which means 'view' objects (which need to be unattached to characters - for example True Seeing in Warcraft 2). Then the default high level AI (in script) and an allegience system to go with it, spawner objects (easy), and finally code cleanup, after which point I'm pretty sure I'll start on a map editor. Somewhere in between these things I'll have to figure out a stat system. After all that is done, it'll be time to begin on content (and perhaps sound, hmm).

Soooo that's the road map from here.

Summer begins

Sat, 17 Jun 2006 17:36:22 -0400

School's finally out. My plan for the summer is as follows:

1) work student job that I got
2) learn to play guitar
3) exercise a lot
4) work on the Faldon rewrite

Hard life. :)

So, about the Faldon rewrite, yesterday I gutted some of the needless complexity and as a result boats, etc. anything that'll hold people and is over 1x1 tile will only support four directions, which makes the code a lot more manageable. I'll spend some of tomorrow finishing up the changes I've made, and then testing. With ten weeks I should be able to make good progress, considering basic scripting and all that jazz are already supported, so in truth the code's been near the barrier to usefulness for a long time now..

As far as the student job goes it involves characterizing the behavior of turbine blades when they're placed in odd situations. I've only been there one day and have a lot of catching up to do, but it'll be a good experience.

On another note I finally got around to looking at how PayPal IPN works. So I've automated the current Faldon order system. Stat resets come in about 15-30 seconds after order, likewise for players. It'll be good since John, having his own business now, doesn't really have time to put them in, and since orders used to go to his e-mail I never was really clear on which he'd done and whatnot. Now that I know how to work with IPN, it should be easy to do again if need be.

The pathfinding code is working

Fri, 18 Nov 2005 17:35:46 -0500

I finally got the first draft of my term paper done for Japanese, giving me free time. I don't have Internet at home at present (that may change -- it's quite inconvenient not to have it, though it does make it easier to concentrate on my studies) so as you've likely noticed I haven't posted much.

Anyway, last Saturday I got pathfinding working, so that's all good now. The pathfinding code properly detects obstacles that pop up along the path and repath if it finds any. The way it determines what is and what isn't a tile is a bit of a hack, so that's the next thing I'll be changing. After that I think there are a couple bugs, and then it'll probably be time to do at least basic game logic. Hopefully over this coming spring break I'll be able to make good progress. The pathfinding wasn't actually that hard per se -- it only took two days to get from broken to working fairly well (I didn't do it entirely properly so I may have to change it later -- because I used floating point and allowed arbitrary orientations for entities -- big mistake as far as sanity, time, and bugs go), but those two days were basically devoted to the pathfinding.

Another thing that the client and server do now (since I last posted anyway, it's not really new) is use Kerberos for authentication. The problem is that the Kerberos server doesn't normally run on Windows (the last version I downloaded anyway, which was admittedly about half a year ago), so I have to run it under Cygwin and even then with some changes. It's got a lot of old code and that wouldn't be a problem except that it doesn't mesh well with our current conception of citizen accounts. If any of you know how to have Kerberos mirror passwords between different subidentities do let me know... The idea of having to have a separate password for logging in as a citizen isn't too appealing in my opinion, so...

As far as game logic goes, it'll probably be basic monster AI, perhaps attacking code, though I'm questioning how much I want to hard code that. After all, what I _could_ do is make attacking for weapons (and receiving attacks for armor) scriptable functions, allowing customized responses on both ends of that. Actually before I do any of that I need to alter pathfinding so that it can stop right before a destination instead of trying to go to it, so that it'll be possible to pathfind to creatures instead of just to tiles...

A couple unrelated bits... Does anyone know how to get a PC-like Home/End behavior on a PowerMac? It's driving me batty how this thing goes to the start of the document instead of the start of the line. Next thing, having taken a year off from college I get the idea that a lot of the stuff people do here they could easily learn on their own. Then again I'm taking sophomore-level Mechanical Engineering classes so perhaps it's to be expected (sigh). All for a piece of paper. Hurrah. Hm, that's about it I guess.

If you're bored

Sat, 28 May 2005 17:34:36 -0400

I was thinking to myself, the Faldon rewrite is going to take a long time to do.
Why not do some tiny games for fun in the meantime? It'd relieve the tedium of it all.
So I decided to learn JavaScript. Anyway, that's been three or four days now.
I made a little game. Click here to go play it.

OT: Slinky

Mon, 23 May 2005 18:17:16 -0400

I thought this was neat, just discovered it today. If you let a slinky move by gravity while the side of it contacts a mildly cushioned chair armrest (not allowing the top to move, such that the slinky acts like a spring stretched by gravity), the sound it makes as the different metal sections brush against the armrest is the movie spaceship laser firing noise.

Pathfinding is going to be trouble

Thu, 19 May 2005 20:09:36 -0400

All right, well pathfinding the way I'm going to do it will be a huge pain to code.
As such, I'm going to take about a week off from anything Faldon-related before I continue on it. I'll let yall know when I get started again.

On to game logic

Thu, 12 May 2005 14:04:23 -0400

Okay, with the status area more or less working and the animation classes in good shape it's time to start on game logic. I want to be able to reuse most of the logic code for a new server also, so all of this will have to be done to a level above and beyond the usual. I'll be starting with the code required for walking around maps.

As such, I'm starting with requirements. Here's what I can think of right now (* marks an implementation detail, better ways are welcome):

Maps
- Instances
-- Parentable to other maps
-- Movable and rotatable
--- Each map functionally a grid
--- Attaches to its parent map by rounding to the nearest cube*
---- This is to make pathfinding more practical
--- Must be able to (at least approximately) pathfind through their parent maps
-- It's be nice if maps were replaceable on the fly, but this isn't strictly necessary
--- The problem is what to do with things that aren't part of the map itself when the replace occurs...*
---- Move them? To where?
---- Don't move them? Then what if the replacement has a wall where they are?
--- This would make map patching easy, and allow drawbridges and planks on boats, but the above problem will need to be solved
- Prototypes
-- Maps are designed as prototypes, and the maps people play on will be instantiations thereof
-- Maps are composited out of other maps, tiles being the degenerate case
Mobiles (monsters, players, etc)
- Mobiles are (with some modifications) 1x1 maps, mobile spawners (later on) likewise
- Basic behaviors
-- Follow (repeating Go To)
-- Go To

As for graphics, the two things I can think of that I still need to do are trigger (door) and animatable tiles, but they can come later. So anyway, anything related to how maps and the mobiles on them operate, this is the time to post your laundry list. :) Also suggestions for modifications, problems I'm not seeing, etc. w.r.t. the above requirements and clean ways to resolve the problems brought up would be appreciated.

Mystery screenshot

Mon, 09 May 2005 14:55:37 -0400

I've been working on a couple neat features. Since I'm using a horrible keyboard today (spilled water on my other one, letting it dry), and can't type very fast on it, I'll let you all guess what the aforementioned features might be. There are about three or four of them.

Anyhow here's the screenshot.

New client can chat

Sun, 01 May 2005 13:37:10 -0400

The new client is finally to the point that you can create accounts, create characters, retrieve your password, and login and chat with people. Next up is testing the GUI game controls and making display code for monsters, characters, ground and wall tiles, etc. Once that is done and tested I'll start on the client-side game logic. Anyhow just to let you all know where the client is at present. :)

Update: The GUI game controls work, with rotation support now too. This'll allow 90' rotations like AoE and SimCity have, assuming we set up the tiles appropriately. Next up is animation transition code, hopefully done right this time (last client it was hard coded and buggy, hence things like characters stepping while walking, and attacking strangely).

Chatter code online, new version of NetIRC

Wed, 06 Apr 2005 21:25:57 -0400

I'm taking this week off as a spring break of sorts, so I've been working on updating some of the open source software on this page. The new version of NetIRC improves decoding reliability for multibyte characters, though I think it still has a bug where a send timeout can raise a SocketException, just noticed that. Chatter is an IRC client I wrote a long time ago but never released. I've put it up with a Zlib license; feel free to use it for NetIRC sample code or what have you.

Network code works, just needs testing

Wed, 23 Mar 2005 21:35:16 -0500

I've finally got the network code to the point where I can start using it. It's built on top of the network code I recently added to the Common Code library, which by the way has a new version up today. The network code supports two protocols, the Faldon one and a better one. The Faldon network code connects fine and reads packets with no problems; I'm going to start on a chat client of sorts to give it better real-world testing (with the Faldon server).

Funny thing about the Faldon server, speaking of which. Before this I'd never written anything that just printed out what channels and data each packet from the server had, so I never noticed. It turns out that the timeout code doesn't check if the player being timed out is still connected to the game, and so every second it broadcasts to all players that a player has left. It's the same player many times in a row, a huge waste of bandwidth. Will be uploading a fix in a couple days.

GUI is almost done

Fri, 11 Mar 2005 17:34:52 -0500

Hm. The GUI code is almost done. All the major pieces are in place (aside from Cut & Paste, docking, fancy window animations, etc. but I figure I can get those in later since they aren't important to the meat of the project). All of the controls work well, and can be deserialized from XML files. There are also two events (ButtonClick and ButtonSelect) to which actions can be attached directly from the XML file. There are only three actions at present: Close, Select, and SetPicture, but that's okay because anything past that should really be done in code. Tomorrow I'm going to put the last few tweaks in and make the ListBox more efficient (at present it would get slow if it had a couple thousand items), and after that I'll be having a look at the network code I wrote a while ago, to see whether I should keep it or write something nicer.

About the XML deserialization, the encoding the program expects is UTF-8 (no big surprise), and that's also the encoding the language files use now. Unlike the old Faldon client which had a custom binary file for languages, the new format is the same as CommonCode.Object's. So it looks like:

<?xml version="1.0" encoding="utf-8"?>
<Object Parent="Gui/Languages/English (US).xml">
<Strings>
<String Key="whatever text key" Value="the translation"/>
</Strings>
</Object>

All language files will (or should) have English (US).xml as the root, that way any strings with no translation will get their text from the English file. Anyhow that supports Unicode and will make it very easy for people to make translations. It also supports (by setting Key="@file-alias:filename" and Value to the new file name) aliasing of text files which are loaded into text boxes. So that'll let us support language-specific tutorial files/help.

FWIW, right now, not counting blank lines or comments, the CommonCode solution checks in at 4983 lines, Illusory.Images at 7601, Illusory.SdlDriver at 1049, and Illusory.Gui which is now almost finished checks in at 5986 lines of code. It's pointless, but to me it's interesting to see that the GUI was in some ways a smaller project than the image library. So thus far the Faldon rewrite is 19619 lines of code long (24996 if you count blank lines and comments). Which is a lot but the old client was much more and this is cleaner and more featureful, so... :)

Birthday

Thu, 03 Mar 2005 19:19:30 -0500

As of yesterday, March 2nd, I'm 21 years old. :) Taking today off from coding, tomorrow I'll be working a bunch on the TextBox control. The GUI is not too far from being useable, though I was thinking I'd spend til the 14th or so of March on it, so with all the extra time I'll just make it really nice. All suggestions are welcome.

Back from the Philippines

Sat, 19 Feb 2005 18:41:56 -0500

Well, I'm back, so I'll be starting work on the Faldon rewrite again in the next few days. I'll answer any questions about the trip in the Comments section, since I'm not really sure what to go into detail about and that'll be easier than making a really long post. :)