Messages

1

Programming / Re: rl oriented scripting language features.

« on: June 26, 2011, 12:59:42 PM »

Not having to recompile every time you change a couple values is a huge blessing.

That's what modern IDEs are for, they only compile files you change and compile times are pretty close to zero. Linux users however may be unaware of such modern tools... and they have to use scripting.

You don't even need a modern IDE for that, since makefiles have been doing it for decades now.  Regardless, I use a modern IDE, and recompiling still takes longer than simply saving a script file.  That's not even to mention the fact that scripts can be edited and saved while the program's already executing, which also saves you the time of having to restart your application.  Good luck doing that with C/C++, regardless of how modern your IDE is.

And as for your silly, pointless, uneducated comment regarding Linux users, well, that actually was about what I expected from you anyway.  Most good IDEs are cross platform, and from my experience, the IDEs that are not cross platform tend to suck anyway.  I can't imagine having to do any serious work on a Microsoft system.

2

Programming / Re: rl oriented scripting language features.

« on: June 26, 2011, 12:34:00 AM »

i'm wondering, does speed really matter in roguelikes? maybe for the AI?

i haven't finished a rogue yet, but we're happy with scripting a complex Java machinery with JavaScript at work. Certainly made our team more productive

I can speak from experience with this one, having produced two nDRLs, both primarily written in Lua, using C++ calls to libtcod.  While Lua is a very fast scripting language (most benchmarks place it as a serious contender among the fastest), some frequently called operations caused significant speed issues.

This was a particular problem for Zombie Swarm, which featured large numbers of zombies, as well as up to three allied AIs.  The allied AIs weren't very complex, and the zombie ones were downright simple.  But repeated calls to these routines (I should note the game was in realtime) resulted in significant slowdown, even on fast machines.  So even with most of the heavier lifting being done by libtcod, like with pathfinding, I just found a scripting language inadequate.  But after moving the AI primitives (move-to-player, attack-player, etc) over to C++, the speed quit being such an issue.  It still wasn't fast enough overall, but I also had lighting effects and other such things further slowing things down.

All in all, I'm still definitely in favor of utilizing scripting languages, but believe that they should be used for what they're good for, and core engine behavior isn't it.  After my experiences embedding Lua in C++, I can't imagine ever writing a roguelike in anything else.  It made my coding sessions far more productive, as well as allowing me to painlessly make minor balancing tweaks, that would have been a chore in C++.  Not having to recompile every time you change a couple values is a huge blessing.

3

Programming / Re: rl oriented scripting language features.

« on: June 24, 2011, 05:20:07 PM »

Maybe if you'd used a higher level language it'd be done by now.

Yeah, that's what people say. But I haven't seen their major roguelikes... I really think that in game development the programming language plays very little role.

ToME 4 is a recently released major roguelike (whether you like it or not), *and* it features scripting with Lua.  Plus, it should be obvious to anyone, and in the professional and academic world is undisputed common knowledge, that the choice of language, as well as what tools you use, undeniably plays a large role in *any* programming project.  Choice of language and tools, coupled with the developer's proficiency in them, is critical to any project that wants to ship this century.  To suggest otherwise reveals an extreme lack of understanding of the software development life cycle.

Higher level languages, which features more machine instructions per line of code, by their very nature result in a more rapid release, whereas lower level languages take more time, as well as requiring a greater debug time.  This is why many software companies make extensive use of higher level languages for applications that are not speed critical, since speed is where most higher level languages lose their edge.

This is also why Dark God has been able to release a very ambitious ToME 4, coupled with constant updates, which are all impressively large in scope.  I'd say he pretty much makes the value of scripting languages undeniable.  By coding a robust engine in C++, which uses OpenGL for rather impressive graphical effects, as well as being highly modular, he's able to add an absurd amount of content with every release, solely because of the increased productivity of working in a higher level language like Lua.

All in all, whether or not you choose to make use of a scripting language is up to you, and depends on your design goals.  But to suggest that because *you* don't use it, that it doesn't provide a huge productivity boost for others who may use it, is silly and absolutely wrong.

4

Programming / Re: rl oriented scripting language features.

« on: June 21, 2011, 11:08:55 PM »

Well, I myself am a big fan of the Lua scripting language, and for some time now have integrated it into every project of mine, and even wrote a couple little games exclusively in Lua, although speed issues kept this from becoming really workable.

In my opinion, embedding a language like Lua presents several clear benefits for roguelikes.  Firstly, it allows for more intuitive, flexible data files to contain various types of game data.  Many RLs use data files for storing things like monsters, items, etc, and the benefit of this is *almost* universally agreed upon, so I won't waste time arguing *why* you would want to do this, but how scripting can make it better.

First of all, with traditional data files, you have to write a parser to read and load all the game data.  This presents its own set of problems, including many potential bugs, caused by either the parser, or a typo in the data file.  By using a script instead, you can more intuitively load this data, and any error will be easy to trace, down to the exact line.  Also, by scripting data files, you can take advantage of conditional statements and other programming constructs that are impractical to implement with a traditional data file.

One example of how conditional statements in a data file might be useful could be in the case of revising content in a future update of your game.  Let's say that in v1.0, a kobold has an attack rating of 5.  You soon realize this makes them underpowered, so for v1.1, you decide to increase it to 8.  Now, normally, you can just overwrite the old value and forget about it.  But what if the player updates your game to v1.1, but is still playing a savefile from v1.0?  Now, suddenly, all the kobolds magically become stronger, which may break game balance for that version.  Using a scripted data file, you can conditionally load different versions of the same data by checking for the version of the player's savefile.  Problem solved.  Obviously, there are many other useful things that can be done with scripted savefiles.

And, on the note of savefiles, using a script for savefiles also makes things easier.  You can simply write the savefile as a script that automatically loads the game data.  This makes the savefile human readable by default, which can be *immensely* helpful for debugging and balancing your game.  And, if using a language like Lua, you can compile the script to bytecode if you want to, to prevent the player from reading or altering the data.

I've also found scripting to be useful for higher level AI implementation.  Since developing any reasonably decent AI involves a lot of trial and error, and constant minor tweaking, using a script for this makes the process much quicker.  If you do this, though, I highly recommend putting all of your lower level AI routines in your engine, for speed reasons.

Dungeon generation, also being a trial and error process, can also benefit from this boost to development speed.

One of the most obvious benefits is that it allows others to modify your game, without being competent C/C++/Java/whatever programmers.  Editing monster values in a script is pretty easy for a beginner.

All in all, I'm very much so in favor of scripting, and I see ToME as being a stellar example of the potential power of a C (or C++, not sure) engine, with Lua scripting capabilities.

If you're serious about adding scripting to your game, I highly suggest you check out Lua.  It's definitely one of the fastest available, is comparatively painless to embed (at least compared to certain other languages), and has, in my opinion, awesome capabilities.  It's a very simple, easy to learn language, but extremely powerful, through the use of its rather phenomenal tables data types.

Anyways, just my two cents.

5

Programming / Re: Windows GUI or Custom GUI?

« on: December 07, 2010, 02:54:19 AM »

Have you looked into agar?  http://libagar.org/

It's a great GUI toolkit, and well worth checking out.  I'm using it myself with libtcod.

6

Programming / Re: In the early midgame

« on: November 20, 2010, 12:56:04 AM »

You have my permission to repost anything I write here, in any form, anywhere you'd like.

7

Programming / Re: Variable sized tiles

« on: November 10, 2010, 06:28:26 PM »

He said that the floor was comprised of tiles. He never said that player movement would be restricted to them, so I'm assuming that he doesn't mean to do that, as I agree that it wouldn't make sense. If memory serves, tiles are used for backgrounds in games that aren't what we would consider "tile-based". It's more reasonable to have a small tile repeated across the landscape than one huge texture.

Exactly.  It uses tiles, but movement is pixel perfect, ala Diablo (or one of thousands of other games).  Indeed, tiles are far superior for backgrounds than one huge texture, especially since OpenGL has a limit to the size of a texture that can be loaded into memory (4048x4048, or something like that, I think).

Thanks again to everyone for their help.  Using the gridded system with offsets that Elig mentioned, I should be able to implement the rendering much, much easier, and much faster.

Unfortunately, collision detection will still be a challenge, and will require a quadtree to keep performance high.  I have no idea where to even start implementing a quadtree, having never used a tree structure before, at least, without just copying existing code.

Oh well.  Thanks again everyone, and wish me luck!

8

Programming / Re: Variable sized tiles

« on: November 10, 2010, 06:24:21 PM »

You can still use a multidimensional array which is normally displayed as a grid. In each tile, simply store a per pixel offset. The wall graphics will be larger than a "normal" tile, but the per pixel offset stored in the tile will allow you position each graphic correctly. During display, add the offset to the graphic's normal position, which will give the correct display location. I've actually done this myself before.

For example, if you have a wall graphic which is 4 pixels higher than a normal tile, and 12 pixels longer, and you wanted the wall graphic to be centered on the tile, your offset would be -6,-2.

Wow.  I feel stupid now.  That's a simple, easy solution, and I can't believe it never occurred to me.  This is, after all, my first game that's not ASCII, so I still find there's a lot for me to learn.  Thank you very much.

9

Programming / Re: Variable sized tiles

« on: November 09, 2010, 06:55:40 PM »

This is probably not what you need as it seems quite simple, but I don't understand your problem, so we can try. For the isometric view, you can just draw all your walls starting from the ones which are furthest from the point of view (i.e. top of the screen) and ending on those which are closest. This can be done easily by changing the sequence of walls generated by your FOR loops or whatever you use. This way you can be sure that a wall or monster which is closer never obscures one which is more distant. I don't think this would need optimizing... [OK, I am not sure whether you are even working in the isometric view, so this might be even less useful]

Maybe your problem is that you are working in OpenGL? This is designed for rendering 3D scenes and seems very strange for a 2D game. For each floor and wall and monster and item type, create a ready-to-use bitmap which can be directly copied without any modifications ("blitted") to the screen, and then just put these bitmaps at correct locations.

The game isn't isometric.  I'm using OpenGL out of necessity.  Since I'm working on the Android platform, I'm limited by memory, and I have a lot of graphics to load.  16MB on older models is the limit for an application.  However, with OpenGL, I can access the VRAM, which opens up nearly 256MB of memory.  Also, speed is a critical issue, since it's in realtime, and OpenGL is much faster than using the 2D rendering.  With OpenGL, I can load my tilesets as textures, and just directly blit the parts of the textures I need.

The Z-ordering issue I'm less concerned with, as I could find a solution for that.  However, because the wall tiles won't be contained in a grid, but rather will have direct pixel coordinates, I can't simply loop through a 2D array.  Instead, I'll have to loop through an array containing *all* wall tiles, and check to see whether or not they're in viewing range.  On any sizable map, this will take a while, when repeated dozens of times a second.

The easy solution would be to limit the map size, and just keep using the vector array system I'm using now, but I really don't want to restrict gameplay due to implementation problems.

Since I seem to be having trouble describing the problem properly, I'll give an indepth explanation:

So, I have a 2D array of floor tiles.  These can simply be for looped, no problem.  Wall tiles, however, don't conform to any sort of grid, since each wall tile has different dimensions.  Thus, it is necessary to specify direct pixel coordinates for each wall tile, as opposed to grid coordinates, like those used for the floor tiles.  So, whereas a floor tile might have coordinate (5, 7), which would correspond to pixel coordinates (32 * 5, 32 * 7), if the floor tiles were 32x32, a wall tile would have no grid coordinate, just a pixel coordinate, like (517, 892).

There's no way to align variable sized tiles to a grid.  Trying to do so would create overlap, visible seams, and other visual artifacts.  So right now, I have a big array containing the wall tiles, and scan each individual one, testing it to see if it falls within the camera's coordinates.  This is way too expensive.  I've been researching 3D methods of solving these problems, but most methods seem unnecessarily complex.

BSP trees, for example, is the typical 3D method of doing this, but that's usually used to speed up the processing of millions of polygons, as opposed to maybe a couple hundred of my wall tiles.  Due to the smaller set size, I'm unsure implementing the rather complex BSP trees would actually gain me a significant speed boost.

Quadtrees are also a consideration, but, again, seem awfully complex for a 2D application.

I'm really at a loss here, and am not up for the challenge of implementing these difficult data structures, just to possibly find out it was a waste of time.  I really need a solution for this damned problem, it's really doing my head in.

10

Traditional Roguelikes (Turn Based) / Re: Windows text-graphic Roguelike HyperSilence released

« on: November 09, 2010, 06:04:12 PM »

I apologize if you can't afford or just don't want to pay for Part Two. Six others felt it was worth it, and it's only been out one day. Feel free to play Part One for as long as you want though. It's completely free. But if you think it doesn't have anything new or different, feel free to play just about any other free "Roguelike"

Fenrir narrows his eyes at HyperSilence.

Well, well, well. What a marvelously passive-aggressive way to tell me to "piss off". It's not like I was trying to discourage you or anything. I put it politely in an earnest attempt to point out a potential problem.

I should really start selling roguelikes, because it seems you can make a generic roguelike, be a complete ass to potential players, and still make sales.

I'd be surprised if he actually made any sales.  The screenshots are totally unimpressive, even by roguelike standards, and the first game was glitchy and unoriginal.  I think it's just an attempt to make the game look worth buying, by claiming others have already done so.  $7.50 for that?  Diablo only costs $10, and is actually fun.

I think HyperSilence's attitude is rather revolting, and has completely turned me off from even wanting to try the game.  Granted, it's Windows only, which is rather lame, considering almost every good roguelike is cross-platform.  Plus it looks like a Technicolor nightmare, with an offensive array of colors blinding my eyes.

HyperSilence, I'd reconsider your stance, and check your attitude before you post in here.  And by the way, if you want to sell a game, try developing an existing fanbase first, otherwise, good luck.

11

Programming / Re: Variable sized tiles

« on: November 09, 2010, 03:49:32 PM »

I suppose I should have clarified more.  The floor tiles are uniform in size, and aren't the problem.  The wall tiles, however, are of varying sizes, so they don't conform to a grid, hence multidimensional arrays are out of the question.

I'm using OpenGL for the rendering, on the Android platform, which isn't exactly the fastest system around.  The slowdown definitely occurs here, in the rendering loop.  Scanning hundreds of tiles many times a second is slow, and I need to keep my FPS up to make the game playable.

The graphical data is stored in textures, which are internally represented by integer values, so this isn't part of the problem.  I've considered using BSP trees, but it seems like overkill, and a bit messy for a 2D game.

I'm really unsure how to progress from here...

12

Programming / Re: A roguelike with tight constraints

« on: November 08, 2010, 05:05:38 PM »

 I have given some thought to this. What I think might work would be a one button and 4 directions scheme. 4 direction arrows to move. Press the button to activate the menu. In the menu screen the up down buttons cycle through the items and the one button selects them for use. The left/right buttons could also select them for use/not use(take off).

That's similar to POWDER system, except that POWDER has a two-dimensional inventory (that is, you use all 4 directions to select items from your inventory), I think that searching for item to use is more convenient this way.

 For example select the bow and it takes you back to the map screen. Then the next direction you press would shoot an arrow in that direction (if you have one to shoot).

There could be some problems with convenience this way, as I would not want to search my inventory for the bow for every arrow I want to shoot.

Diablo handles this well, I think.  Clicking on the enemy, when the bow is equipped, autofires the arrow.  I'll probably take a similar approach, with point and click attacking.

13

Programming / Variable sized tiles

« on: November 08, 2010, 02:07:19 PM »

I'm working on a graphical roguelike, only using libtcod for utilities, like FoV and pathfinding.  My problem is, I have variable sized tiles, and I don't know where to even begin with implementing them.

Currently, I'm just using a vector containing all the tiles in the level, with their positions, and draw the ones that are in view.  The problem with this is the speed.  Scanning every tile is slow, and I have yet to find a better solution.

I feel like their must be some superior method, and it's probably an obvious one, but I'm clearly missing it.  What can I do to solve this problem?  I can't just resize the tiles, because they come from another tileset, and resizing them to fit the same area would cause graphical glitches and artifacts.  There *must* be a solution to this problem, and someone must have encountered this before.

14

Programming / Re: A roguelike with tight constraints

« on: November 08, 2010, 02:01:51 PM »

"not all Androids have touchscreens, not all have trackballs, and not all have keyboards"

  I have given some thought to this. What I think might work would be a one button and 4 directions scheme. 4 direction arrows to move. Press the button to activate the menu. In the menu screen the up down buttons cycle through the items and the one button selects them for use. The left/right buttons could also select them for use/not use(take off).
  For example select the bow and it takes you back to the map screen. Then the next direction you press would shoot an arrow in that direction (if you have one to shoot).

Edit: Hey are those Reiner Tile Sets animated? Didn't think they were. Could be wrong. I would LOVE to be wrong.

Yes, the Reiner Tilesets are animated.  They look pretty damn good, too.  Most sprites feature attack, walking, dying, and getting hit animations, and many feature talking, running, standing still, etc.

As for the controls, you and Z both have some valid points, and good suggestions.  It'll definitely take some tweaking to get the controls solid and smooth, but it's worth the effort.

15

Programming / Re: A roguelike with tight constraints

« on: November 07, 2010, 11:52:45 PM »

I am also thinking about doing something for Android if I ever get time for this (as I own one and I am annoyed by not enough roguelikes for it). What do you mean by "standard hack and slash like Diablo"? Do you mean an action game? (If yes, then I don't see why this is unavoidable, and also it would be moving away from roguelikes) Diablo has inventory management and spellcasting and bows, and these things are still hard to do comfortably with constrained input.

POWDER, which is also designed for devices with input limitations (and BTW can be played on Android via Gameboy emulator, but I have not tried it a lot) uses four way movement. I think it is a good idea in this case, too. Other than that, it has a pretty standard set of roguelike actions (wear armor, wield weapons, throw missiles, drink potions etc) which are not done very comfortably using just a few additional buttons, IMO (although I have played Powder only on keyboard, so I cannot really say).

I think it would be best to have all frequently done actions available by simply pressing one of 4 direction buttons (or touching the part of touchscreen in this direction). Or maybe 4 direction buttons plus one additional, if only 4 directions is too much constraints.

I have seen somewhere (I don't remember where) an idea about "dance magic", where spells were casted by performing a sequence of moves. A similar possibility is special combat movements, also executed by a sequence of moves (like in PrincessRL). I think such ideas would work very well with restricted input.

Another idea is a game where terrain features are important. For example, things like changing equipment and loading weapons can be only done in special places. Then, special action is executed just by bumping into such a special place, so no additional keys are required.

Yes, it'll be Diablo-esque, so a more appropriate term for the game would be an action RPG/roguelike.  It'll still feature procedurally generated content, character building, and a dungeon setting, which are, in my opinion, the key aspects that make a game a roguelike.  It may not be as pure a roguelike as, say, Angband, but still a roguelike, nonetheless.

As for POWDER, I've never tried it, but it looks nice, and definitely accomplishes much for being on a constrained platform.  Four way movement doesn't seem necessary, since a touchscreen or trackball will be present, allowing for diagonal movement.  And since it's in realtime, diagonal movement is made much easier.

The dance magic idea is rather intriguing.  Probably hard to implement in realtime, but not impossible.  I especially like the idea of doing special combat moves that way.

The special terrain idea is also appealing, and could add some depth to the game.  Like using terrain to determine whether or not a spell can be cast, or what type can be cast, like null mana zones, or fire zones, etc.

Excellent ideas, thank you.