Taking some inspiration from Roguebasin, yes I'd love to say any of these mechanics are actually original and mine alone but no, they aren't, yet. It just seems a waste of time to figure out the most efficient way of doing things when people have already found them out, I've taken algorithm ideas from the web but programmed them myself apart from the ones that are included in the XNA platform.
Anyway I got a bit distracted, yes Dijkstra, he was the man who came up with a solution to finding the shortest path between two points on a graph. I've adapted this idea to produce an "AI map" which allows a monster to use the map to head towards it's goal, at the moment I have just implemented the player as a target, so the monsters can now navigate the terrain and find the player from anywhere on the map, hurrah!
At the moment though the combat system is in it's infancy and only one way so the poor little monsters don't stand a chance, boo!
Soon I'll put that right, oh yes, I will.
To keep to subject the idea of the AI map is quite powerful, one could for example make a map to flee from the player or to head towards an item and nab it or even head towards it's friends till there are enough of them that they think tackling the player is a good idea.
If I add a system where the monster is given a weighted chance of which map to follow, perhaps for a given number of turns or until another condition is met, then some quite interesting emergent behaviour could follow, that is until the player caves the poor little monster's head in.
Still to come - time/combat system...
Saturday, 19 March 2011
Time for an upgrade
It was niggling at me, bit by bit, every time I went to Microsoft's api for XNA it kept saying version 4 and I knew I was on version 3.1, I kept putting it off like one of those awkward conversations, until I decided to take the plunge.
Taking the appropriate steps, like crossing my fingers, making a backup and praying to the Tetris God I dove in head first.
It went quite painlessly to be honest, there was one minor change in one of the spritebatch methods (the method's that display 2D sprites on screen, apparently additive alpha channels were gone and it is now multiplicative), half an hour got the code working again.
But that wasn't all I wanted to upgrade, I was also interested in perfecting the lighting algorithm before I got on to anything serious like AI as it will also be acting as my line of sight algorithm, looking through the various algorithms on roguebasin. I decided to go for Restrictive Precise Angle Shadowcasting because it claimed to produce no artifacts(glitches), was fast and I actually understood what it was trying to do, so debugging my code would be easier.
It sounded very simple, you work out each eighth of a circle seperately, you assign the cells angles by dividing 1 by the number of cells in the row and assigning start mid and end angles, if the square is a blocking square ie a wall, you say that all cells after that have angles between the and blah blah blah, click the link if you want to see the details.
After implementing it, I seemed to be getting artifacts, so I studied the code of the guy who has actually implemented it and it seems he omitted to mention that you need to check if the cells in the previous row were blocked. So a few typos in my code and many hours later, I ended up with a fully functioning lighting system.
Still on the horizon, monster AI and time/combat system.
Taking the appropriate steps, like crossing my fingers, making a backup and praying to the Tetris God I dove in head first.
It went quite painlessly to be honest, there was one minor change in one of the spritebatch methods (the method's that display 2D sprites on screen, apparently additive alpha channels were gone and it is now multiplicative), half an hour got the code working again.
But that wasn't all I wanted to upgrade, I was also interested in perfecting the lighting algorithm before I got on to anything serious like AI as it will also be acting as my line of sight algorithm, looking through the various algorithms on roguebasin. I decided to go for Restrictive Precise Angle Shadowcasting because it claimed to produce no artifacts(glitches), was fast and I actually understood what it was trying to do, so debugging my code would be easier.
It sounded very simple, you work out each eighth of a circle seperately, you assign the cells angles by dividing 1 by the number of cells in the row and assigning start mid and end angles, if the square is a blocking square ie a wall, you say that all cells after that have angles between the and blah blah blah, click the link if you want to see the details.
After implementing it, I seemed to be getting artifacts, so I studied the code of the guy who has actually implemented it and it seems he omitted to mention that you need to check if the cells in the previous row were blocked. So a few typos in my code and many hours later, I ended up with a fully functioning lighting system.
Still on the horizon, monster AI and time/combat system.
Sunday, 13 March 2011
I've seen the light!
Or rather anyone in the game whose field of view sees the light from a light source can. Dungeon now looks blank outside of the light radius, except for walls which remain on the map whether you can see them or not. Light radius algorithm also acts as a field of view algorithm.
Unfortunately I'm not quite happy with it, at the moment it spreads rays from the centre of the character and counts a square is in view if the square is traversed 1 pixel along the line, unfortunately that produces situations where A can see B, but B cannot see A.
I'll revisit it in the future and come up with a better algorithm that doesn't visit the same squares multiple times, but the time being something that functions is better than something that doesn't.
Monsters have been displayed on the map and carry their own light sources, well monster type singular, a kobold, more will be introduced of course.
Still debating on the size of the graphics tile's I will be setting as standard, at the moment they are 25*25 which may be a bit large, I might take it down to 16*16.
Next up will be a combat system, first of all the player hitting monster and the monster dying, then figuring out some kind of turn counter and allowing the monster to fight back. After that monster hunting algorithms will be needed so they stand a chance against the over powered adventurers.
Unfortunately I'm not quite happy with it, at the moment it spreads rays from the centre of the character and counts a square is in view if the square is traversed 1 pixel along the line, unfortunately that produces situations where A can see B, but B cannot see A.
I'll revisit it in the future and come up with a better algorithm that doesn't visit the same squares multiple times, but the time being something that functions is better than something that doesn't.
Monsters have been displayed on the map and carry their own light sources, well monster type singular, a kobold, more will be introduced of course.
Still debating on the size of the graphics tile's I will be setting as standard, at the moment they are 25*25 which may be a bit large, I might take it down to 16*16.
Next up will be a combat system, first of all the player hitting monster and the monster dying, then figuring out some kind of turn counter and allowing the monster to fight back. After that monster hunting algorithms will be needed so they stand a chance against the over powered adventurers.
Wednesday, 9 March 2011
Slow and steady wins the race, right?
A couple more features have been added!
I should have a check list somewhere that I can tick off, but that sounds like more effort than it is worth at the moment.
First of all we have a main menu, it's not much, but it displays the menu items, then a method to boxes a String of text if the menu item is selected and then enabling the user to switch between menu options and implementing the change of the game from main menu to "dungeon" when New Game is selected.
Oh yeah, the boxes surrounding the menu items glow, well more of a pulsate I guess.
Second we have the scrolling, scrolling has been implemented to centre on the current character, scrolling the screen by 1/6th of the screen width if the character gets within 1/6th of the screens width. These options may change, or indeed be implemented as options.
I'm quite sure I want the characters to be able to be controlled independently, but in the main I want the player to have the party on follow and the other characters to act as support. Thinking about it I may introduce a party time mode, bit like bullet time, whereby you can control all of the characters at once independently.
I should have a check list somewhere that I can tick off, but that sounds like more effort than it is worth at the moment.
First of all we have a main menu, it's not much, but it displays the menu items, then a method to boxes a String of text if the menu item is selected and then enabling the user to switch between menu options and implementing the change of the game from main menu to "dungeon" when New Game is selected.
Oh yeah, the boxes surrounding the menu items glow, well more of a pulsate I guess.
Second we have the scrolling, scrolling has been implemented to centre on the current character, scrolling the screen by 1/6th of the screen width if the character gets within 1/6th of the screens width. These options may change, or indeed be implemented as options.
I'm quite sure I want the characters to be able to be controlled independently, but in the main I want the player to have the party on follow and the other characters to act as support. Thinking about it I may introduce a party time mode, bit like bullet time, whereby you can control all of the characters at once independently.
Tuesday, 8 March 2011
Just a sheep
It seems rather popular at the moment, opening your design decisions to the world. I don't have the hopes of attracting the masses to this blog, it's more a space for my thought processes to be nailed down and to document the journey.
In fact this first existed as just an OpenOffice document (you might be able to spot as OpenOffice insisted with it's red undulating scrawl that it be capitalised not just once but twice). This was mainly because when faced with the task of naming the blog a blank space just opened up in my mind and was flooded with possibilities, is this going to be my development blog, perhaps a space for all my programming attempts or was it going to be just this game, this Cogband-esque effort?
I think i'd pretty much decided it was going to be the page for just this game, for better or worse it might motivate me to completion.
I suppose you might want to know what kind of game I'm planning, well it's based on a category of games called roguelikes, except I have planned for a few deviations from the norm, using non-ASCII art for a start and actually having a plot, if the player ever finds out about it that is.
I suppose you might want to know what kind of game I'm planning, well it's based on a category of games called roguelikes, except I have planned for a few deviations from the norm, using non-ASCII art for a start and actually having a plot, if the player ever finds out about it that is.
Projects usually start small with some ambition, lets get a list of what I think is going to be included in this game.
- A starting roleplaying scenario to choose initial party composition, I'm afraid there is going to be a story.
- Multiple Party Members – with programmable actions.
- A Marching order that adapts to the dungeon layout.
- Adjustable and adaptable weapons, upgradeable via cogs, pipes, valves, blades and other components. Inspired by Resonance of Fate.
- Upgradeable towns.
Then the standard stuff
- Combat system
- Randomly generated dungeons
- End game goal.
- Deep and varied equipment
- Customizable characters – Via skill trees and other means.
- Stat allocation
So far I have- A window that shows a stats bar at the bottom of the screen,
- The ability to change which character you are controlling and which is being displayed in the stats screen.
- A very poorly randomly generated map.
- Detection of characters bumping into walls.
- Window that works with adjustable tile sizes and map sizes.
Next
Work on camera and scroll bars if necessary to view dungeon. Centring on current player optional of course.
Menu for launching the game/load/save.
One big thing about my code, is I'm trying to make as many things as possible optional or at least adjustable, probably going to have the biggest option menu ever.
Subscribe to:
Posts (Atom)