Messages

1

7DRLs / Re: Into the Darkness (7DRL 2015) SUCCESS!

« on: April 13, 2015, 05:45:51 PM »

By gruelling I mean it felt like a chore at times. Not hard, just time-consuming.

I'm interested in what about the time consuming part made it a chore rather than interesting. Was it because the UI made choosing cards annoying or the fact that you have think about which cards to choose each battle since the pack/enemies make each encounter different? I was hoping the latter aspect would be fun because games where you just repeat the same actions for 90% of monsters can become quite tedious for me. The fun part of games for me is where you have to carefully plan your next move, so the design of this game was based around that aspect.

In general I think the hand mechanic could be designed differently to make it maybe more balanced and manageable. Have less cards for the player to choose from, but more balance in their consistency and more ways to interact with them. For instance you could categorise cards into attack/defence/healing/utility and have a hand size of 6 but make sure each turn there is at least one of each type. Amongst the utility cards you could have one that powers up the next card played (in effect playing that card twice in a row).

Yes the overall balance wasn't what I'd planned at the start. You only had a handful of cards at the beginning, but like you say if you end up with all utility and healing cards then you can't actually kill anything so it all depended on luck.

I think I'm leaning towards removing area attacks/healing/utility abilities from cards completely and delivering them in some other method that you can combine with the card mechanic.

I like a lot the idea of a card powering up the next card.

One other idea is to have the number of cards you can play in a turn dependant on the number of surrounding enemies - it could give a reason to deliberately get numerous enemies together.

I've designed a fair few abilities that give the player an advantage when surrounded by monsters, hoping to get time to put them in soonish. There's a few there already such as Bravery that increases your attack for each monsters greater than 1 that surrounds you. The ones there though need improving though I think.

As for running out of cards entirely, why not just disallow it? When the deck runs dry it just reshuffles. The challenge is still in making the most of your hand and trying not to die.

Actually this was my original design. Unfortunately I realised that if you have non-optimal cards you can just use them up and wait for the good ones with no penalty. Also it removes the incentive to be economical with the cards which adds another layer of strategy. I realise the current system isn't perfect though so I'll have a think about how to improve it.

I'll add that some repositioning/mobility cards would spice things up a lot. ATM aoe cards are really hard to use due to the way AI moves.

Yeah I agree with this. Also the fact that the area attack cards use up one of your possible 3 cards that turn means that they always seem to end up underpowered.

Thanks for all the feedback!

2

7DRLs / Re: Into the Darkness (7DRL 2015) SUCCESS!

« on: April 11, 2015, 07:01:24 AM »

Thanks for playing! Interesting that you found the game gruelling but at the same time too easy.

Actually I agree that if you play efficiently then the game is easily beatable, but the idea was that in doing so it requires thought and planning so it still has a fair amount of difficulty/gameplay.

Adding healing from discarding cards was done late on in the week as before I felt that it was too random whether you had the correct cards for healing at the right time and ended up being not fun. Unfortunately I didn't have time to balance the cards to make healing more viable so I added health gain from discarding cards instead. If I had more time I would have probably not added that feature.

The problem was that if I increased the number of healing cards it made it harder to have the right card combinations to defeat the enemies, I am wondering whether a better design would have things like healing abilities and area attacks separate from the cards themselves.

Also running out of cards is quite an unsatisfactory end to the game as it is impossible to win without any cards, so I balanced the game to be slightly on the generous side regarding getting more cards. Having said that a lot of people said they felt the game was too hard which surprised me as I also completed it on my first play through.

I've not played Mage Knight, I'll have to have a look at it.

3

Programming / Re: Different methods for loading/saving

« on: April 10, 2015, 12:03:06 PM »

Apologies for the delay in replying.

On playback you start from the last save point and then execute the saved player commands, should be at most a few hundred unless you have really big levels.

Ah thanks that makes sense, so you need both the ability to save the game state and step through the moves after that point.

as long as there are no tight couplings between the model and UI.

That makes sense too, although I find it hard to imagine a game with animation that doesn't have couplings between the two.

Regarding the chest issue, you could also just have a separate PRNG for such things. One could be for terrain and/or rewards, while another could be for combat results or spawning.

Excellent point, I'd not thought of that.

You can check out how it's done in Teemu

Thanks I'll have a look. By the way are you the chap from the google groups a few years back? I remember you were working on an epic roguelike back then.

4

7DRLs / Re: Into the Darkness (7DRL 2015) SUCCESS!

« on: April 10, 2015, 10:40:17 AM »

Hey glad you like the game, I think I'm going to expand on the concept further in future but at the moment I'm undecided exactly how to do it. Any ideas for improvement or more content would be very welcome.

The bug seems a strange one, it should process the cards in order and the code looks ok for both Tactics and Death Blow. Maybe something else weird was going on there.

5

Programming / Re: Different methods for loading/saving

« on: April 01, 2015, 07:52:25 PM »

There are two problems, first is that if you don't save the PRNG state, your game becomes trivially easy.  I save just before opening a chest and keep reloading, opening the chest, seeing if it has what I want, and if not, I quit (or crash the prog) and reload.  Same with boss fights (or any difficult fight). 

Ok thanks that makes sense.

Edit: Actually I just thought, even if you did save the seed then what would stop the player saving and then walking away from the chest and back to it (thus moving the random seed onwards) before reopening it again? Wouldn't a better solution be to calculate monster drops and chest contents when the monster/level is created?

If you're using the playback to restore game state instead of actually playing back the game for a viewer, then you can speed things up substantially by skipping anything that is unrelated to changes in the state of the model.  For example, player actions which are just showing game state to the player, inventory actions which do not change the state, even field of view calculations if not required by your mob/actor ai, all can be skipped during a 'playback for restore' since they don't change the game model state.

I'm still a bit confused by the record/playback saving model. If you have thousands of turns will the code have to go through them all one by one resolving them each time? It seems like it might be quite an inefficient way of doing things with AI and everything, also I imagine any bugs at all would cause a lot of issues as the rest of the playback would be broken from that point on. I can't seem to get my head around the idea properly. I have got an animation system in place, but it would be possible to add a "playback" flag which skips to the end of any animations without playing them so I think it would still be possible.

I have managed to implement a different load/save method that seems to work ok.

Each class has a create() and a restoreFromSave(_saveObject) method.
The first one is used when creating the object for the first time and the second when restoring from a save file.

It seems to work without too many problems, but every single new variable I add to each class needs to be stored and reloaded properly which is a bit of a pain. Is that normal for a game of this type?

I am writing the game in Javascript which doesn't have a way of serialising "classes" unfortunately. I'm not really using much OOP to be honest, just have javascript style "classes" that can store data and contain functions as well which I've realised can't all be saved together.

6

Programming / Re: Different methods for loading/saving

« on: April 01, 2015, 12:34:49 PM »

Thanks for the comprehensive reply. I'm a little confused about the potential problems with the PRNG though. If you save the world state as it currently and then reload from that point, why would it matter if the PRNG would be different from that point onwards than if you'd just kept playing without saving?

I will only allow saving on the players turn so all world events should have stopped happening at that point.

Conceptually playback is nothing more than a combination of a saved starting point and a 'undo/redo' stack.  It is easier than doing an 'undo/redo' stack in that you only need a simple list of translated player input.  It gets almost trivial to implement if you have a clean separation between your world model and your screen presentation, especially if you have already added the ability for player remapping of commands.  The only 'tricky' part is mouse input; you need to capture the translated coordinates to avoid ugly coupling with the view state.

If I'm understanding this correctly then the playback is just a starting point and a series of actions (both player and other actor actions) that are played one by one changing the game state from that point onwards?

Edit: I'm beginning to see what you meant about problems with OOP implementation in that the class and the data for an object are combined meaning they have to be separated and then put back together when you load/save each time. It's something that hadn't occurred to me before.

I could save the data from each class and then recreate the class using the data  when I save/load, but perhaps that is a bit too unwieldy. Or I could rewrite the code so that the class and data objects are separate or remove classes completely and just have functions that deal with the data objects. I'm not entirely sure which direction to go from here, any advice?

7

Programming / Different methods for loading/saving

« on: March 31, 2015, 09:20:36 AM »

I'm going to be dealing with loading/saving soon and was wondering what the different options for it were. My game will have persistent levels.

I realise I could save the exact state of the game and all the actors in it, but I've noticed some games allow you to replay the game so it obviously records transitions as well somehow. How exactly does this work? I guess you could save the players actions and random seed, but then you'd have to replay the whole game up to that point when you reload if you use the recording as a game save as well.

Or is the loading/saving normally kept separate from the record/playback?

8

Programming / Re: Programming graphical effects with delays

« on: March 21, 2015, 07:07:35 AM »

Thanks for the replies, very interesting.

I have indeed started down the path of queueing in animation, but it isn't too late for a rethink. It does seem quite silly to calculate everything once and then send it back to be recreated and hope that everything matches up correctly in the end. I hadn't thought of making it a real time model and I'm going to stop and reconsider whether to change to that type of model instead, it might make things much easier in the long run.

By the way Dungeon Bash looks great, I'll have to check it out.

9

Programming / Programming graphical effects with delays

« on: March 19, 2015, 12:10:41 PM »

I'm wondering what is the best way to resolve complex game interactions each having their own graphical effect that takes some time to complete.

For example if you hit a monster, then they get knocked back and then cause an explosion that damages each adjacent tile. I'd want to calculate everything that happens here in one algorithm but then play out the different effects visually one by one.

I could store the original game state then calculate all the interactions and then send them back to be played one by one, but it seems a little bit unwieldy. How do other people do it?

10

7DRLs / Re: Six Way Wanderer [7DRL 2015]

« on: March 15, 2015, 07:30:25 PM »

"By splitting up monster health and attack do you mean changing the Damage = #hearts / 2 formula currently used?"

Yes this is what I mean as currently monsters with more health are massively more dangerous because they do more damage per turn and also have more turns alive in which to deal it before they die.

Also a spell that recovers health might help during longer fights too.

11

7DRLs / Re: Six Way Wanderer [7DRL 2015]

« on: March 15, 2015, 04:22:07 PM »

Hey just played through and it is a fun little romp, I especially liked the way you can progress further with new powers metroid style.

The combat goes from impossible if you meet the wrong foes to very easy once you have lightning though. I initially thought that the jewels were going to act as mana, but it turns out you can cast spells infinitely. Would be nice to have some puzzles/enemies that you need to combine the powers to defeat (as Adam Perry said above) whilst having to watch how many jewels you use.

Perhaps splitting up monsters health and attack would make it more balanced too.

Also is there a way of waiting? I died a few times because I had no choice but to move towards a 3 heart enemy.

Overall though I enjoyed it.

12

7DRLs / Re: Here Be Dragons 2 (7DRL 2015) - FINISHED

« on: March 15, 2015, 03:49:12 PM »

I just played a couple of games. I personally love the look of the game, did you do all the graphics this week too? They're great.

The game is fun to play, but there doesn't seem that much strategy involved since it seems to be mostly luck that determines when you find people to join your party and combat seems to be mostly about getting the first hit and then hope for the best (unless I'm missing something). If there was some way about getting clues as to where you might find treasures and avoid monsters (perhaps by telling you what might be in adjacent tiles in the way that minesweeper does) then it might make an interesting exploration mechanic.

There's definitely something here though that could be expanded to make a very nice game.

13

7DRLs / Re: Into the Darkness (7DRL 2015) SUCCESS!

« on: March 15, 2015, 03:37:43 PM »

Hey thanks glad you liked it!

If the idea works sufficiently well then I have some ideas to flesh it out and refine it as it is still a bit rough round the edges in places (particularly in dealing with multiple monsters at once).

14

7DRLs / Re: Into the Darkness (7DRL 2015) SUCCESS!

« on: March 14, 2015, 08:42:10 PM »

The x key problem sounds strange, probably a typo or something since it was working earlier. Am I allowed to fix it now or is it too late?

Glad you liked it, it changed a fair bit from my original concept but I actually managed to have some fun playing it last night (in between crying with tiredness ).

Good point about the mouse over problem, I guess I knew all the monster values since I designed them. Perhaps I could try adding a list of enemies on the right with their stats and abilities, although that might need a smaller font to fit it all in (it's also a limitation of playing in a browser). The game is quite a slow paced game though rather than the normal hack and slash type gameplay, especially so when you first start playing it and don't know any of the cards.

Anyway thanks a lot for playing, I'm looking forward to playing some other entries myself when I've recovered!

15

7DRLs / Into the Darkness (7DRL 2015) SUCCESS!

« on: March 14, 2015, 01:17:54 PM »

So I managed to finish my first 7DRL successfully! I'm pretty pleased with how it has turned out in the end.

It can be played online here:

http://tjs.itch.io/into-the-darkness





It's a dungeon crawler whereby you start with 1 attack and 1 defence and can change the amount of damage you deal out and receive by playing up to three cards each turn from your hand.
For example Strength increases your attack by 1 and Armour Piercing reduces a monster defence by half (rounded down). So by playing those two cards you can damage a monster with a defence of 3 by 1 point of damage.
Once played the cards are returned to the pack and you get new ones (provided you have any left).

The idea is to combine the cards currently available in your hand as best you can to defeat monsters as you encounter them. Since your cards change each time you play them every battle will play out differently.

Development was a hard slog, I started out with nice classes and code and it ended up as a bit of a mess as I chucked more things in and hacked things about to get them to work quickly.
Originally I intended for there to be around 6 cards in a hand, but it gradually increased to 15 as it was too restrictive otherwise. I also added the ability to discard cards for health and shuffle when you have no options.

As I've not made a roguelike before a lot of work was done just setting things up and getting the game flow working (although a lot of that was handled by rot.js).

There's some stuff I wanted that is missing (ranged weapons, magic etc.), but what is there works quite well and I had fun playing through it last night.