7DRL 2014 – Day 7: In which everything is complete

March 15, 2014 by

Trinkets – the roguelike game I’ve spent the past week creating for the 7DRL competition – is finished, about 20 hours before the deadline! It’s a game about wandering an extra dimensional vault, acquiring trinkets and trying to get back home.

A build for mac is available here. Unfortunately, there’s no windows/linux build, but if you’re on one of those operating systems and want to play, the source is available here.

Screen Shot 2014-03-15 at 2.38.31 PM

… which turns out to be entirely justified.

My high score is 59 – can you beat it? If so, let me know in the comments below!

7DRL 2014 – Day 6: In which victory approaches at high velocity

March 14, 2014 by

One day remains, and I’m actually almost done. It would be nice to redo the map generator, and game balance can always be tweaked some more, but the plot and endgame are implemented, the boss-fights are done with basic AI, and there’s even a score feature. Shown below is the second of four boss fights:

You have a bad feeling about this level...

You have a bad feeling about this level…

… which turns out to be entirely justified.

… which turns out to be entirely justified.

7DRL 2014 – Day 5: In which parkour is performed in fancy shoes

March 13, 2014 by

Today was very productive; I finished the procedural generation of trinkets (for now, at least), improved the magic system, procedurally generated strangely worded descriptions of said trinkets, added new effects including knock-back and circular slide, and added all of the non-boss enemies, including the Abberant visible below:


Parkour shoes acquired!

Shown above is the non-procedurally-generated description of one of the coolest shoe types in the game (thus far, at least). These shoes allow you to run along walls, moving faster than enemies or even jumping over them.

I still have two more days left to go, and quite a bit still to do, including:

  • Plot
  • Victory conditions
  • Boss fights + Boss AI
  • Game balance
  • Prettier maps

I think Craig is right on track with his wearables & Apple

March 13, 2014 by

I think Craig Hockenberry @chockenberry is right on track with his Wearing Apple post.

I’ve been thinking and talking about a “personal secure network” among a collection of devices you are wearing or carrying for a while now and it seems like a no-brainer to me.  Seems totally silly to put all the battery, radios, antennas, storage and whatnot in a single device (google glass for example).

You need less battery in what I call the ‘motes’ if the LTE/WiFi radios and antennas are in the ‘core’ (“hub” in Craig’s post). What are ‘motes’ ? Think rings, earrings, necklace, bracelet, phone in pocket, flexible battery in belt, piezo generator in shoes, motion generator in umbrella/walking stick, bluetooth earpiece, display in glasses and/or contacts, high performance computing cube in our backpack, and sure, even a watch 🙂

What’s the problem with this vision? Lots really 🙂  Charging all these devices will be a pain.  Clearly you need something like a flat pad you set ‘motes’ on while you sleep and they charge inductively.  Better yet would be if they had small energy harvester chips with fractal antennas that harvested ambient energy (microwaves, cellular signals, AM, FM, etc) to extend their battery life.  Oh, yah, better batteries would be a big win and this may not get cool until that happens.

Want to get even more “out there?” Check this out:  Sugar-powered biobattery has 10 times the energy storage of lithium.  Pretty cool but one of the implications of this might be devices that could be powered from our body’s internal processes directly.  So to charge your devices you just eat more.  Be a boon for obesity.  Need to lose weight? Play more flappy birds!  😛

This then lets us surgically implant devices so you don’t have to worry about forgetting it at home.  You may think I’m being silly, but the convenience will win people over.  Also, note the long-time existence and surgical implantation of pacemakers & defibrillators.  Then look at how common tattoos and body piercing are in youth today (in parts of the USA anyway).  We are not that far from this.

Ok Geek’s hungry so leaving it at this quick “jot this down” for now.

7DRL 2014 – Days 3 and 4: In which trinkets are created

March 12, 2014 by

So, I’m about halfway through the week, but days 2-4 were all mostly occupied by other things, so the real productivity is just beginning. I’ve reworked the combat system to use the same generalized targeting/effect model as the spells. I’ve also changed trinket abilities to work on that model, divided trinkets into six types (hats, orbs, wands, cloaks, weapons, and shoes), which can be equipped and used for various nefarious purposes. I’ve started work on the procedural generation of trinkets, but there’s still a lot to do on that front, which will occupy the next day and a half, leaving me with a day and a half for enemies, plot, game balance, and a dungeon generator that isn’t stolen from the libtcod tutorial. That’s plenty of time, right?

Screen Shot 2014-03-12 at 11.36.07 PM

Weapons can now replace your bump attack with one or two spell casts. This one replaces your attack with two fire bolts, but they can also sunder defenses or daze and freeze enemies, among other things.

Screen Shot 2014-03-11 at 9.38.44 PM

Death Star? Death Star! DEATH STAR!
This is what happens when you procedurally generate names by picking two words from a list and concatenating them…


7DRL Competition 2014 – Day 2: In which the art of sorcery is practiced

March 10, 2014 by
Screenshot of Trinkets

Magic system: Activate!

There are now six spells, and status effects, and some of the ‘everything goes horribly wrong’.

The spells have all been divided into ‘targeting’ and ‘effect’ components – except for teleportation, which still consists of duct tape and hacks and probably will remain that way.

There’s also a bit more user interface than before, and the trinkets are actually worth using sometimes (even if they are all still exactly identical).

Melee combat has also been re-written to allow for spells like the Ethereal Axe, which replaces your melee attack with a high-damage Arcane attack.

Tomorrow, I’ll be working on equipment. I won’t have much time though – classes and whatnot – so there probably won’t be a blog post.

The day after, procedural trinkets, more enemies, and everything going even more horribly wrong!

7DRL Competition 2014 – Day 1: In which a roguelike is begun

March 9, 2014 by

This year I’m participating in the Seven Day Roguelike Competition, a contest to make a game in the roguelike genre in a week. (For those not familiar with it, roguelikes tend to be dungeon-crawlers with procedurally generated words, permanent character death, and often old-school graphics. There are frequently some variations from this rough description.)

I’m making a game known as ‘Trinkets’ until I think of a better name. It is a game in which a wizard strapped for cash loots a pocket dimension, and everything goes horribly wrong. It will experiment with a nontraditional power progression; you become weaker, then strong again, rather than a constant power level or steady increase. There will be a plot and randomly generated Trinkets.

My time will be somewhat limited, as I am currently a college student, but after spending most of today programming I produced the following:

Screenshot of Trinkets

Taste the power, troll scum!

I’ve used some code from some past projects, specifically most of the data structures and UI code. I’m using python, with the libtcod library.

Current features:

  • Move around…
  • …on a procedurally generated map…
  • …and hit things…
  • …which hit you back, and can kill you if you’re not careful.
  • Look for trinkets…
  • …which have magic powers…
  • …which are simply not as powerful (at least for now) as your spells.
  • Speaking of spells, you have five (and will have six), which in combination make you nearly unstoppable…
  • …at least until I implement the ‘everything goes horribly wrong’ part.

Brother® stops & refuses to print. Annoying! So I hack their TN-360 toner cartridges to get all the toner in them.

March 2, 2014 by

I purchased a Brother® MFC-7840w multifunction laser printer some years ago and I have to say that it’s one of the better modern printers I’ve owned.  Mac OS X software for it isn’t great (buggy), but it’s better than most of the others I’ve tried and the printer performs quite well.  I’ve been recommending them to anyone who’s asked me (and I get asked quite a bit).

After finishing the small starter toner cartridge they supply with the printer I put in my first TN-360 “High Yield” toner cartridge which claims 3500 pages under “normal use”.  I use this printer under what I’d consider normal conditions – mostly simple text documents.

Worked well but all of a sudden it just stopped printing with a message about the toner needed to be replaced.  “That’s odd,” I thought to myself.  “I’ve owned a lot of laser printers over the last 22+/- years and they’ve always started gradually printing more and more faintly when the toner was running out and I’ve never had a printer just refuse to print until I changed the toner cartridge before! Seems pretty heavy handed.  Then I calculated the number of pages it had printed (2120) and had an uncomfortable thought: “If they just stop and refuse to print and the printouts were looking just fine right up until that point, how do I know it’s really out of toner?”

I didn’t get my money’s worth and the forced toner replacement was feeling heavy handed and annoying.  So I wondered, “how do they decide to put up that alert anyway?”  Pulled the toner cartridge out and started examining it looking for electrical contacts (sensors inside?) or some other mechanism.  I found this:


Note the arrow.  It’s pointing to a clear plastic “window” on the right side of the toner cartridge when you’re looking at the top from the front where the handle is.  It appeared like it might give the printer an optical view into the insides of the toner cartridge. “Ah HA!” I thought.  Small piece of Gorilla tape (sticks much better than electrical tape) later and I had this:


Put it back in and time for a test…

Printer prints PERFECTLY… We are being ripped off by Brother and that really sucks.

This fixed worked for another 1001 perfect printouts and then it stopped again…

“DANG IT! The printouts were still looking *fine*!”

Take the toner out to put in the replacement and notice something on the side when you’re looking at the bottom:


There’s Another Sensor Window!  (With Gorilla tape on it in this image).  Here’s a close-up:


This piece of tape added and, sure enough, working FINE again… ARG FARG SNARG – BROTHER!  I want to like you but this is robbery!  AND it’s bad for the environment which makes it even more offensive.  Rarely do I want to call for a class action lawsuit, but this situation was definitely making me feel that way…

How many perfectly fine beautiful printouts did I get after blocking the second window?  I can’t tell you yet because it’s still going strong 200 sheets later.  :-/

So, if you want to get the full life out of your Brother TN-360 High Yield printer cartridge you may want to pick up a roll of Gorilla Tape and prepare to “fix” the cartridge.  Be careful to make sure the tape is stuck on there will because a loose piece of tape being drawn through your printer will probably do bad things to it (Follow these instructions at your own risk!).

Please add a comment if you try this with a different printer model and it works for that one also; likewise for other Brother toner cartridges. Thanks!


Note: All trademarks noted are the property of their respective trademark owners.

Simple BBEdit Text Filter that’s been useful: PrettyJSON.py

February 18, 2014 by

Dad’s been working with some JSON output from a web service lately and it comes back lacking line-feeds and indentation which is great for transmission but hard to read for humans.  Dad’s not a python programmer and Geek’s busy writing a Humanities 110 paper, but the simple python script PrettyJSON.py (below) seems to work if you put it into

~/Library/Application Support/BBEdit/Text Filters/

It can be used to beautify the front window in BBEdit if that contains JSON:

#!/usr/bin/env python
import fileinput
import json
if __name__ == "__main__":
  jsonStr = ''
  for a_line in fileinput.input():
    jsonStr = jsonStr + ' ' + a_line.strip()
  jsonObj = json.loads(jsonStr)
  print json.dumps(jsonObj, sort_keys=True, indent=2)

Because Bare Bones Software is so cool this works with their free Text Wrangler editor as well except you just put the files in

~/Library/Application Support/TextWrangler/Text Filters/

instead, as one would expect.

This gives you a new item in the “Text” -> “Apply Text Filter” sub-menu named whatever you named the file (PrettyJSON.py in my case).  Open a messy JSON file, select “Text” -> “Apply Text Filter” -> “PrettyJSON.py” and watch your file contents magically become beautiful! Thanks BBEdit!

Core Data – efficient fetching of portions of Entities

February 14, 2014 by

NOTE:  This is reported not to work on iOS 8+ (see comments).  This post is also fairly old at this point and I haven’t re-verified that it works on newer versions of OS X, though the relevant comment in NSFetchRequest.h seems to still be present in the 10.12 OS X SDK.

Quick write up of an active conversation on twitter and the results of some research.

Brent Simmons posted about something I’d started looking into today: Efficient Core Data fetching when you only need a few fields of a database Entity.  The name of setPropertiesToFetch: in NSFetchRequest looks promising however the documentation says:

This value is only used if resultType is set to NSDictionaryResultType.

Well that’s a bummer because we’d really like our nice subclass of NSManagedObject to be used by our view controller (say) or we only need to access one property of the complex object.  Here’s something odd I noticed though: the comment in the NSFetchRequest.h file (OS X 10.8 SDK & 10.9 SDK) for setPropertiesToFetch: says this:

If NSManagedObjectResultType is set, then NSExpressionDescription cannot be used, and the results are managed object faults partially pre-populated with the named properties

Well hey! That’s exactly what we want it to do for efficiency when we only need a couple of properties out of many for a given entity.

Thanks to some twitter dialog with @pgor and others, and especially a reminder from @JimRoepcke about setting -com.apple.CoreData.SQLDebug 1 to show the sql logging for Core Data when talking to an sqlite backend, I was able to verify that this does work the way we want it to, at least on OS X running under 10.8.4:

If you use code like the following:

NSFetchRequest * request = [NSFetchRequest fetchRequestWithEntityName: @"AppEntry"];
[request setPredicate: [NSPredicate predicateWithFormat: @"app_id in %@", inAppIDs]];
[request setIncludesSubentities: NO];
[request setPropertiesToFetch: @[ @"app_id", @"fooprop"]];
// [request setIncludesPropertyValues: NO]; // you need YES, which is the default
[request setResultType: NSManagedObjectResultType];
[request setReturnsObjectsAsFaults: NO]; // maybe not needed.  It will still be a fault,
                                         // but the properties are preloaded
NSError * error = nil;
NSArray * fetchedArray = [self.managedObjectContext executeFetchRequest: request error: &error ];
if ( fetchedArray != nil )
  if ( [fetchedArray count] > 0 )
    AppEntry * entry = [fetchedArray firstObject];
    NSLog(@" isFault? %@", entry.isFault ? @"YES" : @"NO" );
    NSNumber * appID = entry.app_id;
    NSLog(@" appID: %@", appID );
    NSLog(@" isFault? %@", entry.isFault ? @"YES" : @"NO" );
      // accessing property not in setPropertiesToFetch:
      // causes fault to fire & load whole object
    NSString * otherProperty = entry.otherProperty;
    NSLog(@" isFault? %@", entry.isFault ? @"YES" : @"NO" );
    NSLog(@"otherProperty: %@", otherProperty );
    NSLog(@"no resuts");

(code changed to mask client project details so typos are because of that)

and the output is:

// the fetch does this - only the two properties we indicated are fetched:
 CoreData: sql: SELECT t0.Z_ENT, t0.Z_PK, t0.ZAPP_ID, t0.ZFOO FROM 
                  ZAPPENTRY t0 WHERE t0.ZAPP_ID IN (?,?,?)
 isFault? YES
 appID: 281940292
 isFault? YES
 CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZAPP_ID, t0.ZOTHERPROPERTY, 
                   t0.ZDATESTAMP, t0.ZNAME, t0.ZFOO, t0.ZTITLE FROM ZAPPENTRY t0 
                   WHERE t0.Z_PK = ?
 CoreData: annotation: sql connection fetch time: 0.0025s
 CoreData: annotation: total fetch execution time: 0.0030s for 1 rows.
 CoreData: annotation: fault fulfilled from database for : 0x100150590 ...
 isFault? NO
 otherProperty: it works!

So you can see that the main fetch request only grabbed the two properties that were in setPropertiesToFetch:. The result object is a faulted NSManagedObject (see where we checked isFault) but the property values for the properties listed in setPropertiesToFetch: are available without faulting the object and doing another database fetch. You’ll see we accessed appID to check this.

However, if you then access a property that was not in the setPropertiesToFetch: list (otherProperty in the above code) you can see that another sql call is made and the object is faulted and fully loaded.  The next check for isFault returns NO because it is no longer a fault.

So to me this indicates that setPropertiesToFetch: IS useful exactly as we’d like even when you’re not getting the NSDictionaryResultType and so is ideal for exactly the situation Brent was asking about for his timeline view.    I’ve filed a radar on the documentation error rdar://16073227 so hopefully that’ll get updated sooner than later.


I was curious if one could modify one of these limited properties without faulting the entire object and all of it’s properties (which seemed unlikely) and so I did an additional test and the answer is: nope.  Modifying a prefetched property on the object causes a fault and the whole object and all it’s properties are loaded into memory and isFault returns NO.

Update #2: 

So this technique above turns out to work and be handy when you only need to fetch an item in a one-to-many property/relation off of an object with lots of properties to avoid loading all those properties into memory.  In our sample data an AppEntry has a bunch of properties including a relation to a list of prices and we’d like the most recent price (just any price for this sample code) but we don’t need to load in the rest of the data in the App Entry entity.  Works like this:

NSFetchRequest * request = [NSFetchRequest fetchRequestWithEntityName: @"AppEntry"];
[request setPredicate: [NSPredicate predicateWithFormat: @"app_id == %@", inAppID]];
[request setIncludesSubentities: NO];
[request setReturnsObjectsAsFaults: NO];
[request setPropertiesToFetch: @[ @"app_id" ]];
[request setRelationshipKeyPathsForPrefetching: @[ @"prices" ]];
NSError * error = nil;
NSArray * fetchedArray = [self.managedObjectContext executeFetchRequest: request error: &error ];
if ( fetchedArray != nil )
  if ( [fetchedArray count] > 0 )
    AppEntry * appData = [fetchedArray firstObject];
    if ( appData != nil )
      PriceEntry * price = [appData.prices anyObject];
      NSLog(@"a price is: %@", price.price );

and the logging looks like this:

CoreData: sql: SELECT t0.Z_ENT, t0.Z_PK, t0.ZAPP_ID FROM ZAPPENTRY t0 WHERE t0.ZAPP_ID = ?
CoreData: annotation: sql connection fetch time: 0.0005s
CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZDATESTAMP, t0.ZPRICE, t0.ZAPP_ID
CoreData: annotation: sql connection fetch time: 0.0004s
CoreData: annotation: total fetch execution time: 0.0007s for 1 rows.
CoreData: annotation: Prefetching with key 'prices'. Got 1 rows.
CoreData: annotation: total fetch execution time: 0.0022s for 1 rows.
a price is: 0

So you can see that it only loads the app_id property from the AppEntry object but still you can get to the prices relation.  Unfortunately I’m not seeing a way to cascade the setPropertiesToFetch: down into the related entities and so all the fields in the PriceEntity in this example get fetched.  I’d love to find a way to do that so if you figure that out please let me know – thanks!

Update #3: 

(I know, I know! What’s with all these updates?! – I wanted to get the basics out there and then I kept thinking of other angles/aspects of this topic).

So one thing that might be helpful is to show how to use the -com.apple.CoreData.SQLDebug 1 setting to examine what Core Data is doing when you’re using it. Setting this was critical to understanding what was happening in the above research.  You want to pass this as an argument to your app. So if you’re launching your app from the terminal you’d pass -com.apple.CoreData.SQLDebug 1 as a command line argument as usual. If you’re running from within Xcode then you set the arguments to pass to your app in the Scheme settings which you access via Edit Scheme… or Manage Schemes… + Edit Scheme….  Here’s a screenshot of the Edit Scheme sheet where you can see how to enter this flag:

Set Command Line Agrument