Messages

16

Design / Re: Info line idea

« on: May 11, 2016, 01:56:32 PM »

Nice thing to have. Myself I am unable to use any new program if it doesn't offer such functionality. Make it as developed as you can. As of keyboard support, many ideas can be "stolen" from MS Windows, where you can use keyboard for virtually every action available with mouse (at least until Windows 7, not sure about the current situation :-)).

17

Design / Re: Item randomization

« on: April 01, 2016, 07:24:23 AM »

By the way how many different items do you have in your games? I wounder how many Is there required to avoid the feeling of loot repetitiveness in the game

I don't think this is just a matter of the number. You must ensure that every time the player finds a loot, it is useful to him in some way. This is usually easy in an early game - the player will be happy to find any armor, any weapon, any ring, and so on. As the player advances, he will need a better armor, a better weapon etc. It is still fairly easy to guarantee that he will eventually get better items, although it might be quite challenging to drop them at the right moment. The question is what to do if the player already has the best equipment available in the game (or - how to prevent this kind of situation). Anyway, creating a bunch of similar items that differ only by some numerical parameters is probably the worst solution. All items should have some interesting uses, some interactions with the world. Most of the times these interactions should be obvious (for example, healing potions can be used to heal the player, but may be also thrown on monsters to recover their HP, which in turn may have interesting consequences - some monsters might temporarily get confused, other might stop attacking the player character and go somewhere else). Some interactions (but not too many) may be totally crazy and unexpected (like throwing out potions of uselessness in ADOM). The more ideas you put in the game, the better, because it's ideas what really counts, not bare numbers.

18

Traditional Roguelikes (Turn Based) / Fame 0.9.9 Released

« on: March 12, 2016, 08:50:53 AM »

This version was once planned as the last one before 1.0, i.e. an "almost final" release. This won't happen, we're still far away from 1.0. There's much to change and even more to add. Things must be balanced. Lots of content must be added. So, future versions will be 0.9.10, 0.9.11 and so on, until the game is good enough to be called 1.0. Quite challenging, but we'll get there!

Working on the new World Map I've had some headache about the content that currently fills up the game's world. Not because there's so little content - I had known it before. It's because the current content is presented in a very poor way. A World Map is typically the most suitable thing for this role. In Fame 0.9.8 the World Map doesn't even show all the locations and it doesn't change much as the player explores the world. I also discovered that some locations are not given any unique name and most of the area is simply named "Unknown lands".

Apart from the dynamic map, the world will no longer be the same every time you start a new game. Now that random settlements have been introduced, you will have some extra reasons to explore the land. Settlements can be occupied by several different races. They may be neutral or hostile towards you. Buildings in settlements can contain some valuable resources (typically locked). Certain citizens may want to trade with the player, others may offer some services (healer, blacksmith), depending on race and alignment. There's still a lot of space left for creativity here, so the next game release will probably contain more of that stuff.

I had lot of thoughts about procedurally generated content. This has been inspired by another game project, but also by my old notes complaining about numerous problems. The subject is actually never closed in a roguelike game, but this particular game hasn't even reached the playability treshold and I believe that problems with procedural generation have contributed big time here. One thing that has already been fixed are partially predefined locations. There were 8 such locations in Fame 0.9.8 (6 in the Forest Dungeon and 2 in the Altar of Fire) and they all looked the same - the procedural part to the left, the predefined part to the right. Very boring. Now the predefined part is placed randomly and can be of any (almost) size. The only limitation is that the part must have a rectangular shape, although this can be easily worked around (a single cell is still a rectangle). I'm very satisfied with the result and most likely this change will increase the total number of partially predefined locations in the game, which, in turn, should make it more interesting.

Another matter is generation of items and monsters. The old algorithm worked, but it did not give the player the feeling that encountered items and monsters are consistent with the difficulty level of the current location. The new algorithm uses normal distribution and should be much better (although it probably could use some tweaking).

Saved games from 0.8.4 up to 0.9.8 are still compatible with 0.9.9.

Quick summary:

• random settlements
• new locations and quests
• World Map improvements
• procedural generation improvements
• trade system bugfixes and improvements
• ASCII mode bugfixes and improvements

Full change log:

• new location(s): Black Tower
• redesigned Akeram Temple, with certain areas not accessible until completing some quests
• item generation based on normal distribution
• new spell: Destruction
• special locations appear on the World Map only when they are visited
• location/region description is available in the World Map
• partially random locations now have their predefined part placed more flexibly (in other words: they are more random)
• added missing Alchemy quests (available after talking with Babeneys)
• some terrain objects are now destructible
• NPCs are now able to cast offensive spells even (making sure they won't hurt their allies)
  
• Quest Log, World Map and the 'extra info' panel (on the right if Immersion enabled) now drawn entirely using characters in ASCII mode
• items can be kicked or thrown over water or lava
• door cannot be unlocked with a cursed key
• wooden boards and sticks thrown into lava transform into coal
• additional monster information available when looking at it (hostile/ally and experience level)
• additional wound status
• difficulty level tuning: lower parts of Forest Dungeon are somewhat easier, Large Dungeon is much harder
• portals are marked green on the auto-map
• skills not used for too long will not increase anymore when the Hero gains an experience level
• spell tuning: Daylight and Magic Bolt
• hobgoblins are no longer able to steal cursed equipment
• sleep is automatically interrupted when the hero gets attacked (this could happen if new monsters are generated while the hero is sleeping)
• Raylnen now "oficially" gives a quest when offered to be escorted back to town
• prices "per unit" in the Trade window are displayed for Hero's items as well
• Trade: no gold is automatically transferred from the merchant's inventory until all items offered for sale are from the correct category
• Trade: prompt message replaces trade result message as soon as any item is clicked
• reduced chances that early sacrifices would be rejected
• added messages for uncursing an item and teleporting self
• in the post-death statistics a percent of visited locations is listed rather than a number of locations; prayers are counted even if they were ignored
• [bugfix] no more crash when closing certain windows with Esc
• [bugfix] no more crash when starting a new game immediately after quitting a game where the hero had any allies
• [bugfix] no longer possible to cast a spell by using auto-aim when there is not enough focus
• [bugfix] the Elemental Storm no longer crashes the game when cast near the location's edge
• [bugfix] all encountered creatures now have correct AI (especially spellcasters & ranged attackers)
• [bugfix] trying to swap positions with an ally no longer caused them to be attacked by the hero
• [bugfix] grenades no longer fail to explode after being thrown
• [bugfix] red light in the Altar of Fire does not disappear after saving game
• [bugfix] repaired some dialog scripts (Raylnen, Upores) so that they no longer offer options that should appear only once
• [bugfix] prices are displayed correctly in the Trade window
• [bugfix] attacking an enemy by l-clicking it now works for all types of hostile creatures
• [bugfix] wizards no longer appear in the stats as "New Monster"
• [bugfix] items appearing in the stats are no longer unidentified
• [bugfix] the Old Key is no longer "invisible" in the inventory
• [bugfix] editor no longer crashes when entering portal's properties
• [bugfix] editor: clicking "OK" on item's properties automatically applies all recent changes to the selected item
• [bugfix] editor: autopickup no longer used when moving
• [bugfix] editor: door properties no longer display short sword as a default key
• [bugfix] editor: unlocking door from the property window now works correctly

Have fun!

19

Programming / Re: [Python] Looking For Some Good Examples

« on: February 17, 2016, 11:55:38 AM »

I don't have a design document per se, but I do have a half-dozen sheets of paper scrawled full of pretty unorganized notes.  I have this nebulous mass of ideas drifting around my brain that are revolving around a common theme that I could hammer out into an actual game concept, I've just been putting it off  .   Actually, several years ago I first learned a little bit of Python, and even felt the urge to make a roguelike.  I see a post of mine from 3 years ago here asking a pretty stupid question as I was jumping in too deep trying to use Pygame and not use the libtcod tutorial.   I made it to some Cellular Automata caves I could never figure out how to ensure were joined up before I quit.  I bring this up because at that time, I had this generic desire to make a game, but I had no game in mind to actually make.  It seems an obvious flaw now, but somehow it didn't deter me at the time and I feel a lot of the roguelike and gamedev newbies that show up and then disappear again fall into this same trap.  If you don't have an actual game you want to make, how can you expect to actually make it?

Perhaps you don't want to be a programmer at all. If you have a lot of ideas and like to write them down, you may want to become a game designer. Try to organize your notes into a real design document. If you manage to get your ideas presented in a nice, readable form, you'll probably find someone who will gladly help you with the programming side of the project. That would be probably much better than struggling to do something you don't really want to do. I think that some of the most famous roguelike authors are actually not so great at programming, but I doubt that any one of them is a weak designer. Designing skills are kind of more important than programming (this actually applies to all game genres, not only to roguelikes), so let them develop before you grow too old . Some Python knowledge won't hurt, sure, just don't spend too much time on that until you are absolutely sure that you are hopeless as a designer.

20

Early Dev / Re: Ultima Ratio Regum (v 0.7 released, 18th April!)

« on: January 21, 2016, 12:17:01 PM »

Revision control helps a lot when programmer's creativity goes too far, but it is good to backup the repository as well. I do it every week (which means once every 2 lines of code I write ).

21

Early Dev / Re: Ultima Ratio Regum (v 0.7 released, 18th April!)

« on: December 16, 2015, 12:15:06 PM »

These look more like table napkins than castles to me, but still your procedural generation skills are truly impressive .

22

Design / Re: Sorting order of inventory

« on: November 09, 2015, 09:08:06 AM »

You can also remember which category of items player seems to be most interested in and use that data to determine the order. I don't know if that will work, it's just a random idea . Its usefulness will probably vary from game to game as every game has its own ideas for inventory management. For instance, if you need to extinguish your torch very often to save the fuel, it makes sense to give the tool slot a high priority, but you can also have a dedicated keyboard shortcut for that, which would allow you to move more important slots higher. My idea is more universal and could probably fit to every game, but it could also be annoying for people who like to have a fixed order of item categories.

23

Programming / Re: Noob problem with std::map

« on: October 26, 2015, 10:35:25 AM »

I don't believe that 75% (unless the source code is C?). I'm using the debugger only in rare cases when programming more stuff at a time and then notice something doesn't work. The open/known bugs in Kaduria for example has been less than 10.

Is the game publicly available? Nope. So you don't know how many bugs you actually have.

24

Programming / Re: Noob problem with std::map

« on: October 26, 2015, 08:05:35 AM »

This sounds like a faith in authoritative figure. Talk to me like an engineer, not like an adherent.

He must be crazy to use a totally broken pointer class, right?

That article is old, some points are not even relevant anymore. I've actually went over all three use cases he outlines but this produced a wall of text, a lot of what I've already mentioned earlier, tl;dr auto_ptr either useless or potentially harmful.

What was relevant 15 years ago, is still relevant. 15 year could broke my computer or my spine, but it could not break auto_ptr. The fact that the new shiny C++11 is out does not imply that something is wrong with C++03. (By the way, shared_ptr is also potentially harmful, I'd bet you didn't know that.)

The one thing Visual Studio being undeniable good with is its debugger. I mostly work under Linux so I regularly forget about this stuff, but Eclipse's debugger is GDB and it doesn't perform as well under Windows.

I wouldn't say it's the only thing, but I'd say it's unfortunately the crucial thing. A typical programmer spends 75% of their time debugging, so relying on tools like GDB sounds like masochism and a guaranteed way to a failure. I haven't used Eclipse since about a year, but if I remember correctly, it wasn't even able to display a std::string properly.

25

Programming / Re: Noob problem with std::map

« on: October 22, 2015, 08:41:18 AM »

Oh yes it will. You are likely to already know, but for the sake of other readers, I'll remind that the main problem with auto_ptr is that its assignment/copy behaviour is literally broken. It actually performs an implicit move instead of a assignment/copy, silently leaving the original empty. Assignment operator not performing assignment, this is a disaster on many levels rendering auto_ptr unusable with standard library (which relies on copying greatly) and prone to counter-intuitive results.

Maybe you are talking about using auto_ptr as a scope-level guard tasked with calling destructor. In this role auto_ptr mainly fails by not providing means to specify a custom deleter. For example, you cannot wrap FILE* or AVFormatContext* in auto_ptr and make it call suitable close function at scope exit (but you can do this with shared_ptr or unique_ptr). This leaves a single scenario where auto_ptr is useful. That would be scope-guarding a temporary polymorphic object dynamically allocated within that scope. This situation is so narrow that I believe (religious, duh!) it is much safer to just outright ban auto_ptr than keep all this quirks in mind. Raw pointers should be better than auto_ptr, if you cannot or refuse to use normal smart pointers.

Ever heard of a guy named Herb Sutter? Well, he's written an article on auto_ptr:

http://www.gotw.ca/publications/using_auto_ptr_effectively.htm

In short: auto_ptr ain't broken, it's useful, yes, it has some pitfalls, just like anything else in programming.

There are a few options. If you are not too attached to VisualStudio, there are another IDEs, i. e. Eclipse CDT (quite different but really good after you suffer through a bit). There is also Boost, which is admittedly bloated but you are not compiling by hand and paper, are you? And there is always an option to just copy-paste the relevant source from somewhere. Just saying.

I'd rather use Vim than Eclipse CDT. Eclipse may be a great IDE for Java, but it fails miserably as an IDE for C++. It would be unwise to give up something as good as Visual Studio just to get smart pointers . As of non-standard libraries, I try to avoid them when I can. This is mainly to avoid situations when my program crashes executing some code I've never seen. It's enough for me that I sometimes need to go through STL source files. Adding another library with its different coding style, different rules, different debugging techniques, different string class etc. is just begging for more trouble.

26

Programming / Re: Noob problem with std::map

« on: October 19, 2015, 12:56:47 PM »

In fact, to comfortably use a class with standard containers you need both copy constructor and default constructor.

27

Programming / Re: Noob problem with std::map

« on: October 19, 2015, 06:11:05 AM »

I'll start with stressing that auto_ptr is one of the few well-known failures of C++. It quickly became obvious it does not fulfill its role and it was promptly deprecated, so I'm afraid there is no legitimate use for it :-)

This sounds like a religious belief. Talk to me like an engineer, not like a priest. Sure, auto_ptr is not a general purpose pointer, but it is working. It won't explode if you try to use it .

It is beside the point of discussion but I am curious why do you still use VisualStudio 2005 when up-to-date versions of this product are available for free.

They require an up-to-date hardware, I'm afraid, and hardware requires an up-to-date Windows version. I'm not a kind of guy that would happily buy all the new stuff every two years or so. I use the old stuff until it breaks down beyond all repair. Of course, this way I cannot participate in the technical revolution, enjoy smart pointers etc., but guess what - it doesn't worry me that much .

28

Programming / Re: Noob problem with std::map

« on: October 16, 2015, 01:44:05 PM »

AFAIK you primarily use C so this must look like choice between proven, natural approach (manual memory management) and somewhat alien one (automatic memory management). We, however, are talking about C++, where it is as natural and have direct language support.

My previous post might indeed sound like I'm a C programmer, but in fact I've started from Visual Basic and later switched to C++ (like 15 years ago). I've been using stuff like std::string or std::map from the very start, so it's not that I don't value automatic memory management. It's enough to use any raw WinAPI function to see why std::string was such a giant step forward in programming. However, I can't see a single reason why to use smart pointers (apart from one legitimate use of auto_ptr, but that's another story, I guess).

It seems that you are talking about C++11 here. Well, everyone knows it has cool features, but unfortunately some people are stuck in the stone age with their Visual Studio 2005 and can't enjoy that coolness. All the smart pointer support that C++03 has is the infamous auto_ptr, which is not so smart, as you probably know. One day I'll buy a new computer, install new Visual Studio version and port my project to C++11, but before that happens, I would like to learn why smart pointers are as great as they say. There must be something more than just a call to delete at the right moment. Something that would justify the fact that they introduced 3 complicated pointer classes, deprecating a simple

Code: [Select]

type* variable.

You can switch to smart pointers in a week, unless the project too big or you are pressured for time, etc. but we are talking about fairly small programs here (roguelikes), and most of them are written from scratch (though it may not be the case here).

Well, maybe, I've done such things before. Like switching from char* to std::string in my early C++ days, or switching to Unicode several years ago. However, I would like to see how it will improve the development process, otherwise it would be a lost week for me (and definitely a lot of fun ).

And standard library is not a syntactic sugar. Once again, std::list is not a syntactic sugar over prev/next fields, it is a carefully written and extensively tested double-linked list implementation, written and tested in a way not many can do. In the same manner, std::shared_ptr is very robust implementation of reference-counted pointer container. At best, you'll re-implement the same.

OK, I've gone too far saying it's a syntactic sugar. As of shared_ptr's usefulness, I'm not convinced. My biggest problem with reference counting are memory leaks. If I forget to free an object which is tied to a complex hierarchy of objects, all those objects fail to release their dynamically allocated memory and I get a giant leak report. It takes ages to investigate which object has caused a leak. Does shared_ptr address this problem? If it does, I'm already motivated to start using it .

29

Programming / Re: Noob problem with std::map

« on: October 14, 2015, 10:57:40 AM »

After years of practice you start to get around all this intuitively, but in every aspect C-style memory management in C++ just complicate things.

I guess that everybody should use what they are most accustomed to. After years of practice in using raw pointers you probably won't just switch to smart pointers in a week (even if you can start programming Java in a week). Also, refactoring a big project that has been built on raw pointers is definitely not an option.

I have fixed thousands of memory problems in my life. Most of them were not silly mistakes. They were about not understanding how my own program works (yes, this happens in big projects). Smart pointers can not replace thinking. They're just syntactic sugar that often hides the real problem, which is lack of understanding the code. Once you fully understand the code, you know who is the owner of the memory and managing it becomes easy.

30

Design / Re: My thoughts on deep mechanics.

« on: August 10, 2015, 06:26:59 AM »

Your post is not very controversial, so don't expect it'll spark a real discussion here. I could criticize several other things if you want, though ;-).