-
(http://media.indiedb.com/images/games/1/41/40378/add.png)
Racod, scourge for mankind, escaped to its lair to regenerate for his next decade of terror.
You and your brave fellows are willed to find and defeat Racod.
Playable Demo available
via IndieDB (http://www.indiedb.com/games/racodslair/downloads/alpha-demo-v01-alpha)
via GitHub (Source Available) (https://github.com/cgloeckner/racods-lair/releases/tag/v0.1-alpha)
Genre: Coop Dungeon Crawler / Hack'n'Slash RPG
Target platforms: Windows, Linux
http://www.youtube.com/watch?v=-jm08gtHCZk
Core features:
- Procedurally generated dungeons, enemies and loot
- Cooperative gameplay via splitscreen and/or shared camera
- Mod-friendly through XML-based content and Lua-based AI scripting
What is used: C++11, SFML, Thor, Boost, Sol2
(http://media.indiedb.com/images/global/indiedb.png) (http://www.indiedb.com/games/racodslair/) (https://www.adamyourself.com/de-de/assets/brands/opel/images/facebook-icon-44x44.png) (http://www.facebook.com/racodslair/) (https://www.fepblue.org/assets/img/twitter_button.png) (http://www.twitter.com/racodslair/)
-
Interesting!
Are you planning on releasing it? What about other platforms?
Anyway, congratulations on the project, seems nice so far.
-
Are you planning on releasing it? What about other platforms?
Well, it's a pure hobby-based project. So, if it will be ready one day, I will release it for free. So I cannot state about possible platforms. But I'm thinking about versions for linux and windows (hopefully 32 and 64 bit). I don't have experiences in other platforms like MacOS or various mobile systems, yet.
Anyway, congratulations on the project, seems nice so far.
Thanks!
-
Looking good! (sorry for not having something more useful to say).
I'll keep an eye on this, it looks really interesting. Good luck with the project ;)
-
I implemented a first approach of reducing the field of view to a limited area. tiles out of this view are rendered dimmed by applying another sf::Color. Also objects are only rendered if they are within the area. So the entire scene gets more atmosphere.
http://youtu.be/7JODb1Kases
The field of view isn't correct, yet - and the field is rendered very awkward, because I can only apply a color per tile. This might be changed later (a lot later, I guess) when introducing shaders .. one day ^^
-
Let me suggest you this: http://en.sfml-dev.org/forums/index.php?topic=16201.0
;)
-
Hi Glocke,
looks good, and rogue games are very good to learn game dev !
Your dungeons look like the ones in NetHack. The LOS rules can be:
- corridors are in shadows, you've to wear torch to see far,
- rooms are lit, you can see the entire room when you've entered.
I can see 2 tiles wide corridors: you've to think about doors !
libtcod has useful tools for roguelike development.
Good luck with this project !
-
http://en.sfml-dev.org/forums/index.php?topic=16201.0
Thanks, I'll keep this in mind for later UI improvements :)
Your dungeons look like the ones in NetHack. The LOS rules can be:
- corridors are in shadows, you've to wear torch to see far,
- rooms are lit, you can see the entire room when you've entered.
Sounds really interessting! Thx, I'll keep this in mind for the later gameplay implementation. Currently, my project is only a "tech demo" growing with additional features.
I can see 2 tiles wide corridors: you've to think about doors !
Actual, I made all (or at least most) corridors two-tiles-wide. Because I'm focusing on split-screen-coop, additional room is necessary for later gameplay.
libtcod has useful tools for roguelike development.
Well, because I'm in a process of learning, I want to implement everything myself (except SFML of course ^^).
Update
As mentioned, I changed some map generation parameters to achieve corridors which are 2 tiles wide. Also room sizes has been increased. Both should offer more space for later cooperative playing.
Also, I improved the FoV algorithm by using per-tile-raycast (which is currently implemented via recursion and adding visited tiles to a set - for avoiding double-visit).
Thirdly, I changed the graphics. To be honest, I don't know where the previous graphics came from. I just found them somewhere at my disk. To avoid future copyright problems, I'm now using CreativeCommons graphics from http://opengameart.org/ (http://opengameart.org/).
Goblin sprite: http://opengameart.org/content/lpc-goblin
Dungeon tiles: http://opengameart.org/content/fancy-dungeon-tileset
Fireblast sprite: http://opengameart.org/content/fire-blast
Here is another video introducting another feature: casting spells. Currently, only fireblasts are implemented as a prototype for bullet-like gameobjects (arrows, other spells etc.). Those objects kill all gameobjects they collide with - and finally vanish when hitting a wall.
http://youtu.be/PlzL7mK5hdI
By the way: To visualize collision handling for debug mode, I'm rendering all "locked tiles" (tiles where objects are currently located) colored red.
-
Hi, some additional features has been implemented - including:
- animation handling
- simple rpg stats implementation (currently: health and mana)
- fireblasts cost mana and inflict damage to the target on collision
- own mana and health are displayed
- health of the currently focused object (by own face direction) is also shown
- additional gamepad support (using 2 axis and 1 button, yet ^^)
- splitscreen for two players
I'm looking forward for the next development steps. Those steps might be melee combat with some sort of simple animation (as UI indicator in the first place), an additional "bullet-like" attack (e.g. using archery) and attacking enemies. Just walking/standing isn't quite much, yet ^^
-
I think you should consider changing the mechanics for how the visible range is rendered. The choppy motion of the light field around the player is almost giving me a headache from watching those brief videos, and would certainly make me not play the game.
Here are a few considerations from the top of my head:
- Make a simple gradient consisting of 2-3 blocks, so that the contrast is not so strong.
- Make the nonvisible area lighter, so that the contrast is not so strong.
- Make the light area larger, so that the choppiness is not so much in focus.
- Look into using shaders to create a per pixel smooth gradient. I don't know how the current shadow system works because you did not post your source, but I dare guess you don't use shaders.
Anyway, good luck and keep going.
-
I think you should consider changing the mechanics for how the visible range is rendered. The choppy motion of the light field around the player is almost giving me a headache from watching those brief videos, and would certainly make me not play the game.
Your absolutly right!
Look into using shaders to create a per pixel smooth gradient. I don't know how the current shadow system works because you did not post your source, but I dare guess you don't use shaders
Right: I'm not using shaders, yet. The field of view is generated recursive by raycasting into different directions and saving all visited positions to a set - until a given distance has been reached.
I amlost planned using shaders to solve this issue. Because it's a pure UI-related feature, I'll delay the shader-topic to be done before the first release - I don't have any experiences with shaders, yet. But reducing the contrast should work in the first place. So thanks for your feedback! :)
-
If all you want to have is circular visibility, you can always make an image with a transparent circle in the middle, semi-transparent black color everywhere else, then draw that on top of everything. What is outside the circle should get darker. You can even get gradient shadows with that trick.
-
If all you want to have is circular visibility, you can always make an image with a transparent circle in the middle, semi-transparent black color everywhere else, then draw that on top of everything. What is outside the circle should get darker. You can even get gradient shadows with that trick.
Well, I tried this but I didn't get away the "border" between semi- and fully transparent. So the scene would look like "through glasses with thick borders", which isn't what I really what.
Of course the current behavior isn't very different - but more "out of the box" ^^
-
Did you try multiple circles that get less and less transparent to get the gradient effect?
-
Did you try multiple circles that get less and less transparent to get the gradient effect?
Not yet, but I like this idea! ;D
Update
Today, I was reworking nearly the whole event system by introducing an event-driven hud per player. So each event (e.g. onDamageReceived) is forwarded to an object's hud (if it has one). So the hud can e.g. count killed enemies and display it.
As mentioned, I reduced the contrast between tiles inside/outside the player's view. But I will focus on dabbertorres "circle-approach" next.
Here's a small video. It introduces splitscreen (as mentioned before), simple animations, an event-driven hud and a new sprite under CreativeCommons: the red imp :o
Have fun while' watching - I'm sorry for the still awkward field of view rendering :-X
http://youtu.be/7FXOrtkghfM
-
If all you want to have is circular visibility, you can always make an image with a transparent circle in the middle, semi-transparent black color everywhere else, then draw that on top of everything. What is outside the circle should get darker. You can even get gradient shadows with that trick.
Following the idea, I studied about lightmaps. So I pre-rendered some kind of light texture using gimp.
After binding this texture to a sprite, I render all lights using sf::BlendAdd to get the complete lightmap for the current scene. After that I render all tiles using sf::BlendMultiply and finally render all gameobjects using the default RenderState. Because currently every gameobject causes light, the final result looks like this:
http://youtu.be/7KJFtZuxFZQ
It isn't that awkward then before, but is limited to the light shape. But it works in the first place and increases the scene's atmosphere :)
-
This looks much better. It has progressed so much just within this thread! :)
-
This looks much better. It has progressed so much just within this thread! :)
Thanks! After a short weekend-holiday, I'll continue the development tomorrow. The current development goals seem amazing to me and I want to make use of my last two weeks without courses and seminars at university.
Hopefully, a limited but yet playable demo will be available soon. To all the readers and possible supporters: Thanks for your interest and previous feedback. Keep tracking this thread and giving feedback to latest changes :)
-
Update
A first combat implementation (including simple melee combat) has been done. Also enemies now try to track the player and attack (melee or fireball, depending on their mana and the left distance). But the behavior seems stupid, yet - some real pathfinding will be introduced soon!
Also the lighting system is currently under development - and has been deactivated during the following short video:
http://youtu.be/q_Qeog6tB9E
-
Well, lighting is yet disabled and under construction. But some other changes and improvements have been done. A description can be found at this video:
http://youtu.be/P3pyqZsI8Oc
-
Update
Julian finally completed the lighting system. We were prevously experimenting with shadow calculations, but abandoned this idea due to incompatibility with the current rendering approaches and desired atmosphere.
Also, I rewrote the animation rendering to allow the code to use sprites from Clint Bellanger's Flare project. Those fully animated sprites are now used by my game, including dying-animations etc.
Finally, diagonal movement has been implemented. The movement is discrete, yet. This won't change in the future. But perhaps the scaling of the discrete movment grid will be decrease in the future. Currently, I'm thinking of moving to isometric projection using pre-rendered tiles. But this decision isn't made, yet.
http://youtu.be/8Ry3yxIb1GM
Feel free to like the video and comment/discuss on the latest or possible future changes.
Credits
Sprites by Clint Bellanger
http://opengameart.org/content/isometric-hero-and-heroine
http://opengameart.org/content/skeleton-warrior-0
http://opengameart.org/content/minotaur
http://opengameart.org/content/fireball-spell
Chest sprite by Daniel Cook
opengameart.org/content/planetcute-chest-closedpng
Tiles by mfburn
http://opengameart.org/content/fancy-dungeon-tileset
Lighting System by Julian Kanzler
-
The sprites do look quite nice here, especially now that you've implemented different types at once and diagonals.
The lighting's also good now. The (slight) problem, though, is that the 'newly-discovered' tiles are appearing after entering the light. It would look smoother if they appeared while still in the dark. Maybe just one tile further?
On another note, and maybe it's just the games I've been playing, but I automatically associate red damage figures as from the player.
-
The (slight) problem, though, is that the 'newly-discovered' tiles are appearing after entering the light. It would look smoother if they appeared while still in the dark. Maybe just one tile further?
Thanks. "just one tile further" seems to be the solution :) I wasn't noticing the issue until I read your post :D
On another note, and maybe it's just the games I've been playing, but I automatically associate red damage figures as from the player.
Your absoutly right, thanks! Damage inflicted to the player should be displayed red. I'll change this in the future. How do you think about displaying damage to the enemies in yellow color? Perhaps future healing to the player might become green - and healing to the player (e.g. a fire monster absorbing your fireball) blue :)
-
How do you think about displaying damage to the enemies in yellow color? Perhaps future healing to the player might become green - and healing to the player (e.g. a fire monster absorbing your fireball) blue :)
Haha. It's your choice. It was mainly the red that was throwing me. However, since you ask (:P), the common way seems to be:
red: player damage,
green: player healing,
white: enemy damage,
yellow: crit enemy damage,
blue: special enemy damage or XP,
I may be wrong. I never really did understand the difference of the all anyway :D
-
Haha. It's your choice.
:P
red: player damage,
green: player healing,
white: enemy damage,
yellow: crit enemy damage,
blue: special enemy damage or XP
Make sense to me, thanks for that input :)
-
Update
Well, it seems like my Rogue-like is going to look like Diablo1/2. But first, here are the recent changes:
- Changed dungeon randomization algorithm: The dungeons now look more "natural"
- Moved rendering code to isometric perspective: More beautiful in my opinion :)
- The randomizer outputs "there is floor, there is wall".. The rendering code now picks the right wall tile, suitable to the surrounding
- To make the isometric perspective look even better, I moved my dungeon tiles to the one from Clint Bellanger's Flare. Well, it looks like flare, but it isn't ;)
Enjoy watching!
http://youtu.be/28fb1n7a65A
PS: Some shader code changed to make the lighting even more scary ;)
-
Impressive. I like how your game has evolved from a simplistic top-down to a really nice isometric roguelike. Any chance for a demo anytime soon? :D
-
Impressive. I like how your game has evolved from a simplistic top-down to a really nice isometric roguelike. Any chance for a demo anytime soon? :D
Thanks! About a demo: I want to implement some basic gameplay features, first... So, no..^^ Not, yet :P
-
I think that the development of this game qualifies the use of the phrase, "well, that escalated quickly." :D
Again, about the colour thing, though. I'm probably wrong here but "block" in red seems wrong as the player blocking isn't actually a negative thing. I suppose it could mean that you've been attacked though, so that justifies it in my mind!
Good work :)
-
ms wrong as the player blocking isn't actually a negative thing. I suppose it could mean that you've been attacked though, so that justifies it in my mind!
Well, it will be escalating quickly. *block* is currently just a placeholder (including it's color etc.)
-
Development Paused
The development of "Rage" will be paused for some time, because the new university term will start soon. I will use the next days to cleanup the code and document architecture and other decisions. This will hopefully help to continue working on later. So this project isn't dead ;)
Again, thanks to all your feedback. I'm looking forward continuing development as soon as possible 8)
Kind regards
Glocke
(http://glocke.bplaced.net/rage/dev_pause.jpg)
-
Meanwhile, minor architectural changes are made. I also applied some performance-relevant improvements, so the game is now able to run on my netbook smoothly. By the way: the machine has a single-core cpu with 1.6 GHz and a low-end built-in intel graphics card. That's not much, but quite enough to run the game - at least at 30 FPS, yet!
Because of too little free time, I wasn't able to really continue development. But I studied about modern C++ style, architectural designs and possible performance improvements. Therefore I started to write a huge list of (pure internal) changes need to be done. I'm not sure about how quickly this list's items can be implemented - referring to having not enough free time. But again: This project isn't dead ;) I'm looking forward to be able to continue development 8)
Kind regards
Glocke
-
Hi folks,
meanwhile nearly everything changed :D I was redesigning the whole architecture from pure OOP (fail due to performance) to a hybrid of DOD and OOP. Now, pure DOD is used for the core systems such as physics and rendering. A hybrid of DOD and OOP is used for less performance-critical systems such as input.
Also I started writing unit tests for nearly everything I can imagine. So the entire physics system's testing code is as large as the physics itself - but covering many edge cases. Because I totally rewrote the systems, using those unit tests I discovered bugs which might have shoot off my entire leg :D The old code was out-dated referring to coding style, so rewriting and redesigning everything from scratch was a lot easier ^^
So meanwhile, I also stepped back to topdown perspective in order to simplicity during development. I use predefined vertex definitions (parsed from files) to describe 2d terrain- and object-"meshes" built from triangles. It isn't looking like before but it's working for development purpose ^^
Here's a short video of a performance test: I was hitting spacebar to spawn 500 "flying" chests (they're handled as bullet objects for testing purpose) at once. Hitting the spacebar agains spawns another 500, hitting return removes all objects (except the player). This is some kind of performance test to check out how many objects can be handled by the game in current release mode on my netbook. So, looking back to the "old days"-code (as above), I eliminated many performance issues by moving to a more DOD-like design.
But the, here's the video. Enjoy!
http://www.youtu.be/cH6LETygPeI
Technical Stuff: It's using C++11 (now, really ^^), SFML 2.2, Thor 2.0 and my own extension SfmlExt (which can be found at my signature below all posts) for further implementations, which aren't covered by SFML of Thor (not covered at or all not in the way I'd like to).
About further dev steps: I'm going to finish documentation and unit testing within the next weeks. So reimplementing the lighting system and writing a simple audio system will be the next steps after documentation and testing :)
About the visuals: I decided to simplify, because everything is easier if you don't focus too much on graphics. Because I'm a totally newbie to graphics design, I'd need a graphics artist for the dev team. But that is totally unecessary at the current state of development. So I'll stick with this for a while. But I'm also now sure whether staying at topdown or going back to isometric perspective is better. Future will show!
-
Hey, meanwhile the graphics changed again. I created very simple non-animated pixel graphics which are now displayed by the render system. Also, the sight-range-based lighting system was implemented - with very hasty flaring effect (just temporary, because it's too fast :D ). To give it a touch of atmosphere, I also wrote a simple ambience theme which is also shown in the video. Enjoy.
http://youtu.be/74YOBMdiCrk
-
Nice progress. Yeah, I also often prefer starting over in favour of refactoring old code ;D That's why I recently started challenging myself to do small projects from start to finish in one month time, so that I'm forced to finish something rather than just rewriting the same "epic" project again and again every time the old code starts to look embarrassing.
Do you have a github page or similar? Having a look at your source would be interesting.
-
Nice progress.
Thanks :)
Do you have a github page or similar? Having a look at your source would be interesting.
Well I have a github page, but I don't want to publish the game code for the moment.. maybe later after a playable version when the code feels "ready" :D It's too embarrassing at the moment but I'm looking forward to ;D
But if you have some questions I'd like to answer them!
But you can browse some code I'm using inside the game: https://github.com/cgloeckner/SfmlExt
Kind regards
Glocke
-
Hi, after experimenting with GIMP, I finally found an art-style which fits my game idea best and is easy to be made on my own. Here's a short animation video introducing a dude who might become the player avatar :D He's currently idling, moving and attacking using eight different directions. Because the perspective is topdown, the sprite can be easily rotated for different facing directions, so I won't need too many graphics :)
http://youtu.be/TC4T20dL1N4
By the way: I'm using my Image Atlas Generator (see SfmlExt) which creates a tightly packet texture atlas for the sprite (see attachment).
Kind regards
Glocke
-
Well, splitscreen isn't all. So I experimented with another camera handling approach: A shared camera instance using some additional math :)
http://youtu.be/H71eiaZjdVE
-
Meanwhile, I reimplemented the lighting system including hard-edge shadow casting. The lighting isn't optimized yet. Also the game is running in debug mode on my netbook. So, the low FPS and some lags occure :S But I'm looking forward to fix that!
http://youtu.be/Px34r6CWFI4
-
Meanwhile, I fixed most of the performance issues with dynamic lights and hard-edge shadowcasting. The final result looks like this: Every lightsource can cast shadows, including players and fireballs.
Next step will be an animation handling system for sprites (frame animations) and lighting (flaring lights).
-
Today, after some weeks with too little or without any free time, I spent time writing an initial implementation system. Next step might be creating more animation and objects for a more interesting demo video :D
http://youtu.be/weVXzDv1lmA
-
Hey followers! :)
Here's another demo video. I implemented a minimal combat system as well as a player hud. This time, two players are slaying non-acting enemies... not really heroic but it's working ;D
http://youtu.be/XeTC3qJgrR0
Of course there are still some bugs referring to the targeting system .. going to be fixed :)
-
Meanwhile, some visual effects have been added. There's also a simple teleport mechanism, which will be used later when moving between dungeons (stairs -> teleport ^^)
https://youtu.be/NtSh_qK1bEM
-
"Split, or not to split. That's the question."
https://youtu.be/ErLcIeKSMPU
Meanwhile, after heavy reconstructions, I finally improved multiple systems, especially the camera system. Now the screen can be splitted into multiple parts. Each part can observe one or more players (camera is zooming etc.). It's now working with resize, with fullscreen and without breaking the lighting or hud system.... Yeah ;D
So, leaving the decision - whether split or not - up to the player is now possible. Maybe this can be adjusted while playing (without restarting the session)... Stay tuned!
-
Hey guys! Meanwhile, I implemented a menu structure including settings menu (in and off game) as well as a lobby menu (where to select players and profiles) and a profile menu (where to configure the keys). There are still some bugs in the menu.. But I hope you like it :)
https://youtu.be/tfB3auvul-M
-
The major issues with the menu has been fixed by now. So I proudly present to you a brand new feature which will give a bit more customizability to the players: Changing the camera setup during game via pause menu:
https://youtu.be/B9jOHytXhYw
-
At the moment, I'm working on the game art. So two tilesets (with higher resolution!) has been created: dungeon and castle. Also some addition shading has been implemented to get a nice gradient from wall texture to "void". Next on my todo-list are:
- New sprites for player and enemy
- (New) art for chests, arrows, fireballs
- And an advanced set of animations including: Idle, move, melee attack, archery attack, cast and dying
Stay tuned 8)
-
Finally, I decided to keep low-res pixel art. So I created several layers and animation types:
- 1 Frame Idle, 8 Frame Move, 6 Frame Melee Attack, 6 Frame Range Attack
- Basic "Human" Sprite
- Body Layer: Wizard Robe, Leather Armor, Plate Armor
- Weapon Layer: Sword, Bow, Staff
Some (gimp-made) combinations of those layers are attached.
-
I like the sprites, except for the rogue :D.
He either looks like as if he has really long arms, or he is holding a saw "gangster-style" in front of him.
-
He either looks like as if he has really long arms, or he is holding a saw "gangster-style" in front of him.
Well, thats actual a single melee attack frame ... so all sprites has a long arm while attacking xD But you're right: it looks strange if viewed out of context :D
By the way that "saw" was supposed to be a sword ;D
-
I know that it was supposed to be a sword but the weird arm angle made it look like a saw to me :D
I guess it's just the banana arm going on there ;D
Edit: This will most likely look better in motion though.
-
This will most likely look better in motion though.
Stay tuned for the next video post .. hopefully all animations will be shown :)
-
Meanwhile, initial pathfinding and dungeon generating algorithms have been implemented. Stay tuned for some weird maze chases.
Here's an example output (ASCII style, yet) from the dungeon generator
Generated within 21ms
################
################ #..............#
#..............# #..............#
#..............# ####### #..............#
#### #..............#####.....############## #### ##########################..............#
###..#### #.....................................# ####..#### #.......................................#
#.......# #.....................................# #........# #.......................................#
#.......# #..............#####.....###########..# #........# #..#######################..............#
#.......# #..............# #.....# #..# #........# #..# #..............#
#.......# ################ #.....# #..# #........# #..# #..............#
#.......# #.....# #..# ####..#### #..# #..............#
###..#### #.....# #..# #..# #..# #..............#
#..# #.....# #..# #..# #..# #..............#
#..# ####### #..# #..# #..# #..............#
#..# #..# ##..######## #..# ######..########
#..# #..# #..........# #..# #..#
#..# #..# #..........# #..# #..#
#..# #..# #..........# #..# #..#
#..# #..# #..........# #..# #..#
#..# ###############################..## #..........# #..################# #..#
#..# #.................................#### #..........# #..................# #..#
#..# #....................................# #..........# #..................# #..#
#..# #.......#########################....# #..........# #..#############..## #..#
#..# #.......# #....# #..........# #..# #..# #..#
#..# #.......# #....# #..........# #..# #..# #..#
#..# #.......# #....# ##..######## #..# #..# #..#
#..# #..###### #....# #..# #..# #..# #..#
#..# #..# ###### #..# #..# #..# #..#
#..# #..# #..# #..# #..# #..#
#..# #..# #..# ####..###### #..# #..#
#..# #..# ###### #..# #..........# #..# #..#
#..# #..# #....# #..# #..........# #####..######## #..#
#..# #..# #....# #..# #..........# #.............# #..#
#..# #..# #....# #..# #..........# #.............# #..#
#..# #..################ #....# ##..##########..........# #.............# #..#
#..# #.................# ##....# #.......................# #.............# #..######
#..# ##.................# #.....# #.......................# #.............# #.......#
#..# #........########### #.....# #.....########..........# #.............# #.......#
#..# #........# #.....# #.....# #..........# #.............# #.......#
#..# #........# #.....# #.....# #..........# #.............# #.......#
#..# #........# #.....# #.....# #..........# #.............# #.......#
#..# #........# #.....# #.....# #..........# #.............# #.......#
#..# ##..###### #.....# ##..### #..........# ############### #.......#
#..# #..# #..#### #..# ############ #.......#
#..# #..# ##..####### #..# #..######
#..# #..# #.........# #..# #.....#
#..# #..# #.........#######..###### #.....#
#..# #..# #.........##............# ########## #.....#
#..# #..# #.........##............# #........# #.....#
#..#############..###########################.........##............############ #........# #.....#
#.....................................................##.......................# #........# #.....#
#.....................................................##.......................# #........# #.....#
################..#############.....#########.........##............########..## #........# #.....#
#..# #.....# #.........##............# #..# #........# #.....#
#..# #.....# #.........#######..###### #..# #........# #.....#
#..# #..#### #.........# #..# #..# #........# #.....#
#..# #..# #.........# #..# #..# #........# #.....#
#..# #..# #.........# #..# #..# #........# #..####
#..# #..# ##..####### #..# #..# #........# #..#
#..# #..# #..###### #..# #..# ##..###### #..#
#..# #..# #.......# #..# #..# #..# #..#
#..# #..# #.......# #..# #####..#### #..# #..#
#..# #..# #.......# #..# #.........# #..# #..#
#..# #..# #.......# ####..###### #.........# ##..#### #..#
#### #..# #..# #.......#####..........# #.........#########......# #..#
#..# #..# #..# #......................# #........................# #..#
#..# #..# #..# #......................# #........................# #..#
#..# #..# #### #.......#####..........# #.........#########......# #..#
#..# #..# #.......# #..........# #.........# #......# #..#
#..# #..# #.......# #..........# #.........# #......# #..#
#..# #..# #.......# ############ #.........# #......# #..#
#..# #..# #..###### #.........# #......# #..#
#..# #..# #..# #.........# #......# #..#
#..# #..# #..# #.........# ##..#### #..#
#..# #..# ############# #..# #####..#### #..# #..#
#..# #..### #...........# #..# #..# #..# #..#
#..# #....# #...........# #..# #..# #..# #..#
#..# #....# #...........# #..# #..# #..# #..#
#..# #....# #...........# #..# #..# #..# #..#
#..# #....# #...........# #..# #### #..# #..# #..#
#..# #....# #...........# #..# #..# #..# #..# #..#
#..# #....# #...........# #..# #..# #..# #..# #..#
#..# #....# #...........# #..# #..# #### #### #..#
#..# #....# #...........# #..# #..# #..#
#..# #....# #...........# #..# #..# #..#
#..# #....# #...........# #..# #..# #..#
#..# #....# ####..####### #..# #..# #..#
#..# #..### #..# #..# #..# #..#
#..# #..# #..# #..# #..# #..#
#..# #..# #..# #..# #..# #..#
#..# #..# #..# #..# #..# #..#
#..# #..# #..######## #..# #..# ############### #..#
#..# #####..######## #.........# #..# #..# #.............# #..#
#..# #.............# #.........# #..# #..# #.............# #..#
#..#########.............# #.........# #..# #..# #### #.............#######..#
#........................# #.........# #..# #..# #..# #......................#
#........................# #.........# #..# #..# #..# #......................#
#..#########.............# #.........# #..# #..# #..# #.............#######..#
#..# #.............# #.........# #### #..# #..# #.............# #..#
#..# #.............# #.........# #..# #..# ############### #..#
#..# #.............# #.........# #..# #..# #..#
#..# #.............# #.........# #..# #..# #..#
#..# #.............# #.........# #..# #..# #..#
#..# #.............# #.........# #..# #..# #..#
#..# ############### #..######## ###..####### #..# #..#
#..# #..# #..........# #..# #..#
#..# #..# #..........# #..# #..#
#..# #..# #..........# #..# #..#
#..# #..##### #..........# #..# #..#
#..############################......################### #..........#######..############################..#
#......................................................# #.................................................#
#......................................................# #.................................................#
#..############################......#####.............# #..........#######..########............########..#
#### #......# #.............# #..........# #### #............# ####
#......# #.............# #..........# #............#
#......# #.............# #..........# #............#
#......# #.............# #..........# #............#
#......# #.............# #..........# #............#
#......# #.............# #..........# ##############
######## ############### ############
The grid (sized ~120x120) was generated within ~21ms (@Netbook).
-
This project looks promising! And you seem to be quite ambitious with it :)
I like the randomly generated dungeon, it will be funny once you populate it with all kinds of creatures and treasures. Also that you occasionally write about your code design, and the optimizations to run the code on the netbook. Even if it's sometimes a bit difficult to imagine without the context ;)
-
This project looks promising! And you seem to be quite ambitious with it :)
Thanks a lot! Reading those comments is always pushing me :)
Also that you occasionally write about your code design, and the optimizations to run the code on the netbook. Even if it's sometimes a bit difficult to imagine without the context ;)
I plan to write more about code design and netbook-related optimizations. Soon, my next semester will start, so time will be rare, so there won't be much progress. But in the meantime I plan to add lots of unit testing (which isn't always fun but useful). Also I plan to write more about e.g. my entity-component system or other parts (pathfinding, dungeon generator etc.).
So if someone is curious about some implementation details, just ask!
-
Also I plan to write more about e.g. my entity-component system or other parts (pathfinding, dungeon generator etc.).
So if someone is curious about some implementation details, just ask!
Well yeah, ECS is something I'm looking into right now, I nailed the theory down, but I cannot come up with a good implementation in C++. If you could show the basic concepts (Is there an entity class, or is there only an unique ID somewhere for example) and some headers, this would be awesome, cause I couldn't find such information on the net yet.
Thanks and keep up the good work ;)
-
If you could show the basic concepts (Is there an entity class, or is there only an unique ID somewhere for example) and some headers, this would be awesome, cause I couldn't find such information on the net yet.
My basic concept is a clear seperation of system end entities, like the data-oriented design claims. So I built a generic ComponentSystem, which holds a std::vector<T> with the (homogenous component data).
If doing so, you are forced to deal with the fact, that resizing a vector will possibly move the current data out of its current spot to another location. That's why started to identify objects via an ObjectID (just a typedef to an unsigned int). So I changed the component systems' API towards querying via ID.
This leads to the next problem: If everything is querying the objects, you'll need to speed that up. So I introduced another container, which I call "lookup vector". At this point I decided to preallocate the data and lookup vectors to a specific size (which is for MAX_OBJECTS, just a const ObjectID that is very large). So all systems preallocate memory while startup. So data and lookup vector are preallocated. I limited valid ObjectIDs to be >0 to use 0 as "nothing is set" (like nullptr, but without having pointers here).
Btw data is reserved, lookup is resized and filled with "0". The lookup's value is the index within the data vector. But "0" is also used as "not in list". So when adding an object, a new T is emplaced at the end of T and it's index is stored within lookup via lookup[id] = index. So querying for an id will result an index (remember: index 0 is "object not found"). Around this basic concept, I built my entire ECS with the following systems:
- Physics (component with position, face direction, collision info etc.)
- Render (component with sf::Sprite etc.)
- Animation (component with thor::Animator etc.)
- Avatar (component with health, mana etc.)
- etc.
At my design each object is just an ID (not an instance of a specific struct/class). When creating an object, an ID is (externally, via a seperate ID management system) fetched and a physics and render component are acquired. If the object is animated, an animation component is also created etc.
Because there's no object itself, e.g. the (later) AI Component will store it's target's object id (instead a pointer or so). So if the target is removed, the AI system can recognize this when asking the physics whether there's such a component or not.
Well, about releasing objects: I prefer adding the ids to a "unused" vector, because objects might be released during udpate iteration. So I collect all "should-be-released"-ids and call each systems' cleanup() method at the end of each frame.
I hope that helps :) If not, just ask :)
/EDIT: The component systems header looks like this (not exaclty, I removed stuff for simplicity):
template <typename Id, typename T, std::size_t N>
class ComponentSystem {
private:
using container = std::vector<T>;
container data;
std::array<std::size_t, N+1> lookup;
protected:
std::vector<Id> unused;
public:
ComponentSystem();
virtual ~ComponentSystem();
/// Create and return an object with the given id
/**
* @pre The id mustn't be used, yet.
* @pre The id must be > 0.
* @pre The id must be < MAX_OBJECTS.
* @post The object's data is initialized according to T's default ctor.
* @param id to use
* @return reference to the object
*/
T& acquire(Id id);
/// Release the given object
/**
* The object is only marked for deletion. You need to call `cleanup()`
* after iteration to remove all marked objects.
* @pre The object must exist.
* @param id to identify the object with
*/
void release(Id id);
/// Query whether an object with the given id exists or not
/**
* @return true if the described object exists
*/
bool has(Id id) const;
/// Query const reference to an object
/**
* @pre The object must exist.
* @param id of the desired object
* @return const reference to the object
*/
T const & query(Id id) const;
/// Query non-const reference to an object
/**
* @pre The object must exist.
* @param id of the desired object
* @return non-const reference to the object
*/
T& query(Id id);
/// Cleanup unused object
/**
* Call this method to cleanup all unused objects.
*/
virtual void cleanup();
/// Query number of used components
std::size_t size() const;
/// Query maximum number of usable components
std::size_t capacity() const;
typename container::iterator begin();
typename container::iterator end();
typename container::const_iterator begin() const;
typename container::const_iterator end() const;
};
I derive e.g. from
ComponentSystem<ObjectID, PhysicsData, MAX_OBJECTS> at the physics system.
-
Meanwhile, several things has been implemented, which I'd like to present to you :)
- Dungeon Randomization: Size and number of dungeons can be adjusted when starting a game session. All dungeons are procedurally generated. Yet they are not filled with enemies, chests etc. but with stairs. Unfortunately, using stairs is currently not working with automatic camera (see below). This will be fixed soon!
- Automatic Camera Handling: If enabled, the cameras are automatically splitted and/or merged when the players are moving. A player, who is moving far away is moved to a single camera, while all other players stay at a shared camera. And so on. If a player with a splitted cam comes closed to another player, both cameras are merged.
- Manuel Camera Handling: If automatic camera handling is not what you want, it can be disabled at the settings (also while running a game session). If automatic camera handing is disabled, another pause-menu-option is available. It can be used to setup the camera system.
http://youtu.be/tdfAknzQSdI
-
So your ComponentSystem is just a component container? Where is your logic?
I'm particularly interested because I made many different component-based systems before and this seems new to me :D
-
So your ComponentSystem is just a component container? Where is your logic?
All component-related logic is inside the component-system. So all physics logic is handled by the physics system. Each system has a void X::update(sf::Time elapsed) method which updates all its objects (= object components of its specific type) in a "tight" loop (over the contigeous container inside the system).
So e.g. the physics system has some additional methods to e.g. check for collision of the given object, like bool PhysicsSystem::wouldCollide(PhysicsData const & data, sf::Vector2u tile_pos) const;.
I'm particularly interested because I made many different component-based systems before and this seems new to me :D
There are some interesting articles about component-based systems with data-oriented design (too many to post links, nearly each article is useful). Especially a talk by Mike Acton at CppCon was interesting (not about ECS but data-oriented design in general; https://www.youtube.com/watch?v=rX0ItVEVjHc).
But the entire system isn't just data-oriented. Some internals are data-oriented, some object-oriented. And the major API is also object-oriented. So I'm using a hybride of both approaches where it makes sense in my opinion :)
-
Ah ok, you stripped out so much of the header that it seemed to only be a container which holds component data :D
But doesn't this mean that each system can only hold one specific ComponentType e.g. the PhysicsSystem only holds PhysicsData?
How do you update the position of the Sprite then?Does the PhysicsData only point to/reference positional Data of the Sprite?Or do RenderSystem and PhysicsSystem know about each other? :o
I'm particularly interested because I made many different component-based systems before and this seems new to me :D
There are some interesting articles about component-based systems with data-oriented design (too many to post links, nearly each article is useful). Especially a talk by Mike Acton at CppCon was interesting (not about ECS but data-oriented design in general; https://www.youtube.com/watch?v=rX0ItVEVjHc).
But the entire system isn't just data-oriented. Some internals are data-oriented, some object-oriented. And the major API is also object-oriented. So I'm using a hybride of both approaches where it makes sense in my opinion :)
I have already seen that talk(and most probably all the links you could've posted ;)), but thanks anyway ;D
-
Ah ok, you stripped out so much of the header that it seemed to only be a container which holds component data :D
The shown class is only the base class - at yes, it is only a container. The actual derived systems (physics) inherit from this container and provide their logic.
But doesn't this mean that each system can only hold one specific ComponentType e.g. the PhysicsSystem only holds PhysicsData?
Yes, that's the idea of my design: Seperation of concerns / domains. If a system needs data from another system, it needs to know it. E.g. my render system holds a const reference to the physics system to be able to query e.g. for the world position of an object. Some kind of coupling is always needed :D
How do you update the position of the Sprite then?Does the PhysicsData only point to/reference positional Data of the Sprite?Or do RenderSystem and PhysicsSystem know about each other? :o
Well, the physics data contains the position and face direction of the object. If one of these changed, the render system is notified in order to recalculate the transformation of the sprite. In my case this is done via dirty flag.
Other communication is done via events. E.g. in case of a collision, the physics system propagates a collision event without knowing who's listening. Listeners are registered through an interface, so they are notified about each event. So e.g. the (later) sound system could register for collision events to play "blobb" if a player runs towards a wall - without letting the physics system know about the sound system.
But this kind of messaging and decoupling is up to your personal view. Of course you could solve all communication via messaging, leaving all systems decoupled. E.g. the render system would request the obejct position via event... up to you how you life it :)
-
I see :)
In my current component-based system the systems have handles to components they need(Transform,Velocity,Render etc.).
If the entity in question has all the components it needs, the system adds the handles and processes them in its update method.
The MovementSystem for example is like this:
MovementSystem : public EntitySystem<Transform,Velocity>
{
...
void Update(float delta) override
{
for(auto&& component_pack : components)
{
auto position = std::get<0>(component_pack);
auto velocity = std::get<1>(component_pack);
if(position->x > 800 || position->x < 0)
{
velocity->x *= -1.0f;
}
if(position->y > 600 || position->y < 0)
{
velocity->y *= -1.0f;
}
position->x += velocity->x * delta * 0.1f;
position->y += velocity->y * delta * 0.1f;
}
}
The template parameters depict which Components an Entity(just an id) needs to have to handle said entity.
If an entity has all needed components I add them to the component_store(components) as a tuple.
If there are other systems like physics which need Transform, Velocity and e.g. Volume it references the same Transform and Velocity as the MovementSystem.
That way they are decoupled and the only downside is that I have to keep track in which order systems are executed(e.g. if the movementsystem updates before applying physics the positions will be one frame behind)
But enough of my shitty ecs, I don't want to flood your thread with my stuff, we are here to enjoy your stuff(at least I do!)
-
I have to keep track in which order systems are executed(e.g. if the movementsystem updates before applying physics the positions will be one frame behind)
That's also true for my system! First input & ai system to generate object behavior events, then physics. Later avatar (aka rpg-system), then animations and finally render.
But enough of my shitty ecs, I don't want to flood your thread with my stuff
No problem. Your approach is also interesting (but of course I'll keep mine xD). My current code is around ~370kb and makes heavy use of my system :D But I like your idea!
we are here to enjoy your stuff(at least I do!)
Great! ;D
-
In the last days I implemented several features and now, here's a demo video and a list of these features:
- Multiple Dungeons accessable through stairs ("door" through the ground :D )
- Simple AI (using A* for pathfinding). Now, there are enemies who can chase the enemy, melee attack him, lose track and return to their spawn position.
- Fading objects (Characters and projectiles, see fireballs at the end)
- Strafing movement (using a modifier key to lock the face direction)
Currently, enemies are not chasing through doors. But this will be implemented for some type of enemy. In general, enemies are able to use doors and traverse the entire dungeon if necessary.
http://youtu.be/TA3nFBTKWDc
/EDIT: Also follow the project on IndieDB (http://www.indiedb.com/games/rage-2d-coop-dungeoncrawler) ;)
-
Hey folks,
because a new semester has started, the work on rage will be slowed down. Up to my freetime I plan to do some unit testing and want to create additional sprite sheets and other graphics. Stay tuned!
Greetz, Glocke
-
Hey folks,
while testing in my rare freetime I discovered lots of bugs. So I decided to heavily push the unittesting part of the game architecture in order to be able to get rid of those bugs. Also, some refactoring (yees, again :D) will occure.
During this process I'm planning my further steps. Feel free to discuss on features you would like to see in the game!
Greetz, Glocke
-
Meanwhile, I'm nearly 100% focused on refactoring the entire(!) codebase and applying unit testing to it. Up to now, I found lots of bugs (undefined behaviors, annoying copy-paste-based fails and lots of other crazy stuff) by applying unit testing to the yet refactored parts of the codebase. Additionally, I'm going to improve the overall architecture (more loose coupling and fast event-based notifications) to improve the quality of future enhancements.
Up to now:
Linking CXX executable rage_test
Running 296 test cases...
*** No errors detected
-
What unit tests do you have? I can't think of anything reasonable in my game to test with unit tests... :D
-
I can't think of anything reasonable in my game to test with unit tests... :D
I'm unit testing for example collision detection, movement interpolation and the culling of visible objects. I also test lots of conditions within this cases, e.g. that the object - that is going to be moved - is really assigned to an existing scene. (else the interpolation algorithm should throw an usable exception). Therefore I create demo scenes where the exact result is easy to describe.
-
Meanwhile, the core systems (collision detection, sprite animations etc.) has been (re-)implemented and tested. So I started focusing on more high-level features like inventory and quickslot implementations. The quickslot is supposed to allow the player to create shortcuts for spells and items. Both inventory and quickslot implementations are also great for unit testing ;)
Unfortunately, there is no "game code", yet. At the moment, the entire development is about designing, implementing and unit-testing piece by piece. So there's nothing to showcase, yet. Sorry :P
-
Today I face another interesting use case of unit testing: I'm implementing a simple looting system: A dying enemy drops a set of its inventory to "his corpse". That corpse contains several items per registered player - so while looting the items is strictly player-assigned (in terms of who-is-picking-which-item). Then a player can loot the corpse (in fact: the items that were assigned to him). Creating such a drop distribution is interesting here, because my items are structured like that:
struct item_slot {
item_data data;
int quantity;
};
struct inventory {
vector<item_slot> items;
};
where multiple items of the same type are stacked.
Let's come to the point: The distribution's implemented can easily be unit tested. To test whether its precondition is satisfied (that the items will be distributed to the players as equally as possible), can be tested by distributing some items to some players, counting the items per player and building up a histogram to finally verify the dimension of the distribution. Like: 7 items are distributed to 3 players, so two players will obtain 2 items, and one player will obtain 3 items.
-
Meanwhile, some features about the modability of the game has been implemented. So e.g. items or spells can be added by writing additional XML files. Also status effects (like "is burning") can be applied (e.g. by a fireball spell).. I hope this flexibilty will allow many cool stuff for the future development!
Hopefully, the current implementations (combat calculations and similar things) don't take too long .. I can hardly wait to present a brand new demo video, but this will take some additional time...
But stay tuned! This project is not dead ;D
-
Again, here are some experiences about unittesting parts of a game: I'm currently unittesting some sound triggerings. I have a dedicated sound system that is notified via events:
struct SoundEvent {
int object_id;
SoundAction action; // an enum, see below
float pitch, volume; // where 1.0 is "normal"
};
My sounds are grouped to specific actions, specified by an enum:
enum class SoundAction {
Attack, UseItem, CastSpell, Die
};
Additionally, my sound component per object looks like this:
struct SoundData {
map<SoundAction, sf::SoundBuffer const *> sfx;
};
A note about those pointers: They are non-owning raw pointers, because all game resources (including sound buffers) are held by the game session. They are released if the game quits - as the soundsystem is destroyed as well.
Finally: When equipping a weapon, the actor's sound component's "Attack"-action is changed to the weapon's attack sound. This can be unit tested ... EquipWeaponChangesAttackSound ... EquipArmorDoesNotChangeAttackSound.
Additionally, triggering the sounds can also be tested: My systems message each other through those events (see above). So when testing the "equip-items"-code, I can fetch all outgoing SoundEvents (without forwarding them to a soundsystem - there is no sound system involved in this test ^^ But there's a SoundSender who produces SoundEvents) and check whether the correct sound (object id + sound action) was triggered. 8)
-
Meanwhile, I reimplemented lots of features (existing and new ones). But there aren't colorful pictures, yet... sorry ^^ But here's a list of features I plan to ship with the game.
Features
- Free to play and distribute
- Platforms: Windows, Linux; probably Mac OS
- Very low system requirements (e.g. a Netbook)
- Hack'n'Slay combat
- Minor puzzles
- Procedurally generated dungeons, enemies and loot
- Cooperatvie gameplay via splitscreen / shared camera
- Customizable keyboard and gamepad controls
- Modable game content via XML and Lua (for AI scripting)
- more tba
Visit Rage @ IndieDB (http://www.indiedb.com/games/rage-2d-coop-dungeoncrawler) for media.
-
After refactoring major parts of the actual game logic (using potions, casting spells, inflicting status effects like "burn" or "frozen"), I'm reimplementing the combat system.
At the moment, most actions like attacking, using a potion or a spell, or even interacting with the environment (e.g. moving a barrier) is executed with a slight delay: The animation is started immediately, the actual action (as ItemEvent, SpellEvent etc.) is sent to a delay system. It will delay the event some milliseconds and finally forward it to the actual system that is handling the event.
Example: The player presses an action button. An ActionEvent is sent from the Input- to the ActionSystem to check e.g. whether the actor can do anything (he might be dead, stunned or just temporary not allowed to attack..). If commited, the action's animation is triggered (e.g. melee attack animation if using a sword). A combat event is generated and forwarded to the delay system. The animation will be played and after some time, the delay system will finally forward the combat event to the combat system.
At last: Damage, experience and possibly inflicted effects (a firesword might inflict "burn" to its target) will be propagated.
Later, the Hud can display "+5 EXP" or reduce the player's health bar. Also the AI can be notified about "player X damaged you with Y dmg" or "you received 'burn' by player X".
At the moment I'm very very excited about writing the later AI. But I'll stick at improving and unit testing my system at its current point.
Stay tuned 8)
-
In the past, I was talking about XML-based modability. Here's an example about adding something like a "burning bow" (let's call it "Firebow") to the game.
<general type="Weapon" display_name="Firebow" icon_name="icon/bow" sprite_name="bow" worth="100" />
<equip slot="Weapon" melee="false" two_handed="true" />
<bullet name="fireball" />
<effect name="burn" ratio="0.1" />
<require Dexterity="15" />
<damage Bullet="10" Fire="5" />
The specified icon_name refers to "data/gfx/icon/bow.png", which should be used for quickslot shortcuts. The sprite_name refers to the object's sprite layers used to draw different equipment. I plan to show some GIFs about those layers and their animations, soon!
A flexible thing is that effect node with its "burn" effect. It refers to this XML-file:
<general display_name="Burning" />
<damage Life="-10" />
The display_name could be displayed e.g. when looking to the player's state to see active effects. As you can see: The object will lose 10 life (e.g. per second) while burning. Those nodes can be extended to realize e.g. boosts to defenses etc.
-
After refactoring major parts, I'm proud to present you some sprite animations. I seperated legs and torso and splitted those into different layers, in order to combine different sprites (e.g. basic human + heavy armor + bow) to achieve very flexible rendering possibilities. Also, attacking while moving is possible now.
Next step will be a playable demo with a subset of gameplay features - so stay tuned!
(http://cgloeckner.bplaced.net/public/rage-sprites/archer.gif)(http://cgloeckner.bplaced.net/public/rage-sprites/cleric.gif)(http://cgloeckner.bplaced.net/public/rage-sprites/fighter.gif)
(http://cgloeckner.bplaced.net/public/rage-sprites/rogue.gif)(http://cgloeckner.bplaced.net/public/rage-sprites/wizard.gif)
And here is one with a simple dying animation at its end:
(http://cgloeckner.bplaced.net/public/rage-sprites/full_animation.gif)
-
I'm currently working on a (at least semi-well-tested) playable demo. To be able to release the demo, I reduced the subset of gameplay functionality to the following features:
- [ Done ] Basic Gameplay (Combat, Leveling etc.), I spare you further details^^
- [ Done ] Local Coop (including Gamepad support)
- [ Done ] Character classes: Warrior, Rogue, Wizard
- [ Done ] Savegame Management
- [ Current ] Random Dungeons, but pre-generated Enemies
- [ Planned ] Powerups (Life/Mana) dropped by Enemies
- [ Planned ] Suitable Enemy AI
- [ Planned ] Enemies: Thief, Giant Spider, Skeleton, Ghost
- [ Planned ] Game Menus
- [ Planned ] Available for Windows and Linux systems (*)
(*) I haven't compiled the game under windows, yet. But I'm looking forward to do this as the demo is near completion.
-
Hi guys!
since I started this project, I always compiled on a x86 computer using Ubuntu 14.10. Since my new laptop arrived, I was curious about compiling on other systems. So I setup my laptop with a Windows 7 and Ubuntu 15.04 (both 64 bit versions). Yesterday I spent time to setup the build environment on my Ubuntu 15.04 and finally made it!
Today, I'm very happy to successfully compiled my project on Windows 7 using MinGW. This sounds simple, but is a huge step towards on of my milestones. So I'm looking forward to a playable tech demo!
- [ Done ] Basic Gameplay (Combat, Leveling etc.), I spare you further details^^
- [ Done ] Local Coop (including Gamepad support)
- [ Done ] Character classes: Warrior, Rogue, Wizard
- [ Done ] Savegame Management
- [ Done ] Random Dungeons
- [ Current ] Random Enemies and Loot
- [ Planned ] Powerups (Life/Mana) dropped by Enemies
- [ Current ] Suitable Enemy AI
- [ Planned ] Enemies: Thief, Giant Spider, Skeleton, Ghost
- [ Planned ] Game Menus
- [ Current ] Available for Windows and Linux systems (32 and 64 bit versions)
-
Meanwhile, I finished the initial AI-Implementation using customizable Lua Script via LuaBridge!
Short video:
https://www.youtube.com/watch?v=62WzeasgQLU
- [ Done ] Basic Gameplay (Combat, Leveling etc.), I spare you further details^^
- [ Done ] Local Coop (including Gamepad support)
- [ Done ] Character classes: Warrior, Rogue, Wizard
- [ Done ] Savegame Management
- [ Done ] Random Dungeons
- [ Current ] Random Enemies and Loot
- [ Planned ] Powerups (Life/Mana) dropped by Enemies
- [ Done ] Basic Enemy AI
- [ Planned ] Enemies: Thief, Giant Spider, Skeleton, Ghost
- [ Planned ] Game Menus
- [ Current ] Available for Windows and Linux systems (32 and 64 bit versions)
-
I love roguelikes!
Nice to see things up and functional in Rage.
The background art is obviously pretty barren still, but I agree with getting the core mechanics up and running before dealing with the window dressing.
-
I love roguelikes!
Nice to see things up and functional in Rage.
The background art is obviously pretty barren still, but I agree with getting the core mechanics up and running before dealing with the window dressing.
Thannks man! But yes, the arts (in general) are pretty easy at the moment.. Gonna overhaul this once the game is in a release-near state :)
-
Hey guys!
despite the obvious inactivity in this thread ... the project itself is still alive! In the recent past, I was struggling some issues referring Pathfinding and the AI's Lua Api. But those problems are solved and I'm looking forward working on the actual game again :)
As brief update: The upcomming steps are some respawn implementation and building up the player's HUD (supporting splitscreen with a dynamic number of players etc.). Furthermore, I plan to work on a "room editor".
Since the dungeons are generated completly random, the corridors and rooms look like badly procedurally generated: unexciting, empty, boring! To solve this, I plan to add random vegetation on the corridors and hand-crafted rooms, which will be randomly distributed (including rotating and/or mirroring them) over the dungeon. I'm really curious about this ... hope you're curious too!!
-
I just nailed the pending milestones for the playable alpha demo:
- Game UI: This is the current milestone. This includes game menus (settings, title screen) as well as the game's hud (health bar, levelup-popups etc.)
- Enhanced Randomization: Including a Room editor and more beautiful corridors
- Enemies (like in the last list)
- Powerup system: Items won't be completly implemented, so killed enemies will drop health boni etc.
- Enhanced Code quality: Pure internal stuff (further unit testing and code documentation)
- Initial Audio implementation: Sound effects for attacking, some basic background ambience sounds etc.
Some other features like enhanced animations or an implementation of blocking enemies' attacks will be delayed to another version. This way I try to make sure that the demo will actual be available ... some day :D
-
I attached a screenshot of the current alpha menu's "Lobby screen". It's minimal but powerful ;) Stay tuned!
-
Today, I'd like to preset some piece of music I wrote for becoming the "dungeon theme" of the game. The composition is still in progress, but I'm not sure which style of interpretation fits the visuals the most: Classical or chiptune style.
http://www.youtube.com/watch?v=OG88cP3-ed4
What's your oppinion?
PS: I still suck at embedding videos ^^
-
I quite like the music and I personally prefer the non-chiptune style of this piece.
To embed YouTube videos, just remove the "s" from https.
→ http://www.youtube.com/watch?v=OG88cP3-ed4
http://www.youtube.com/watch?v=OG88cP3-ed4
-
I quite like the music and I personally prefer the non-chiptune style of this piece.
As people most do :D
To embed YouTube videos, just remove the "s" from https.
Thanks!
-
Meanwhile, not just terrain can cause shadows... now, also movable objects can!
http://www.youtube.com/watch?v=Fnyq4CPviAc
-
Today, I also added some simple menu animations
(http://i.imgur.com/GM1B1Bk.gif)
-
Meanwhile, more progress happened!
- new HUD: small tubes show the amount of life, mana and stamina. also the experience is shown
- camera decoration: since camera borders can be hard to figured out, they are now decorated :)
- player colors: to have a better overview, players now have colors which represent them (lighting, player name).
Enjoy watching!
http://www.youtube.com/watch?v=D8eY4cRAXxA
-
Another step towards playable alpha demo was implementing powerups, that are dropped by killed enemies.. they can be used to regenerate life and/or mana! Implementing the complete UI for looting and inventory management would be too much to add, because I want to release the alpha demo more soon than later ^^ So ... having less (features) is more :)
(http://cgloeckner.bplaced.net/public/rage-powerup.gif)
Next changes:
- improved dungeon randomization (especially room generation)
- improved game mechanics (base for simple puzzles)
- more graphics (mostly enemies)
- audio implementation (background music, simple sound effects)
- better AI scripting
Stay tuned!
-
While heading to better dungeon generation, I added some ambience stuff to rooms to make them look more interesting - even without lighting. So I added some simple vegetation.
(http://i.imgur.com/CNpS2YF.png)
(http://i.imgur.com/ega8yyZ.png)
-
Hey guys!
atm I'm working on a room editor (based on ImGui within SFML). Here are some WIP screenshots of the editor and the rooms loaded to the game:
(http://i.imgur.com/ZpXpY7h.png)
(http://i.imgur.com/ugB3EAE.png)
(http://i.imgur.com/u7Twuwr.png)
(http://i.imgur.com/Vhik63R.png)
-
This looks like it would be fun. I like how the progress looks so far ;)
-
Thx Recoil!
Meanwhile, more stuff has been finished. The most useful is transforming predefined rooms while the actual dungeon generation. The rooms are not just filled with ambience stuff (plants, corpses etc.) but also rotated (by multiples of 90 degree) and can be flipped along x- and/or y-axis.
Editor:
(http://i.imgur.com/ca2ZwP5.png)
Ingame:
(http://i.imgur.com/LoVQgaW.png)
(http://i.imgur.com/v211EbQ.png)
(http://i.imgur.com/nyZWEU5.png)
(http://i.imgur.com/G1DkDWU.png)
-
I just finished the game's debugging/test mode.. hopefully a good foundation for all further development! :)
(http://i.imgur.com/Pqpfpse.png)
/EDIT: Just added an animated spider sprite.. after cheating on the savegame I've got this... Enjoy watching!
http://www.youtube.com/watch?v=FHWcN_hUry8
-
After tons of additional changes (mostly referring audio implementation), I'm proud to preset an alpha gameplay demo video:
http://www.youtube.com/watch?v=-jm08gtHCZk
Stay tuned for the playable demo! :)
-
Love it! Audio and the new ambience tiles truly add a lot to the game. I'm really looking forward to trying it out :)
-
Love it! Audio and the new ambience tiles truly add a lot to the game. I'm really looking forward to trying it out :)
I'm happy reading this :D
But before I gonna release a demo, I'd need to change the project name to avoid confusions with Rage by id software. Suggestions requested! :)
-
No, no! You know your game best. You put countless hours in its development. The name must be something that comes from yourself. Something that important cant grow on the responsibility of someone else.
-
Coduc
(co-op dungeon crawler)
You can't expect anything good from me; I know nothing of the story :P
-
You can't expect anything good from me; I know nothing of the story :P
Me neither - there is no story :D
No, no! You know your game best. You put countless hours in its development. The name must be something that comes from yourself. Something that important cant grow on the responsibility of someone else.
That's right I guess ^^
Well... the name "rage" was basically the best matching word do describe the desired gameplay: fast, frenzied and raging ^^ So I'd really want to keep this in the name, because it's that what Ungod described. I was thinking of "Dungeons of Rage" or "Rage of the Rogues" - both transport the message (dungeoncrawling, rogue-similar) to the name. But I'm not a 100% convinced yet :D
-
If you have a appropriate lore background name it after your main hero (in case there is one) or the world the game is settled in. If you want to title it according to the style of gameplay, just find a synonym for rage. :D
But in general, I think I like story-based names more.
-
If you have a appropriate lore background name it after your main hero (in case there is one) or the world the game is settled in. If you want to title it according to the style of gameplay, just find a synonym for rage. :D
But in general, I think I like story-based names more.
Unfortunately I don't have a lore background... also the game's world has no name :D
I'm currently brainstorming for giving the game some basic story later on ;)
Now a bit progress:
While working towards the playable demo, I added the last piece of player animation that was yet missing: an animation for moving crates and other obstacles.
(http://i.imgur.com/8Y6BpdW.gif)
Maybe the actor object should follow the crate ^^
-
Maybe the actor object should follow the crate ^^
Maybe, but it would depend on if your character had some psychokinetic power!
-
Maybe the actor object should follow the crate ^^
Maybe, but it would depend on if your character had some psychokinetic power!
I like that idea :D Unfortunately it doesn't match the scenario :D
-
Because "Rage" is already the titel of a (large) existing game and I don't want to cause confusions/problems, I decided to rename the project. Actually, the project has only a working titel ("rage"), yet. So the real project title is upcomming!
Dungeons of Racod
Racod is an abreviation for Rogue-like Action Coop Dungeoncrawler und reflects 100% of the game's intension.
Furthermore: I think of adding "Racod" as final boss, so the players get an objective: explore die levels of Racod's dungeon to finally find and defeat Racod himself.
Feedback requested ^^
-
Like it. Similar method to what I used for the name suggestion earlier ;)
I think it's a good idea to use the word in the story; final boss sounds like the perfect solution. Don't tell people what it means (oops, maybe too late? ;D )
-
Don't tell people what it means (oops, maybe too late? ;D )
Nobody will remember :D
-
I'm currently working on proper balancing, ai and some new enemies. A playable state is coming closer each day 8)
(http://i.imgur.com/xUK7QEY.png)
-
Current project: Rage - Rogue-inspired Coop Action RPG
You might want to update your signature ;)
-
Current project: Rage - Rogue-inspired Coop Action RPG
You might want to update your signature ;)
thx ^^
-
After migrating my lua integration from outdated LuaBridge to the awesome sol2 (https://github.com/ThePhD/sol2), I finished the alpha demo's ai. Now the enemies can change their weapons on demand (e.g. between sword and bow referring to the distance between the bot and its target).
(https://media.giphy.com/media/l0Hlzgb5QMMMqKCdi/giphy.gif)
-
I'm currently thinking about adding a tutorial to the alpha demo or not. The later game will feature a tutorial, but I'm not sure whether this is a good idea at the current stage.
There's a poll on twitter: https://twitter.com/racodslair/status/755755210509869056
Feel free to participate :)
-
What kind of tutorial are you thinking about?
-
What kind of tutorial are you thinking about?
Basically to explain how the controls work. But also referring basic gameplay (how to cast a spell etc.).
-
Meanwhile, I decided not to implemented the tutorial at the current stage of development. Implementing a good tutorial would crash my schedule :(
And this schedule says: I'm going to release the demo either this or next week - hopefully, if no major problems occure.
-
Playable Demo available
via IndieDB (http://www.indiedb.com/games/racodslair/downloads/alpha-demo-v01-alpha)
via GitHub (Binary Release) (https://github.com/cgloeckner/racods-lair/releases/tag/v0.1-alpha)
(http://media.indiedb.com/images/global/indiedb.png) (http://www.indiedb.com/games/racodslair/) (https://www.adamyourself.com/de-de/assets/brands/opel/images/facebook-icon-44x44.png) (http://www.facebook.com/racodslair/) (https://www.fepblue.org/assets/img/twitter_button.png) (http://www.twitter.com/racodslair/)
-
Nice! I've been waiting for this :D
Tested on Windows 10, x64
First impression
Dark, creepy, love it! Especially the music. You wrote you used certain samples, so I guess you've created it yourself? It fits pretty well, menu and ambience. The only thing I'd change is to make it loop smoothly.
Well, then I got a list of issues that I noticed while playing it. I know it's a pre-alpha and there are lot of things that you'll change, but I'll list it anyway.
Issues
- Fullscreen The game's options say "fullscreen" but it isn't. It actually creates a borderless window with the given resolution. SFML supports fullscreen and if you want to stay with a borderless window, you can read out the resolution of the users screen and use that if fullscreen is checked
- Window Resizing ... doesn't work as expected. The canvas is fixed. If you want it like that, don't give the user the option to resize the window.
- Close Button If you are inside a dungeon and press the close button, the game switches into the menu (pause). I'd expect it to close.
- I'm dead, help me! As I'm a noob in roguelikes, I died very very soon. Is there anything I can do to revive my char? If there is, make it clearer. Otherwise, show an option on the screen to return to the main menu.
- Saves There is an option "autosave" in the settings. Is there also an option to save manually?
- Collision Some corners (and barrels?) behave like a ramp, but they're drawn like a square. If you are able to have ramp collision, why not draw it as one? :)
Also, this strange behaviour:
(https://media.giphy.com/media/l0MYub5aalDYQSjTi/giphy.gif)
It shakes when I try to walk against a corner. It doesn't when I walk against straight walls. - Mana I played as a rogue. What is the mana for? (Give us a special attack :P) Shooting arrows doesn't need any mana and I can just spam them by staying on space. There is no penalty for this behaviour. Maybe change it to attack only when space is just pressed and not repeat if it's always pressed.
- Chests How can I open a chest? Interact doesn't work. Isn't it implemented yet?
- Levelup I know we programmers start counting at 0. But levels usually start at 1 :)
- Interface It isn't directly clear what the several bars are in the interface. Maybe use xp text for xp? Mana and health are pretty clear on the other side - if you're used to gaming. Also, showing the difficulty in the top right corner seems a bit weird (is this the debug mode.. or is this the real life) - it's no information a user needs to see constantly.
- Shifting Objects Nice to have. But what for?
Well, overall it makes a pretty good impression. I didn't experience any crashes so far, but I got stuck in the first dungeon. I'm lost. It's dark and creepy. I don't find any more enemies and I don't know how to return to the lobby / change the dungeon. Where is that RACOD, he needs to die!
Final question: Are the levels handmade or randomly generated? I know that a lot of roguelikes have randomly generated dungeons, which saves the developer time but also introduces limitations, of course.
Cheers,
a fellow "bell".
-
Nice! I've been waiting for this :D
Tested on Windows 10, x64
First impression
Dark, creepy, love it! Especially the music. You wrote you used certain samples, so I guess you've created it yourself? It fits pretty well, menu and ambience. The only thing I'd change is to make it loop smoothly.
Thanks!! You mean the music transitions?
Fullscreen The game's options say "fullscreen" but it isn't. It actually creates a borderless window with the given resolution. SFML supports fullscreen and if you want to stay with a borderless window, you can read out the resolution of the users screen and use that if fullscreen is checked
This is unfortunately a workaround: The fullscreen on linux is broken for me, so I switched to that solution. I also faced issues when running through wine, so it seems like I totally forgot about that! :)
Window Resizing ... doesn't work as expected. The canvas is fixed. If you want it like that, don't give the user the option to resize the window. [/li][/list]
Can you make a screenshot?
Close Button If you are inside a dungeon and press the close button, the game switches into the menu (pause). I'd expect it to close.
Good point ... fast exit should be possible.
I'm dead, help me! As I'm a noob in roguelikes, I died very very soon. Is there anything I can do to revive my char? If there is, make it clearer. Otherwise, show an option on the screen to return to the main menu.
Reviving characters is implemented but not used by the alpha demo. But there'll be spells to revive your friends - or even a limited number of free revives. Anyway, you can just pause the game and quit to the menu.
Saves There is an option "autosave" in the settings. Is there also an option to save manually?
Yes: quit the game. This option prevents savegame loss in case of a crash.
Collision Some corners (and barrels?) behave like a ramp, but they're drawn like a square. If you are able to have ramp collision, why not draw it as one? :)
What do you mean by the term "ramp" exactly? That avoid-wall-collision-by-automatically-changing-the-movement-direction?
Also, this strange behaviour:
(https://media.giphy.com/media/l0MYub5aalDYQSjTi/giphy.gif)
It shakes when I try to walk against a corner. It doesn't when I walk against straight walls.
That's pretty cool :D Even cooler: I cannot reproduce this with wall tiles but with objects (barrels etc.). But I've got an idea about the root of that evil :)
EDIT: Meanwhile, I'm able to reproduce it :)
Mana I played as a rogue. What is the mana for? (Give us a special attack :P)
Technically, each character can use spells (later^^). Atm there is only one way to consume mana: be a wizard. Later, all characters will have possibilities to use their mana :)
Shooting arrows doesn't need any mana and I can just spam them by staying on space. There is no penalty for this behaviour. Maybe change it to attack only when space is just pressed and not repeat if it's always pressed.
Well, the bow-animation should be played and the arrow should spawn delayed. Is this not happening? I'm not sure what you're describing :)
Chests How can I open a chest? Interact doesn't work. Isn't it implemented yet?
The chests are currently only decoration. In fact, looting is already implemented but (as you might already guessed^^) not used by the demo :D There are lots of things semi-done :D
Levelup I know we programmers start counting at 0. But levels usually start at 1 :)
Oh, did I forgot the increment? Thanks ;D
- Interface It isn't directly clear what the several bars are in the interface. Maybe use xp text for xp? Mana and health are pretty clear on the other side - if you're used to gaming. Also, showing the difficulty in the top right corner seems a bit weird (is this the debug mode.. or is this the real life) - it's no information a user needs to see constantly.
Right! I delayed the interface explanation to the later tutorial (huhuuu... delaying importing things xD).
Yeah, the difficulty could be moved to the pause screen or else.
Shifting Objects Nice to have. But what for?
For confusion the demo testers :D
I scheduled minor puzzles using this mechanism ... but as always: not fully implemented yet :D
I didn't experience any crashes so far
Yay, that's cool :)
but I got stuck in the first dungeon. I'm lost. It's dark and creepy. I don't find any more enemies
Well, sometimes the game makes me feel lost, too :D
and I don't know how to return to the lobby
Pause game and select "quit" -- should work ^^ ... should :D
Where is that RACOD, he needs to die!
Explore the dungeon ;)
Final question: Are the levels handmade or randomly generated? I know that a lot of roguelikes have randomly generated dungeons, which saves the developer time but also introduces limitations, of course.
The dungeons' layout is randomly generated. All rooms are handcrafted and randomly distributed. So I've got something from both "worlds" :)
Cheers
Cheers! And thanks a lot for testing. I hope you stay in touch (also on reporting things^^)
-
Thanks for the explanations :)
Music: Yes, I mean you can hear where the track ends and restarts.
Window Resizing: It just shouldn't be that a user with a bigger screen (resolution) sees more of the level. Playing the game in a small window shows significantly less of the dungeon. Not fair :P
Fullscreen: We've also had to fight with the SFML fullscreen bug on Linux (and Mac). I'll drop you a PM.
Ramp: a "slope". It was just unexpected, regarding the wall shape.
Anyway, I'll keep playing and exploring then ;) looking forward to see more of that great game.
-
Thanks for the explanations :)
You're welcome! I added the "highlights" to the issue section of the game data's github repository (https://github.com/cgloeckner/racods-lair) (the game itself is yet closed source but the repo contains the game data)
Window Resizing: It just shouldn't be that a user with a bigger screen (resolution) sees more of the level. Playing the game in a small window shows significantly less of the dungeon. Not fair :P
Well ... "fair" is not the right word in that case :D All players (playing together) share the same screen :P But I share that feeling of unfair due to screen size ... I'm unsure what to do here... because I don't want to stretch the screen ^^
Fullscreen: We've also had to fight with the SFML fullscreen bug on Linux (and Mac). I'll drop you a PM.
Thanks.
Ramp: a "slope". It was just unexpected, regarding the wall shape.
So, if the player would "slide" along the book shelfs would be better? :)
Anyway, I'll keep playing and exploring then ;) looking forward to see more of that great game.
8)
-
I've tried it to, and will come with full review later. But about the full screen:
Have 2 extra floats:
Xscale, Yscale.
Make sure to store your original oXsize and oYsize.
And have your current cXsize and cYsize.
Then after each resize:
Xscale = (1.0 / oXsize)*cXsize.
Yscale = (1.0 / oYsize)*cYsize.
If (Xscale < Yscale) your_scale_function(SF::vector2f(Xscale,Xscale));
Else your_scale_function(SF::vector2f(Yscale,Yscale));
This way the scale /shown window will always be the shortest.
Another more hacky way would be to draw a black texture with a transparent center the size of your view. Then render that last over ever, scaled to the view...
Just suggestions....
-
Hello, saw your post on twitter, so I thought I'd drop in and give my impressions.
I think you've got a good base game to build on. I didn't really encounter any bugs, although I was curious, is there a reason that the character and save file names have a minimum length? I often use single letter names, but that might not be something other people run into.
I think a few things that will help generally fall into UI:
-Make the damage done by you (and enemies) more visible, maybe make the text larger when a large amount of damage is done
-I think a mini-map will help a lot. I got lost and wasn't sure where I was supposed to go.
-I'm not sure where my health is? I thought the blue and red meters were health and mana, but they didn't change when I got hit, are they potions?
-I wasn't able to pick up the plus icons (I'm assuming they're power ups of some kind), but then at one point I could pick up one of them. I'm assuming eventually I took damage, and the game then let me pick up the health up. Maybe allow players at full health to pick up the health-ups for a small amount of experience or money instead?
Overall, I think it's a very good start, it will be interesting to see your progress!
As a side note, is there any mechanical difference for light and dark areas? For example, could a rogue hide in the dark, or sneak attack someone? I realize features like this are probably a way off, but just curious about the design direction you're headed in. I think if you did have something like that, you could distribute the light less evenly, so it might be visually a little more dynamic.
-
Hello, saw your post on twitter, so I thought I'd drop in and give my impressions.
Great, you're welcome! :)
is there a reason that the character and save file names have a minimum length?
Not really, it was just a quick idea ^^
-Make the damage done by you (and enemies) more visible, maybe make the text larger when a large amount of damage is done
The damage by enemies is indicated by the labels. If the player's damage is shown, too this messes up the screen with (in my opinion) too many numbers. But feel free to discuss @ all.
-I think a mini-map will help a lot. I got lost and wasn't sure where I was supposed to go.
Well, yes, that would help. But I'm unsure whether this fits the genre well... but I'll note that minimap-idea! :)
I'm not sure where my health is? I thought the blue and red meters were health and mana, but they didn't change when I got hit, are they potions?
Health is red, Mana is blue. The meter's behavior and graphics do not match 100% each time. In fact, if you've got a little damage, the cork of the tube hides the upper end... that's now on the list, thank you :)
-I wasn't able to pick up the plus icons (I'm assuming they're power ups of some kind), but then at one point I could pick up one of them. I'm assuming eventually I took damage, and the game then let me pick up the health up. Maybe allow players at full health to pick up the health-ups for a small amount of experience or money instead?
Since no potions are implemented, I added those powerups for this demo. They are automatically used if necessary if you enter their tile. But I plan to drop them later.
Overall, I think it's a very good start, it will be interesting to see your progress!
Thanks!
As a side note, is there any mechanical difference for light and dark areas? For example, could a rogue hide in the dark, or sneak attack someone? I realize features like this are probably a way off, but just curious about the design direction you're headed in. I think if you did have something like that, you could distribute the light less evenly, so it might be visually a little more dynamic.
Well, the entire lighting can be disabled (e.g. if necessary due to performance on machines with a lowend graphics card). So I don't want to add lighting-related mechanics, because they would be ridiculous after disabling lighting :D
Thanks for your feedback :)
-
No problem! I hope some of it was useful!
-
No problem! I hope some of it was useful!
Sure it was!
I'm looking forward to some feedback on the multiplayer mode :)
-
Played it for a bit. Looks pretty great and runs very smoothly.
Didn't notice any bugs, you've done a lot of work! :D
There are some issues with game feel, though.
* The movement feels floaty due to player not stopping at the moment I release the walking buttons. It feels like a player is aligned to some grid. Is there a reason for doing this? Maybe that's a standard for some roguelikes? If so, can you tell me which good roguelike games do this? I want to see how they handle this and I'll provide some feedback on how you can improve walking.
* Attack animation doesn't tell you about attack hitbox. I'm not sure how far I can reach with it and if I can attack things in front of me or not.
* It's unclear if I hit enemy or not. There should be sounds when you hit something, enemies may shake a bit or become red for some frames. Their health bar should probably be above them because it's hard to look at their health meter that's so far away. Maybe you can add some numbers which appear when they do damage to you or you do damage to them?
* Attack animation should look something like this:
(http://orig08.deviantart.net/2429/f/2012/005/8/f/scott_pilgrim_animation___gideon_by_omgitslucas625-d4lg903.gif)(http://rs1309.pbsrc.com/albums/s630/BackwardsPenguin/RamonaFlowersgif_zpsf39b78a7.gif~c200)
Check out this animation's frames. It starts slow and then the attack itself is very fast. This is how attack should feel.
Check out this book (https://www.amazon.com/Game-Feel-Designers-Sensation-Kaufmann/dp/0123743281/ref=sr_1_1?ie=UTF8&qid=1470813082&sr=8-1&keywords=game+feel). It's pretty great and tells you how to make input feel more responsive.
P. S. If you want me to give feedback on other aspects of the game, please tell me, I'll play a bit more and provide some additional feedback. :D
Good game, keep working on it!
-
It feels like a player is aligned to some grid. Is there a reason for doing this?
It's because all objects are aligned to the tile grid. I made this assumption in the early beginning for simplifying the later systems that are based on that (like collision or aiming). The initial idea was to allow the game to run with as less computations as possible - I'm also testing it on a netbook.
Also, I found this behavior suitable for the traditional oldschool rogue-likes. But I was thinking about moving to "more modern" non-grid-aligned movement from time to time.
Attack animation doesn't tell you about attack hitbox. I'm not sure how far I can reach with it and if I can attack things in front of me or not.
Basically, the melee hit range is about exactly one tile. But I enlarged this to allow chasing an enemy through melee. But there's an audio feedback if you really hit the opponent :)
It's unclear if I hit enemy or not. There should be sounds when you hit something
Maybe the enemy-was-hit-sound gets lost in the madness of sound effects :S
Their health bar should probably be above them because it's hard to look at their health meter that's so far away.
Good point!
Maybe you can add some numbers which appear when they do damage to you or you do damage to them?
The damage towards the player is already shown. But I don't want to mess up the hud by damage towards the enemy :S
Attack animation should look something like this [...] Check out this animation's frames. It starts slow and then the attack itself is very fast. This is how attack should feel.
Thanks for that!
P. S. If you want me to give feedback on other aspects of the game, please tell me, I'll play a bit more and provide some additional feedback. :D
I'll really looking forward to some multiplayer feedback, because it allows local coop :)
Good game, keep working on it!
Thanks for testing and your feedback!
At the moment there's not that much time. But the development will be continued - for sure!!
-
Gave it a try and I found it really enjoyable except it wouldn't work with my xbox one mini controller.
But I'm just glad the controls are customizable for once ^^
This has a lot of comments and I didn't read all of them so maybe it's been mentioned. Sorry :)
Anyway I hope to see this again in a alter version - if I do I'll definitely download again.
-
Gave it a try and I found it really enjoyable except it wouldn't work with my xbox one mini controller.
Glad you like it! Does your XBox One Mini Controller work with a basic SFML-based application?
Anyway I hope to see this again in a alter version - if I do I'll definitely download again.
Thanks, I'll do further work once I've got more free time :)
-
I currently think about changing the graphics style (including perspective). Some prototype sprites are already finished:
(https://media.giphy.com/media/3o7TKxxgrP71izrjAA/giphy.gif)(https://media.giphy.com/media/3o7TKsKsTj7cFAZWXm/giphy.gif)
-
Hey, I went as far as the 3rd floor, this is my feedback.
- The game crashed once when pressed ESC during a game, but I've failed to reproduce this problem (Windows 10, x64). Other than that, no other significant technical issues.
- I would rather use the mouse for facing a direction and attacking, but if you do commit to the arrow keys to change players face direction, make so the players ALWAYS face the direction they are walking UNLESS they are pressing the arrow keys. Since you are walking through straight corridors, the enemies will always appear in front of you, so it makes sense to have you facing walking direction by default.
- Make the ladders more visible so the player inevitably notice it if he finds it.
- Since there's a lot of walking around, you should consider having a sprint button if you haven't yet.
- The health bar is red. The health increased labels are green. I'm confused.
- The ranged combat has some skill involved since you can dodge projectiles and completely avoid melee enemies, which is good. The melee combat on the other hand doesn't seem to have any skill involved. You can't block, you can't predict when the enemies' melee attacks are going to land, you hold space bar and hope you don't die. Something you can do though is strategically place your character in a 1 tile wide corridor so only one enemy can hit you at a time, so maybe you can explore this idea further when implementing abilities.
Anyway, it has growth potential. About your plans to change the perspective, I particularly like the top-down perspective, as long as everything is polished in the final version. These new prototype sprites look pretty good though, reminds me of Crawl (http://store.steampowered.com/app/293780/).
Good job, keep up the good work!
-
I found a glitch I have not been able to replicate.
I switch my quickslot to no 1.
Pressed enter on a wooden chest(thought they opened)
Crash.
-
Thx for your testing! :)
The game crashed once when pressed ESC during a game, but I've failed to reproduce this problem (Windows 10, x64). Other than that, no other significant technical issues.
Glad there's nothing significant ^^ But the crash on esc sounds really interesting :)
I would rather use the mouse for facing a direction and attacking, but if you do commit to the arrow keys to change players face direction, make so the players ALWAYS face the direction they are walking UNLESS they are pressing the arrow keys. Since you are walking through straight corridors, the enemies will always appear in front of you, so it makes sense to have you facing walking direction by default.
Yes! Mouse support and minor other input things are scheduled. Stay tuned! :)
- Make the ladders more visible so the player inevitably notice it if he finds it.
- Since there's a lot of walking around, you should consider having a sprint button if you haven't yet.
- The health bar is red. The health increased labels are green. I'm confused.
Thanks, I'll consider that!
- The ranged combat has some skill involved since you can dodge projectiles and completely avoid melee enemies, which is good. The melee combat on the other hand doesn't seem to have any skill involved. You can't block, you can't predict when the enemies' melee attacks are going to land, you hold space bar and hope you don't die. Something you can do though is strategically place your character in a 1 tile wide corridor so only one enemy can hit you at a time, so maybe you can explore this idea further when implementing abilities.
To be honest, I'm not happy with this lack of skill-involve-unbalance. I scheduled an idea on shields and blocking attacks etc. This needs definitely more work!
Anyway, it has growth potential. About your plans to change the perspective, I particularly like the top-down perspective, as long as everything is polished in the final version. These new prototype sprites look pretty good though, reminds me of Crawl (http://store.steampowered.com/app/293780/).
Good job, keep up the good work!
Thank's and that's a point, too: I think the shown perspective would make it (from a graphical perspective) too similar to crawl (which I want to avoid). Until now, the pure (not slightly altered) topdown perspective is not that common afaik. Possibly a feature to keep.
I found a glitch I have not been able to replicate.
I switch my quickslot to no 1.
Pressed enter on a wooden chest(thought they opened)
Crash.
Thanks! Hmm, difficult to debug.. any console output or similar things available for this crash?
-
Since I haven't released something since quite a while, I decided to release the full source of this project on GitHub.
Maybe someone wants to dive in and revive the project.
I plan to return on some point. but idk when this will be.
https://github.com/cgloeckner/racods-lair
-
Meanwhile I found same spare time to continue my work. My current schedule contains improving the movement system (going away from the strict tile-attached movement to a way more "free" floating-point-like way of moving).
Hence my cmake configuration was total bullshit, I started there :D Idk when the next vital sign will appear... but it WILL! :)
So far
Glocke
-
I plan to change the entire physics implementation to be more flexible - and hence - be based on Box2D.
So I build a quick'n'dirty example program for integration Box2D into a simple SFML-Application in the context of a topdown perspective.
I'm looking forward implementing the lessons I've learned 8)
(https://raw.githubusercontent.com/cgloeckner/sfml-box2d-demo/master/screenshot.png)
GitHub Link to the example: https://github.com/cgloeckner/sfml-box2d-demo (https://github.com/cgloeckner/sfml-box2d-demo)
-
Working on v0.2-alpha
Atm, the major milestone is overhauling the entire physics system to purely float-based movement and proper collision (using different 2d collision shapes). After a sh*t pile of work and unit testing, I finally was able to make the game run again :D
#RefactoringIsKing