Efendi and Sigma
Posted 08.02.10 at 07:41 AM UTC
Tagged programming | # | Comment [3]

I'm very happy with Efendi. I have a little file locking bug in my sqlite database that occasionally hiccups, but generally it's stable and there's nothing I would add. Well, for the sake of completeness there is actually no comment editing facility once the comment is approved, but for me that's not important.

Sigma is really going nicely. I am eager to get it on my system sometime soon. My job will be to jump in after Meta finishes the combat core. I have learned a lot more about Python, and I know some design patterns that will straighten out mistakes I made years ago. We'll get the codebase nice and tidy and start looking at the last few big things to do.

Unless you've dabbled in what I might call stateless scenarios, a lot of this thinking is very peculiar. When I say stateless I mean: there is no way to "pause" a MUD, because it's a world rather than a game. If one player wants to stop, what about everyone else?

A good example of the illogicality of the big blockages is shopkeeping. If you think about going to the store in Secret of Mana or Final Fantasy, you probably expect a tunnel-vision scenario: the shopkeeper engages you, you say what you want, you pay, sell something, and get out. Seems like a small thing.

Again, you might have three people in the room in a MUD scenario, and getting that individual attention becomes either difficult to implement or could even cause a break in the "reality" of the world.

Also, if somebody comes in and attacks you, you had better be able to know. How do I manage that state? Are you in state SHOPPING, and a certain list of actions bring you back to state PLAYING? But you don't get any world action updates until then? That's hardly realistic or reasonable. Screwing with player state (meaning, effectively pulling a player's perception or even existence out of the world for some reason), is frowned upon because it takes away the activeness of the surroundings. You're back in Zelda, where everybody only ever talks to you.

But how do you manage a shopping scenario where people are entering and exiting the room while you're looking at the product list? How do you define who a shopkeeper is in a game, and can a human player become one?

The fact is, it's probably best to have a 'shop' command, which can take the name of a character to be specific when we have multiple shop keepers. This prints out a product list and a 'buy' or 'sell' command completes the transaction. If you don't like scrolly text, set a notification threshold to ignore player movements and conversations for a while.

I think a 'vend' command is nice, where you put a tag on items that are currently being sold by a character. This allows individuals to become shopkeepers.

Then, you have to think architecture: I think it's best to have shopkeeper be a 'persona' where a character automatically puts a 'vend' tag on any item added to his inventory. This ties up a lot of loose ends in one swipe, as a sold item would be automatically tagged as it entered the inventory of the purchasing shopkeeper. Another option would be to have a kind of special case somewhere:

if character == shopkeeper then ...

Sigma has always been about putting a system around things to make sure good logic can be good logic throughout the game. For me, it's almost always better for an automated action to simulate a typed command:

character.queue('go west')

rather than use some library command:

move_character_between_rooms(character, room1, room2)

The result is the same, but let the command interpreter figure out what to do about moving a character. Because as the game gets more complex, moving a character becomes a highly controlled activity: checks to make sure the player is not asleep while trying to move, not fighting (or if allowed, that needs to be an attempt to run away), not dead, not logging in, and if there are followers the followers need to be moved as well. You tear the game asunder if you start calling brute-force backend functions to do these tasks.

Circle, the old premade engine we used in high school, didn't have this rich of a backend interface. I struggled to make things work because I overlooked necessary checks when extending the system.

Once You mod_wsgi You'll Never Go Back
Posted 11.19.09 at 11:05 PM UTC
Tagged programming | # | Comment [0]

PHP is quite a language. I'm glad I know it and know how to use it, but in all but the basic shared hosting scenario there are certainly better options.

A Nice Little Python Story
Posted 06.16.09 at 06:36 AM UTC
Tagged efendi, programming, python | # | Comment [1]

I talk quite a bit about Python recently, partly because it's the only language I'm actively using right now aside from VBA. I was doing a little gedankening (it's a gerund now!) this morning about folding RSS feeds into the main content stream of Efendi.

Typically, if you are throwing around what just instinctively feels like a classical computer science problem, you need to start just absently paging through Python documentation looking for an official solution to your problem.

It seems a little esoteric at first, but my problem is a fairly classical one when broken down:

• We have an ordered list of blog entries, sorted by date
• There are zero or more other lists, not necessarily in date order, involving things like Picasa pictures, Google Code commits, Cluster updates, etc.
• We slice the primary ordered list to show, say, the fourth set of 10 items (this would be page four on the blog if there were ten nodes per page)
• We want to fold in (my word picture on "fold" is like putting the whipped cream into key lime pie filling, umm umm, don't think about that in the morning when in a Central Asian country!) any entries which fall in between (or immediately above) the entries in the sliced list

Let's substitute numbers for dates to make things easier to read, and I'll depict it below:

Main list:

30 - Cookies
42 - Brownies
45 - Key Lime Pie
49 - Lokum
52 - Jello
58 - Fruit Salad
60 - Baklava
75 - Carrot Cake
88 - Chocolate Cake
92 - Ice Cream

Let's take the second slice of four:

52 - Jello
58 - Fruit Salad
60 - Baklava
75 - Carrot Cake

If we were folding RSS entries into this list, we would only want "dates" between 50 and 75. A date of 49 would be above Lokum on the first page, and a date of 76 would be above Chocolate Cake on the third page.

Anyway, I now need some efficient way to do this slicing.

Enter bisect, a nice little module tucked away in the mathy part of the Python library docs. Its function is to calculate where a certain item should be inserted into a sorted list to retain sorting order. Sounds like the solution.

But, we're dealing with RSS feed items, not raw numbers. This module will have to compare things, so what to do?

In C++, you might have a remote shot of using operator overloading.

In Python, just monkey patch the RSS library. What? Monkey patching means overwriting or adding functionality atop an existing library. So, Python tells you to implement a class function called __cmp__() to override or add comparison functionality. You just have __cmp__ look at the dates of the posts to derive the comparison.

For non-programmers, it is probably hard to see the appeal of such flexibility. In fact, it might be expected that there has been this kind of flexibility in programming for a long time. This is not the case.

In C, you get errors or warnings trying to convert figures from decimals to whole numbers. And there is a compiler switch called pedantic to make it even worse.

Python is freeing, as is Ruby, and also JavaScript (which is much better to write when there's a toolkit like jQuery to help with browser compatibility). It says "if it can work it will work," which is much different than getting your knuckles wrapped for initiating an implicit forced coersion on type int, or something like that.

It's Exciting
Posted 06.08.09 at 09:37 AM UTC
Tagged efendi, programming | # | Comment [0]

I am having trouble looking at my live install of Efendi 0.1.1 right now, because the working progress toward 0.1.2 looks so darn good. In addition to some big-time code cleanup, we now have a full-blown templating system and live tag suggestions as you type. The site template can also be uploaded or updated online now, with no filesystem access. The admin site also finally notifies you upon success (since response time is so fast it's quite hard to tell sometimes without this).

I have conceptually redesigned the "commissions" system (inviting guest authors to post an entry). There will only be one open commission at a time (at most), which really streamlines the way everything will work on the back end. It's a small price to pay to get what is a valuable but probably lightly used feature implemented with low overhead.

E-mail announcements are kind of fish in a barrel at this point, meaning I can focus my last-push energies primarily on feed management and display, which was the point of this project in the first place. It's going to be lovely.

I am really amazed with the speed (when I'm not at work, of course). I was afraid Python might be a bit high-overhead, but clearly it's beating the socks off TxP. I'm considering turning on template caching and see how much more I can squeeze out of the engine.

What's next? Comment moderation will probably be the 0.1.2 landmark. Then comes the grunt work around feeds, commissions, and e-mail announcements.