Temple of The Roguelike Forums
Development => Programming => Topic started by: jaydg on September 11, 2009, 03:19:29 PM
-
Hello everybody,
I am working on a remake of Larn.
I baptized it NLarn.
You can have a look at it. (http://nlarn.sourceforge.net/)
It's already quite playable but still lacks some things, thus I posted it here.
Some notable differences to Larn:
- There can be more than one item on the floor
- A friendlier interface with color
- FOV
Greetings.
-
Hello everybody,
I am working on a remake of Larn.
I baptized it NLarn.
You can have a look at it. (http://nlarn.sourceforge.net/)
It's already quite playable but still lacks some things, thus I posted it here.
Some notable differences to Larn:
- There can be more than one item on the floor
- A friendlier interface with color
- FOV
Greetings.
This is fantastic! Great job! :D Always nice to see a new version of Larn.
-
Cool! Keep at it! 8)
-
Thank you for this. I am interested.
-
Larn is my favourite, so I'm very interested in this indeed!
-
Very nice game, keep up the good work.
-
Thank you all for your interest!
For the next version I made the town level static and much nicer than the original bunch of capital letters. Attached is a screen shot of the new town.
How do you like it?
-
Looks cool!
-
That looks beautiful
-
I like that alot.
-
Today monsters learned to pick up weapons, wield them and hit the player with them, if the are aware of armed combat. Simple monsters like the gnome and hobgoblin can be dangerous now, as they are able to damage the player when wielding a proper weapon. Unfortunately all slayed monsters leave a weapon and turn the caverns into a junkyard. Now all monsters need a strength attribute, and finally monsters and the player will fight with the same rules.
The next important step toward completion (is there such a thing?) will be time management. Currently NLarn suffers from a very simple player-centric time management inherited from Larn. I want to transform that into a world-centric time management, which deserves to bear the name. Unfortunately I'm pretty clueless how to do that, as everything I have done till now just turned the time by a certain number of turns.
This will turn into a big rewrite of almost everything, which will be pretty time-consuming. I hope this will allow me to fix all problems regarding time, e.g. knowing that a spell book can not be understood before reading it or to allow to abort actions which take multiple turns when under attack. Speed is another aspect connected to time. This has to be fixed, too.
-
I like the idea of a kobold or something with the lance of death - arguably the deadliest weapon in roguelike history.
-
Currently the lance of death is a simple wooden lance. In Larn it's totally unbalanced and makes the game too easy once you can afford it (at least that's what I hear).
I think I will turn it into a "one hit wonder" which will instantly break after killing something. This way it will turn into an emergency solution.
-
I disagree, the lance is SUPER expensive, making it a one hit wonder is pointless. also nuetering it breaks some of larn's charm. It does make the game easier but surviving without it becomes really hard, yeah its a balance thing but its part of larns flavour
-
I like the lance of death in Larn, personally. Yeah, it's broken balance-wise, but once you get it, the game's mostly over anyway, and it's fun. I look at it like I look at the dark energy gravity gun segments of half life 2, or being supersonic in a sonic game, it's just a sort of reward for making it to the end.
Anyway, if you're set on nerfing the thing, maybe a better way to do it would be to have it damage the player every time you use it, or make them more vulnerable defensively while wielding it.
I really don't think it's necessary though, a lot of my favorite single player games have intentionally unbalanced rewards for their players. Morrowind is an unbalanced mess, and, in my opinion, it's all the better for it, or what about Crissaegrim or the Shield Rod in Castlevania: Symphony of the Night? The game is easy enough on its own, and it hardly needs those to make it easier, but they're fun.
I do understand that roguelikes are about challenge, but it seems to me that a powerful character fighting powerful enemies is more fun than if both sides are just average.
-
Phil Cordier, who maintained ULarn for many years, chose to modify the Lance, too:
In Larn, the basic strategy was to get enough money to buy a Lance of Death, usually by getting to dungeon level 10, killing or getting around the demon lord, and getting and then selling the Eye of Larn. This would usually get you enough money to buy the Lance from the dnd store. You could then go into the volcano and kill everything in sight with one hit from the Lance.
Well, the Lance is still deadly to all monsters. Demons, on the other hand, are merely tickled. And there are a LOT more demons (and relatives) in Ularn than in Larn.
(see http://www.cordier.com/ularn/ (http://www.cordier.com/ularn/))
This helps to get rid of all the other annoyances in the deeper levels, but keeps the challenge.. This is appealing to me, as the umber hulk or other nasties are pretty annoying when they get near.
-
also remember, larn was an beginner game with a low difficulty level, it is not adom/omega/nethack etc with high difficulty.
-
Larn must have been my first roguelike ever. I don't know which version or variant that was, just that I had an Amiga 500 those times, and was amazed how much game there can be behind such simple ASCII letter. I had mostly no idea what to do, but I remember that I was pretty impressed.
It must have been fairly easy at the beginning, in Moria or Angband I remember dying way often on the early dungeon levels. Maybe it was good that I got my hands on Larn first :)
-
Another week is gone, and fortunately I've been able to make some progress:
- made the LoD deadly ;D
- improved town further: (see attached image)
- added mountain tile type
- changed dirt symbol
- changed the elevator to match the dungeon entrance
- cleaned up spellcasting:
- book get used up by reading
- spell power is increased according to spell knowledge level
- spell description can be viewed.
- it is now possible to examine a remote position
- containers can be used (taking things out and putting things in is possible
- ...and of course: fixed some nasty bugs
Proper time management seems to be so complicated that saving and loading the game looked easy compared to it. So I started with that and hope to it this week. If I manage to do so I will put out another release this weekend.
-
the new town map looks very busy, remember its a town, not a complete wild wilderness.
did you use the larn 12.4 code or are you writing it from scratch?
-
the new town map looks very busy, remember its a town, not a complete wild wilderness.
I tried to separate the dungeon entrances and the regular part of the town, hence the forest.
did you use the larn 12.4 code or are you writing it from scratch?
I used only a few lines of the original Larn 12.3 code, e.g. the level generator, but almost all of the games data, such as monsters and spells.
If you compare the code of Larn and NLarn, you will find very little similarities.
-
I'm guessing from the screen shot too you don't have random building placement either.
I'm itching to play this one
-
I will need a few more days till a new version as making the game structures saveable is such a gigantic change that almost everything is broken right now and the only thing I get when starting the game is a SIGSEGV. Thus I'll spend some days with my friend gdb.
-
ah yes. save should be built from the beginning, its very hard to add later on :)
-
Unless you are using Java and default serialization :P
then again, you will still stumble a bit :P
-
ah yes. save should be built from the beginning, its very hard to add later on :)
Not true. In fact saving is easiest to add when everything else is ready, because you don't have to adjust the save routine every time you add something.
-
ah yes. save should be built from the beginning, its very hard to add later on :)
Not true. In fact saving is easiest to add when everything else is ready, because you don't have to adjust the save routine every time you add something.
That's excactly the reason why I started to think about saving so late. On the other hand it would have been very smart to think about saving in the beginning as stu said and just implement it now. Too late!
I now keep a hash for all of the game object types and register and unregister things I create or destroy there. All of these hashes use pointers as key. Glib offers black-magic macros to hide integers in pointers, thus allow me to use unsigned integers as object ids and store them where these objects are used. When finished (20% done) saving will be a piece of cake (I keep telling me).
@Slash: Many times I cursed my decision to use C and wished I had used something that offers handy high level functionality and does not waste so much time. Too late, as well. ;D
-
@Slash: Many times I cursed my decision to use C and wished I had used something that offers handy high level functionality and does not waste so much time. Too late, as well. ;D
I write in python, and I sometimes curse myself for not having chosen a lower-level language. For various reasons. The grass is always greener on the other side, I guess.
As always,
Minotauros
-
ah yes. save should be built from the beginning, its very hard to add later on :)
Not true. In fact saving is easiest to add when everything else is ready, because you don't have to adjust the save routine every time you add something.
I disagree... you'll have better times if you design your saving routine (and rules) carefully early in the project. A nicely designed saving routine won't be affected by big "adjustments"
-
the new town map looks very busy, remember its a town, not a complete wild wilderness.
What is the difference in a fantasy-world with a tiny town such as this one? :-) For some reason, towns in original roguelikes looks like they have been paved with concrete..pretty dull and uninspiring.
I love how your town-map looks! It looks..alive!
-
I write in python, and I sometimes curse myself for not having chosen a lower-level language. For various reasons. The grass is always greener on the other side, I guess.
That being said, I just got around to implementing saving and restoring, which I was really loath to do, thinking it would cause all kinds of problems. But it was done in a few minutes: I scimmed some documentation, added a few lines of code and cleaned up a class property, that was obsolete anyway. Hacking together the interface to save/load turned out to be more work than the actual serialization. So today I feel that the grass is pretty green right here where I'm at.
As always,
Minotauros
Edit: Using Python's pickle module, of course.
-
I think another benefit of high level languages is that you usually can access libraries. So you can always code something in C, compile a library from that and use it in your project.
So you can have the greener grass from both sides of the fence :)
-
I found a pretty nice library for JSON file handling and have already successfully implemented saving with this. The resulting file was ~800kb large, so I implemented to compress it with zlib, another brilliant library.
As soon I find time I will implement restoring the save file.
JSON (http://www.json.org/) is actually a pretty cool and very useful file format. Bindings exists for every language under the sun and it can be edited with any text editor.
-
A little progress report: restoring saved games is finished.
Unfortunately I broke some things which have to repaired - this happens all the time. Next time I will use an object oriented language to hide all the object's attributes.
When I'm finished there will be another release.
Edit: Ok, that was easy. The release is there (http://nlarn.sourceforge.net/articles/7/released-05)!
I would really like to hear from you about any bug. I dont like bugs, but I can't find them all alone. So please if you find any annoyance, post it here. I'll be glad to take care of it.
-
I'm currently working on cleaning all the bug I know of from the current version and release a fixed version pretty soon.
If anyone is interested in playing NLarn on an Apple - no problem. A friend was able to build NLarn on MacOS X!
See building NLarn on MacOS X (http://sourceforge.net/apps/trac/nlarn/wiki/NLarnBuilding) to learn how to do so.