WWWWWWWWWWWW
WW....@....W
WW........@W
.@.........W
WW......@..W
WW.........W
WWWWWWWWWWWW
So I'm working on version 0.0.0.4 of Adventurer, and I know it's been just two days since my last update. But I just had to share some of the cool things I'm doing, and have already got done. If you want to, check it out at the http://code.google.com/p/adventurerroguelike page, I've got a little mid-progress file up. Some of the new things I've got done already are: potions are working correctly, multiple monsters, monsters respawn, a scent trail system, a message system, and some optimization code. Next up is a sound system, and the aforementioned importing of libraries of creatures and items. I'll throw in whatever else I can. I want to keep a weekly major update schedule.
Let's go over this.
Potions work. You can [e]at them, which refills your health by 5. Monsters pick them up and know how to use them too. If you manage to kill one before they can drink what they've got, they'll drop everything in their inventory.
There's multiple monsters that respawn now. The level starts with five, and after a mystery number of turns, there's a random one out of the number of creatures on the level chance of spawning a new creature. The creature AI got some updating so that they can handle having others on the board with them. There's still a couple oddities, the most major being that they get a little confused if they bump elbows, take a 'wander' step, then are back at chasing the player next turn. They may also whack each other if they're both adjacent to the player and another creature. But overall, they play nice. That'll get a lot more work when I get around to working in individual personalities.
The scent trail system is an interesting and simple system that does a surprisingly good job. Put simply, every creature gives off its own distinct scent onto the tile it's on. Every cycle, the scent spreads. It does this by checking all tiles on the board, and setting each tile to the average of itself and its neighbors, minus some scent degrade. If a creature is on a tile where the scent is higher than their scent sensitivity, they'll know it's there and what it smells like.
I've got a message system working. You know that box in the bottom right that used to say only "Welcome to Adventurer"? Well, that's now your message box. Whenever your character notices an event that triggers a message, it ends up there. Later I'll put in an optional full message menu. Ignore the "You smell a goblin" spam in this one. Later, I'll code it to not bother with the obvious messages.
And finally, some optimization code that will be really useful in the future. See, there's multiple places it can process code. From the moment the player pushes a button, it heads down code paths. As it was before, it would have to complete absolutely everything before giving the controls back to the player. I figured it would start getting sticky feeling at some point. So I looked at the other place it can process: When the player isn't pushing anything, and it's waiting on a button press. So I put in another place in the code where I can put some processing, that will only activate if it has time for it. And it won't just throw it out if it doesn't have time; it'll queue up the cycles. That way, when it does have time, it catches up to where it would normally be. This should have almost nil effect on internal physics, and only when the player is rapid-firing button presses like move. But it should have a huge performance boost whenever it needs by putting off stuff for later.
And that's it. Expect the full 0.0.0.4 in a couple days.
A roguelike game inspired by the complexity of Dwarf Fortress, Adventurer seeks to provide a deep level of detail to an Adventurer in a setting more like Nethack. Realistic combat, an item crafting system, and a general attitude of improvising what you can out of what you have in order to overcome the challenges of the dungeon; that's what I'm trying to do with this. You can find the project at: http://code.google.com/p/adventurerroguelike
Friday, July 16, 2010
Tuesday, July 13, 2010
V 0.0.0.3 - Items and Optimization
What's that I hear? Is that an update? Why yes it is. Version 0.0.0.3 is up. I basically ripped the guts out of the game and stuffed them back in, in different places. I put things like Move where they belong, and simplified my 8 or 27 or so direction command sections into two simple sections. One lists those 8 directions, the second does a short loop and catches them all. 1/4th the size of before.
I've got items working now, too. Now, it's nothing too major at the moment. But it's a new toy you can play around with. The level generation creates five health potions, and puts them randomly around the dungeon. You can [,] pick them up and [d]rop them down elsewhere. You can even try to [e]at them. (I see eat and quaff as the same thing - one's solid, the other's liquid. So my [e]at command will do either.) There is a little bug though that's keeping potions from working perfectly. When I call the Eat command, it calls the Item object's Eat command, instead of Potion's Eat command. I need to look more into having Potion's Eat command override that, if the Item in question is a Potion.
0.0.0.4 should see that fixed, as well as a true inventory menu. Also, monster spawning. The most major thing I want to implement, though, is to have the game load in its libraries of default items and creatures from text files. That way, anyone outside the code can mod those text files, and mod in/out creatures and items. That should really increase the variety in the game. And you know what? I have some ideas for neat tricks I can get going without much work, I'll try to throw those in too.
I've got items working now, too. Now, it's nothing too major at the moment. But it's a new toy you can play around with. The level generation creates five health potions, and puts them randomly around the dungeon. You can [,] pick them up and [d]rop them down elsewhere. You can even try to [e]at them. (I see eat and quaff as the same thing - one's solid, the other's liquid. So my [e]at command will do either.) There is a little bug though that's keeping potions from working perfectly. When I call the Eat command, it calls the Item object's Eat command, instead of Potion's Eat command. I need to look more into having Potion's Eat command override that, if the Item in question is a Potion.
0.0.0.4 should see that fixed, as well as a true inventory menu. Also, monster spawning. The most major thing I want to implement, though, is to have the game load in its libraries of default items and creatures from text files. That way, anyone outside the code can mod those text files, and mod in/out creatures and items. That should really increase the variety in the game. And you know what? I have some ideas for neat tricks I can get going without much work, I'll try to throw those in too.
Labels:
adventurer,
c#,
code,
donationware,
free,
freeware,
game,
project,
roguelike,
rpg
Thursday, July 8, 2010
Items and Organization
WWWWWWWWWWWW
W.......@..W
W..........W
....@......W
W........!.W
W..........W
WWWWWWWWWWWW
*****
Items
*****
So it turns out it wasn't that hard to get the implementation of items underway. In fact, I've already defined the potion class, which is a specific type of item, so I'm learning more about inheritance. The level defines a Potion, a health potion, and starts to spawn these randomly around the dungeon. This is all fine and dandy, and it works perfectly, except for one bug: All those potions end up on the same tile.
I don't know whether it's a problem with the Random function, or something I'm doing with determining item placement, but I'll figure that out.
************
Organization
************
Another thing I'd like to smooth out, that won't really have an in-game effect, is how I'm organizing what goes where. For instance, the Move Creature function is sitting up in the main update code, instead of belonging to the Creature class. The Creatures and Items are created as part of the Level, instead of being a list of them on the individual Tiles.
0.0.0.3 should see these properly organized, and proof of concept Items should be up.
W.......@..W
W..........W
....@......W
W........!.W
W..........W
WWWWWWWWWWWW
*****
Items
*****
So it turns out it wasn't that hard to get the implementation of items underway. In fact, I've already defined the potion class, which is a specific type of item, so I'm learning more about inheritance. The level defines a Potion, a health potion, and starts to spawn these randomly around the dungeon. This is all fine and dandy, and it works perfectly, except for one bug: All those potions end up on the same tile.
I don't know whether it's a problem with the Random function, or something I'm doing with determining item placement, but I'll figure that out.
************
Organization
************
Another thing I'd like to smooth out, that won't really have an in-game effect, is how I'm organizing what goes where. For instance, the Move Creature function is sitting up in the main update code, instead of belonging to the Creature class. The Creatures and Items are created as part of the Level, instead of being a list of them on the individual Tiles.
0.0.0.3 should see these properly organized, and proof of concept Items should be up.
Labels:
adventurer,
c#,
code,
donationware,
free,
freeware,
game,
project,
roguelike,
rpg
Tuesday, July 6, 2010
Version 0.0.0.2 is up!
**************
Version 0.0.0.2
**************
After nearly three weeks of work on pathfinding, version 0.0.0.2 is up. It really shouldn't have taken that long, I was moving onto a project that is now a core system within the game, when I should have just thrown something quick up and work on other things. But no matter. It's done now, and now I can focus on the quicker-to-implement things. In fact, I went ahead and threw in a little bit of code already in 0.0.0.2. If a creature doesn't see the player, it'll path to where it last saw the player. If still nothing, it will go back to wandering around. It sounds simple, it wasn't that hard to put in. But it greatly enhances the overall effect and realism.
That's the kind of things I'm going to be working on for 0.0.0.3. Quick, easy to implement things, as well as some general code improvement. After all, Move Creature is still the Level object's job, when it should be the job of the creature itself. Another rough edge is that creatures are stored in an array, when they should really be a list. Switching from an array to a list should speed things up, as well as allow a limitless number of creatures. I think I can put in creature spawning for 0.0.0.3.
I hope to have 0.0.0.3 ready within the next few days, and again, the project can be found at code.google.com/p/adventurerroguelike.
Version 0.0.0.2
**************
After nearly three weeks of work on pathfinding, version 0.0.0.2 is up. It really shouldn't have taken that long, I was moving onto a project that is now a core system within the game, when I should have just thrown something quick up and work on other things. But no matter. It's done now, and now I can focus on the quicker-to-implement things. In fact, I went ahead and threw in a little bit of code already in 0.0.0.2. If a creature doesn't see the player, it'll path to where it last saw the player. If still nothing, it will go back to wandering around. It sounds simple, it wasn't that hard to put in. But it greatly enhances the overall effect and realism.
That's the kind of things I'm going to be working on for 0.0.0.3. Quick, easy to implement things, as well as some general code improvement. After all, Move Creature is still the Level object's job, when it should be the job of the creature itself. Another rough edge is that creatures are stored in an array, when they should really be a list. Switching from an array to a list should speed things up, as well as allow a limitless number of creatures. I think I can put in creature spawning for 0.0.0.3.
I hope to have 0.0.0.3 ready within the next few days, and again, the project can be found at code.google.com/p/adventurerroguelike.
Labels:
adventurer,
algorithm,
c#,
code,
donationware,
free,
freeware,
game,
pathfinding,
project,
roguelike,
rpg
Sunday, July 4, 2010
Pathfinding and Binary Search
.........
.........
....W....
.@..W..O.
..xxWxx..
....x....
.........
*************
Pathfinding
*************
I'm in the process of coding the main pathfinding code of Adventurer. You may be interested to know that it isn't as simple as "go here", or "move towards here". No, pathfinding is a problem that has plagued and intrigued coders for years. It handles the problem of figuring out how to get from point A to point B. I've looked at the Bresenham Line Algorithm before, and I use it for my line of sight calculations. But if I used a pure line for deciding where to go, creatures would endlessly bump into walls if it was the most direct route in a wall-less environment. That's unrealistic and not very fun.
So I'm looking into what is known as the A* pathfinding algorithm. What is this, you might ask? Put simply, it looks at all adjacent tiles, guesses which one brings it closer to the target, and looks at all adjacent tiles to that one. It keeps looking at the shortest paths it's found, combined with its guess at which is next. This bit of code is very efficient, and only rarely wrong, and only by a little even then. It's perfect for what promises to be the processing-heavy Adventurer.
Now, one crucial part of this is finding the lowest number in a list of numbers. I've found it's easiest for my purposes to keep the list in order, and just pluck from the bottom. The only problem comes when it comes time to put a new number into the list, i.e. the best path estimate of a tile. I have to find where it goes. Now, I could look each and every spot, and figure out where the number I'm putting in is greater than the number to the left of it, and less than the number to the right of it. This is known as a sequential search, and it's fine if you just have a few numbers in your list.
But this list is tracking all tiles adjacent to the ones it's looked at. this could be hundreds of tiles. But there's a nifty trick that works perfectly. It's known as a binary search. It works like this: Look at the number in the middle. If yours is higher, look only in the numbers to the right and look halfway there. Same if it is lower, but for the left side. Eventually, you'll find the spot where your number is right between two. Suddenly, 2 million items takes at most 20 cycles of this pattern.
So that's what I'm implementing in my code: an A* pathfinding algorithm, saving its values in a list with binary search. It might not be the absolute most efficient thing out there, nor the easiest, but it combines the two worlds in the best way I can think of. I can expand and fine tune it later if I need to.
I expect to have this implemented within a couple days in Adventurer, and have a new download up. Then that test critter can hunt you down much more intelligently. >:D
The game can be found at code.google.com/p/adventurerroguelike
.........
....W....
.@..W..O.
..xxWxx..
....x....
.........
*************
Pathfinding
*************
I'm in the process of coding the main pathfinding code of Adventurer. You may be interested to know that it isn't as simple as "go here", or "move towards here". No, pathfinding is a problem that has plagued and intrigued coders for years. It handles the problem of figuring out how to get from point A to point B. I've looked at the Bresenham Line Algorithm before, and I use it for my line of sight calculations. But if I used a pure line for deciding where to go, creatures would endlessly bump into walls if it was the most direct route in a wall-less environment. That's unrealistic and not very fun.
So I'm looking into what is known as the A* pathfinding algorithm. What is this, you might ask? Put simply, it looks at all adjacent tiles, guesses which one brings it closer to the target, and looks at all adjacent tiles to that one. It keeps looking at the shortest paths it's found, combined with its guess at which is next. This bit of code is very efficient, and only rarely wrong, and only by a little even then. It's perfect for what promises to be the processing-heavy Adventurer.
Now, one crucial part of this is finding the lowest number in a list of numbers. I've found it's easiest for my purposes to keep the list in order, and just pluck from the bottom. The only problem comes when it comes time to put a new number into the list, i.e. the best path estimate of a tile. I have to find where it goes. Now, I could look each and every spot, and figure out where the number I'm putting in is greater than the number to the left of it, and less than the number to the right of it. This is known as a sequential search, and it's fine if you just have a few numbers in your list.
But this list is tracking all tiles adjacent to the ones it's looked at. this could be hundreds of tiles. But there's a nifty trick that works perfectly. It's known as a binary search. It works like this: Look at the number in the middle. If yours is higher, look only in the numbers to the right and look halfway there. Same if it is lower, but for the left side. Eventually, you'll find the spot where your number is right between two. Suddenly, 2 million items takes at most 20 cycles of this pattern.
So that's what I'm implementing in my code: an A* pathfinding algorithm, saving its values in a list with binary search. It might not be the absolute most efficient thing out there, nor the easiest, but it combines the two worlds in the best way I can think of. I can expand and fine tune it later if I need to.
I expect to have this implemented within a couple days in Adventurer, and have a new download up. Then that test critter can hunt you down much more intelligently. >:D
The game can be found at code.google.com/p/adventurerroguelike
Labels:
adventurer,
algorithm,
c#,
code,
donationware,
free,
freeware,
game,
project,
roguelike,
rpg
Friday, July 2, 2010
Blog Launch for Adventurer
**************************
An introduction to Roguelikes
**************************
Roguelikes. They're one of the most amazing experiences in gaming you can have. They're often free, in both terms of software. Free as in freeware, and free as in open source. They're amazingly deep and complex, attaining quality of gameplay that is rarely seen even in commercial games of today. How do they do this? They dump the sound department, music department, texture department, model department. The entire world is rendered in ASCII tiles, also known as letters. But don't let this throw you off.
First, plenty of Roguelikes offer graphical tilesets. Some mods even offer isometric or 3D views. Second, the ASCII can be surprisingly beautiful when pulled off right. Third, ASCII is raw utility incarnate, letting you see at a glance what you're up against. Fourth, ASCII has its own charm in letting you visualize the various creatures, items, rooms, or whatever else you'd like, much like a book, instead of having the game's artists visualize it for you, with less than perfect results.
************************
The Launch of Adventurer
************************
These are the chronicles of one coder's journey into the making of a Roguelike. He has big plans for his pet project, venturing to recreate the very structure of the universe in a computer's algorithms. This is no ordinary attempt at simulation, for this is a game, a glourious experiment into what it would be like to be an adventurer. No restraints beyond the world's laws. And some things can bend even those. No string parser telling you that you can't take ye flask. This is your quest, and ye can do what ye like, well-advised or not.
So go forth and Adventure!
******************************
Where's the Development at Now?
******************************
It's not finished yet, but it does have and will continue to have working updates that you can download and try out. It's an open source project done in C#, but you can just run the .exe file after extracting. Right now, I'm on version 0.0.0.1, the initial release of what I have done so far. Don't expect it to be a complete game at this point, but it's definitely a start, and I'm continually working on it.
Dev team? What dev team? I'm just the one coder, and I have high hopes and plans, that I am constantly working towards. Any help is appreciated. Especially donations. If I get enough coming in, I can host it on its own site. Or do anything else the donors suggest, really. If you do donate, tell me what name you'd like to be called as and a simple message or shout out, and I'll post Blog updates of who donated, how much, and what they'd like to say. I suggest $5.00 donations, but don't go below $0.30, PayPal fees exceed the donation then. Donate to me at PayPal at zahru.tesla@hotmail.com. It'll be much appreciated.
***********************
How do I Get This Game?
***********************
It's not finished yet, but you can keep up with the development and download the working game files as they come at Google Code. The project has its own page at code.google.com/p/adventurerroguelike. As of now, version 0.0.0.1 is out. It generates levels and has line of sight and fog of war. It has a foe you can fight. Soon, pathfinding will be implemented better and hostile opponents will actively pursue you.
*************
In Summary...
*************
It's a Roguelike. Get it.
Google Code:
code.google.com/p/adventurerroguelike
Donate to:
zahru.tesla@hotmail.com, at PayPal. You'll get your name recorded in the Blog if you like.
Feel free to give comments and suggestions, or even do some work of your own on the files. Show me, and I may just include your code and give special thanks.
Subscribe to:
Posts (Atom)