• entries
31
27
• views
26180

## Roguelike - mouse control and side project

ROGUELIKE - INTERFACE CHANGE

Small update for the roguelike project, well sorta. Im changing all the controls to a mouse based design and ditching the conventional keyboard shortcuts. Inventory and equipment management is far simpler now.. even though the nostalgia is gone :/ Movement is slightly clunky feeling though. I'm suspecting a possible bug in the alignment of the mouse to grid conversion.

I'm working on some visual ques to improve the use of the mouse. Simply highlighting the grid square the mouse resides on. I need to improve the logic and have it color coded. Something like a blue highlight being default and if the mouse is hovering over something attack-able, it'll red. If the mouse is over another interact-able such as an item or door it'll highlight green.

a slightly less noticeable highlight will light up each tile leading to the hovered over tile. Unfortunately I haven't implemented path finding yet. I've been kinda dreading this actually. I'll be going with a typical A* algorithm, it's what I've always used in the passed and am most familiar with with. I fear without implementing the path finder directly into my grid class, it might be too slow to be immediately calculated every time the mouse moves to a new square.

My grid class was designed as a random access interface and very brute force about it. You might say it'll be fine because obviously my LOS/FOW algorithm uses Breshenham's line algorithm to cast 360 rays around the player to determine the FOW each movement and the player can move rather fast. That's not entirely accurate, under those circumstances there is actually almost a 1 second stall between movements. I actually only cast an 8th of those rays, and use a anti aliasing style hack to keep the sight clean. This can really be notice in big rooms where the edge of view has a large edge. It's not a perfect circle and is very blocky.

My goal has been to keep things as modular / encapsulated and clean as I can through out the project to avoid nasty spaghetti code that might force a re write again. I want the pathfinder to use the grid class rather than be apart of it. I've got a few ideas on how to improve the logic behind accessing the grid and or implementing an iterator. Which might actually be a better considering the pathfinder and the line algorithm both access one tile randomly and then traverse from the one tile.

SIDE PROJECT

I'm gonna start a small side project to test and work out some of these changes in a less cluttered environment. I want to finally create some basic GUI elements as well, nothing bigger than basic buttons. I've already got several classes I've hacked together for the Roguelike project. I want to clean them up and improve their functionality.

The projects gonna be a basic old school rpg of sorts. The game will take place on a world map that has a series of way points. Each waypoint is an area that the player can enter, either a battle or a town. Basically the world map represent the campaign timeline. Each area / waypoint must be cleared before the player can progress to the next waypoint.

The player will be a 4-5 character team. The player can build the team out of a pool of characters. All of which can be recruited at the towns and will have unique abilities or stat progressions. Only one of each character can ever be owned by the player. The player can further equip the characters with items bought from the towns.

Battles will be automated with an old school rpg look. Think the old Final Fantasy series, with each team lined up on each side. Each character ; player or ai, will have a battle timer that determines when they can attack or use an ability. So things will be real time.

Nothing major, and probably won't even come close to being finished, just need something to test ideas with. This is just how I tend to learn ;)

Till then happy coding.

## Roguelike - Equipment System

Holy molly I just went through probably the most tedious adventure I've ever been through in my entire programming experience. Cutting out sprites and editing xml files is definitely not my forte. Alas in the end I've got a plethora of weapons and armors included in the game to test out my new ideas for the equipable item system.

All equipables distil down to either weapons or armors, rings and amulets are a little different but are basically armors. Weapons have a damage value and damage type, where as armors have a defense value and defense type with is really a damage type under the hood. rings and amulets don't have defense values though. Further each item can have one or two mods as well which aren't entirely tied to the item type.

I haven't fully planned out the mod system, I'm working on them in conjunction with how I want to do the potion, scroll and food items as well. Also the curses/ailment system will dramatically affect the types and amounts of possible mods too.

The vast majority of items except rings and amulets will spawn without mods and there will be a system to add these mods to them. There will be some unique items that spawn with specific mods all the time though.

I have the display panel for the equip pretty much finalized :) You'll notice each slot is show and off to the side of them are the mods and specific stat of each item, along with its value. In the screen, the sword = damage, the shield = defense, the boot = speed. You'll notice each is grey, the differing damage types color code these icons as well.

No download this go around, I just wanted to show off what's going on. I'll be putting together The rest of the item types and changing up the curse/ailment system a bit and have a nother release next time. Till then happy code y'all.

Another build, this time with a complete game? Almost, if you consider being able to go from start to victory a complete game. I think I've got 99% of the base skeleton in place and will be focusing a specific modules of the game from now on. As usual the game requires a numpad and runs in a 1280x720 window... I'll be addressing different resolutions soon. I promise.

Download the game and unzip it with your favorite zip program (I use 7zip). Run the appropriate visual studio redistributes in the C Runtimes folder, if you have visual studio 2012 installed, you probably wont need these. Then simply run the game and go

Pressing 'H' within the game will show all the controls that are activated right now.

Now on to what's new and what's next. Alot of the work is still under the hood and not completely visible. The biggest features is the addition of the boss and being able to win or lose. Losing is disable for the build as combat isn't stable enough, I want everyone to have the chance to try it out without dieing every time an ant charges you.

Next I'll be going back and reworking a lot of the item system, setting in concrete my plans for the system. I've been doing a bit of research and reading up on ideas and something I want to put some thought into is multiple uses. Even if the second type of use is just throwing the item. I don't have enough of it thought out to go into detail yet unfortunately.

the one last big change.... NO MORE HUNGER. I'm thinking as hard as I can for a need of the hunger system beyond it being a staple in roguelikes. My dungeons will be small, monsters wont respawn, I don't see scumming being a good reason with those factors. It feels more like a burden, a clock you're working against.

I'll go into better detail next time, just wanted to get a build out enjoy and till next time happy coding all.

## Roguelike - Refocus

OK I think I got it out of me, had a little fun messing around with the system and trying different ideas. Really needed that to clear my head and break past the tediousness of working on the same project for too long. Along with a huge event in my life that's been taking up alot of my time... well really it takes all my time and will for a while. But that's being a family :)

Getting back to the roguelike project. I spent a little bit of time looking over things and trying to get my head wrapped around what my plans were. I'm not sure I really have a final goal anymore, or if I really did. I'm attempting to distill the project down to the exact basics that would constitute a finished game. The struggle is finding that exact minimum while also have the minimum of what would be a fun game, and what is the minimum that is still expandable to include my big ideas.

While I contemplate the basic goals I took some time to work on menu, ui, and state components. Also allowing choosing what class to play as instead of only having the one player class. Finally expanded the inventory to allow more than just the 10 items and decided to drop stacking. I stripped almost all of the UI code I had in place and am working on modularizing it. The old code was almost entirely hardcoded and quite a mess.

As things settle for me, I'm hoping to have more time for the project, more frequent updates. Either way, time or not, my goal from now on is to get to a complete game state, no matter how basic it is. Then work on the fancy polish, gotta get my focus on the finish line back. This project is long over due, especially compared to the first iteration :(

## Roguelike - Dodge the Bullets

Hope everyone had a merry Christmas time. Just a quick entry to show another video. Basic AI makes the enemy monsters wanderer and shoot the player. The AI takes a coordinate used as an anchor to keep the creature in a specific area. Along with the range around the point that it's aloud to roam.

Well I'll admit it, I haven't had much time at all for the project. Finally sat down a couple days ago and got working on it. Then one night while playing Path of Exile I got the urge to work on animating the combat in the game. I wanted to add more feeling to the players actions. Just a simple slide animation. Attacking would cause the attacker to quickly slide towards the target then back into place. Like they just chest bumped them suddenly. Something more than just reading text and assuming who made the attack on who.

When I sat down yesterday I got another urge, and I honestly don't know why I suddenly wanted to try this out, but I did. I thought about making things real time, like Diablo or P.O.E. I threw some quick code together to allow the creatures to move freely from the grid towards way points. Clicking the mouse would set the way points and the player creature would move towards it. Collision checking and everything was implemented. The original system of using a grid and such was and is still completely intact and used more as a partitioning system now. I might even think about implementing a quad tree within its innards for speed if necessary or if I decide at all to bring fog of war back.

The controls were working more like League of Legends than Diablo though, click to move. Hit a key to activate an ability and click again to shoot in that direction. But it felt super sluggish, and increasing the speed of movement just made it clunky. Maybe adding auto attacking and or clicking on target to attack would've made it feel smoother. Maybe it was cause there was only ranged attacks and no melee.

I quickly scratched the way point idea and tried a dual stick design. Moving with 'WASD' and shooting / aiming with the mouse. This felt far smoother. The character was definitely more responsive and felt more in control.

After 12+ hours, a very late night, I now bring you a very basic prototype of a different idea. The original game I was designing is still there, just alot of the systems are deactivated at the moment to test the idea of going real time instead of turn based.

Try it out and tell me what you guys think. I'll be honest it's rather refreshing to me. Though I'm not sure which branch of the project I'll move forward with.

Once again the game is zipped up using 7zip but any zip app should be able to unpack it. If you don't have visual studio c++ 2012 installed, install the appropriate runtime redistributable in the C runtimes folder. Run the game from the Game folder, nothing else needs to be installed.

The game only runs in a 1280x720 window, and uses 'WASD' to move the player creature. and the left and right mouse buttons to shoot at the mouses position.

## Roguelike - Cave In and Missing the Target

Well I caved in, I re wrote the project. I'm even happier that I took the time to write the Grid class. It made what started as just a tinkering idea flourish into a complete rewrite. Estimating it only took me 3-4 days of coding too. Things are finally cleaned up, far from optimal but it gives me some breathing room and clarity. A time system will finally be, hell it partially is already.

I haven't fully got all the actions back in, else I would've released a build. What I do have so far works like so. Every creature has a turn delay. Performing an action adds to this delay. A creature can not perform any action until the delay returns to zero. The system happens seamlessly without the player even know its waiting as long as it might have to. Right now there's no delay between turns, which causes fast creatures to seem to move multiple squares at a time. I'll be trying out a delay before releasing, very short delay but something to notice what each action is that's being taken.

My first inclination for speed is to have a speed rating for each creature, not sure what I want to effect it though, or if specific items will effect specific actions. I want to keep it simple so for now, speed affects every action equally. Speed is rated as one equals the fastest and ten or more equals the slowest. Each action will have a base turn delay, which is multiplied by the creatures speed. A creature with speed one can move one space per turn, but a creature with speed five can only move one square per five turns. Right now it works just how I want it too.

Though I have one worry that I don't have enough functionality to test yet. Every action no matter how big the delay, happens immediately. I could see the delay being broken when it comes to really powerful attacks. What draw back does the player encounter if an ability is strong enough to wipe out all threats in one use. What matters if it has a 100 turn delay if it removes any threats that might have killed them during the delay? Like I said though, I wont know till it comes up.

I also redid the basics of the combat system. You can finally miss and so can the AI. Each creature will have a hit chance ranging from 0 to 100, and a defense rating that should range anywhere from 0 to ~200, though anything above 200 should be difficult to achieve if not impossible. The calculation I'm using issuccessful Hit = rand(100) < (hit / (hit + def) * 100)

For now defense only helps in dodging. I plan to incorporate a sort of damage reduction later like a sort of resistance. I want multiple types of damage, not just physical. Different weapons will have different attack properties. They will all act almost identical to physical damage except they use a different resistance parameter for reducing the damage taken. These will go along with the dungeon theme-ing. Ie a snow filled dungeon will primarily spawn creatures with ice based weapons.

Continuing the dungeon theme idea, I've implemented the finite set of floors. The bottom floor spawns the boss creature. Killing it wins the game and starts it over again for now. The player dieing does the same. The system uses a Boss parameter that identifies a specific creature that should spawn only once on the floor. I haven't done too much thinking about it but I might use it to add unique monsters to the game, one per floor. They'd have to be specific to each floor the way it's implemented but I'm thinking they could give alot more xp or even have unique items they only drop.

One last major change. I'm trying my hardest to stick to my coding rules of this project. Most of the major parts of the game are split into separate systems that contain and manage their respective data. This data should never be directly exposed and forcing the use of using the systems as an interface is a must. It helps keep things clean no more mingling code spread out amongst three system just to preform a ranged attack. Creatures no longer contain items, let alone have an inventory. Atleast not exactly. Creatures no have a handle to an inventory that is managed by the item system. They use id's and names to link the items, and higher level systems apply and remove the effects upon equipping or unequipping. In theory this will make it easier to script starting weapons and such on creatures.

Till next time, happy coding and I promise a build next post :)

## Roguelike - dungeon themes

An update before another release :) Putting alot of work into the new dungeon system / floor layout. I'm working on adding variety to the game and testing out some ideas that will have to wait for the next iteration of the game. Though the basics of it can easily be tested this go around. Each floor will now be generated using a theme configuration. Each theme will be randomly selected each time the player enters the floor.

I'm still keeping the idea of non persistent floors, the player can never return to a floor once they've descended. Though there will be a set number of floors, and a complete rework on how items and creatures are selected to be spawned. I'll be keeping this rather low, this isn't going to be the next OMG UBER ROGUELIKE ;) so expect something like ten floors max. With the same idea that you're descending the dungeon to find and kill the boss of the game. You win when this creature is slain, you lose when you die.

I'll be honest, I'm having a hell of a headache trying to implement the planned turn system. The way I've got things coded so far is very counter intuitive to the design. I'm contemplating just dropping the idea of speed and saving it for the next iteration, when I can design it in from the ground up. It's disappointing to me, but at the same time I'm feeling it'll take rewriting most of the game to make it work without causing a ton of bugs and alot of time fixing everything for one feature.

All in all I'm looking at finishing the themes design and finalizing the curse / status effect system. The later is pretty much complete, just needs UI and visual queue tweaks. After the next build I'll be taking a look into my original notes on what I wanted from this iteration and deciding if I go further or move on to balancing and polishing to finish the project. I hate to fast track the project, but like I said the design is making it more work than I'd prefer. I'm starting to feel starting the next iteration would be more worthwhile and easier to implement what I want.

Until then keep coding and happy Halloween to all :)

Phew that was quite the refactor. Creature system is almost 100% finished. I've left out the status/Curse system for this build. It's not perfect and feels clunky in its hacked together state. But beyond that everything but the dungeon it self is now defined and loaded from external xml files. The project will keep to that standard from now on.

I've put the code in place for win/loss conditions, though they are ignored at the moment for testing purposes. This build too is just to show off and let you see what it's actually like. I unfortunately had a couple last minute decisions about how to handle the turn system and actions. So the idea of queuing and using energy to perform everything from moving to dropping items is by passed as well.

Disappointments aside :( . I've done a little tweaking to the LOS algorithms and its looks cleaner now. No more strange cases where you can't see corners even standing right next to them. The UI has been cleaned up and rearranged a bit differently now. Notice the players information is in the right side panel. The bottom right panel is still the players inventory. Information about the players inventory is a bit more obvious and clear. The center panel that was originally for the players information is now for displaying examination information. Hovering the mouse over a creature or item that is visible will display it's information here.

INSTALLATION

As usual the game folder and runtimes are packed together with 7Zip, though and zip program can open them. Unzip them where you like. If you don't have visual studio 2012 installed, run you appropriate redistributable from the "runtimes" folder. either x86 or x64.

Enjoy and feel free to let me know your thoughts so far.

## Roguelike - grid abstraction

Bugs and frustration.... Looks like I need to do a little more cleaning before releasing. Been so long since I worked on the creature system, I had forgotten how I designed the current template loading. There's a bit of work to be done to bring it inline with how I refactored the item system. Not to come empty handed I figured I'd write about a couple templated classes I designed and implemented over the summer delay.

Ive been writing 2D games since the get go. I can't count the amount of times I've coded a tile map. Every time it's almost the same exact map class over and over. I decided to write to kinds of tile map style classes that would be reusable in future projects and bring cohesion to how I store and position the various objects in the game.
Grid and UnorderedGrid

Each stores cells that are a bounding box in the world and the 2D coord within the grid that it resides along with a templated data parameter. The grid makes sure that all objects stay within a certain bound. Has access to position data and generic querying of objects. The basics of Everyone of my tilemaps and probably all yours aswell ;)
template class GridCell { public: GridCell(); GridCell(cii::GridCell& gridCell); GridCell(sf::Vector2i newGridCoord, sf::Vector2f newWorldCoord, sf::Vector2f newWorldSize); cii::GridCell operator = (const cii::GridCell& gridCell); void init(sf::Vector2i newGridCoord, sf::Vector2f newWorldCoord, sf::Vector2f newWorldSize); sf::Vector2i getGridCoord() const; sf::Vector2f getWorldCoord() const; sf::Vector2f getWorldSize() const; void setData(T& newData); T* getData(); private: sf::Vector2i gridCoord; sf::Vector2f worldCoord; sf::Vector2f worldSize; T data; };

The Grid class is the basic tilemap class. You initialize it to a specific size, giving it a cell size in world coords as well. It'll then generate a 2D grid of cells giving them all a grid coord and world coord based on the cell size and that the starting cell is always at 0x0y.

It doesn't initialize the data though. I though about having it except a factory method or something that would allow setting a default state to all the data. After looking into how it would be used, all the data gets set right after being initialized and almost all of it is unique. It seemed counter intuitive to do so.

This also allows grid to be used purely as a coordinate system. It doesn't have to store information other than position of each cell if all you need is to be able to get position data.
template class Grid { public: Grid(); void init(sf::Vector2i newGridSize, sf::Vector2f newCellSize); void clear(); cii::GridCell* getCell(sf::Vector2i gridCoord); // returns the cell at the given gridcoord. / returns NULL if the coord is invalid or cell doesnt exist. cii::GridCell* getCell(sf::RenderWindow& window); // returns the cell at the current mouse position using the given window and its current view. / returns NULL if the coord doesnt exist or is invalid. std::vector*> getCellsInArea(sf::Vector2i startCoord, sf::Vector2i areaSize); bool isGridCoordValid(sf::Vector2i gridCoord); sf::Vector2i getGridSize() const; sf::Vector2f getCellSize() const; private: sf::Vector2i gridSize; sf::Vector2f cellSize; std::vector> cells; };

The big difference between the two classes; Grid initializes every cell in the grid and they will always be available, whether data is present or not, UnorderedGrid doesnt actually initialize any cells and allows adding them one by one. Like grid though, UnorderedGrid follows the same rules that only one cell can exist per coordinate on the grid. Think of Grid being used for terrain, and UnorderedGrid is for things like items on the ground. Items are scattered about but my stay within the grid and follow the rule of only one per cell.
template class UnorderedGrid { public: UnorderedGrid(); void init(sf::Vector2i newGridSize, sf::Vector2f newCellSize); void clear(); // getCell() / getCellsInArea() returns null if the gridcoord is invalid or the cell doesnt exist cii::GridCell* getCell(sf::Vector2i gridCoord); std::vector*> getCellsInArea(sf::Vector2i startCoord, sf::Vector2i areaSize); bool isGridCoordValid(sf::Vector2i gridCoord); sf::Vector2i getGridSize() const; sf::Vector2f getCellSize() const; // push tries to adds a new cell with the given data. return false if the coord is occupied or invalid bool push(sf::Vector2i gridCoord, T& data); // removes the cell at the given coord from the grid. return false if the coord deosnt exist or is invalid. bool pop(sf::Vector2i gridCoord); private: sf::Vector2i gridSize; sf::Vector2f cellSize; std::vector> cells; };

Since I've implemented this into the game, it's helped with quite a bit of clutter removing alot of copy pasted code that existed in every system. And for something that only took a day to put together and test it's been satisfying and cant wait to put it to use in other projects. It should help speed up development which is always I nice feature.

Next time I'll go into the TemplateFactory I wrote for the item system and am having a headache refactoring the creature system to use. Till then keep coding and stay classy.

## Roguelike - Big rewrite progress

Been a while. Still don't have as much time as Id like, but I've been making some progress. More of a refactoring rather than a rewrite. Tore apart how the entire item system loads templates, creates items and the whole drop system. The entire system has been parametrized and is completely defined and loaded from external xml files. The goal being to move more and more to an engine framework.

The UI pertaining items in the inventory has been cleaned up to. Every item displays, displayable, parameters along with description text that is loaded from the same xml files. A few other changes will be left for later. Such as a bigger inventory, stacking and equipment comparison.

I've done a lot of cleanup in the code base. lots of little things to help myself out. Just cleaning up header files, commenting and renaming several functions to make it clearer what they do exactly.

I've also set the win condition for the game. There will now be a finite set of floors. The bottom floor will contain a boss that must be defeated to free yourself from the dungeon. The dungeon will still be regenerated on each floor and no way to back track. I'm hoping this will still keep my goal of a fast game yet casual game. I've also gone with smaller floors,, from ~50x50 to 30x30 maps. As I don't plan on an auto explore feature it helps cut back on the tedium of exploring useless area after useless area.

Along with making everything mod-able and more of an engine with a game built from it. The dungeon will use loaded parameters as well. Each floor will have a defined them, list of creatures that can spawn. Definition for the type and amount of features that can spawn on the floor. Each floor will have a list of creatures that can spawn on it. This could allow mini bosses on certain levels aswell.

I'm hoping to have enough time to finish some features and have a release by next weekened... by the 5th. It's been fun again develing back into the code and actually getting things done. Summer is finally coming to an end letting me have time again.

Planned Features Before Release:

- Double the inventory space.
- Stackable potions and food in the inventory.
- potions that cause over time affects
- making the creature system completely define/loaded from xml files.
- making the curse/aura/status effects system completely define/loaded from xml files.
- completing the creature stats system.
- completing the inventory system.
- completing the curse system.
- clean up the combat algorithms.
- implement the new turn system.

Alot of what I have planned to work on next revolves around the creature system. Most of it is very simple, just a matter of taking the time to code it. Some of it is just re plugging systems in. The major and only no sure of feature is the turn system. I have the concept and plans all laid out for it. I just don't have it clean enough in my head. A portion is a bit muddled with the fact alot of the coded auto assumes it's the player performing the action. The AI can only perform moving and attacking right now. Making the change to allowing it to do anything the player can and displaying it properly I fear might take more than I'm thinking. Though I may just be psyching myself out.

Till next time, keep coding and never give up.

## Roguelike Back to Development

Alright I'm probably coming off like a 3 year old that can't decide; pool or park? Those two comments on the last entry have been stuck in my head this whole time. So much so that I just couldn't commit to another project, even if small and temporary. Instead I've been spending this whole time making small tech demos, testing ideas and trying to get my ideas in order.

I'm still not going to do a rewrite, not completely. There's one big rewrite but it's higher level, and should of been thought of from the get go. A turn system that actually handles speed. Others are a bit more features and refactoring of the games systems. Gases that effect whatever they come into contact with. Every system will be as data driven as possible, moving towards more of an engine than a game.

TURN SYSTEM

The original system was literally turn based. The player takes a turn performing whatever action, then each creature gets a turn. There was no speed variance at all. Everything took just as long as everything else.... one turn. From now on everything from walking one step to attacking, drinking potions, putting on armor, will take different amounts of energy to perform.

Each turn of the simulation will divvy out an amount of energy until the player has enough to perform an action. Then the player can perform an action they can afford or wait and store up more energy. AI creatures are also doing the same during simulation. This way fast characters, or quick actions can be performed before slower creatures and react. A fast swordsman could attack more than once per it's opponents attack.

Once a creature, player or AI, have enough energy to perform an action. They take priority of the simulation until they perform an action or decide to idle, the simulation won't divvy out energy.

CURSES

The main focus one the refactoring is the creature system. A lot of it will be getting split up and with cleaned up interfaces. The old status effects, that handled poison and such over time effects. Is going to be curses now. With a cleaner interface and design.

ENGINE

Several of the system will be scripted/data driven. Making the game more moddable, and quicker for me to edit and design. Creatures, items, and a couple configuration properties are the base plan. The whole system when I'm done.

...AND A LOT MORE

until next time, keep coding. I'll be going into more depth once I got a couple things finished first.

## Uncaged, Too Much Time and Still Going Backwards

So much has been going on in the last month and a half for me. Was back on that damn roller coaster, of ups and downs for a bit there. Too many good things, made it hard to notice how crappy I put that roller coaster together. Though I keep my head up and moving forward. Just now I'm walking rather than running towards the future. Bit off way more than I could chew and didn't realize till it had burned me to the ground.

Vague talk of life aside, Rogue is still on hold. I'm going through with the little war game I mentioned last posting. Something simple to clear my head and test a couple ideas I have for cleaning up rogue and implementing a couple features. Looking over the code now after a month away from it. The glue tying items, creatures, and the map together to allow things like ranged attacks and such is a huge mess. There's alot that should be contained to just the creature system, but parts are hacked into both the item system and dungeon systems. Just tracking down why a thrown potion wouldn't apply its effects to the hit creature was a massive headache. and came down to some code in the dungeon system.... had nothing to do with the item or creature system....ugh.

I was bored and just with half an hour I didn't want to start on either project just to have to leave it when I finally got going. So I put a little more flexibility into the particle system that is used to splatter blood and pop the floaty text you've been seeing in the game demos. and a very rudimentary Arkanoid clone for testing. I had to have something to show off right :)

Phew, with that off my shoulders, its time to code.
Till next time, keep coding and don't quit.

## Roguelike delayed

Oh work, work work work. Time has been flying, it's been almost 3 weeks, and honestly I haven't had time to work on the project. I picked up a ton of hours at work trying to bring in some extra cash :). What little time I have I've been devoting to the family. Another downer was loosing my secondary monitor, thank god it wasn't my main. Gonna save up for a new main screen now, I want something with a bigger resolution. along with that much needed system upgrade. Think it's been since 09 when I built this rig.

I'm probably gonna put roguelike on hold till the end of the summer season here. Not sure if I'll even have time to focus and work on a smaller project. If I do I'm gonna make an even simpler of my turn based strategy game conquest. The same project I started, but turned into the first roguelike project. Imagine a simple version of risk meets total war and civilization

It takes place on a 8x8 sized grid, that represents the world. The goal is to control the whole world. Each of 4 players, starts with just a couple nodes. They can attack from nodes they own and take control of other nodes. Each node can be constructed upon by a single structure; town, castle, farm, mine, etc.

Each turn is split into different phases; attack phase, move phase, build phase, train phase... Only one action can be performed per node each turn.

Probably just gonna be an idea till I can get back to roguelike 2....

## Roguelike - Status effects and carnage

A short update this time around, I modified the LOS system to be able to use it for targettting. Then I ruined it and spent alot of time fixing some stupid bugs.

Just updated the effects/particles to allow sprites and added some carnage to the game to test it out. was a real quick effect, that'll be used for abilities. to make them more abvious.

condensed the UI down to incorporate a better text display. Added status effects to the UI. Poison, Sleep, and Sickness the only effects I'm handling rightn ow but have several others in the works. postitive statu effects aswell. There won't e more than 7-8 of them. I want it to be kept simple and be more of a way to incorporate effects that happen over multiple turns.

Just about got the targeting system down, and will have a throwing. All the status effects. and polished the console reporting (I've been really neglecting this). All in a new build by the end of the week.

## Rogue build 040 - potions and mushrooms

Roguelike040

Install:

- run the appropriate visual studio 2012 redistributable in the C Runtime folder.
- run the executable in Game to play.

Keys / commands:

- move around using the numpad keys "1-2-3-4-6-7-8-9".
- attack creatures and interact with dungeon features by simply walking into them.

- Interact with items by pressing;
--- 'P' to pick up items.
--- 'D' to drop items.
--- 'E' to equip armors and weapons.
--- 'F' to eat mushrooms.
--- 'Q' to quaff potions.

- use the "-" and "+" keys to move the inventory cursor.
- actions will be applied to which item is selected by the cursor.

- press 'H' to show keys again.

What's New

Finished getting everything working under the new design. Still a little busy, so I didn't get to much time to polish. Though I did get a couple systems completed.

Got potions and food system working and pretty much finished. I have 5 other potions planned but they require another system I haven't started yet. Both use the identifying system. Food are more than just to stop from starving. Food can heal (less than potions can), but some grant xp. Some can be deadly just like potions. One of the potions is designed to make the indentify system more of a constant threat. Amnesia can make the player very forgetful.

What's Next

To finish up the potions, I'm diving straight into a simple status system. It's basically just for over time effects. It'll work just by keeping track of healing/damage , hunger effects per turn and for how many turns it should persist. Poison will cause over time damage instead of instant. Maybe healing potions could actually be done over time. The system will also handle simpler states that stay active for an amount of time. a potion could give strength and make the player do more damage for a couple turns... etc.

enjoy, and code along.

## Roguelike dungeon generator update

Unfortunately I've been plagued with this feeling of irritation. Just can't seem to focus or sit still lately. Finally got some things in life out of the way that I think was bringing this on and got the refactoring almost complete. While I was cleaning up some code I made a couple small tweaks to the dungeon generator. Oh boy it made a big difference in my eyes, funny it was sort of a bug that I fixed that made this huge change ;) . My BSPTree wasn't splitting and reporting pairs correctly, though it worked good enough it went unnoticed.

Heres a couple shots of the new dungeon layouts that are possible now.

The layouts are quite a bit more varied, and less grid based like they were before. Just a quick run down of how I generate my layouts. I use a BSPTree to split the level into a series of rooms. The splits have a slight bit of variance but always split on the longest edge. Once I have these rooms, I randomly remove a third of them. This was the biggest affector to the new look. Once again using the same bsp tree I query it for every pairing and connect each one together with a corridor aslong as one of the pairs still exists. Another change was including "parent + child" as a pair and not just "child + child". This causes the more varied hallways.

I'm really pleased with how it turned out. It does have a slight bug where one or two 1x1 rooms sometimes exist with no connecting corridors. i thought about just making a quick pass and removing any of these. but once I get the LOS system back in the player will never know they even exist. Also because of their size nothing will ever spawn within them.

Another day and everything should be back in place and ready to move on. I've done a little assestment of things so far and I'm thinking all that's left beyond polishing and adding in the rest of the assests. Is just getting the ability/skills system and the new ranged targeting system. I'm hoping to power through the rest of it by the end of the week, release a build and start polishing.

To help speed things up, I'm dumbing the system down a little. You'll no longer be able to go back up stairs, the goal of the game will still be reaching the end and grabbing the magical item at the bottom. You just won't have to bring it back up. Each floor will be generated when you enter it rather than generating every level at the beginning.

Till next time. keep on coding.

## Rogue restart

I'm looking towards a redesign, big re factor. I've moved onto keeping aspects of the game into their own systems. It's made the way I handle actions/events quite a mess. I'll have to butcher it to handle the abilities I have planned.

The current system, events, specifically key presses are checked to call the action that's assigned to them. Any time an action succeeds I set a flag to simulate a turn. Then simulate the turn, applying ai, remove dead things, gain levels...etc

game onKeyPress case : key = p bool simulateTurn = pickupItem(...) simulateTurn if true
This is further complicated by an actionState that I used for multiple state actions. Using item in the inventory used to take two steps; choose to 'u'se an item, and choose the item to use. The system that morph out of that right now uses a always on cursor to the item in the inventory you want to use. Now pressing 'u' automatically tries to use that item.

game onKeyPress if (actionState == idle) check player moving check pickup check drop check eat ... if (droppingItem) choose item to drop write to console if (eatingItem) choose item to eat write to console if (drinkingItem) choose item to drink apply potion effects write to console ...
Most of it is redundant, just like that. The change to the inventory removed a little bit of the redundancy and I feel speeds up inventory use quite a lot. I want to keep things fluent as possible.

I'll be using a simple interface to derive systems from, and contain all logic and state to these systems. The interface will basically just need to be over-ridden and used to dispatch to the specific actions that system handles.

system virtual bool onKeyPress(...)
Then the logic of the game will be separated into these systems;
item systemdungeon systemcreature system
Unfortunately, for my sake, I'm going to restart this project. Taking whats still reusable and glueing it to the new system skeleton. I'm hoping that similar to starting this project after the last should go rather quickly. It'll make things easier for me in the long run. It's getting a little complicated to do these re-factorings any more. Unfortunately what I had designed before is not allowing what I want to do.

So ill leave you with a little snippet of what I had going before all this came to fruition. I have reimplemented all my items, with the new concepts already. Added a drop system similar to Diablo 2's drop class system. Drop classes contain lists of items that can drop and the chances for those items. Then things like creatures or chests are assigned a drop class. Got creatures and basic AI up and running.

## Rogue graphics

been doing alot of work doing my own graphics, still need to do the items. Messed around with a grid based shadow system. Just casting shadowsoff the player. but it didn't work quite right. The code is still there so I might go back to it but I feel i need to research it first.
Got the text effects running aswell.

Im going to expand it into a simple particle system and use similar but with sprites for the abilities to make them usnique. and add more visual queue as to what is happening.

Been doing alot of clean up to, and alot of actual work/family. but still chugging along when I can.

## Rogue inventory and new build

Got a new build for yall to give a try. I haven't gotten any menu code in place yet so I hacked a way to use different resolutions. Theres 3 options to download each one uses a different resolution. Choose your preference. Like before the game is zipped up with 7zip, but any zip progrogram (winzip, winrar, ...etc) will extract it. If you don't have 2012 vsc++ installed, install the c runtime for your os.

Rogue 021 --- 720x400
Rogue 021 --- 1280x800
Rogue 021 --- 1440x900

Progress So Far

inventory screenshot

Made some big changes to the inventory and items. Got the basics of the item system in place.... got more than the basics of the item system in place. Inventory is now interacted with by moving a cursor up and down to select items. This cursor can move at any time, deteaching the selection process from the actions. Making it easy to do things multiple times without haveing to hit weird sequences of keys. I'll be doing something similar for selecting abilities and skills to use.

Whats next

With as much of the item systems completed and things are starting to need other components. Next I'll be focussing on the creature system. Theres alot I want to do differently here. Creatures won't be dropping items. I think that would introduce way too much chance for items to appear in the game. I already need to put a chance roll on barrels whether they drop or not.

The new creature system will be using some features I implemented for smarter placement of barrels, chest and so forth. It calculates the neighbor types around a specific tile and only allows changeing or adding features if the neighbor counts are in a specfic range. Such as chests will never spawn near a wall. This was to prevent blocking doors and the fact chest can spawn alot of items i want them to have room to drop them.

Creatures will be getting smarter spawnning. There will now be leader type creatures that will spawn follower type creatures around them. The biggest effort will be giving every creature abilities. Or the ability to use abilities. Even ai will be using them.

The last little thing I'll be getting to finally is little floaty text effects, to help notify what happening on the map and make it more lively. Things like combat damage will show. Little question mark pops up everytime an item is spawned (not dropped), Exclamation point or even the item count that dropped when you open a chest or barel.

So until then hope yall enjoy.

## Rogue Droppables

A quick one... spent alot of time cutting out and putting together all the item assets for the game. Very tedius. Next post I'll have all the item use actions plugged back in. and a smarter generator for placeing the features like chests, racks and barrels.

## rogue game 2

Finally got some time to focus on what my goals will actually be for the next installment. Another roguelike, turn based. trying to build upon the last game rather than start from scratch. I got a pretty good grasp on how things were laid out and how I'd like to lay them out now. There's hopefully gonna be some big additions to the game. Abilities, ranged combat, far better item system supporting procedurally generated stats and properties. I have some ideas on how to implement a simple lighting system underneath the LOS-Visibility system.

Moving the style of the game more towards the older diablo series. I've been working on improveing the dungeon, did a huge refactor on it cleaning it up and expanding features. Items will no longer spawn in the dungeon from the get go like typical roguelikes. I'll be using a drop system to spawn items from killings monsters, opening chests, breaking barels, weapon racks and more.

The biggest change addition and still not sure if it will be there in the end. Waypoints and partial persistence. Think of it like hardcore mode. The game would randomly spawn waypoints through out the dungeon. non of which are garaunteed on any level. Once on is found the dungeon is saved along with the current player. Now at any point aslong as there are no enemies nearby the player can save the character and it's dungeon. Each time the player is reloaded, it respawns at the last waypoint and the entire dungeon is repopulated with creatures. If the player is to die, they can't be reloaded at all. There would still be the idea of eminent death and never coming back from it. Hunger is gonna be the number one threat more than likely. But the idea of packs of monsters and a slightly faster, quicker deaths battle system. The goal will be more on tactics. Positioning yourself to get the first hit, better use of your abilities, and a ton more item uses.

The first system I plan on getting up and running is the item system. It'll be completely redone. Towards the end of the last project I started to refactor it to make it more generalized and easy to expand. I'll be taking that approach from the ground up this time. Items will now have a rarity when spawning. There are normal items which are jus the base item. such as a weapon, at it's base has only one property... damage. Then you have magic rarity items and godly rarity items. magic items spawn with an extra property and godly with 3 random properties.
The planned properties or moddifiers;-- +Damage-- +Armour-- +AttackSpeed-- +maxHealth-- +maxAP-- +ElementalDamage-- +ElementalResistance
Abilities I still need to think how much they'll effect the game. The main think I want them there for is to make combat more impactful. Allow a bit of player controlled development. Each ability will be weapon specific. Granting a 150% increase in it's damage if using that weapon type. I don't want to screw over the player but I want them to have to think about how they evovle. You may really like an axe based skill, but the game keeps giving you swords and bows.

All abilities will cost AP to use and can target anything in a radius around the player, 1 or 0 should only allow the player as a target. Abilities under the hood will be rather simple and mostly just fancy text.
-Thunder Spear- + 10% damage- 4 range- spearTypeAttack- cost 2 AP- AOERange 0- ElementalType electric

This just shoots the current weapon damage + 10% of that damage to any target in 4 square radius and cost 2 AP to use. It gains 150% extra base damage if the weapon is a spear. The skill magic dart could easily be the exact same skill with a different name and weapon type. Lightning strike too. Abilities will also in corporate AOE dealing it's damage to every target in the radius around the target. and elemental type aswell.

## Rogue Final Build

https://www.dropbox.com/s/bsxgr9njkcqki0f/Roguelike.7z

Download the zip file (created with 7zip) and extract it. I should create two folders. C runtimes which has the visual studio redistributal packages. Install the one that corrisponds with you OS if you don't have vsc++2012 installed. The game folder ofcourse holds the game and the needed assets.

Shouldve mentioned last time the game runs in a 1280x800 window, I opted out of fullscreen and supporting other resolutions as this was meant ot be a personal project for testing purposes. Still a bit shocked or suprised that it ended up being what it is. Let alone making it to a final state.

Bare with me.... this is a long post....

Post Morteum

As mentioned before the game started off as a remake of a strategy game I once made. I jumped straight in working on the terrain/map/gameboard (whatever you like to call it), and go figure that is the portion of the game I'm most satisfied with. I'll definitley be refactoring and expanding it for the next project. I plan on doing another roguelike or gauntlet style rpg for the next project. and I've alrady got a list of ideas I've been jotting down the entire time I've been working on this project.

In nearly every project I've done so far, I now realize I over design everything to the point its impossible to accomplish. I've had breakout clones that have gotten to impossible states without huge refactors. Typically I just give up on these projects. Mostly giving up cause I can no longer grasp the design at one point or another.

This time I focused on getting things done rather than worrying about the design. If that meant everything was in one file was perfectly fine for me aslong as it worked. A total of 14 files (counting header + source as one file), a huge difference from one of my breakout clones I just counted at 32 files (counting header + source as one file). Holy crap you might say... yes that is major over designing.

One of my refactors did add 2 files, simply for readability sake. In the end I feel it was a good design aspect I wish I wouldve done from the get go though. I'll definitley incorporate it in the enxt project to a fuller extent. Seperateing the processing of item based actions, especially the use action. The use action function went from a 200+ line function of copy paste code to only 22 lines. Making it capable of reading the flow of the function without taking notes as I scrolled through it.

The entire game is hardcoded and I particulary didn't like this aspect. It's what actually discouraged me from adding a plethora of new potions, scrolls, weapons and armours. Especially with potions and scrolls, all their effects immediately created spaghetti everywhere. It took the huge refactoring to atleast make it manageable and still it wasn't what I wanted. It wasn't as easy as I thought it would be to incorparate things like weapons that could heal (think wands). Some thing I greatly want to work on for the next project is extracting such affects or abilities from unique items and allow any item to have those properties. Cursed items wouldve even been another headache, copy and pasting it to every item type I wanted to be able to be cursed.

I've never been that great with coming up with formulas, solving them sure. It shows especially in the combat calculations. It just seemed no matter what, the players stats just didn't have any effect unless pumped in big jumps. You might notice strength really doesn't have any effect between increments of 5. I probably tried to hard to keep things small numbered. I like the idea of the player not know the exact formulas but being able to deduce it by doing the math in there head and dealing 9999 damage with 324 strength just isn't friendly doing it in your head. I'm strongly thinking of removing stats such as strength. Making everything gear dependant. Your character is only as strong as the weapon you're swing with.

I'll admit I modelled or atleast drew alot of my inspiration from dungeon crawl stone soup which I consider the tiles version the best roguelike out there. Granted I haven't played a huge amount of them but I've dipped my feet in a fair amount of them. Everything you do in it seems to have a feeling to it, there's just alot more feedback though there isn't. I couldn't seem to reproduce that, and i blame my formulas for that. A lot of the times it just desn't feel like the player is actually in combat. I want to try for more visual ques, simple ques, like floaty-text numbers to show damage dealt. Nothing major but more than just the console narrating.

What's Next?

Same concept, more depth, and A roguelike engine. Probably just a framework, but I want to take what I've got and start to put together an engine to make these projects faster and easier. This project already incorporated a couple aspects from my last project and I'm definetly keeping the dungeon code around for future projects. The console and BSPTree are surely reuseable too. Unfortunately the rest of it is only reuseable in concept.

I want to incorporate more procedurally generated content. The item system, I want to be able to randomly generate items with different properties. Such as the sword of healling. Not all of which would be gauranteed in every play through. I'm thinking of for weapons for example. The game will have a set of base weapons that will all be included in the game. But the game can also generate random versions of the base item with random abilities and effects.

More livly dungeons. I've been playing Craft The World quite alot recently, if you haven't heard of it check it out on steam. If you like games like terraria but wanted it to be simcity esque... craft the world is your game. Everytime it makes me think why can't i change the dungeon as the player? Why do I have to use that door everytime? What if I found some explosive and wanted to blow a hole through the wall instead? What if not every creature was a midless enemy hell bent on chasing you to your death?

I'm not sure how far Id take the idea. been wanting to do more experimenting with AI in a game. That along with the idea of an ever evolving world. Like dwarf fortress, towns and civilizations are constantly changing and doing their own thing to progress through the game just as the player is. I would take things that far, not yet atleast. Something simpler along the lines of maybe an ant colony. Think of a room with a queen ant in it that when not hungry places eggs on the floor. The eggs will eventually hatch and generate new worker ant creatures. These worker ant might tunnel through walls expanding the nest making it possible for the queen to place more eggs. The workers will also search out food and bring it back to the queen to feed her so she keeps producing more workers.

and oh my god I think I have my idea :) I've been thinking along with all that, that I'll ditch the multi floor dungeon in favor of one huge world. a world that isn't entirely exploreable right away and has to be manipulated (dug out) to find and reach your goal. Also instead of only controlling the player, you'll have a group of adventurers that you could consider your civilization. AI controlled, you would issue things to do and the AI would decide how they do it. everything will still be turn based, I want to keep the roguelike idea alive, but make it far more next ime.

I just need to figure out what the purpose of all the extra characters would be except for having somewhere to fall back to in a fight. So with that I begin a new design process and will begin brainstorming ideas tomorrow. Farewell till next time.

Hopefully this works, never really used drop box out side of personal use. Download the zip file (created with 7zip) and extract it. I should create two folders. C runtimes which has the visual studio redistributal packages. Install the one that corrisponds with you OS if you don't have vsc++2012 installed. The game folder ofcourse holds the game and the needed assets.

Its a really rough build, but I'm sure it'll give a better feel for the game then the videos ;) any feedback is welcome. enjoy.

https://www.dropbox.com/s/bsxgr9njkcqki0f/Roguelike.7z

## Rogue Cleaning

Re thinking the console message system. Having game handle the messages or just the way it does handle and dispatch them is very clunky and verbose. So I think this is gonna be my next goal, get things back to a more manageable state by cleaning up this system. Before jumping straight into the last major must have factor of the game... starting, winning, dieing, restarting

What if items them selves held the strings. Better yet since I want to keep items as pure data as much as possible. What if the itemFactory could generate the messages and report them. I've been wanting to do this with actions as well. For example;
itemSystem.reportUseAction(isPlayersAction, item, console);itemSystem.reportEatAction(item, console);itemSystem.reportFoundItem(item, console);combatSystem.reportHitAction(isPlayersAction, damageDealth, defender);//.....etc
The isPlayersAction would be for discerning how the message is worded, of course this will get a lot more use when updating the combat messages as well.This is gonna help the item systems code a bit as well. Right now it currently is the one that owns the information about what item type have been identified or not. right now there's a lot of copy past code for discerning whether and item has been identified or not, do to the hacked way of doing checks on it.

This is also going to be applied to how actions are are processed. Right now the highest level game namespace processes all item actions such as eating, using and even discarding. All of which I want to put into their respective systems.

This would be my first idea of how the functions would be modelled.
itemSystem.useItem(item, creatureToUseOn);
But that wont handle everything, scrolls may interact with more than creatures. I could double the functions split into different item types. Though I want to lower the code. I don't know how many items will eventually be in the game that I'll want to able to be used.
itemSystem.usePotion(isPlayer, item, creature, console);itemSystem.useScroll(isPlayer, item, creature, scroll, console);
I might just limit the use to just potions and scrolls and make it more general in the next attempt at this project. The last bit to note, in each action command is the console, cause they will also call the respective report function as well.

Now that I got my idea, its time to get coding.