Messages

31

Programming / Resolution and Fonts

« on: July 09, 2010, 08:03:19 PM »

I have come across a dilemma. Earlier I asked for some opinions on scrolling vs static dungeons, but recently I realized something problematic with static dungeons. The maximum size of a dungeon floor is based on the size of the font, and the size of the game window (and thus resolution).

Allowing people to change fonts or screen size requires a scrolling dungeon. Now, if I wanted to instead make a static dungeon, the most obvious approach would be to just use a set font size (which is fine) and a set resolution.

What resolution would be "acceptable"? I am aiming for desktop machines, not handhelds, but OS should be irrelevant. I'm thinking 1024x768 is a standard monitor size now, but when I was in a computer store the other day I could not find a non-widescreen monitor. Is everything widescreen now?

So, does anyone have some ideas on an acceptable resolution?

32

Programming / Re: Supporting Multiple Platforms

« on: June 23, 2010, 05:32:41 PM »

Actually, has anyone with a Linux or Mac box tried out mono? I'm curious how effectively C# roguelikes actually work on it, just as I'm curious how well regular Windows roguelikes would work with wine. Given that almost all of my time (both recreational and developmental) is spent on a Windows machine I'm curious how well someone who wanted to play a Windows roguelike could do so on a non-Windows machine.

Any thoughts? (Aside from just saying "use java")

33

Programming / Re: Pathfinding implementation not working the way I want it to.

« on: March 26, 2010, 01:28:35 PM »

As far as I can tell, your code is returning a correct result: a path from A to B with minimal length. The problem is how it decided which square to take next. Since all directions have the same cost, it's probably just using whichever square is first (or possibly last, I'm not sure) in the list of squares and continuing from there. Additionally, you're using floor to keep the H cost an integer but that could be your problem.

My recommendation would be to first try getting rid of the floor call and see what happens. Then I'd do a walk through of your algorithm to see the order of the tiles chosen. That should let you know why it's creating the path it is.

34

Programming / Re: Restricted Actions

« on: March 24, 2010, 12:34:44 AM »

Wow, that was a fast response!

For some obscure reason context sensitive (or partially restricted actions) keys are generally considered a really bad thing for a roguelike.

This I was aware of, and I think ywgdana provided a nice explanation of why. The freedom to perform a variety of actions with the same set of objects (actions that may not be obvious) is a particular highlight of roguelikes, but not all of them do this.

There's also the fact that although the action is available it often does nothing. I've tried digging in Angband without a shovel and realized, as Yyrkoon said, that it's actually pointless; why even allow it? It's allowed because of how the commands were created.


So, from this I'm guessing that key items need to make sense (or at least be accessible when they should be), and I also need to recognize that restricting the freedom of use on items can be detrimental. This at least provides some guidance on how to organize the commands and possible actions of the game.

Really, what I wanted to do was create a progression of useful items that increased the capabilities of the player (though the capabilities of the player's character could just be improved over time as well). My concern was that it would be detrimental, but actually now that I think of it (and think of how Metroid did this) there was also the notion that the new commands opened up more of the game. It wasn't just that you couldn't get past this wall without a shovel, you could explore so much more of the game with one.

So if I want to go down this path, I'm guessing I need to make a game that has a lot of hidden secrets that get unlocked the further the player progresses through the game (and make sure it isn't tedious for the player to revisit old areas).

On that note, do people prefer the range of uses items have (such as in Nethack, Adom, and to an extent IVAN) or do you think having that makes the game more complex than necessary? Assume the game is supposed to be larger than a 7DRL.

35

Programming / Restricted Actions

« on: March 23, 2010, 08:58:32 PM »

So far I've noticed roguelikes tend to have all actions available at the beginning, and I'm wondering whether a variation of that would be good or bad.

Basically, I've considered using 'key items' of some sort to provide an available action. Such as requiring a shovel in order to dig. This would turn a 'dig' command into 'use' command on the 'shovel' item, or something similar. However, that would also mean you cannot dig without a shovel. Another idea would be requiring a quiver before you could get arrows to perform a ranged attack. The newer Zelda and Harvest Moon games use this mechanic, as I'm sure other games do.

Does anyone see potential pitfalls with this idea? I'm sure there could be some actions that may be annoying, such as not being able to attack without a 'weapon' item, but I'm hoping that having a smaller set of actions at the beginning would not be detrimental.

36

Programming / Re: A peaceful dungeon exploration game

« on: February 26, 2010, 02:04:26 AM »

My apologies if this thread is too old to revive, but I wanted to make some comments.

All games require an artificial conflict of some sort. Artificial in the sense that the players are not really hurt in any way by the conflict. As well, conflict does not imply traditional combat. It just happens that, as was stated, combat is the easiest form of conflict to implement in a digital game.

When thinking of peaceful games, you have a couple options:
1) Completely peaceful, as in no conflict what-so-ever
2) Non-violent, in the sense that conflict exists but there is no combat
3) Pacifist; there is conflict and combat in particular, but the player cannot partake in the combat

I'm not particularly sure how you would go about creating the first one, nor do I think it would create a very good game. A game without conflict would be closer to free play, where a player would just do whatever with the environment without any restriction or game-provided goals. The free play ideas work well in simulations, though there tends to be conflict of some sort (or a way in which you can lose the game).

The second one I think is what you should be aiming for. Conflict can be viewed as "some problem exists and it must be solved". Finding and performing the solution becomes the goal of the game, and you can chain these together. In order to solve the larger problem you must first solve smaller problems, which could create new problems when you go to implement them. Here, I would actually look at puzzle games and other simulations. Harvest Moon could be a good source of inspiration (It's a farm sim in case someone doesn't know what it is) and many of the ideas from that game could be expanded on. I liked how Rune Factory took the harvest moon engine and added combat, particularly with how combat and farming were linked and supported each other. (The crafting ideas they added felt tacked on and unfulfilling though.) Several of the building and environment-altering ideas from Dwarf Fortress could also be relevant. I would also look at the Eggerland series (Adventures of Lolo for the North American audience) as that shows how you could incorporate enemies but provide a way to get past them without really implementing combat.

The third situation would be tricky to implement in an enjoyable manner, as you have to give players something non-violent to do but also throw in combat and a way for them to escape it. Some players may find this restriction rather arbitrary, but it does work in a game where you can fight but are encouraged not to.


The groups you outlined Hajo are excellent places to start with. Focus on the scope of your game, and that will give you a good idea of the activities to incorporate.

37

Programming / Re: Ridiculous amount of links for hopeful gamedev aid

« on: December 05, 2009, 02:41:53 AM »

Depending on what you'll use Linux for, knowing a lot about it may not necessary. If you're going to program in C or C++ on it, then you're gonna need to know more detail for it (and definitely will want a Linux distribution on your machine). Otherwise, you'd probably just need to know how to install and run programs on it and not much else. It's better to just get familiar with command line interfaces anyway, though plenty of Linux distributions are GUI based now.

Actually... you may want to look in to Virtual Machines for Linux. If you have a good enough computer (which, I remember from your other post, you were hoping to get) you could run a virtual O/S on it for testing. That will let you compile/run your programs in a different environment to see how they work. It's not as much of an issue for some more portable languages (such as Java, depending of course on how you use it), but for programming languages that can have platform specific issues (ie: most, if not all of them) it's incredibly useful to have a virtual machine for testing. It's also cheaper than getting a second/third computer.

I've used Microsoft's Virtual Server, and it's pretty good but costs money. There are some free ones (such as Virtual Box) but I have not tried those before. Definitely look into those first before trying out Microsoft's, because getting a working virtual machine for free is a huge benefit.

On the other topics... well, I'm more of a "Learn the Theory behind it while doing some examples" kind of guy. So, tutorials or books on programming languages (not a specific language, but languages in general) would be good but probably overkill right off the bat. Books on algorithms though wouldn't be bad. Naturally I think every programmer should read books on compilers (or write their own), but I don't recommend that at this point. ^_^;

Start with an Object-Oriented language (Java, Python, C# or C++), since that seems to confuse many people. The non-OO languages that are still procedural languages (ie: they aren't Prolog or Scheme) can be treated in practically the same way, but it's apparently more difficult to start with them. That's just what I've heard, as my personal experience is not a good indicator of the norm.

38

Programming / Re: Skill suggestions

« on: December 05, 2009, 02:14:41 AM »

I also intend to have some late-game enemies with immunity to physical damage.  How could I make Kineticism useful against them?

Well, you could always suffocate them (though maybe that's just a StarWars reference with all the "force" effects you have there). Obviously it wouldn't work on a creature without lungs, but you would have to concentrate for several rounds while you suffocate the target. This would leave you open to attacks from other creatures, so although it's "instant death" in a way it actually isn't since it takes some time and makes you more vulnerable in return.

Or a force wall... stop the physically immune enemies from walking towards you so you could kill them later (maybe by setting them on fire or something).

39

Programming / Re: Ridiculous amount of links for hopeful gamedev aid

« on: December 03, 2009, 06:07:02 PM »

Having lots of links can be handy, but if you're looking at learning any of it you'll need to decide on how you want to split breadth vs depth.

Breadth implies you know about a lot of different tools (programming languages included) but don't necessarily know any of them really well. That's where depth comes into play. It's very time consuming (and likely impossible given our finite time) to have a great deal of depth in knowledge about everything. It's much better to choose certain things and have more depth in that, but you should also have some depth in everything.

Basically, you want to understand how each tool works in general and then know how to use the more popular/prevalent tools specifically. That way you can do work that helps the majority, but if you want to help another group who uses something totally different you can still offer some help.

I find it unlikely you're not willing to learn, or you wouldn't have bothered to post those links. You already have a good headstart with that willingness. Knowing about programming languages, computer graphics and graphics tools, and some low-level O/S stuff in general basically means you can learn the specifics when you need to.

For example, if you understand procedural programming languages at the conceputal or general level, then it's just a matter of "I know how to write this statement in <language X>, now I just need to look up how to write it in <language Y>". Initially, books or the Internet will provide that, which is where your links come into play. The more you use language Y, the less you'll have to look it up. But the more you program period (provided you focus on the general concepts and not just syntax), the better you'll become at any programming language.

If you knew absolutely nothing about programming (which I don't think is the case), I would recommend learning more conceptual stuff with examples in two specific popular languages. For example, learn about object-oriented programming and control flow and do examples of that in Java and C++. In doing so you'd learn the concepts behind program flow, control structures, and OOish stuff while also learning how it's done in Java, C++, and the differences between the two. That is useful knowledge, far more useful than merely memorizing C++'s standard library (which you'll memorize anyway if you use C++ enough).

For the graphics tools, any decent tool should provide similar functionality so you'd want to learn what those functions do and how to utilize them. I'm not a graphics guy, so aside from suggesting knowledge about layering (and how to work with tools that do not layer), recoloring and texturing, there's not much else I can add. However, if you plan on doing anything in 3D definitely learn about modelling and how models + texture are used. That's the main difference between 2D sprite/image-based games and 3D games.

40

Programming / Re: Multi-tile Creatures

« on: December 03, 2009, 05:48:57 PM »

I think the big SDL letter accurately describes the notion that "this dragon is much larger than you", certainly better than the 4 D's in a block. This is only because how do you know the 4 D's are one large dragon instead of 4 smaller dragons that happen be standing very close by? Or, even more confusingly, if you unfortunately walked into a dragon nest you could see this:

#######
#DDDD
#DDDD
#######

Now, without using color what on earth is this? A very long dragon? Two large dragons (knowing that 4 D's are one big dragon)? 8 small dragons (where D is one tile in size) or some combination? Color would help immensely, and case could help too. But if different casing is used, then we run into issues of "d" being part of a dragon or a dog that happens to like standing beside a dragon.

Incursion's idea is quite nice, and I can see that being necessary given its source material. If I was to go with multi-tile creatures I'd probably use that, and say "based on Incursion's multi-tile creature display" or something similar. How do they do creatures of size Tiny or smaller just out of curiosity? Or has anyone encountered that before? (I need to play more Incursion.)

I didn't like the Chocobo Dungeon bosses (or at least the bosses in the 3rd game, since that's the one I played). The bosses were far too trivial since spatial strategies could not be used. It basically came down to making sure you could do enough damage to the boss before it could attack you, because once it was on an adjacent square you could never escape it.

Ivan's idea of having immovable creatures can work, since large things might not need to move. Wall breaking could be exciting too, but it might be more interesting if you're walking along and see broken walls ahead of you (suggesting some large creature made its way through there). Otherwise, you'd need to use corridors larger than 1 tile in many places. This isn't necessarily bad but it does require strategies other than "move to a narrow area so only one enemy can attack you at a time", and depending on the game that could effectively make it impossible to win.

41

Programming / Multi-tile Creatures

« on: December 02, 2009, 03:55:42 AM »

Alright, I've got another set of questions for everyone out there about creatures that are larger than a single square. ZZT has those centipede like creatures, and Dwarf Fortress has seige equipment and wagons that take up multiple tiles, but are there any other roguelikes with large creatures like this?

Do you think it'd be good to have large creatures like this? I can see wagons and catapults (or workshops) being big, but in that case would a dragon be the same size? And how would it show up? Just a larger D or some other sequence of letters?

I know tile-based games can simply show a larger tile (and those games are valid enough to be listed here) but what would be a good way to do this in ascii?

42

Programming / Re: Skill suggestions

« on: November 28, 2009, 09:09:05 PM »

I think my problem is that something that would be cool in an action game, like the ability to do backflips off of walls or something, isn't as interesting in a roguelike ...

First, think about why it would be cool in an action game. Is it because of the animation of the character performing the action? Is it because of what the action means for the player? Or is it because it's something the player wouldn't expect to be able to do in the game?

Athletics, as a skill tree, would include things such as running, jumping, climbing, etc. There's no reason why those skills should not be included. The trick is, how can the player use them? A wall jump that moves them two spaces away isn't particularly interesting... unless facing is involved, and then the wall jump could get the player behind an enemy for a strike in the back.

Jumping could be an incredibly important skill if there's pits or chasms in the game. Being able to jump over the pit rather than, say, expending items or magic to somehow bridge (or teleport or fly etc) over it is a huge advantage. Likewise, jumping onto an enemy should give a bonus to damage, making it a very effective melee option. You could shoot the enemy for a bit until it got too close, then switch to a hammer and jump-attack them.

If you have water, swimming should be there too so players could cross water or fight in it with less difficulty. Climbing would be good if you had scalable walls. Running could give a bonus to a charge of some sort, doing more damage if you can run in a straight line into an enemy (or a door or something breakable).

Basically, skills like athletics are only meaningful in a game if they're useful. Most digital RPGs don't bother including skills like climbing or jumping because the game never includes anything which would require it. So, your game has to have situations where those skills would be needed. However, keep in mind that if players may choose an athletic skill but don't have to, then there must be alternative options. If there's a chasm with an item on the other side, the player who has jump will happily use it. But the player without jump is out of luck, unless there's some other way to get there (even if they don't have it right now). Without a way to get to that item, the game becomes unfair to the players who did not pick jump.

43

Programming / Re: Skill suggestions

« on: November 27, 2009, 02:00:01 PM »

Powerful wizards casting illusions wielding illusory weapons causing illusory wounds (so that the victim does not know which one is real even when he is wounded...) Seems very hard to implement.

That depends on how you consider illusions. For example, in the 3rd Edition of D&D there's an illusion spell that can actually kill a creature (phantasmal killer). Essentially, the illusion is something so frightening that the creature dies from being so scared. Which makes sense from a physiological standpoint: our minds do a pretty good of job of making unreal things still seem real (otherwise, horror movies and games could never be scary). So, even an illusion can have very real effects.

So how does this apply here? An illusionary creature would have infinite health, in the sense that whenever anything attacked it the attacker would get a chance to realize its an illusion and the illusion would disappear. Otherwise, it would always remain. Any damage it dealt would still be real damage, but once the creature being damaged realizes its being hit by an illusion it is now immune to further damage. That could be tricky to implement for illusionary weapons, as you'd have to keep track of whether each creature knows its an illusion. For illusionary creatures they could just disappear as soon as someone realizes they're an illusion, and single-use effects (such as an illusionary damage spell) would only do something if the target thought it was real at the time of the effect (ie: the target only receives the effect if they fail a check of some sort).

Some may consider that broken, so damage from an illusion could simply be in a "non-lethal" category. Whatever was hit by an illusionary source could do damage, but it would only ever knock a creature unconscious (if non-lethal + lethal dmg > max_health). This would imply that taking non-lethal damage at the same time as lethal damage could never kill you. Of course... if the player is unconscious they may as well be dead, since the enemies will probably still keep attacking. But it should heal at a significantly faster rate. I would recommend against having it linked to the illusion itself (so when the illusion disappears its damage effects do too) unless you have a system that handles such things for all effects. Otherwise, that could be difficult to implement.

So... I suppose illusions could be hard to implement depending on what you want, and what you consider "hard to implement".

44

Programming / Re: Run and hide

« on: November 24, 2009, 04:55:55 PM »

This looks like a fun game! I'm looking forward to seeing what else you do with it. I have a few ideas for you.

You could vary the behaviors of the zombies a bit. Some would just wander aimlessly and fight any living things they see (or maybe stop to eat a corpse if there's any around). Others could actively seek out living things (such as the player) and hunt them down, making these zombies more of a threat. Other zombies could act as a group leader, and any wandering zombie in a range around them would just follow the leader instead of doing their own thing. The zombies don't need to have different strengths as their behavior is enough to change how deadly some may be, though you could still keep the a - e level of zombies if you want. An e hunter would then be the most deadly zombie.

Another thing you could add would be other humans wandering around. They could also be trying to hide, but could be good for the player in that they distract zombies. You don't necessarily need to interact with them. Having other living things around (that when killed could turn into a zombie) would add to the mystery about what thing you hear. Seeing a ? in the corner of your view could be a zombie, but it could also be a human that doesn't actually pose a threat.

Likewise, if you go with the concept of carrying a friend out your friend doesn't necessarily have to be annoying. Your friend could provide warnings, such as "I hear something east of me". Just make your friend more unrealiable (because he's scared or something), so you may get a lot of false alarms. That would add on to the other human issue above: you could hear something, but it may not be a zombie. Your friend could hear something, but may not be a zombie (it could be another human or nothing at all).

Given that the point is to survive you'd want to give the player reasons to think they could be killed at any moment, but the game doesn't actually have to be deadly. The player just needs to think it's deadly.

45

Programming / Re: View of a Scrolling Dungeon

« on: November 24, 2009, 04:37:44 PM »

What do you think of this setup? Any problems that I didn't think of?

How does the view scroll when there are enemies all around the player? I don't mean the player being surrounded (and thus can't really move), but when the player is moving towards a ranged enemy but there's other ranged enemies being him. Will the view just stay focused on the player in that case? That's really the only issue I can think of, though there may be others.