Messages

226

Programming / Re: Importance of persistence

« on: August 31, 2012, 04:36:48 PM »

I think what I'm feeling here is that SOME persistence is a good idea at least on the floor the player is exploring.

I wouldn't worry about persistence of other levels. Within one level it would be really nice if the items would be staying where you dropped them. But would it be possible to prohibit players from dropping items like suggested earlier? They could only pick up items, and every time they pick up a new weapon for example, it replaces the old one. Player could only have one of each type of item and managing them would be part of the challenge?

Keep us posted about your progress. This is fascinating project and I would like to see how it develops. Are you programming it on a genuine Atari or on an emulator?

227

Programming / Re: Debugging and other helpful things

« on: August 25, 2012, 07:21:45 AM »

Returning to an old thread..

I have been playing around with some tools and libraries again and found two that I like.

First is behave, small tool/library for behaviour driven development. It allows me to write tests with almost natural language that is much easier for non-programmers to read. Below is two simple tests/specifications:

Code: [Select]

Feature: Combat
  as an character
  in order to kill enemies
  I want to damage my enemies

  Scenario: hit in unarmed combat
     Given Pete is Adventurer
       And Uglak is Goblin
       And Uglak is standing in room
       And Pete is standing next to Uglak     
      When Uglak hits Pete
      Then Pete should have less hitpoints

  Scenario: hit in melee combat
     Given Pete is Adventurer
       And Uglak is Goblin
       And Uglak wields dagger
       And Uglak is standing in room
       And Pete is standing next to Uglak     
      When Uglak hits Pete
      Then Pete should have less hitpoints

Output:

Code: [Select]

1 features passed, 0 failed, 0 skipped
2 scenarios passed, 0 failed, 0 skipped
13 steps passed, 0 failed, 0 skipped, 0 undefined
Took 0m0.0s

If I were to work with something more complex than roguelike and had a team of programmers and non-programmers, this could be really useful tool. Now it's fun tool to play around and experiment.

Another one I tried briefly is quickcheck. It allows me to wrap test functions and feed random test data into them:

Code: [Select]

    @forall(tries = 5,
            loc_x = integers(low = 1, high = 19),
            loc_y = integers(low = 1, high = 19))
    def test_dropped_item_added_to_correct_location(self, loc_x, loc_y):
        """
        Test that dropped item is added to correct location
        """
        self.character.location = (loc_x, loc_y)
        self.item.level = None
        self.item.location = (0, 0)
        self.character.inventory = [self.item]

        self.character.drop_item(self.item,
                                 self.action_factory)

        assert_that(self.item.location,
                    is_(equal_to(self.character.location)))

Nose (test framework I'm using) detects that function automatically based on its name and executes it. It doesn't know however, that it has been wrapped with @forall decorator that causes the test to be run 5 times, with random data for loc_x and loc_y parameters. This can be useful if you suspect that the function might be working differently with different parameters. Because of the way quickcheck is written, it can even made to generate random complex objects for testing purposes.

228

Programming / Re: clean code

« on: August 24, 2012, 08:09:07 AM »

That sounds big and very enterprisey, must have been really good coding exercise too actually. Doing something like that probably teaches your a thing or two along the way.

Trying out things and changing them when it doesn't work / doesn't look good is one approach to clean code. Of course usually the larger and older software system grows, the harder it is to make big changes on it. Currently I'm rethinking my user interface and map implementations. I took shortest path with the map and just created an array of integers, where each integer represents picture that gets drawn there. Add two layers (one for floor and one for walls) and you can know where you can walk and where not. After switching to PyQt, it would be nicer to be able to treat everything that gets drawn on screen in the same way, so maybe I'll switch representing the map with more complex objects after all.

I was going through some code today that I haven't touched in a bit and started wondering how many roguelike developers are running static analysis for their code (like lint) or otherwise analysing it? And if they think it's worth doing?

I have been running pylint for the longest time and occasionally check statement coverage of my tests (but don't really track it, it's just an interesting number to see).

229

Traditional Roguelikes (Turn Based) / Re: Herculeum released - 0.5

« on: August 24, 2012, 05:30:33 AM »

Title: Herculeum
Summary: Simple Rogue clone written in Python.
Version: 0.5
Released: 2012-08-24
Site: https://github.com/tuturto/pyherc
Online manual: http://tuturto.github.com/pyherc/index.html
Direct download: https://github.com/downloads/tuturto/pyherc/pyherc-0.5.zip

New features that are readily visible to players:

* User interface rewrite with PyQt
* 16 inventory window (https://github.com/tuturto/pyherc/issues/16)
* Message is shown for missed attack
* Message is shown for dying monster
* Message is shown for picked up item
* Message is shown for dropped item
* Player character can be given a name

Following new features are more technical in nature and not visible during gameplay:

* _at function added to Cutesy
* is_dead matcher added
* other components can register to receive updates from domain objects
* pyherc.rules.items.drop replaced with DropAction

Fixed bugs

* 17 Taking stairs do not update display correctly (https://github.com/tuturto/pyherc/issues/17)

Other notes

* Services are no longer injected to domain objects
* pyherc.rules.effects moved to pyherc.data.effects
* EffectsCollection moved to pyherc.data.effects
* qc added for testing
* poisoning and dying from poison tests moved to BDD side
* is_at and is_not_at changed to is_in and is_not_in
* herculeum.gui.core removed
* PGU and pygame removed as dependencies

I'm currently having some troubles generating statement coverage reports from tests (http://tuturto.github.com/pyherc/cover/index.html). If you spot something funny there, please let me know.

230

Programming / Re: SVG fonts

« on: August 21, 2012, 08:38:53 AM »

I have looked at them very briefly, but not used yet. I'm kinda on the edge to port my roguelike to use svg only, instead of having bitmaps. Might be fun and interesting exercise to get the whole thing running resolution independent.

What are you planning to do with the svg fonts?

231

Programming / Re: clean code

« on: August 21, 2012, 08:31:14 AM »

While we're talking about clean code, Gamasutra ran an article In-depth: Cleaning bad code. Nothing reaslly ground breaking I guess, but still interesting to read. Frykholm has very opionated way of writing, which is good for starting discussions.

232

Programming / Re: clean code

« on: August 21, 2012, 07:25:18 AM »

Wow, that's a wall of text with loads of good information. Took while to read and digest it properly too.

Well, anything that is highly distributable and concurrent is bound to be more complex than single user application running in a single thread.

The use of properties is really nifty way of doing things. Like you said, adding new features on the existing system is easier that way, than when everything is in a huge blob of code. Writing the whole realm system must have been fun too.

How long did it take to get initial version up and running?

233

Programming / Re: clean code

« on: August 18, 2012, 07:10:50 AM »

I'm interested on the object model (characters, items, rooms and such) and how you get them working together (characters walking around and fighting with each other).

Thinking from point of view of other person using your engine is good. They probably don't have the same knowledge as the person who wrote it after all. That's an interesting question actually, how much of bad code should the engine tolerate? With languages that are compiled to create an executable, you can at least lean on the compiler to tell you if you're doing something really stupid. With interpreted languages first sign of error is often runtime crash.

There's this short poem that gets shipped with standard python implementation.  Currently I like especially the two lines about explaining the implementation.

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

234

Programming / Re: clean code

« on: August 17, 2012, 04:57:16 AM »

Good stuff indeed. Treating player character in a same way as all the other character (be they monsters or other players in multiplayer), also makes things much simpler and cleaner.

I'm a fan of iterative development. Usually I aim to write best what I can at any given time, but don't worry about future too much. Like I haven't really given any thought on ranged combat yet, because there's so much other things to work with first. But when I get there, I try to make that as good and clean as possible. This of course means that I have to change existing code sometimes to make the new design as good as possible at that given time.

Keeping steps small seems to help with motivation for me. I get something new relatively fast and if feature I chose turns out to be bad idea, I can just discard it without losing too much time and effort.

Do you happen to have any source code available Leaf that I could have a look at?

235

Programming / Re: clean code

« on: August 16, 2012, 05:30:22 PM »

That sounds pretty good and flexible. Different kinds of game objects would be easy to construct and they would follow same rules. Definitely a good approach I would think.

That's half of the solution, you still need a game engine that is clean and easy to maintain.

236

Other Announcements / Re: Project: Roguelike Renaissance

« on: August 16, 2012, 06:57:04 AM »

Sorry to hear that. I wish all the best to you and your family. Hopefully you can return back to renaissance project after sorting out the real life issues.

237

Other Announcements / Re: Project: Roguelike Renaissance

« on: August 15, 2012, 01:45:19 PM »

getter77, how is the roguelike renaissance progressing, very well I hope? Anything interesting going on that you could share with the board?

238

Programming / Re: clean code

« on: August 15, 2012, 12:44:49 PM »

I think the cleanest way to implement a game like this would be to use an OO language to build an engine with an event-driven paradigm around various interfaces.  Perhaps with some sort of compositional object model to get rid of the boilerplating problem.

That is quite high level, could you elaborate it a bit?

On another note, I have been reading through Trystan's blog and he seems to have good ideas about developing roguelikes (and software in general). Maybe I'll get code for his roguelike tutorial later today and have a look at there too.

239

Programming / Re: clean code

« on: August 13, 2012, 12:29:14 PM »

It's been interesting to read loads and loads of source code written by others.

I came across blog of Trystan and he seems to be quite tidy code. I only found two 7DRLs by him though. Would anyone happen to know if he has written more of them or even a full blown roguelike?

240

Programming / Re: clean code

« on: August 10, 2012, 03:20:42 PM »

Yes, that is somewhat more what I'm after. Would still push stunning to be an entity of its own (either class or function). Poisoning and stunning are just status effects after all that have slightly different behaviour, so it might make sense to model them like that.

Maybe I should try some java-based games, since it's object oriented language. Might have more luck there than with pure C.