Plugging away

I know I’ve been rather sparse in posting of late… lots going on, not much energy to spare.  As things calm down on various fronts with the approach of winter here in Minnesota, it should pick up again.  Having my annual tussle with seasonal affective disorder hasn’t helped much, either… that should disappear here shortly as the length of day starts to stabilize again.

Sandwiched between other tasks and distractions, I’ve been continuing to plug away at that XNA project I’ve mentioned a few times in the past.  It’s something I can work on for as little as a half-hour or so and achieve something, and yet drop at a moment’s notice without even a tinge of guilt.

A brief list of my latest and current tasks/goals, since there might be someone out there vaguely interested…

• As I mentioned briefly a couple weeks ago, I added “seamless zoning” to the application.  Currently, it works as follows…

The application can track up to 16 “zones”, which are simply square regions of a uniform size (currently trying it with grids of 50 tilesx50 tiles).  Nine of those zones will always be active, the other seven are for managing transitioning and data loading more smoothly.
When the character first enters the world, the basic layout of the 9 zones immediately surrounding the character is loaded from the server, rudiments like walls, doors, etc.  State information (whether a door is open or closed) and transitory objects (other players, NPCs, items laying on the ground) are sent later, based on more specific location and line of sight information.

As the character moves from one zone to another, new zones are loaded into “open” slots to keep an active 1 zone “buffer” around the character’s location in play.  Zones which were loaded but moved outside the buffer area are just marked as “stale”, so that if the character moves back in that direction in a short time frame, a request to “refresh” the zone based on actions which took place in the interim can be sent instead of having to reload the entire zone.  Once all 16 slots are in use, the oldest “stale” slots start to be re-used.

For example, if a character is in zone (10,10), the following zones would be in memory:

(9,9) (9,10) (9,11) (10,9) [10,10] (10,11) (11,9) (11,10) (11,11)

If he then moves to a tile that is located in zone (11,10), three new zones are loaded, and three old zones are marked as potentially “stale”, denoted by {}:

{9,9} {9,10} {9,11} (10,9) (10,10) (10,11) (11,9) [11,10] (11,11) (12,9) (12,10) (12,11)

If for some reason he turned around and moved back into zone (10,10), the basic data for the (9,x) zones is still fairly readily available… the only potential issue should be any events in those zones that changed the core structure of the zone (explosions?)

Pretty rudimentary, like I said earlier, but it seems to work okay so far, within the other limitations of the app at least.  I doubt it scales all that well, but for a hobby/test application it should be adequate.

• Switched over to more of a web-based network paradigm.  While the socket class was working, it was becoming somewhat of a pain to be going back and forth writing code in two separate apps.  What I’m currently trying is simple calls to web pages (php pages, actually), sending and returning whatever data I happen to be working with at that moment.

Now, why I’m finding it easier to write standalone php pages to perform discrete tasks, than I did to write discrete C classes/functions as part of a server app to perform those very same tasks, I really don’t know… I just know that it has proven more workable for me, and therefore, that’s the route I’m going to pursue for the moment.  It won’t be all that hard to go back to the other code, when it proves necessary.

The code to implement this on a rudimentary basis is so dirt simple, it’s almost criminal… I don’t even bother doing anything in the constructor at present, and it’s working fine…

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Net;
using System.Web;
namespace TestEngine
{
  class WebAccess
  {
  public WebAccess()
  {
  }

public string PageLoad(string reqURL)
  {
  string strURL;
  string strResult;
  string strResultTemp;
  HttpWebRequest wbrq;
  HttpWebResponse wbrs;
  StreamReader sr;
  int xx;

wbrq = (HttpWebRequest) WebRequest.Create(reqURL);
  wbrq.Method = “GET”;

wbrs = (HttpWebResponse) wbrq.GetResponse();
  sr = new StreamReader(wbrs.GetResponseStream());
  strResult = sr.ReadToEnd().Trim();
  sr.Close();

// strip off excess http/html in response
  xx = strResult.IndexOf(“[START]“);
  if (xx > 0)
  {
  strResultTemp = strResult.Substring(xx+7);
  xx = strResultTemp.IndexOf(“[END]“);
  strResult = strResultTemp.Substring(0, xx-1);
  }

return (strResult);
  }
  }
}

Again, not exceptionally robust, but adequate for the present and fairly easy to expand…

• Modifying my tiling code to more fully incorporate wall/edge data.  I’ve decided I want to allow “thin” walls… I already have a tile structure that tracks which edges face onto a “filled” tile as opposed to which do not, which was added to make the lighting code a little easier.  However, as things stand, while I can draw a thin edge wall, it’s utterly transparent to the other processes… neither light nor movement gets blocked at present, as you can tell from the “shell” of wall segments near the NPC in the upper part of this screenshot.



In particular, I want to be able to have different textures on each side of a wall segment, which should be simple, and I want to keep wall segments from being lit that face away from the light source, but are attached to floor segments that should have some lighting… two examples near the “doorways” in the screenshot below.  (I should try adding a slight yellow tinge to the outdoor light… that white is supposed to be “sunlight”, but it looks more like fluorescent cafeteria lighting to me right now…)



Shouldn’t be hugely difficult, but since I haven’t looked at that code for a while now… ah well, worst case, I just go back a rev…

• I want to add some “paper-doll” capability to the code.  Probably just start with my poor overused “generic fighter” sprite, and make it so the weapon, cloak, and some off-hand items like a torch and/or shield can be added and removed.  Start simple, within the (very) limited boundaries of my artistic ability to create new pieces/parts, and accrete from there.

I know, simple stuff, but it’s fun to be able to just putz away when the mood takes me.  (And it fills the occasional blog post, tho I try to avoid doing that too often, since I imagine it’s rather boring to read.)  But, if you want to kibbitz, feel free…

About these ads