clean code

[Leaf]

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

I don't remember exactly.  It took some experimentation.

I started out trying to avoid partitioning the world into areas, and used a global lock on the whole object tree.  Events fired out of a thread pool.  This was of course only marginally better than using a single thread.

Then I tried putting a lock on each object and doing some spin-release-wait locking to acquire locks on objects before the guts of the events ran.  This worked ok-ish, as long as you knew what objects you needed to access beforehand.  If you found that you needed to access another object half-way through processing, you had to add it to the lock list, roll everything back, unlock, spin through all the locks again, and reprocess (rather like backing out of a database transaction).  But it was hideously complicated to write properties for.

That led to the investigation of software transactional memories, but it turned out that none of them that I examined at the time were really of production quality.  The fast ones were really buggy, and the robust ones were really slow.

Somewhere in there I tried to write it on JPA/tomcat, and then GAE, but both of those were too slow.  GAE would have been good enough it they supported persistent TCP connections or http streaming or something at the time, but they didn't (the slowness there was due to HTTP polling; their memcache backed by bigtable makes for lightning fast persistence as long as you're not too write-heavy).  JPA was /horridly/ slow with many-many relationships being mapped to POJOs.  It works pretty good if you avoid many-many relations, but otherwise it brings even the fastest DB to an ignoble grinding halt.

After that, I settled on having to partition the world into areas with the realm model, which I didn't want to do, because it doesn't scale as well, but....  Oh well.  I think it took 3 or 4 days to get that model relatively bug-free with the compositional object model and some basic dungeon geography properties and a stat-less @ wandering through halls of #s, but there was a lot of bits of code to be reused from before so it wasn't /all/ from scratch.  It helped that I was using all the maps from Daniel Lawrence's DND for test areas, so that made for a quick relatively large dataset to test with without having to mess with writing random generation stuff.

I think it also helped that I was unemployed and very very bored at the time.

[tuturto]

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).

[yam655]

I want to point out that the data-driven approach (human-editable files with property definitions) and the object-driven approach (implementations and interfaces) need not be entirely different worlds.

The data-driven approach is great for massive numbers of nearly identical things.

For uniques, though? The Angband stuff has an explicit set of "unique" properties they set on the unique stuff. You end up dividing your logic between undescriptive data and custom logic elsewhere.

It makes more sense to have a combined approach. A system where the common stuff is super easy to make, but the unique stuff is super easy to maintain.

It shouldn't be particularly hard. You start with an Object system and the first object you make is the generic/common thing used by the data-driven objects.

The problem is that if you want deep interactions between objects (like, say, Nethack) you can easily end up tightly binding objects to each other. When objects are bound to each other, you end up dealing with an object system in which is complex to extend and requires non-obvious edits to fully add new subtypes -- no matter how you originally planned to design your object system.

This leads to many Roguelikes having elegant objects systems which actually prevent deep levels of object-object interaction. The simplest example of object-object interaction I can present would have to be dipping things in to potions in Nethack. You're dealing with an action with two different objects and an effect which is frequently similar -- but different than -- the standard player/monster potion effect. Depending on what is dipped (both the type of item and the existing intrinsic attributes it possesses) different results occur.

It's hard to write such interactions cleanly. It's even harder to have such a system be both clean and generic.

But... To me, the depth of interactions was part of the initial draw to Roguelikes. I don't care about the cleanliness of the code, I just care that the game is awesome.