Jump to content

  • Log In with Google      Sign In   
  • Create Account

From End to Beginning

Roguelike - mouse control and side project

Posted by , 29 January 2015 - - - - - - · 836 views
roguelike, 2d, c++, sfml, rpg and 1 more...

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.


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

Posted by , 17 January 2015 - - - - - - · 800 views
roguelike, 2d, c++, sfml, rpg and 2 more...
Posted Image

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.

Posted Image

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.

Rogulike - Download Build 056

Posted by , 12 January 2015 - - - - - - · 1,077 views
roguelike, 2d, rpg, c++, sfml and 1 more...
Rogulike - Download Build 056 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 Posted Image

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 Posted Image enjoy and till next time happy coding all.

Roguelike - Refocus

Posted by , 04 January 2015 - - - - - - · 1,023 views
roguelike, 2d, c++, sfml, rpg and 1 more...
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

Posted by , 27 December 2014 - - - - - - · 679 views
2d, sfml, rpg, roguelike, c++ and 1 more...
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.

Roguelike - Download Build 055

Posted by , 07 December 2014 - - - - - - · 1,072 views
roguelike, 2d, rpg, sfml, c++ and 2 more...
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

Posted by , 11 November 2014 - - - - - - · 783 views
roguelike, c++, sfml, 2d, rpg and 1 more...
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 is
successful 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

Posted by , 30 October 2014 - - - - - - · 814 views
roguelike, 2d, c++, sfml, rpg and 1 more...
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.

Posted Image

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 :)

Roguelike - Download Build 050

Posted by , 14 October 2014 - - - - - - · 1,795 views
roguelike, 2d, sfml, c++, rpg and 1 more...
Roguelike - Download Build 050 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.


Roguelike 050 download

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

Posted by , 05 October 2014 - - - - - - · 581 views
roguelike, rpg, sfml, c++ and 4 more...
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 T>
    class GridCell

        GridCell(cii::GridCell<T>& gridCell);
        GridCell(sf::Vector2i newGridCoord, sf::Vector2f newWorldCoord, sf::Vector2f newWorldSize);

        cii::GridCell<T> operator = (const cii::GridCell<T>& 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();


        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 T>
    class Grid


        void init(sf::Vector2i newGridSize, sf::Vector2f newCellSize);
        void clear();

        cii::GridCell<T>*			  getCell(sf::Vector2i gridCoord);            // returns the cell at the given gridcoord. / returns NULL if the coord is invalid or cell doesnt exist.
        cii::GridCell<T>*			  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<cii::GridCell<T>*> getCellsInArea(sf::Vector2i startCoord, sf::Vector2i areaSize);    

        bool isGridCoordValid(sf::Vector2i gridCoord);

        sf::Vector2i getGridSize() const;
        sf::Vector2f getCellSize() const;


        sf::Vector2i gridSize;
        sf::Vector2f cellSize;

        std::vector<cii::GridCell<T>> 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 T>
    class 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<T>*			  getCell(sf::Vector2i gridCoord);
        std::vector<cii::GridCell<T>*> 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);


        sf::Vector2i gridSize;
        sf::Vector2f cellSize;

        std::vector<cii::GridCell<T>> 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.

January 2017 »

22 23 2425262728

Recent Comments