implementing speed in projectiles with libtcod

[Z]

I could make my T-Engine games look *exactly* like my FreePascal games if I wanted to.

It does not matter whether you could give a classic look to T-engine games, because (1) in a powerful enough programming language you can do anything (you just need Turing completeness which many "simple" modding engines lack but any real programming language has, reasonable speed, and a way to interact with required software/hardware), (2) you need some work to obtain what is straightforward with FreePascal or Curses, (3) look is not everything, would you get ssh/NotEye compatibility?

From what I have seen, with T-Engine you can easily obtain something that looks like ToME (graphical menus that do not fit ASCII games, ToME running in background of the main menu), you need to partially rewrite this anyway if you want something else (opinions based on T-Engine games I have seen, not on trying to use it myself).

Having tried out both methods of operation I can't imagine going back to self-coding everything.  Such a lot of hard work.

As Mosenzov says, if you do it right and do not want to try something different later, you only have to do it once. Consider Jeff Lait's 7DRLs. If you look at Sword in Hand, you will see things that obviously come from Jacob's Matrix, a closer source inspection finds things tracing back to You Only Live Once (and probably even to POWDER).

In the beginning of every roguelike, you usually have to re-create the same systems you had that most (not all) roguelikes generally have (Ex: Displaying tiles, picking up items).

For my next new roguelike, I would probably use the NotEye lib for displaying ASCII/tiles (unless I wanted something very different like in HyperRogue). But even such simple thing as picking up items can be done in many different ways. Hydra Slayer has a special inventory system (limited capacity for weapons, no equipment otherwise, unlimited capacity for potions etc, which come in just a few varieties and thus we can just count the number of each of them in the inventory, and assign them fixed hotkeys), and the UI is designed around this; I think it would make no sense to copy it from another game, or to hope that T-Engine's inventory management system is just what I want. If your two games are similar, that is good for you, but do not limit your creativity

Anyway, I think this is really subjective and experienced programmers will have their own impressions about which way of programming is the most effective and the most fun for them, and these impressions would be mostly right (the recent counterexample was a newbie writing a roguelike in Assembly, a bad idea IMO). I am not sure about newbies, but ToME fans would pick T-Engine, Angband fans would go create a variant, and so on. Although my knowledge about T-Engine is based only on several games I have tried. This allows me to see some common shortcomings and good features (you seem to get the ability of redefining keys comfortably for free, which is quite boring to program by self). It would be helpful for T-Engine to have an easily findable article pointing out which things are actually easier to do than with other techniques.

[Darren Grey]

T-Engine is unfortunately very undocumented, with many things having to be found out by asking the developer directly.  But there are various things you get with it essentially "for free" - hex mode, item/inventory system, AI behaviours, keyboard/mouse input (I still have no idea how it distinguishes between numpad numbers and numline numbers, but it does and that's great), several FOV algorithms, several built in dungeon generators.  And every item can be modded to your heart's content (though it involves a fair bit of trial and error).  Of course getting away from the generic look and feel is an important step, but only needs to be done once.  You can see in my T-Engine games a gradual progression towards an individual style, just as Jeff's games have progressed.

libtcod of course is much freer, but doesn't have as much initially on the table.  I'd generally recommend new developers to use it when coming into the genre, as it provides a nice balance between creating your own style and not having to continually reinvent the wheel.  Plus there are plenty of games to snatch code from.

[Sleep]

If you cannot figure out how to make a @ moving on screen yourself, you should base your work on some game where this already works (popular choices include T-Engine, Angband, Thomas Biskup's Qhack, etc), instead of copying the tutorial.

This just sounds like elitism. You'd have to explain why it would be better to lift code from existing games than a tutorial, or why you couldn't do both.

[Z]

I don't know why this is elitist. I just say that copying is better than reinventing the wheel, and that it is better to start with a true, well written, working roguelike, than to follow the tutorial (which is kind of reinventing the wheel). How would you do both?

Anyway, I have posted a longer critique of one tutorial there. Maybe simply I have not seen a good roguelike development tutorial.

[Sleep]

A tutorial is 'reinventing'? It's just as much a copy. All it is is a stripped down version of the way the writer creates roguelikes, and afaik, no two coders create roguelikes the same way anyway so this idea of 'reinvention' doesn't have much weight to it. As a beginner, looking at code from existing games without any reference can be overwhelming; a tutorial may help make sense of the code, go through the steps, and once one has that basic understanding then peering at code from existing games will seem more familiar.

The tutorial at roguebasin for using python with libtcod seems decent.

[requerent]

A tutorial is 'reinventing'? It's just as much a copy. All it is is a stripped down version of the way the writer creates roguelikes, and afaik, no two coders create roguelikes the same way anyway so this idea of 'reinvention' doesn't have much weight to it. As a beginner, looking at code from existing games without any reference can be overwhelming; a tutorial may help make sense of the code, go through the steps, and once one has that basic understanding then peering at code from existing games will seem more familiar.

The tutorial at roguebasin for using python with libtcod seems decent.

Learning video game architecture is important. Copying and pasting doesn't give you a good idea as to why things are organized the way they are (unless, ofc the source is well documented). A good tutorial should provide some insight into the ideology behind how video games are organized. Asset management, threading, inheritance hierarchies, collision and scenegraphs are all important things to cover.

That said, this tutorial doesn't do a very good job of that.

[Darren Grey]

I don't know about any of that stuff. And for most new developers that would be immensely off-putting. The way to learn is through crude hacks in small projects and refining in newer projects. Jump into the deep end and most people will drown.

[kraflab]

I don't know about any of that stuff. And for most new developers that would be immensely off-putting. The way to learn is through crude hacks in small projects and refining in newer projects. Jump into the deep end and most people will drown.

If designing game architecture isn't enticing, then I guess I just don't understand what type of person wants to develop a game.  I'm sure you've picked up on a lot of things just by messing around with stuff, and that's fine.

Anyway, I'm surprised at your comment because this is similar to saying that roguelikes need to be simple to be accessible You can have plenty of "complex" information on game architecture in optional marked info sections, perhaps marked as being unnecessary on a first read, but useful in the long run.

I would prefer tutorials to be significantly more about game architecture than actual code, since anyone can go anywhere to learn code syntax.  If you don't know how to program, then a rl tutorial is not really the place (and going in with a lack of knowledge would probably hurt you in the long run).  If you do know how to program, then you don't need a tutorial on syntax.  The only thing left really is learning why and how things are done.  Code would be better only as pseudocode, as A) translating pseudocode into your platform is good practice if you are new to programming, or B) you know programming and pseudocode is all you need.

...And throwing someone into the deep end is the fast way to teach swimming

[Quendus]

Learning video game architecture is important. Copying and pasting doesn't give you a good idea as to why things are organized the way they are (unless, ofc the source is well documented). A good tutorial should provide some insight into the ideology behind how video games are organized. Asset management, threading, inheritance hierarchies, collision and scenegraphs are all important things to cover.

That said, this tutorial doesn't do a very good job of that.

ASCII graphics make asset management unnecessary, turn-based systems make threading unnecessary (unless you want the animations or AI running at the same time as the player input), inheritance hierarchies should be covered in an OOP tutorial, and coarse grid-based movement makes collision detection unnecessary. Scenegraphs may be useful when developing dorflikes and very large-scale roguelikes, but a tutorial for writing dwarf fortress clones would need a lot more chapters than a tutorial for writing roguelikes anyway.

Those things would be good inclusions in a general tutorial for writing video games, but a tutorial for writing video games would be about as much help as a tutorial for writing a book. Different elements are important in different genres. Dialogue may be important in a novel, but less so for a field guide. Knowing 50 words for blood may be important in a murder mystery, but less so in a medical textbook. Different genres need different tutorials.

One of the reasons I develop roguelikes is *because* so many elements of more traditional game development are completely unnecessary, or at least can be put off until after the game is fun to play.

[requerent]

Learning video game architecture is important. Copying and pasting doesn't give you a good idea as to why things are organized the way they are (unless, ofc the source is well documented). A good tutorial should provide some insight into the ideology behind how video games are organized. Asset management, threading, inheritance hierarchies, collision and scenegraphs are all important things to cover.

That said, this tutorial doesn't do a very good job of that.

ASCII graphics make asset management unnecessary, turn-based systems make threading unnecessary (unless you want the animations or AI running at the same time as the player input), inheritance hierarchies should be covered in an OOP tutorial, and coarse grid-based movement makes collision detection unnecessary. Scenegraphs may be useful when developing dorflikes and very large-scale roguelikes, but a tutorial for writing dwarf fortress clones would need a lot more chapters than a tutorial for writing roguelikes anyway.

Those things would be good inclusions in a general tutorial for writing video games, but a tutorial for writing video games would be about as much help as a tutorial for writing a book. Different elements are important in different genres. Dialogue may be important in a novel, but less so for a field guide. Knowing 50 words for blood may be important in a murder mystery, but less so in a medical textbook. Different genres need different tutorials.

One of the reasons I develop roguelikes is *because* so many elements of more traditional game development are completely unnecessary, or at least can be put off until after the game is fun to play.

Completely unnecessary? Put off until it's fun?

Roguelikes make the problems minimally complex, but it doesn't make them unnecessary.

You're still rendering images to a graphics object- even if your assets are ascii characters (the structure of your objects will be similar whether you have sprites, 3d models or bitchars). You're still separating render calls from your logic, even if you don't need threading or aren't in real-time (some roguelikes also simulate in real-time and just pause whenever a player can take an action). You're still checking to see if two objects would occupy a tile or if a tile is already occupied and with what it is occupied by, even if you aren't using continuous collision detection. You're still organizing entities into a tree or some data structure that will resemble a super simple scenegraph (more important if you have a movabe viewport or chase-cam).

I don't see how this stuff is 'unnecessary.' The algorithms to solve each problem is much simpler, but you don't solve collision through the inherent virtue of a grid-based map. You still have to solve the problem and find a way that is extensible for all the sort of interactions you want to support. Using a grid-map doesn't solve it for you.

Otherwise, I agree. But a book is still a book. The pages still have to be bound. There is a paradigm for publishing books that works, just as there are healthy practices for creating games.

[tuturto]

Well, the difference is that do you want to write SOLID software system or do you want to tinker around with stuff that you don't really know and see if you can get it running and maybe learn something while doing it. Lot of trouble, sweat and tears could be saved if your first roguelike had a really good architecture and sound design, but where's the fun in that?

You can program for living or you can program just for fun (and maybe later switch to living thing if you have so much fun with the code). That's how I started in the 80s, copying from how to write X articles in magazines, changing the code and messing around with it.

The point is that if you just want to mess around with code and get used in programming, you don't have to know who Liskov is. All that stuff can wait for later day when it really matters. However, if you're interested in such things right from the beginning, then it would make sense to read about those too. There's a limit how much new information you can pour into one's head in a given time after all.