I've been gone for far too long. I'm in my final semester as an undergraduate, and I must say that I've been feeling a little down. Living in Michigan (United States) means that I'll soon be out in state with over 15% unemployment. At least we're the best at something... being the worst. Luckily though, I live in Ann Arbor, which is likely my best hope at getting a job in the state.
Though, Michigan does have a lot of nice things, especially when you look at our countryside and natural aspects. I believe we have the most/largest fresh water lakes in the world.
Anyway, I'm back; I've fixed my installation of Eclipse on my laptop; and I've actually started thinking about this project again. I've got about two months of archived rec.games.roguelike posts to sort through. I'd also like to separate my class that deals with the display and make it a little more robust. I can see it being the starting points for many of my other projects; such as artificial life simulations. Another long-term goal is to have some sort of framework, a skeleton, so that I could quickly make a roguelike game for a 7dlr competition without having to start from scratch. I've never been that into using other people's libraries, mostly because I feel that any problems I have to solve will help be get better footing as far as coding goes. I don't mind reinventing the wheel, at least, when I don't have a deadline.
5 comments:
It's good to see that you are still pursuing this. I've been wondering where it would go.
Just figured I'd chime in with some encouragement and remind you that there are people out here who are interested to see what you've got to contribute. Post freely to RGRD if you hit any snags.
A novice programmer was once assigned to code a simple financial package.
The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.
When the master asked about this, the novice became indignant. "Don't be so impatient," he said, "I'll put in the financial stuff eventually."
(from The Tao of Programming.)
Just so you don't work too much on making it general, the focus should be on something that works.
I want to see this work. So tell us more!
Most of my conceptual snags surface when I try to deal with 3 dimensions. I know that roguelikes usually don't deal with this. I'm dealing with light sources right now, and as soon as I cast light from one dimension to another, it seems to add more complexity to the code. Lights would only ever be fully 'drawn' when they are turned on/off (when the map is loaded) and if you move through a light's radius, it would only draw/undraw a single ray, cast at the user. (otherwise it would just be wasting huge cycles to redraw the light that's not affected at all)
What if I did a preliminary version in only 2D? (how roguelikes are typically done) My implementation of a 3D environment would be very similar to how it's handled in the newest versions of Dwarf Fortress.
Also, I appreciate everyone's comments.
Also, thanks for the Tao of programming.
I doubt that anyone would mind a 2D version. Pull out an old copy of X-COM and see how little, outside of mood, the third dimension really adds. X-COM didn't do 3D very well, either, from explosions to pathing to FOV.
Dwarf Fortress started life two-dimensional, too. There's no shame in it.
When you do get around to true 3D, if you ever find the need, you'll notice that it suffices to approximate. Anyone can see when 2D FOV goes bad, but no one can tell if you've faked it vertically.
Even with naive FOV, you'll have no trouble revisiting all of your lights every time something changes, and you'll dodge a whole class of potential bugs. When efficiency finally becomes a concern, you can switch to something faster.
Post a Comment