Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Pickledtezcat

Pages: 1 [2] 3 4 5
Mr Pickledtezcat, your blog seems broken with allowing comments by the way ;)

Hi, thanks for the heads up.
I think I fixed it. There was a problem but it should now allow anyone to post without having to do a verification or anything.

Those plantmen look pretty cool. Is it possible for them to hide in high grass or some other vegetation? Since they certainly look like they would blend in very well.

Yeah, I want to add some code so that certain monsters might spawn out of a certain tile or furniture item under certain conditions, like a giant spider may crawl out of a barrel if you check it for treasure, or zombies might come out of a grave. The plant men might climb up from out of the ground leaving a mound of dirt behind. I've got flying monsters such as bats which can fly down from the ceiling to land next to the player and ambush them (they will play a special animation as they are placed).

Such monsters should be quite weak, because players will be annoyed at a powerful monster suddenly appearing right next to them and killing their character before they get a chance to do anything. But having the ability to spawn in an unexpected place could be a fun game mechanic for certain monsters. The key is to make it interesting but not annoying, perhaps only allowing it to happen rarely, or limiting the number of times it could happen in a single level...

I've got some plant men in my project. They are not that tough but they give out a cloud of spores when hit.

I'm trying to include a lot of different types of monsters which have different behavior and attack types rather than just a bunch of progressively tougher enemies.
These plant creatures for example won't usually attack unless you get too close, but the 'diseased' variety (the brown ones) start out crazed and will attack anyone they see, even other monsters if they are the closest threat.

Some roguelikes have a set of effects that can be set on the player, like dazed, diseased, poisoned etc... I hope to make good use of that to include a bunch of secondary effects.

I think using dictionaries for map data is a great idea for roguelikes. Most computers now can handle the extra drain and it makes things much more flexible. A tile can contain almost anything, and you can set traits of a tile on the fly, allowing spells or effects which can change the layout of the level. Imagine being able to place lava on a tile by hand, or "zap!" a wand of pit traps!

Unless your level is like 500x500 tiles in size I don't think you're going to get performance issues. Even then you could crop the areas which is active, not performing checks on creatures or items which are outside the active radius.

Design / Re: Brainstorming: Item lists.
« on: June 30, 2014, 12:52:54 PM »
This is from my own project. It is an outdated and incomplete list but it might help you out.
I advise you to create families so you can browse items in your game with filters, assuming you are including a large diversity of item types.

Thanks, I think I have nearly all of those ones now.

I think it's always best to start out brain storming lists.

Things in a game are not real things, they are just signs of things.
If I find a skull in a game, it's not really a skull. It won't break if I drop it. My character won't be creeped out about touching it. It won't decompose. I can't get DNA from the teeth.
Actually it's more likely to be a key, or an ingredient or a junk item or a bonus item or even food. It could be any of these and any of these usages could easily use something other than a skull to represent themselves.

Some things lend themselves better to a particular use than others however. A sword is most often a weapon, a knife sometimes a weapon or sometimes a tool. A jewel is usually a treasure item, but may easily be a puzzle item, required to solve a particular puzzle. The semiotic relationship between signifier (visible in game object) and signified (the function of that object) is pretty loose in games. This is especially so in ASCII roguelikes where @ is a player and % could be an item and "G" could be a giant or a goblin or a gargoyle.

Sometimes there is a particular mechanical link that fixes how an item must be used. For example, the belt might need to be "worn" before you get any use out of it. A potion needs a certain key press to "drink" it. But in many cases the difference between two items is almost unimportant. If you don't have drinking restrictions or item damage then scrolls and potions are nearly the same. They both start out unidentified and trigger an magical effect when used. Scrolls might require a special skill to read, or not.

How the designer decides to separate the usage of various items is up to them, but once you start introducing mechanical limitations to an object then it needs to be a separate class.

One game might have
magical_items(scrolls, potions, wands, etc..)
Where each is activated by the use item action and any potion can have the same sort of magical effects as any scroll or wand, and there is no item damage (like your scrolls being damaged in fire or water)

another game might have
Where there are restrictions on what kind of magical effects each item class can have, their might be different actions for using each type and each type might have other restrictions.

But before you decide on those things you need a pool of possible themed item types so you can draw from them. You don't have to use everything on the list, but it's good to have a list to start with. Same with monsters, skills, spells and everything else.

Many items have restrictions of convention inherited from the roguelike genre, but it's really OK to break these conventions if you feel the reward of fresh game play is worth the risk of confusing players who are used to a certain convention. If the usage of an item is not clear and there isn't any help to describe how to use it you could end up with a useless item.

Programming / Re: How to make a roguelike in java?
« on: June 30, 2014, 11:43:40 AM »
What's curses?  ;)

Development Process & non-technical / Re: Dev blog aggregator
« on: June 21, 2014, 02:03:02 AM »

Development Process & non-technical / Re: Dev blog aggregator
« on: June 19, 2014, 08:56:09 AM »
Just out of interest how do you run an agregator like this? I'd love to set up a similar one for the blender game engine. Is there something you use to do it automatically or do you have to manually add entries?

I like the way it tends to drive blog posts on to shared subjects, like a few days ago there were several posts by different bloggers about random level generation.

Design / Re: randomness as a replacement for identification
« on: June 19, 2014, 03:27:22 AM »
Those sound like bad design decisions. It's something that plagues all RPGs as you get higher in levels.

For instance some games will force random encounters where enemies spawn right next to the player. This is because the player has by this time found easy ways of dealing with all the monsters they are likely to encounter, and ambushing them is the only way the game designer has of beating their tactics.

The real problem is that the player often relies not on tactics, but on exploits. That is bits of broken game play which allow you to win with no trouble. An example of this is certain combinations of spells which have powers far in excess of what they should, or certain spells or items where they haven't been tested as well as they should, and the result is completely overpowered.

In Warriors of the eternal sun on the sega genesis entangle (the second level spell) didn't allow any saving throw and always hit its target. That meant it was possible to kill a dragon with low level characters, simply by having a lot of entangle spells and ranged weapons.

In Temple of elemental evil the sleep spell was combined with a coup de grace attack which allowed you to put someone to sleep and then kill them with one attack. A higher level version of the spell kept this exploit viable up until the later stages of the game.

Really the designer should be addressing the broken gameplay, instead of just trying to find counter exploits.

Some ideas would be:
Some spells require multiple turns of casting preparation or require spell components (like you need a human skull for teleport, which is destroyed after use).
Make sure higher level enemies have protection against immobility spells and effects.

Anyway, if you were able to remove a good number of the worst exploits then there wouldn't need to be so many instakill or high damage attacks. The game could be more about a death of a thousand cuts rather than a one-shot kill fest. Nerfing damage per turn would also mean you don't have to have the big gulp potion game mechanic, potions could be toned down and made more interesting without making players really annoyed.

Design / Re: randomness as a replacement for identification
« on: June 16, 2014, 12:40:12 PM »
It sounds like the side effects label you get on the side of medicine.
Actually that could be a fun idea, add side effects to your potions, so you know the potion will heal you, but it could also make you sick, or give you a tingling feeling in your scalp.

What about if there were a way of minimizing or completely removing some or all side effects? As the player progresses through the game, he could find items or skills or whatever, that could be used to mitigate the effects. And those would be limited, so it would always be the choice of "do I make all the future healing potions more desirable, or would I rather invest on the potions of bull strength?".

I like that idea. I'm fiddling with the idea of an alchemist class who will be able to brew potions. In the past I was thinking they could brew more potions with less ingredients as they become more experienced. Now I like the idea of removing unwanted side effects as you gain in brewing skill.

I expect a level 1 alchemist would be something like this:

Of course, these would be homebrew potions, it's likely you could find masterbrewed potions in a shop or in the dungeon which would work correctly 100% of the time.

Another mechanic I'm toying with is having potions have a number of charges, or sips. So you might find a half full blue potion (12 sips remaining), after sampling it once you find that it heals you a little but makes you sick (temporary penalty to intelligence~ "Your open wounds begin to heal, but you feel dumber already!"). I think if potions lasted more than one use, you could have more meaningful interactions with them. It's also stop you from having to carry around 500 potions of healing.

I think however, these kind of things would only really work with the inclusion of a dedicated alchemy mechanic and potion crafting. Many people like that part of RPGs, seeing which potion ingredients combine in the right way to make a potion. It also helps if there are scrolls which describe the recipes used, to be found laying around in the dungeon. It's a kind of meta puzzle, something that makes people get more involved in the game the more they play (like hidden uses of items) but it has to be optional. Otherwise making a core game mechanic, like using potions for healing and buffs, more random and frustrating would only turn players off from your game.

I've seen studies which suggest that frustrating and annoying game mechanics are more likely to make someone commit violent acts than depictions of graphic violence in video games.

Design / Re: randomness as a replacement for identification
« on: June 14, 2014, 12:09:52 PM »
It sounds like the side effects label you get on the side of medicine.
Actually that could be a fun idea, add side effects to your potions, so you know the potion will heal you, but it could also make you sick, or give you a tingling feeling in your scalp.


Less serious side effects may include:

    tingly feeling in your scalp.
    dizziness, spinning sensation.
    mild nausea, upset stomach.
    tired feeling.
    stuffy nose; or.
    difficulty having an orgasm.

That way you could add a little bit of randomness and fun without being totally annoying.

Though who'd drink the potion of bull's strength which had the legend:
Warning: May cause microphalus and male pattern baldness.

Thanks for all the replies! I'll take a look at each and give them a go.

I'm working on a project right now for windows, but there's a lot of art stuff I'll be able to re-use later in a simpler mobile project I hope.

7DRLs / Re: Escape from lab 99b- 7DRL 2014
« on: March 14, 2014, 04:43:15 PM »
So close to being finished, but I don't think I'm going to beat the deadline.

I still have to do enemy attacks and put in the code for switching levels, but there's just not any time left. :(

I'd also have to do something about packaging it for people to play and getting people to test it to make sure it works.

Anyway, next year 'll give it a try again. I learned a lot and I'm sure I'll have a lot of useful stuff to put in to the mix next time, and so won't have to write so much from scratch.

The biggest drain on time has been testing everything and clearing bugs. It didn't leave much time for actual design, and like 70% of features didn't make it past the coding stage.

Stuff that i wanted to work on (parts of the code were there but not working):
Hacking, some drones have a hacking module making them able to activate repair booths or damage nearby enemies from a range.
Stealth, some enemies and player units should have stealth, making them invisible.
Weapon stats. Right now every weapon is 100% accurate and just blazes away at the enemy armour. I wanted so much more including hit location tables, ranged attacks and accuracy.
map nodes and AI nodes. Some computer booths where supposed to have a special effect if you activate them with a hacker, such as revealing the level map, or making every enemy drone inactive.

Here's a picture of the final result in all its not finished glory:

7DRLs / Re: Escape from lab 99b- 7DRL 2014
« on: March 13, 2014, 04:42:51 PM »
After some playtesting I think the idea needs some extra work.

Some of the connecting corridors have to be wide because moving between rooms without stackable movement is a little hard work, and there's a lot of corridors. Maybe having some bigger room archetypes would help. Enemies don't generally spawn in corridors so it's not a big deal.

Maybe a follow AI for non stacked units would be good, but I don't have the time to implement that yet.

You can see in the screen shot that some squares have one D (drone) while others have 3 or 4. Where there's only one unit in a square it's placed in the center of the square, otherwise they are placed in a 2x2 grid.
It's not clear from the screenshot where the squares are but you get a idea of the layout very quickly when playing and moving your pieces about.

BTW, There will be other enemy types, and the game is written so that not all "D"s are equal.

It's been great entering the competition because it allowed me to try some ideas I have for my current big project. Stackable/group-able movement for multiple player characters being one of them.

Some things have worked well, others haven't.

Somethings have made me question whether code I'm using in my main project is working properly because it isn't working here.

I'm not sure I'm going to get finished on time but it's been useful anyhow.

7DRLs / Re: Stubborn Warriors - 1DRL
« on: March 13, 2014, 12:55:39 PM »
A very interesting concept. Nice.

7DRLs / Escape from lab 99b- 7DRL 2014
« on: March 13, 2014, 12:52:43 PM »
I'm posting updates in my blog:

but I'd like to get some feedback (almost no-one reads my blog and those who do never comment) so I'll post here too.

Here's a shot of the game with map and entities working:

I'm using the in game map from my current RPG roguelike project but modified.

All entities will be represented by symbols, just like a traditional roguelike. The game will be turn based.
One area I'm departing from tradition is in stacking. Most units can be stacked up to 4 in a single square. I'm going to allow stacked movement and maybe stacked attacks.
This is how I plan to deal with the multiple character aspect of the game.

You'll be controlling up to 4 drones, but it's possible to move them as a single group, though not in narrow corridors. Choke points like that will require you to advance one at a time, making you more vulnerable. You may also want to split your group for scouting (if you have a drone with a stealth module) or to remove a seriously damaged drone from the stack to avoid it taking damage.

Player movement and map reveal is working, entity population and placement is working, map generation is working, though I will probably add more room variations.

7DRLs / Re: 7DRL 2014 Hype it UP!
« on: February 27, 2014, 02:52:24 PM »
Well, I've done a lot of testing of Blender to make it run well on any computer. I even has success getting it to run at work on the 10 year old reconditioned windows XP computers we have at school. No dedicated graphics card, just integrated graphics and a CPU which makes my mp3 player look state of teh art.

I can do stand alone versions for linux and mac, but need someone to compile them before distribution using the appropriate computer, maybe I can find someone on blender artists to help out. I've done it in the past, but it meant that the mac version of my game was often several releases behind the Windows one, so I stopped bothering.

Anyway, I'm looking forward to seeing some of the entries and doing some reviews.

Pages: 1 [2] 3 4 5