Saturday, August 9, 2014

Politics website idea

I have an idea for a politics-related website. It simplifies the issue of special interests in to one of trust.

Citizens rate special interests in order of trust.
Special interests have opinions on issues. They can either support, oppose or have no opinion on issues.

Issues are defined as legislation or concrete potential legislation. Abstract issues are off the table.

Ideally, the special interests should have web pages specifically targeting legislation, so their opinion on it is clear and well articulated. The site would only support a link to the organization's page on the issue.

Citizens can see the issues they support by proxy, but do not directly have opinions on issues. They can also see how politicians favor their special interests.

Politicians can see the overall trust for special interests and know when they're taking money from a group that's out of favor with their constituency.

A citizen's opinion on an issue is provided for them by their special interests, walking the list of special interests from the most-trusted to the least-trusted until one of them has an opinion on the issue. This proxied opinion on issues is also related to politicians.

It is basically a simplification of the petition-modal. If I support organization A, the only reason I wouldn't sign a petition they send me is because it conflicts with organization B that I favor over them.

Sunday, April 6, 2014

thoughts on a music feed aggregator

I've been toying with some ideas on music aggregation.

The problem: I don't listen to music I can't share with my children without fear of violating copyright. This means I listen to a lot of CC licensed music, a lot of music contest websites, and a lot of very independent one-person bands.

I've been thinking that the music aggregator should support distributed operation, so in addition to consuming media feeds that others produce, it must be able to consume its own output.

With that, a lot of normal product assumptions regarding music consumption are destroyed.

Use-Case: When downloading tracks from a contest website some/all of the metadata embedded in the tracks may be less valid than either the metadata from the feed it is found in or the metadata available in the HTML page it is sourced from.

Use-Case: Artist uploads track for contest and uses same track for their album. The music data is the same, but the metadata is changed.

Use-Case: Artist evolves their name over time without having any clear breaks. (Example: "ADD Music" becomes "ADD" later on.)

Use-Case: Artist uploads the track and changes the name of the album before it is finished and officially released.

I've been looking at playlist formats as the basis the information exchange format. A lot of them are light on the metadata.

Something like the format used by MusicBrainz might seem ideal. It's a self-contained format dedicated to distributing music metadata... the problem, however, is that every entity (be it artist, album, track, etc) has a GUID assigned by MusicBrainz. Moreover, while MusicBrainz reliably gets finished releases (even electronic ones via BandCamp), they don't seem particularly designed for demos and ad hoc music contests... so it becomes a format that should be supported in the future, but not one suitable for the primary interchange format. (Though there do appear to be Python bindings.)

Use-Case: Artist picked a well-established name, not realizing it was already taken. The two bands/artists have the same name, but are wildly different.

Use-Case: There are a lot of duplicated album names with different Album Artists. (The simple "Compilation Flag" of iTunes breaks.) This can be done on purpose as an homage to another artist, or an accident.

Use-Case: The fantastic Song Fight! contest uses the same song title for all contributed songs in the current contest. Anything expecting a song title alone to be meaningful is broken.

I had previously seen the page mentioning Playlists on Wikipedia. It was revisiting this that I saw references to SMIL.

I also ran across a comparison of various playlist formats. The context of this data was specifically remote playlists, so it was the sort of thing I was looking for, but old data. It was missing XSPF. It covered the idea of using a metadata-heavy markup and hijacking it for playlist purposes. I'll get back to that.

It (and links related to it) indicated that SMIL was once considered an attractive format for remote playlists. While tracking down a lead from SMIL research, I found the Playr bookmarklets and references to the service previously supporting SMIL. At this point, I found that perhaps SMIL isn't really a favorite any longer. XSPF, however, is available directly, and is used by the (open-source) Flash player.

Regarding SMIL, the possibilities for doing karaoke with SMIL look really nice. In fact, integrating a video with a presentation sort of thing looks straight-forward. I did a little investigation, and while complete support for SMIL is somewhat rare, there appear to be a ton of applications that support DAISY Talking Books, which is a subset of SMIL. To that end, I've installed Obi, an application to easily create them. (A good test-case for this is Josh Woodard's music, as he makes vocal, instrumental, and lyrics available for all his stuff.) Not a high priority, but it periodically comes up.

The idea of the metadata-heavy markup, led to the Dublin Core Metadata Initiative, the Music Ontology (and Omras2), OWL, and LinkedDataTools. Bonus: Since I'm all about CC licensed music, the license can be encoded in the documents using CC REL.

Of course, I reminded myself why RSS stinks and why Atom 1.0 is the way to go, syndication-wise. I looked at django-planet as a source of ideas for how to get started.

That's basically my brain-dump for now.

Monday, August 27, 2012

Asynchronous Roguelike idea


I was on a Roguelike forum and the topic turned to multiplayer games and whether they would be possible for a Roguelike. I posited that it was possible, and that you would want to retain the turn-based structure as much as possible. (While others talked about real-time games which are, in my opinion, not like Roguelike games at all.)

Anyway, during the discussion, I described an interaction mechanic that would scale out to asynchronous multiplayer while having turn-based combat. (I describe it in my second section below.)

More importantly, it's a mechanic that's testable in a small single-person game -- fit for a 7DRL.

[question about multiplayer roguelike and some initial discussion]

Personally, when I think "multiplayer roguelike" I don't think of an MMO. (Probably because I hate MMOs.)

My first thought is multiplayer like Civalization. It's turn-based. While each unit has few choices, each player controls a lot of units at the end.

So: a small group of friends play together.

Now consider: there is no actual requirement to keep the turns in sync across all players except when they're within line-of-sight. If I can't see you the difference of you going one turn or 10 to my one turn is meaningless.

So, when players are within line-of-sight, they need to wait for the other players to finish their turns. Talking to each other is still a free action, of course.

Next, more squelching of boring things.

If the group is moving as a unit, one player is given control and everybody moves as a single unit until enemies are encountered. This is simply squelching manual follow commands.

If a player is on auto-explore, their next command is handled automatically by the system so there is zero delay. If every one in the party is on auto-explore together, they should fan out, explore the map, then converge on the first monster found. (Given that talking is free and the first thing a person in their party would do is say, "Hey, there's something I need help with over here!")

So, yeah... the only time you should be waiting for other players is when you're near each other and monsters are around -- or you're near each other and playing non-cooperatively.

Then again, I see multiplayer as an extension of single-player multiple-character. We see those sorts of games in RPGs all the time, but they're rare with roguelikes.


[someone commented that it ruined causality]


It only ruins causality if you assume that one turn for player 1 is the same amount of game-time as player 2.

I'm saying that implication is flawed. One turn for me is not the same as one turn for you. Turns != Time.

If I'm not in the room with the other player, they could be in the middle of a Rest 1000 cycle. My character could be in the middle of a Rest 1000 cycle. It shouldn't matter.

Of course, it couldn't just be line-of-sight of other players, it needs to be line-of-sight of players or monsters that can see said player.

What it does do is ruin the possibility of having any concept of "game time" so any mechanic which relies on such a concept should really opt for something else -- like having the concept of time be tied to average player level.

Anyone who thinks you can't do real small-scale turn-based multiplayer has clearly never played Civilization with human opponents. Get yourself a copy of Freeciv (Mac, Linux, Windows) find yourself some friends and give it a go. By default it's true turn-based and if someone goes for tea, you're stuck waiting. (Though current versions of FreeCiv support 126 concurrent players, that is clearly overkill.)

With Civilization each player makes decisions at the same time. If you finish your turns at the same time there is no waiting for the other player. This approach should work for a Roguelike.

However, it's better if you only need to do this with the line-of-sight limitation I originally mentioned. If I'm playing with someone and that person needs to rest for 200 turns to heal and restore mana, I don't want to be on my own for that time. It's better if I just leave the room and when they come out they're all rested. (Though this has so many repercussions that I think the "rest to recover" logic needs dropped.)

As far as NPCs -- both friend and foe -- there would be two types: those that are only awake when in line-of-sight of players, and those that are like the players and can mysteriously know where the player is at and suddenly be within line-of-sight.

Being turn-based (even the variant where players do not take turns) should give you very much the same feel as a traditional Roguelike.

Being line-of-sight+turn-based would be a different sort of game. It requires a different concept of time.

The thing is... it's testable within the confines of a 7DRL. Not even multiplayer, as a simple single-player game. It breaks the simple "player goes" / "computer goes" logic that frequently drives simple Roguelikes. Will it feel all that different, though?

More importantly, will it feel more or less like a Roguelike when compared with a real-time game?

Sunday, August 26, 2012

Blacken Java Library update

So, when I put Blacken to the side, I had posted code, but I was unhappy with it and I was feeling pretty down with the whole thing overall.

Not so anymore. I ran across someone speaking relatively highly about it. It encouraged me to fix it. I have someone developing it with me now. I have other people writing games using it.

Next month we release Blacken 1.1. It stomps all over the 1.0 release.

I'm planning to start writing an in-depth "Developing a Roguelike Game with Blacken" tutorial after the release.

(I'm putting aside NaNoWriMo this year to work on it. I've loved NaNoWriMo, but I need to finish the first pass of big edits to my first book and... well, so far it hasn't happened. I am committed that my next NaNoWriMo related task will be to replan and rewrite my first book. It'll be mostly a rewrite, but the bones are good. I'll be keeping the good things.)

So, yeah... major changes in priorities, but these things happen periodically. As they say, "Life is change."

This actually marks the second year with a Blacken release, as I released it to the community about a year ago next month. I actually expect 2012 to see a second release, as well, as I'm planning 1.2 to be a release to fix the nits that crop up while writing the tutorial.

Monday, December 19, 2011

An example of Java being broken-by-design

Java complaint: java.sql.Timestamp is based upon java.util.Date, so you can pass it to functions expecting a java.util.Date. The difference is that java.util.Date specifies time is millisecond-precise and java.sql.Timestamp specifies time is nanosecond-precise. They can both be assigned a value using using a millisecond-accurate function with the same name. However, if you compare a Date and a Timestamp initialized to the same millisecond-accurate time, they are never equal.

This means that while there is fancy object-oriented code-reuse arm-waving, if you actually try to use these classes in a generic manner things fail mysteriously. This is fundamental breakage in the design. First they "enforce type-safety" then if you actually rely upon type-safey you get bit in the ass.

This is documented (from http://docs.oracle.com/javase/7/docs/api/java/sql/Timestamp.html):
Due to the differences between the Timestamp class and the java.util.Date class mentioned above, it is recommended that code not view Timestamp values generically as an instance of java.util.Date. The inheritance relationship between Timestamp and java.util.Date really denotes implementation inheritance, and not type inheritance.
This gets me in a lather. Clearly being a child of java.util.Date means nothing.

What they should have done was have a Date-like interface specifying the getTime()/setTime(long) functions and defined that they accepted time in milliseconds and their epoch. Then we could use any getTime()/setTime() related function the same without caring about the advanced features it possessed.

As it is there are too many different ways to specify dates and they're all incompatible. It's almost easier to pass time around in milliseconds and convert to the desired type as-needed.

Sunday, November 27, 2011

Roguelike development deferred

For now all my roguelike projects are officially deferred for the indefinite future.

The Blacken Java library is on code.google.com. It is currently usable, and I may use it on a 7DRL at some point. There are no immediate plans for a full-scale roguelike.

The Python STEW Roguelike library ran in to trouble with the desire to go to Python 3. It also suffered from repeated redesigns. The dependency on full Unicode support -- while required for my goals -- further complicated things. Add to this many of my goals for it are now met with LibTCOD, and it just isn't high-priority.

The joy I get out of talking about writing projects is just as great as the joy I got out of talking about Roguelikes or my other projects when I managed to talk to someone who "got" it. More than this, the chance of an average person "getting" what I am talking about is so much higher that it is suddenly a joy to talk to complete strangers about my passion projects.

This site will remain the location for my random tech notes. The primary audience here has always only been me.

Friday, November 25, 2011

New writing blog

My writing/fiction work officially has a blog of its own.

S. W. Black, a blog named after my (current) fiction writing moniker.