Depression, a dark and evil foe.

November 22, 2014 by

About a year ago I was trying to write a story for NaNoWriMo, but the mood of the time lead me into deep waters.  I wrote for 6 more days after this first entry, but the direction of the words was ever darker and trending towards frightening, so I stopped.  Here then is that first free-write because there are pieces of it that resonate for me.


Depression is among the most challenging of foes to overcome.  Silent, hidden, sneaky and pervasive it festers and grows most when you’re weakened by more common challenges such as hunger, exhaustion, or common illness.  It’s an enemy like fog, thin and insubstantial while at the same time somehow heavy enough to crush your spirit and sap all energy from your mind and body.  Like fog it parts with ease when slashed with a weapon, but curls back around to fill in the space just cleared.  Never standing still and facing you in battle – indeed a difficult foe to vanquish.
 
Those of one religious group or another will tell you that belief in their deity can help but only if you forsake all other religions and believe in theirs alone as the one true deity.  Such hubris, such blindness.  Do they not see that all roads lead to the same place, eventually?  All paths to the same great beyond?
 
Difficult to view any of them as knowing that of which they speak and one has to wonder which of their words be Truth and which just the folly of mortal man creating structure to validate that which they want to believe.  And thus another path must be found for the organized religions seem imperfect and as likely to shatter as a flawed sword when needed most.
 
Those that claim to be modern healers offer chemicals to dull the mind and spirit.  While no doubt easing the pain, and thus useful at times, such things seem likely to blind one to the path of true healing.  Those that would speak of one’s troubles and attempt to guide one through the rapids of battle with the fog seem more interested in mapping the battle to those they’ve fought before and it’s difficult to see any true wisdom in such an exercise.  Skeptical of help there, one looks beyond for some way to find peace, to gain one’s life back…
 
…to little avail.
 
And ever in this journey the depression colors the picture.  Deep in the bones, it seeps out, poisoning and weakening the body, mind and spirit.  Causing pain and fatigue anew each day, and worse at night.  Ebbing and flowing like the tides of the sea.  The efforts of one human as seemingly insignificant in its clutches as a man floating in the vastness of an ocean.

Fix for spinning Pizza in Finder (10.9.5): remove dropbox contextual menus

November 7, 2014 by

Got  really tired for seeing the SPOD (Spinning Pizza of Death) in the Finder while trying to navigate in the folder hierarchy.  Happens off and on every 30 seconds or so.  Finally tracked it down to something dumb that Dropbox’s contextual menu code is doing (version 2.10.41).

It’s a bit of a pain to remove but here’s what you need to know:

/Library/DropboxHelperTools/

is where the nasty is.  Contents:

DropboxHelperInstaller
Dropbox_u###/
DropboxBundle.bundle
FinderLoadBundle
mach_inject_bundle_stub.bundle
dbfseventsd

The “###” is the user id number of the current OS X user (probably 501, 502, etc).

You need to move the “DropboxHelperInstaller” out of this folder or it’ll just keep re-installing the other stuff. I didn’t track down which of the two bundles are causing the problem, but it’s one of the “FinderLoadBundle”, or “DropboxBundle.bundle”. I removed both of these and the “mach_inject_bundle_stub.bundle” and that seems to solve the problem (after you quit Dropbox and relaunch the Finder).

Unfortunately Dropbox really wants to repair itself so it will keep prompting you every time it launches to put these back:

Screen Shot 2014-11-07 at 7.44.40 PM

Just select “Cancel” and it won’t be able to put these buggy files back.  Everything except the Finder integration seems to work fine and the Finder doesn’t keep dying inside dropbox contextual menu code for some indeterminate (but too long) amount of time.  I’ve told them on Twitter but they haven’t fixed this yet :-/

UPDATE:  As of Dropbox v2.10.52, and only when running on OS X 10.10.1, there’s a checkbox for “Enable Finder Integration” that might turn this stuff off more easily.  I haven’t tried it yet, but I’m hopeful.

Objective C Builder Pattern play

April 12, 2014 by

So I read two posts on the Builder Pattern from Java today that got linked to off of Twitter.

This by Klaas Pieter which referenced this one by Uli Kusterer.  Both good articles.

I haven’t done Java much at all for the last 10 years and so am not used to this pattern, but I thought about how I might do something similar and while I’m not sure my first thought is any better, it seems to meet the requirements and/or benefits noted by the two blog posts in question and the tweet discussion referencing them.

Instead of:

 Pizza pizza = new Pizza.Builder()
     .size(12)
     .pepperoni(true)
     .mushrooms(true)
     .build();

(from Uli’s post), or

  Image* theImage =
    (new Image.Builder)->SetWidth(100)
    ->SetHeight(80)->SetDepth(8)->Build();

(from Klaas’ post)

I tried something like:

Foo * aFoo = [Foo fooWithData: @{
     @"width" : @21, @"height" : @22 }];

Here’s one way to implement that - there are multiple, clearly
(pardon the formatting, trying to fit into our narrow blog them is annoying):

// .h file
#import <Foundation/Foundation.h>

@interface Foo : NSObject

+ (instancetype) fooWithData: (NSDictionary*) initParams;

@end

// .m file
@interface Foo ()
@property (nonatomic, assign) long width;
@property (nonatomic, assign) long height;
@property (nonatomic, assign) long depth;
@end

@implementation Foo

+ (instancetype) fooWithData: (NSDictionary*) initParams
{
  Foo *result = [[Foo alloc] init];

  // If one uses setValue:forKey: in a loop as
  // as Uli notes then we can't support integral
  // properties like ints.
  // Also doing it explicitly as below
  // means we don't have to have the same name
  // for our private internal properties as we
  // document for our public parameters because
  // we can map them here.
  // e.g.,
  //  result.imageWidth = [initParams[@"width"] longValue];

  if ( initParams[@"width"] != nil )
    result.width = [initParams[@"width"] longValue];

  if ( initParams[@"height"] != nil )
    result.height = [initParams[@"height"] longValue];

  if ( initParams[@"depth"] != nil )
    result.depth = [initParams[@"depth"] longValue];

  return result;
}

- (instancetype) init
{
  self = [super init];
  if ( self )
  {
    // init with defaults
    _width = 10;
    _height = 10;
    _depth = 1;
  }
  return self;
}

- (NSString*) description
{
  return [NSString stringWithFormat:
           @"Foo: (%p), width: %ld, height: %ld, depth: %ld",
           self, self.width, self.height, self.depth];
}
@end

// main.m
#import <Foundation/Foundation.h>

int main(int argc, char *argv[]) {
  @autoreleasepool {
      // note no depth specified, taking default of 1
    Foo * aFoo =
      [Foo fooWithData: @{ @"width" : @21, @"height" : @22 }];
    NSLog(@"aFoo: %@", aFoo );
  }
}

Paste the above into CodeRunner and run it and you get:

2014-04-12 16:22:38.918 Untitled 7[71144:707]
aFoo: Foo: (0x7f8842c0af00), width: 21, height: 22, depth: 1

In the above I only typed in the class method as taking the full parameter list but normally I would have made the init method take the same parameter and do the initialization & mapping there. Something I’d likely add if I was going to actually use this, which I’m not likely to. Why not? Because to use the construct above you’d have to document the parameter keys available to use in the dictionary and what type of value each takes. This is where ObjectiveC’s named parameters comes in handy: they are self documenting.

Anyway, an interesting procrastination from what I was supposed to be doing this Saturday afternoon… :-)

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:

Image

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!  :-P

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.

Follow

Get every new post delivered to your Inbox.

Join 1,237 other followers