Messages

46

Programming / Re: jumping, crawling and swimming.

« on: February 14, 2014, 04:02:34 AM »

Well I'm using a multiple movement points system with a star pathfinding. I want to allow jumping but I have to stop the player and monsters from making turns in mid air, or jumping round corners. Also they shouldnt jump in to impassable tiles.

47

Programming / jumping, crawling and swimming.

« on: February 13, 2014, 11:38:50 PM »

Has anyone tried any non standard movement methods, such as jumping over pits crawling through tunnels or swimming in flooded areas?

I'm curious about how others might handle that.

implementation would obviously be different in systems that have more than one movement point per turn, and those which allow the player and monsters to move multiple squares.

48

Programming / Re: Monster generation

« on: February 13, 2014, 11:31:01 PM »

Oh well, different horses for different courses.
in my case I'm sure this will be a useful system but in other cases it probably wouldn't work.

I agree with all the criticisms of your idea to shape the game around the player - I've seen it tried a few times before and there were always counter-intuitive consequences. But don't let that discourage you. Make a prototype and let people try it. Prove everyone wrong. Maybe a 7DRL in March?

thanks,
I'm certain it'll work in my own long term game project, and I know that it will work in certain situations,  so it would be fun to show other situation where it could be used. Now that ive got a lot of the basic code worked out it wouldnt be impossible to do such a thing.

49

Programming / Re: Monster generation

« on: February 13, 2014, 04:23:13 AM »

Oh well, different horses for different courses.
in my case I'm sure this will be a useful system but in other cases it probably wouldn't work.

50

Programming / Re: Monster generation

« on: February 12, 2014, 12:20:23 AM »

Well how would we gauge a player's ability as a DM? By spiking difficulty at certain times and seeing their response to that. setting difficulty would simply be a matter of returning an xp pool that is bigger or smaller than the players. (0.7, 0.9, 1.1, 1.3 etc). If the player deals with the difficulty spike with out any problem you can set this as the new base level. If on the other hand they nearly die you can ramp back down to the earlier level. If they do actually die you could save info about that event in a config file for next time they play. The game would keep on spiking the player trying to equal but not exceed their ability threshold.

Games, like stories should have a narrative, development, progression. There needs to be time for you to develop your character. Just because the game is procedurally generated shouldn't mean that it is totally random. I'd like to challenge the player and yes they should die if they don't play well. But they shouldn't die even though they played well (or not that often).

Rogue was a very difficult game because all games were like that then. Go and play even a Disney game from the 1980s. They were hard as hell. Certain people, like me, were prepared to play them even so. Why? Because I was a kid, because I had lots of free time and not much to do but fight with my brother. Because getting to the end of Black belt would be the ultimate in bragging rights. But these days things are different. Who's got time to play a game with only 10 minutes of actual game play, but which takes months of hours a day practice to beat?

Sure, a difficult game will force you to improve so you can beat it. You can't just coast through. But there has to be a better way than save die reload or die restart infinite loop. At the end of the day we want people to play our games (I assume) and there aren't many people with the patience to put up with that kind of thing any more.

EDIT: Just been reading on the news about flappy bird. It seems that people do want to play that kind of game after all. However, I'm not really thinking of making games for the mobile market. That whole demographic is something I can't identify with anymore.

51

Programming / Re: Monster generation

« on: February 09, 2014, 04:38:18 AM »

Well, we'll just have to agree to disagree on that one.

EDIT:
I wrote a lot in support of the system I'll be using, but it doesn't really matter. If the OP wants to use it they will, and if it's not your cup of tea I doubt anything I can say is going to bring you over to the dark side. 

52

Design / Re: DawnLike - 16x16 Roguelike Tileset

« on: February 08, 2014, 01:34:18 PM »

Wow, it looks great. Congratulations on such a huge achievement.

53

Programming / Re: Monster generation

« on: February 08, 2014, 01:30:50 PM »

Have you thought of having a cost for each enemy/weapon/item and matching it against a current potential value of the player?

IVAN has a system where monsters which are allowed to appear depend on the player's HP and equipment. This has counter-intuitive effects. Like, items which increase HP are considered worthless, because they cause stronger monsters to appear. Or, when going to a new level, it might be better to stash the best equipment and have temporary buffs off. This way, strong monsters won't be attracted. Overall, it is not clear whether you should make your character stronger, or not. I recommend against using such kind of systems.

You could also include modifiers, like if the player is a cleric, skeletons points value is halved, or if he doesn't have a ranged weapon green slime points value is increased by 15%
This gives a very balanced and fair game.

Again, in such a design it is not clear what is good for you and what is bad. Clerics have a some special power which helps against skeletons, but on the other hand, they face more monsters. You might consciously decide that you do not want to bring a ranged weapon, because you want less green slimes, or less monsters in the rooms containing the green slimes. And as the total number of points depends on your character, you learn to develop the character in a way which makes them strong, but the game does not see it.

IMO such a design is cheating, and the player will cheat you too.

I understand your reservations about such a system, and you have made me think more carefully about using it, but I think The system is sound as I described it.
When I used to DM paper and pencil RPGs in highschool I used to balance the encounters against my players, if they had a weak combination of party members or a couple of poor character builds I'd substitute some of the monsters in the module. I didn't want them to get killed too easily, but I would make it challenging and sometimes they did all end up getting slaughtered even with the substitutions because of making poor tactical choices. I'd do other things to make the game more survivable too, such as including more healing potions if the party (which would some times change from week to week as the club membership shifted) didn't have a healer, or less traps if they didn't have a thief.

When I've played RPG games on computer I've found myself almost always playing a cleric just because, they have a fairly good set of combat abilities, they can heal themselves and allies, they can summon creatures and they can buff themselves. Most games become a walkover in such a case. If I chose to play as a bard or a gnome illusionist it's going to be much much harder, probably impossible unless I play on an easier difficulty setting. This is a problem because I actually don't really like playing a cleric, I actually want to play a thief and sneak my way through the game, but it's rare to find a game that will adapt to my playing style.

I think an auto-tuning game system gives you more freedom to play the game anyway you want to instead of being forced to play only the "right" way.

Such a system could leave itself open to being "gamed" but as I showed above (but didn't thoroughly explain), it's important to have a mixed system. Although most encounters will be balanced to the player's abilities (generating monsters from a pool of XP), there will be some which have a set value. You could strip off all your armor and weapons and descend in to the dungeon in just your loin cloth expecting to fight only pixies and gnomes, but that rare encounter where you face a set of monsters pitched at what "should be" your value at that part of the game if you are playing as expected will soon wish you didn't leave your armor behind.

Besides, an item that gives more HP is always useful right? No matter what enemies you're facing, it's better to have 10 HP than 2HPs. Being stronger is always going to be better than being weaker, as usually some enemies will have special abilities which let them hit above their points value in certain situations. For example spiders have poison, giant rats have disease. You may be facing less of them because you are not a cleric, but still once bite can be enough to really ruin your day. If you haven't got a ranged weapon then that one rust monster (instead of two because of the XP modifier) is still going to be chomping on your fine plate mail if he scores a hit. Problems could arise if you set the XP modifiers too high, effectively pricing certain monsters out of the bell curve, but that's part of the design process and something that needs to be gotten right for the game to be any fun.

Every game becomes an arms race between the player who is trying to beat the DM's tactics and the DM, who is trying to beat the player's tactics. As a game designer you have to think ahead to find ways to confound the player without just throwing random stuff at them.

As a games designer I could cheat and use the system to single out a player's weaknesses so that I could kill them off easily, but then who's going to want to play my game then? It's important to get the balance just right so the game is challenging to every player but not impossible.

54

Development Process & non-technical / Re: Gettin it done

« on: February 04, 2014, 09:56:39 AM »

I usually do a project in stages with each stage ending with a playable "game" that could be considered finished. Maybe just kill one enemy or pick up 8 apples in a minute. Then I add more features an go on to the next stage.
the benefit of the game being ki.d of finished at each stage is that you can attract playtesters to test the game. Also if you ever give up on the project you can consider it finished but with room for emprovement.

55

Incubator / Re: Dragon's dungeon (Roguelike/RPG)

« on: February 01, 2014, 09:26:58 AM »

It looks really good, I hope lots of people buy it.

56

Programming / Re: Monster generation

« on: February 01, 2014, 07:58:49 AM »

the whole XP thing sounds very similar to the CR value system I was using before based off of Pathfinder games (Might be in original D&D).

so here is a question the tangentially relates. How do you guys usually go about finding what squares to place your monsters on. Right now I just fill them up randomly, but does anyone use monster placement rules?

Well, if you use room_ids in your level designer (give each tile that is part of a room a unique numbered tag so you can see which parts of a map are in a particular room) you can have the monsters placed in themed groups in a room. You could use arrays to store potential formations (everyone standing around a table looking at a map, people sleeping on mats etc..) as well as props. The arrays can be mirrored or rotated (in python I use reverse or zip functions) to provide variation and you can select randomly from a dictionary of arrays. You can easily check the room is big enough to hold the formation and if not (perhaps a pillar is already placed where the table is supposed to go) you can select another formation. You could also include an extra index in the dictionary to indicate size and then only select those that can fit before randomly choosing an entry.



Please keep in mind the above is just a sketch, I use a spreadsheet editor for mocking up dictionaries or ideas, keeping notes about possible function calls or stats. I haven't run it to check the result so you'd have to do your own testing.

With this kind of method you could have spiders (a monster) and cocooned prey (a prop), or a book case and scattered books (all props) or a barracks with beds, chests and sleeping guards and lookouts. Further refining the random monster function, you could use a wild card such as False or None instead of xp amount to use XP from the spawn pool I mentioned above. Or you could add an extra argument to the function such as monster type, which only adds monsters with that type to the random generation pool. A typical type would be "furry" which would generate giant rats, wererats, werewolves, cave bears and such, or "insect" which could generate all kinds of bugs, or "human" or whatever. The more tags you have, the more you can control the spawns and create more narrative for your game, but the more chance of getting an empty list.

For instance you spawn a monster formation on level one which includes a random monster call for a "demon". The xp pool is just 100 xp, but the lowest level "demon" monster is 5000xp. That's going to result in no monsters being spawned unless you have a fall back, like:

else:
       monster("giant_rat", "crazed")

In which case the player is going to be so busy dealing with a berserk Giant rat they may not notice the "pentagram" and "sacrificial_altar" props in the room.

57

Programming / Re: Where to start?

« on: January 31, 2014, 03:15:30 PM »

I'm only part way through my own game but I'd say its a good idea to start with the level generator before combat or ai or magic or other things.
That can be one of the hardest parts because if the level generation isn't convincing or interesting the game probably won't be either. In a randomized game world the level layout is your "plot". How you move through the level is what shapes your gaming experience. If the map is too random the player may feel lost or bored, not random enough and it gets repetitive very quicky.

Placing rooms is just a start. How will you populate and decorate those rooms so they're not just empty rectangles? Will you have keys for doors? How can you keep one area secure while making sure the required key is not inside? will you have puzzles? They are a big part of rpgs but randomized puzzles are not easy to program without a lot of planning.
Anyway, I agree with most of the 15 steps but I think random level generation is something worth investing in early on.

on the otherhand you may want to get a working game first an leave perfecting procedual generation until later.

58

Programming / Re: Monster generation

« on: January 29, 2014, 08:33:48 AM »

Have you thought of having a cost for each enemy/weapon/item and matching it against a current potential value of the player?

Then you could choose random monsters and loot while reducing a pool of points for that location.

So for example room 23 has just been opened by the player, at the moment the player has skills and equipment worth 567 points.

We randomly select some monsters getting the following:
A green slime (120 points)
A skeleton (100 points)
A skeleton (100 points)
A skeleton archer (150 points)
and a giant rat (50 points)

At this point only 47 points remain, and as a giant rat is the cheapest enemy available to this level we stop adding more monsters.

The 47 points are deducted from any loot the player picks up from the encounter to keep things balanced.

You could also include modifiers, like if the player is a cleric, skeletons points value is halved, or if he doesn't have a ranged weapon green slime points value is increased by 15%
This gives a very balanced and fair game.

59

Development Process & non-technical / Re: Dev blog aggregator

« on: January 29, 2014, 08:01:26 AM »

I've finally started up a blog to cover development of my game. It's a 3d roguelike.

Blog is here:
http://pickleddevblog.blogspot.kr/

60

Development Process & non-technical / Re: Greetings from a new roguelike developer

« on: January 27, 2014, 07:16:09 AM »

Well, races are something I wonder about in RPG games. You know the more recent star wars movies got panned for (among other things) shallow racial stero types in their aliens.
The old tried and tested races like elves and dwarves are fine, but what if you want to add something different? It's not easy to add both a race and a culture.

At the moment all the human NPC heads I've got are white people, I have some black faces (from another project) but adding them will mean making an extra texture set for black bodies too. I'm thinking of keeping them back and adding a different culture group later (when I've got the over land world map up and running) with some new clothes, weapons and armor types. Not a race, but a culture.

But do I want to add races?

I don't want elves and dwarves really, they are a bit [yawn].
I'm contemplating giants, they would be ex-slaves of the meta-humans bred for size, strength and toughness but of limited intelligence, since the fall of the old empires they have started raiding and maruading around the coutryside, forming bands or small giant kingdoms, drinking, fighting and stealing whatever they can get their hands on.
I'm also thinking of adding fairies to the game at a later date as a playable race. They were an early magical experiment, the fairies are simple avatars of a uploaded human intelligence. since the fairy bran is too small to hold a full adult intelligence, their personallity is held in "the cloud" and they have a kind of connection or hive mind with other fairies and magical beings.
They can't do combat, but they would be inately magical, and of course they could fly and pull levers and whatever, making them great scouts. They would play a big part in the second phase of development which will be adding random puzzles, including pit traps, sliding blocks, and other staples of the genre. Their weakness would be dead magic zones as they would sever the link to the cloud conciousness.
Another group is the aquatics, one of the oldest human empires, they adapted to live under water when global warming came and they have kept to themselves ever since, but agents of the sea people sometimes come up on land to find out what's happening. Unlike the fish men or croc-men they are not the decendants of gene spliced animals, but are neary fully old style humans, just with adaptations for living under or in water. Some dungeons in the final game will be partially or fully flooded, so having a water breather in your party would be an advantage, and I may allow the option for characters from the party to visit dungeons solo, for a different kind of adventure.

I'm not sure whether I even want to visit the idea of races right now, they are usually either offensive racial sterotypes or a shallow re-skinning of regular humans (the man in a monster suit effect). It takes a lot of effort to really introduce a fully fledged new race, most games systems usually first introduce them as enemies and then later make them playable.

Anyway, right now I'm concentrating on getting some early gameplay demos up and running, just so people can walk around in a dungeon and give feedback on layout and the feel of movement.
Later I'll have some basic combat demos and then move on from there to inventory, crafting, leveling and other stuff. I'll post a proper WIP thread when I've got some progress to show.