(broken) los, (sorta) working combat, and other misc features

I've added a stab at some basic line of sight using a couple ideas. My first thought was to use the midpoint circle algorithm to generate the list of end points which I would then run traces along using Bresenham's line algorithm to generate the points. That of course generated a very pretty circle without nearly enough traces to cover the actual interior area.

Round two, generate a circle of end points using ol' fashioned cosine/sine, stepping the angle by an educated guess (Pi/(Radius^2)) and then trace to those end points using Bresenham's again. This generated slightly better results (near perfect @ 4 > Radius <= 8 or so), but anything other than that small set of magic numbers causes holes due to Bresenham's skipping. Next step is to just breakdown and write a trace that correctly touches all cells, and will give me the flexibility to handle various 'edge' cases depending on the angle of the trace (stuff like illuminating the walls of a corridor). For now I'm living with half-working solution #2, telling myself I have much bigger fish to fry...

From roguelike

At any rate, adding even broken LOS makes a huge difference in the feel of the game, and adding the various bits starts to glue everything together. More stuff keeps catching me unexpectedly, such as the seemingly simple combat text. When to capitalize, when to not, arbitrary formatting of strings based on various attack attributes, etc all add up to a bit more than you'd expect.

at any rate, basic combat is in with some bells and whistles. Goblins all get daggers - which they drop on death of course, although you can't pick them up, rats get their claws, and you the daring 'DEBUG' get your amazing hand of god which annihilates anything if it manages to hit.

making a game is... hard

I've finally gotten my "engine" up to the point that I'm actually starting to make a game of sorts, which is sort of like hitting a brick wall given that I haven't really thought much about how the game I want to make will actually work.

Take a simple attack for example - the attacker conceivably needs a set of values to represents how accurate their attack will be, how long that attack might take, and possibly how much damage that attack would do were it to hit successfully. Of course on the other side you have the victim, who conceivably has some sort of evasion or dodging properties, some damage absorption/resistance, and of course a health value which our attacker is attempting to deplete. It all sounds relatively straightforward right? Pretty much, except now we have to figure out what sorts of relationships all those properties have to each other, what sort of equation do we need to work out to make something that's workable much less balanced, or even worse... fun.

For the chance to hit I went with something pretty simple really:

- Accuracy (Some summation of various Attacker stats)

- Evasion (Another vague summation of various Victim stats)

- ToHitCap = Accuracy + Evasion

- ChanceToHit = BaseChanceToHit + ScalingToHitValue * (Accuracy - Evasion)/ToHitCap

Basically this means that if my accuracy matches your evasion then I have no advantage or disadvantage in hitting you, but as my accuracy starts to outpace your evasion it becomes easier for me to successfully hit. I have no idea if this is going to work very well in the long run, but so far it seems to be working well enough, and leaves me free to keep both those stats somewhat unbounded.

Now I just need to work out about 5 more of those sorts of encounters, implement an inventory system (or at the very least a weapon for the player to wield), and I might actually get to the point where someone might confuse this project for a game...

progress on the ol' roguelike

Been working on UI stuff mostly, added frivolous stuff like multi-colored strings, extended ascii character support, and more animation. You'd think it'd be completely wasted on a text-based game but it's keeping me entertained so that's really all that matters. Anyways, here's the first screenshot posted for posterity...

From roguelike

As you can probably see the executable is currently named aethrya, which I now think is pretty crappy for a title (and I really have no idea where it came from), but I've been too lazy to change it (and I keep telling myself it doesn't really matter until I get to the point where I want to release something anyways). According to source control the project officially started on August 12th 2007, and I've only recently picked it up again as of a couple months ago. I've spent quite a bit of time working on creating the base engine parts that are independent of the game to be made (honestly I have no clear idea what kind of game I'm actually going to make yet), which has been quite a bit of re-inventing wheels and whatnot - which has been incredibly educational.

I've been working professionally as a game developer for over six years now, and during that time I've always worked with existing engines, which means I end up taking a ton of functionality for granted without ever getting a chance to dig into the how/why. From simple stuff like templated data structures to more complex reflection systems and even garbage collections, it's been highly entertaining, educational, and a bit humbling.

I'm not sure I'll be inclined to start this sort of endeavour from scratch again in the future, but I'm definitely glad I've put the time into this effort, even if it never matures into an actual game someday - and I strongly recommend anyone with too much time on their hands to reinvent a wheel from time to time. Jeff's post at Coding Horror on this is a bit more compelling than my own: http://www.codinghorror.com/blog/archives/001145.html.

Bit of irrelevant trivia - the player is currently bright red to test out the '!' for bold colors on the TextColor property importing. Exciting stuff, really!

tools for starting a new c++ project

Here are some tools I recommend for anyone starting up a new project (on Windows), most of which are free for personal use or somewhat cheap...

Perforce (http://www.perforce.com/) - source control that's easy to setup, easy to use, and has a free personal license.  I know many programmers don't see the point of source control for small personal projects, but I find it invaluable.  First and foremost having a changelist history will become invaluable as your project grows, and it also helps you pick up where you left off when you happen to have months in between development.

Visual Studio (http://www.microsoft.com/Express/) - even if you don't use this for primary editing (I use slickedit for actual code writing) it's invaluable for managing projects/compilation, and the debugger is invaluable.  If you're not down with using VS for whatever reason, you can always go the mingw route (http://www.mingw.org/) and compile using gcc + makefiles.  I've heard mention of Code::Blocks (http://www.codeblocks.org/) as an IDE to use with mingw, but I haven't tried it myself.

Slickedit  (http://www.slickedit.com/) - this has been my primary IDE for nearly a decade now.  At first glance most people don't see the point, but the beauty of this program is that you can configure exactly to what you like, and eliminate the rest.  If you don't want to spend money however, there's plenty of other free/cheaper options out there, but your best bet would probably be XEmacs (http://www.xemacs.org/).   It's not pretty, but it can do pretty much anything you could ever want in an editor.

Jira (http://www.atlassian.com/software/jira/) - this is a fairly powerful issue/bug tracker that has some decent licensing options (right now they have a 5-user for $5 promotion actually).  the UI is a bit brutal, but it's all web based and definitely has all the features you'll need (plus plugin support for everything else).

auspicious beginnings

Not much to say, just getting the ball rolling...