Time, Life, and Footage

In my last post, I mentioned I would be uploading a devlog for Roshambo Adventure to my YouTube channel. So where is it? I had planned for that video to be different from my previous devlogs. Rather than a short feature showcase of what I had worked on in the past week or two, I wanted it to be more of a look into my thought process and how my ideas changed and developed over time into the game that exists today.

It turns out that making that kind of a video is really difficult if you have no footage of the actual development process. I contemplated trying to rebuild some of the earlier versions of the game that I had gone through to record footage, but that seemed like a lot of work in the wrong direction just for a video. While I was debating how to approach this devlog, some things came up in my day job and my daily life that left me with less time and motivation than I would have preferred to work on the game and make blog or video content. Hence “the next few days” for a video turning into a month for a blog post explaining why there is no video.

I came across a post on r/gamedev1I don’t have a link to the actual thread, but I’ll update this post if I come across it again. that I thought was particularly insightful. The thread topic was about how to balance time between making a game and making devlogs. The post suggested that the key is to focus on your goal. If your goal is to make videos, then stop making games and make videos. If your goal is to make games, then stop making videos and make games. Every minute you spend making a video about your game is another minute closer to done your game could have been.

This insight made me realize that to make a video I would be happy with posting, the time investment is not worth the return. Blog posts here, however, are much easier to put together so I think going forward I’m going to favor blog posts for development content, and save videos for major milestone feature showcases.

In contrast to the previous times I’ve found motivation fleeting however, this time it’s not a function of having no direction. I find that my vision for what I would like Roshambo Adventure to be is still clear as day, and when I do sit down to work on it I don’t feel like I’m banging my head trying to figure out what I want the game to be or what I should work on next.

Roshambo: Serious Business

After lamenting about my inability to finish projects but prior to identifying the actual issue I was facing, I theorized that perhaps my problem was just not having enough constraints. To test this, I decided to make a game styled like a game jam1Primarily due to lacking the confidence and wanting to avoid the pressure of joining an actual game jam.: 24 hour time limit with a specific art pack. This would force my scope to stay small. I found this wonderful art pack by Pixel_Poem, fired up Godot, and in a couple short hours had put a simple little scene together.

A screenshot of a darkened scene with scattered torches emitting light. Monsters hide in the darkness.

A simple spooky scene

There was still a pretty major problem I was facing though: I had no idea what I was making. I was just throwing things together hoping something would stick. It was a slow process, and with every hour that ticked by I grew more and more discouraged. Like most of my previous projects, this led me to a place where I was frustrated, had no idea what to do next, and was just completely unmotivated to continue working2Interestingly, it seems having either too much scope or not enough scope results in me ending up in the same place..

Searching around for videos or articles about how other devs start new games, I came across HeartBeast’s video and while it didn’t provide the answer I was looking for, it did give me new insight into the problem I actually had. With that, I changed my approach. Rather than picking a genre (“I want to make a dungeon crawler”) and then trying to massage all other details together to result in something I could enjoy, I tried going in the opposite direction: picking a mechanic and letting everything else revolve around that.

I wanted something simple, something that I knew couldn’t have a scope that would explode out of proportion. I also wanted something that I hadn’t really seen used very often. A few options occurred to me: Tic-tac-toe, some kind of word game, Lights-Out; none of these really intrigued me though. Then Rock Paper Scissors popped into my mind. It’s trivial to implement and I had only ever seen a single game use it as a primary game mechanic.

I briefly looked into how difficult it would be to make an AI more competent than just picking one of the three actions at random and happened across a very in-depth article. The descriptions in this article of the history, strategies, and meta game conjured a picture of tournaments in which RPS is Serious Business. This made me draw comparisons to the Pokémon Trading Card Game on Game Boy. Suddenly the clouds parted, the fog cleared, and I had a crystal clear vision of the game I wanted to make!

Over the next seven days I would work on realizing the vision I had3My previous plan of a 24-hour restriction was entirely forgotten and I’ve started expanding beyond the original art pack, but in terms of design and scope I’m still treating this like a game jam project.. It all came so effortlessly. I knew exactly what features I wanted and how to break them down into workable tasks. That’s not to say I didn’t have to experiment, try different approaches, and choose which results I liked better, or that I didn’t run into various bugs that proved difficult to resolve. I certainly did, but throughout that process I had a guiding star that ensured I would never lose my way or get overwhelmed, and that the scope would continue to stay extremely small. A bit of sanding and couple coats of paint later and Roshambo Adventure was born!

A screenshot of the title screen of Roshambo Adventure.

The adventure begins…

Within the next few days I plan on putting together a proper devlog video over on my YouTube channel showing off what I’ve built so far and what I’m planning on working on next. Keep an eye out for that! I will also be making another post here in the near future talking about my time management strategy. I’ve traditionally been extremely terrible at time management on my projects, so for this I came up with a new plan that I’ve been enacting over the past couple weeks. I’m super happy with how that has been progressing and look forward to telling you all about it!

A Very Simple Mistake

In my last post I talked about being discouraged that although I have technically been developing games for over twenty years I’ve never actually released a single title and how despite my skills and experience increasing over the years, I’ve found it more and more difficult to get even close to feeling like something I’ve built would be release worthy.

Every indie game developer has their own graveyard of failed and forgotten concepts, but there’s usually a number of releases scattered around as well. They may not consider these releases “successful”, but each one provides a wealth of information on what worked, what didn’t, what could be changed, and makes getting to the next release a little easier.

One of the first mistakes most new game developers make is making their scope too ambitious. The halls of Discord and r/gamedev are littered with the posts of newcomers who want to make their own Skyrim or Breath of the Wild armed with a cornucopia of ideas and aspirations but not a sliver of prior experience. Don’t start with your most exciting idea. Aspire to that by all means, but just like you’re setting yourself up for failure by fighting the final boss with no power-ups, no extra health containers, and only the starting pistol, so too are you doing so here.

After watching HeartBeast’s video and puzzling on it for a few days, I realized that my issue was a variation of this very simple problem. Coming from an enterprise software development background, I knew that the key to solving complex tasks is the ability to break those tasks into smaller, more manageable chunks that can be quickly and easily completed. My mistake was thinking that doing that was equivalent to reducing scope.

I generally try to manage my scope very carefully to make sure I’m not targeting something too big. However, my process for doing so was flawed. Rather than design content, I would design systems that I could plug into to generate more content. Picture a game with themed dungeons. If I build a dungeon generator, then creating a new dungeon is as simple as providing new theme graphics. Thus I can build one dungeon as part of my initial scope, and then just expand on it post-release.

But I realized recently that designing systems and breaking down their complexity into tasks is not the same as reducing scope overall. Sure, it means I don’t have to design 32 different dungeons, but it’s still a ton of work. If we suggest that scope is the combined total of quantity and complexity, my old process was just trading quantity for complexity while the overall total stayed the same.

I also realized that a game doesn’t have to be a certain length to be considered successful. I’ve recently been watching videos covering various games developed as part of game jams, and many of these games only provide minutes of gameplay, but are still able to provide wonderful experiences that players enjoy and remember. A game doesn’t need to be ten, forty, or one hundred hours long to be a success. It’s about the quality of the experience and how much it conveys the experience the developer intended, not the duration of that experience.

Gone Home is a great example of this. It is widely regarded as a successful indie game1There can be some debate about whether it is a “game” in the traditional sense, but that’s irrelevant for the point I’m making here., but it is also often estimated at only having one to two hours worth of gameplay. It’s also not one that most players will return to over and over again. Duration and replay value do not determine quality.

With these two points in mind, I started a new project with an intentionally limited scope. In only a single week, I’ve found that I made more progress on this project and am happier with that progress than on any other project I can remember. Along with having a new strategy for time management2This is something I’ve always had a very hard time with and that I’ll be writing a post about in the future., I’m very excited about this one and am very optimistic that I’ll be able to take it all the way to release! In my next post, I’ll reveal the changes I made to my process and what this new project is that was born from it!

My Game Dev Graveyard

For as long as I can remember, I’ve wanted to make games. In the late 90’s I discovered QuickBASIC on our family computer. Then in the early aughts I found tools like Klik & Play, Zelda Classic, and RPG Maker. A great many other tools and languages would follow as I proceeded down the path towards my current career as a software engineer, and at every step along the way I would make games.

These games would range the gamut of genres: text adventures, top-down shooters, shmups, mazes, point-and-click adventures, RPGs, strategy games, puzzle games… you name it I’ve probably tried to make it at one point or another. Many I remember, and I’m certain there are many I don’t. But you may notice there is a distinct lack of information on this site about any of them. This is because I’ve never actually finished one.1Well, that’s not strictly true. There are a precious few that I did finish many years ago. Those however were in the days before source control, and even if they weren’t I wouldn’t have been experienced enough to save them anyway. Those few finished games were only ever seen by myself and my family. They never made it beyond the boundaries of the family computer.

This is a fact that in recent years has begun to weigh on me. In the more than two decades I’ve been making games, not one scrap exists that I can show as an accomplishment even as an unfinished prototype. They say getting started is the hardest part, but when it comes to creating I and many others haven’t found that to be true. Like most game developers, authors, artists, etc. I have a veritable graveyard of half-started demos and concepts that will never see the light of day. When it comes to game development, it is well established that finishing is the hardest part. My graveyard just happens to get paved over fairly regularly so I couldn’t dredge things up even if I wanted to.2Which is to say I frequently go back through those concepts, find absolutely nothing of value, and delete them. This is a habit I’m trying to break, but I think going forward my concepts will end up more fully fleshed out such that I won’t feel inclined to delete them in the first place. More on that later.

A few weeks ago I saw a video from game developer and YouTuber HeartBeast titled Gamedev Constraints and New Beginnings. In it, he ruminates on why when he was younger he had no trouble building and releasing games, but as his skills and experience grew he found himself less able to do so. He came to the conclusion that when his skills were less refined they acted as a constraint, limiting what he could produce. Thus, he would build his game to the maximum his skill would allow for and then release. As his skills increased they became less of a limit, and he would spend more and more time trying to reach his vision of the game rather than settle for something else. He theorized that placing artificial limits on himself would help him return to that place where he could release with relative ease once he reached the maximum of what was possible.

I find myself in exactly the same predicament and while I agree completely with his findings, I’m also sure that’s not exactly the same issue I’m facing. I’ve long believed that the complete freedom that comes with having the skills and tools to build the vision you have is what prevents that same vision from being realized and I’ve strived to place constraints on myself for that reason, but still I find that as my skills have grown I’ve found it more and more difficult to be proud of what I’ve built and to be comfortable finishing and releasing anything.

While HeartBeast’s video didn’t give me the answer to my problem, it did get me thinking about the situation and if my problem wasn’t a lack of constraints then what was it? I’ve spent a lot of time contemplating this and trying to narrow in on exactly why I can’t seem to carry any of these projects to completion. I believe I’ve identified it, and the plan I’ve come up with to address it is what led to the creation of this very blog. In the next post I’ll go into what I think the issue is, my plan for addressing it, and why after only two weeks I believe I’m seeing tremendous successes that indicate I’m on the right path!

A New Chapter

It’s been a while since I’ve tried to do the blog thing. Every few years I’ll give it a shot, write a couple posts, and then forget all about it until the next time. I’m not promising this time will be any different, but I think I’m coming from a different direction this time; different mindset, different goal.

I’ll talk a bit about that in a different post though. I’d like to keep this one short and sweet. Welcome to the new site! Stick around and you’ll hear about the things I’m working on, or whatever other random thoughts I have. Or not… who knows?

I’m also debating about whether or not to migrate the posts from my older blogs here, more as a personal archive or a curiosity than because they contain anything of particular interest (they really don’t). If I do I’ll probably backdate them before this post so they don’t clog up the main page. If you’re presently reading through the archives and just got to this post, I guess I did that. Also, I apologize for the drivel you’ve just exposed yourself to. But then you chose to read that old stuff, so I guess it’s really your fault huh?

Python and pyenv: In Practice

This post has been migrated from my older blog The Castle.


If you’re looking for an explanation of what all the moving parts are, make sure to read the previous post on this topic. If you’re ready to fire up your terminal and get your Python environment set up once and for all, read on!

A few details before we start:

  • We’re going to assume you’re working in a Linux environment. While pyenv may still be helpful on Windows, Windows is much better at handling multiple Python installs.
  • As to which particular flavor of Linux, we’ll be using CentOS 7. By and large this shouldn’t really matter, except that you’ll need to use your distribution’s package manager of choice. For us, it’s yum but you may use apt, zypper, pacman, emerge, dnf, or something else entirely. The process should be roughly the same, but some of the package names may differ.
  • The pyenv setup and configuration utilizes bash scripts, so we will be using the bash shell for this guide. I’m not familiar with other shells, so I can’t say how much work it would be to modify those scripts to run in other shells.

Update 2018-07-10: My understanding of pyenv was slightly mistaken. pyenv is a bash extension, thus it cannot be run on Windows or in a shell other than bash. The majority of the functionality pyenv provides is implemented into Python itself as of version 3.3, so the virtual environment handling is available cross-platform/shell, but the ability to work across Python versions (including versions prior to 3.3) and to automatically enable and disable environments on a per directory basis is pyenv exclusive as far as I know.

With all that settled, let’s open up a terminal and get started!

CentOS, like most Linux distributions, comes with Python pre-installed. However, it has become best practice to basically never use this installation. It’s being used by the operating system, and updating or installing modules could potentially interfere with its operation. So we’re going to take some minimally invasive steps to separate ourselves from it.

sudo yum -y install gcc zlib-devel bzip2 bzip2-devel readline-devel sqlite sqlite-devel openssl-devel xz xz-devel tk-devel libffi-devel python-pip

Update 2018-07-21: Added a few potentially missing dependencies. See https://github.com/pyenv/pyenv/wiki for the list of dependencies you should install for your particular linux distribution.

This will install a number of libraries that Python and/or pyenv need in order to run properly. Of particular note here is python-pip. Pip is the Python-specific package manager. It’s actually invoked by calling Python and passing a particular parameter string, but many tutorials will invoke it directly. This package provides a simple alias to allow you to do that. If you want to skip this step and invoke Pip using the Python executable, you can do so with the command:

python -m pip install

Next we’ll upgrade pip to the latest version.

sudo pip install --upgrade pip

Note: In general, you shouldn’t have to sudo every command. If you do, either your permissions are not configured appropriately, or you’re doing something you probably shouldn’t be doing. Here, we only use sudo when dealing with the system installation of Python. When dealing with pyenv or any installation of Python installed by pyenv, you should explicitly NOT use sudo. Using sudo when executing a non-system pip, for example, may install packages to the wrong installation of Python.

At this point, there is one last step to take before we are done messing with the built-in version of Python: installing pyenv. pyenv works by replacing the Python executables with proxy shims that will redirect your commands to the correct Python installation. It does this in such a way that the operating system won’t know it’s happening, and thus it shouldn’t have any effect on the system’s operation.

curl -L https://github.com/pyenv/pyenv-installer/raw/master/bin/pyenv-installer | bash

This downloads and executes the pyenv-installer script which installs pyenv and those shims. The final step to getting pyenv up and running is to open the ~/.bashrc file and add the following lines to the bottom of it:

export PATH=$HOME/.pyenv/bin:$PATH

eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

This adds pyenv to the beginning of your PATH and runs some initialization scripts any time you open a terminal. Now close the terminal and open a new one so that these initialization scripts run, and that’s it! pyenv is installed! There is one final thing we want to do though. I mentioned before that best practice is to not touch the system installation of Python. With pyenv, we can take steps to make sure we don’t accidently do that. On CentOS, the system version of Python is 2.7.5. What we can do is install a separate copy of Python 2.7.5 and tell pyenv that we want to use that if no other environment is specified. That way if we accidently install or upgrade something outside of a virtual environment, it will use this second installation and not our system one.

pyenv install 2.7.5
pyenv global 2.7.5

Since we haven’t used Python 2.7.5 from within pyenv before, the first line tells Python to go ahead and create its own installation of 2.7.5. The second line says that when we’re not using any other virtual environment, we should use this one. Now we are completely decoupled from the system installation. Now, let’s say we want to start a new project using Python 3.6.5. Since we haven’t installed Python 3.6.5 before, we tell pyenv to do so:

pyenv install 3.6.5

And then we create a new virtual environment for our particular project. This allows us to use the same Python version for multiple projects, but also ensures our installed dependencies and versions won’t interfere across projects. We tell pyenv to name our virtual environment “myproject” and that we want to use Python version 3.6.5.

pyenv virtualenv 3.6.5 myproject

Now you can switch to this environment to work on your project

pyenv activate myproject

and you can be sure that anything you do won’t have any impact on any other project or installation on your machine! Bonus: when you go to use python or pip, you can just run that command. No more python2, python3, python36, etc.! Just make sure that when you’re done working on your project that you deactivate your environment

pyenv deactivate

so that you don’t accidently mess it up in the meantime.

pyenv has one other really cool trick that you’ll want to use. Let’s say you have a handful of different projects using various Python versions and dependencies. This all works fine because each project has its own virtual environment. But it’s a hassle having to manually enable and disable the environments since you’re working on all the projects at the same time, and you have to remember to do actually do that. Well, pyenv can help you out here. You can mark a particular directory as using a particular environment, then any python commands you execute from within that directory (or any of its children) will automatically use the correct environment! You can set this up by navigating to your project’s root directory and running:

pyenv local myproject

This will create a .python-version file in this directory, which is what pyenv uses to know it needs to automatically change the virtual environment! Make sure to add this to your .gitignore or otherwise exclude this file from your source control.

And there you have it! You’re all set up and ready to write some Python! It’s actually not that complicated of a process, and the possibilities and workflows it opens up are pretty powerful, but most of the documentation around this process is scattered, broken, out of date, or just otherwise woefully lacking. If you have any questions or run into any trouble, please leave a comment below. Otherwise, enjoy writing some Python!

~ S

Comments Are Now Available

This post has been migrated from my older blog The Castle.


One of the goals I had with this blog was to keep the infrastructure simple. When I’ve tried to use full Content Management Systems like WordPress or Drupal in the past, I felt like I spent more time and effort customizing the site, updating plugins, and keeping it working the way I want that it just felt like work, which led to me not really spending much time on the real content: the posts.

For this blog, I opted to pass on all that and try out a static site generator which seems to be the new craze in website construction. There are a “couple” options available (See staticsitegenerators.net for a full list), but I also wanted to simplify the hosting situation. For that, GitHub Pages seemed like the perfect option, and that made the choice pretty simple since Jekyll is natively supported by GitHub. I’ve since learned that a couple others are also supported, and you can technically make any of them work if you upload the build artifacts manually instead of letting GitHub handle the build, but there are a fair number of guides and tutorials for Jekyll and GitHub Pages so it seemed like a good place to start.

I’m absolutely thrilled with how it has turned out so far! The infrastructure and hosting takes care of itself, and outside of some tweaks to the theme I’m using, I pretty much don’t have to touch anything. I just create a new markdown file for my post content, drop it in a particular folder, and push it up to my git repository. Awesome!

The only catch is that Jekyll out-of-the-box doesn’t support any kind of user-generated content, in particular comments. Comments are a pretty important part of a tech blog in my opinion. They let people easily point out coding mistakes in the posts and facilitate direct communication and discussion. In a field where discussion can make all the difference to what approach is taken to solve a problem or can have a direct impact on how people learn, that communication is critical!

It took a bit of work, but thanks to the awesome Staticman service, I was able to integrate comments into this site, have them fully embedded in the theme and design, and keep them version controlled right alongside my posts! Right now I have moderation enabled, so when you leave a comment it makes a pull request into my repository and I have to approve it before it will appear on the site. I may disable this going forward since I have reCAPTCHA working, but at least while I’m still tweaking the theme it’s useful to have that step in there. There’s also additional features such as reply notifications and threading that I haven’t tackled yet. I will probably work toward these at some point, but for now I’m happy with the basic comment setup.

It was not entirely trivial getting this all up and running, so you can expect a post walking through what it takes to set all this up sometime soon.

~ S

Python, Virtual Environments, and pyenv: Explained

This post has been migrated from my older blog The Castle.


On a recent client project I was required to set up a Python development environment on a CentOS 7 virtual machine. I haven’t had to work with Python since version 2.3, so I was basically starting from scratch as far as prior knowledge went. I’m generally pretty good at figuring things out and following instructions, but my gosh what a mess!

Between the system insisting that there are no newer versions of Python past 2.7.5 (there’s a reason for this that I’ll detail in a moment, but the actual latest is currently 3.6.5) and every other blog post and documentation page I could find telling me to do different things to set it up, I don’t know how anyone can call Python “a language for beginners”.

I ended up spending three days trying to get the system to work without it complaining pip wasn’t installed or that I didn’t have permission to do something. Many blog posts, Stack Overflow questions, and re-created virtual machines later I finally got it working and (I think) I understand how everything fits together. My stance on it now? The way Python handles environments is pretty clever and powerful once you get it set up, but getting it to that point is a nightmare!

For those of you who are as lost as I was, let me explain all the pieces to you in simple, understandable terms. Then I’ll make a second post that shows you step by step how to get this all up and running slick as a whistle.

Python

Let’s talk about Python. You may have seen in various guides that the Python executable is referred to differently depending on which tutorial you’re reading. It can be either python or python# where # is seemingly any arbitrary number. Basically, because Python comes pre-installed in many Linux distributions, a number of system and third-party scripts started relying on it. The executable at that time was python. This persisted up until Python 2.x. When Python 3.0 was released, the parser changed fairly significantly. Rather than trying to handle versioning in a scalable, future-proof way, the Python developers decided that the Python 3.x executable would be named python3.

Here is where things get tricky. Because some distributions wanted to update to Python 3, but wanted their existing scripts to continue working, they aliased python to resolve into python3. This, apparently, broke things. So Python released an official statement saying that python should always refer to Python 2.x and that distributions should use python# to refer to a specific version installation. But, each distribution interprets the # differently, so Python 3.6.5 can be any of python, python3, python36, python365, python3.6 (yes, the executable has a dot in the filename), or python3.6.5. As a commonly installed module, pip follows this same convention and has the same problem. Interestingly, a growing contingent of users are beginning to frown on the use of pip install , instead perferring the more direct python -m pip install . I suspect this is because depending on your system setup, python and pip may reference different versions of Python, which won’t do what you think it does.

Virtual Environments

To make matters worse, there is also a potential conflict with dependency versions. Assume, for example, that your Linux distribution has a dependency on pyzip 0.1. You want to use pyzip 0.2 in your scripts, so you pip install –upgrade pyzip. One of two things happens here:

1. It throws an error while updating and you are effectively stuck with pyzip 0.1.
2. It upgrades pyzip to 0.2 and your system becomes unstable.

Obviously, these are both bad outcomes. In order to handle this, Python came up with the concept of Virtual Environments. Basically, a virtual environment is a sandbox. You select which environment you want to use, then you can install, upgrade, or uninstall any dependencies you want without regard for anything else on the system. It is all kept separate. You can create a new virtual environment just for your current project and the entire Python installation will be completely unaware of any dependencies (or versions thereof) of any other project as well as the system itself. This is where virtualenv comes in. virtualenv is an extension included with later versions of Python that allows you to create, delete, and manage these virtual environments. There is a catch though, it can only do so within a single Python version installation. So you still need separate python and python3 executables, and separate sets of virtual environments for each.

pyenv

Enter pyenv. pyenv is a virtualenv wrapper. When installed properly, pyenv adds a shim which basically takes over your system’s python and pip commands. pyenv then allows you to manage your virtual environments as well as all your Python versions all from a single executable. You can install new versions of Python, create new virtual environments for different projects, and never need to worry about what # to stick on the end of your python call or where Python is installed to ever again. You always call python or pip, then pyenv will automatically route your request to the correct version, installation, and set of dependencies for what you are doing.

Note the words “when installed properly”. Apparently, pyenv is particularly difficult to install by hand. Thus a sister project, pyenv-installer was born. It seems, though, that the installation instructions provided on the pyenv-installer don’t actually work. I will walk you through the correct way of installing it in the next post.

So I hope that helps clear all that up. Python, like most scripting languages, is a hot mess of libraries with obtuse names and wrappers upon wrappers upon wrappers, and most documentation assumes you have intimate knowledge of not just Python, but half the libraries involved. It can be very difficult to find your footing and much of the community documentation that is out there is long out of date. The information is there if you’re willing to dig, and my goal is to do some of that excavation so you don’t have to.

~ S

Welcome to The Castle!

This post has been migrated from my older blog The Castle.


Hello! Welcome! Make yourself at home!

It’s been a long time since I’ve had a blog. I wasn’t good at it back then, hopefully I’ll be a little better at it now.

In my day to day as a software engineer, I’m finding that more and more often I’m running into the scenario where I’m trying to set something up, and the instructions to do so are confusing, incomplete, or just plain wrong. It’s infuriating!

I decided that rather than continuing to scour the internet, pulling together bits and pieces from blogs, mailing lists, and Stack Overflow to get something working, then promptly forgetting all that information once it was up and running, that I should create that which I wish had existed; a single, complete, and correct write up of how to do what should be simple but for some reason is not. That is the primary type content that you’ll find here.

I’ll probably also be posting various thoughts and ramblings from time to time and I hope you’ll forgive me for that. Those may range from opinions and frustrations to simple updates about my weekend plans.

Hope you all are having a wonderful day!

~ S

Broken Like Shattered Glass

This post has been migrated from my older blog A Bad Case of Nostalgia.

Broken Chain

Suddenly, a post!

Hello all. Between not much to talk about and working on other things, I’ve mostly stopped blogging as I’m sure you’ve noticed. But I still have this blog set as my homepage and I noticed that it was down yesterday. It turns out that CWahi had their servers hacked which resulted in many user accounts having their sites wiped out. Luckily the background databases remained intact (meaning posts, comments, the footer quotes, things like that were still there), but it meant that the WordPress installation along with all the content had to be re-uploaded.

As I no longer had copies of most of said content, I spent most of yesterday trying to replace it. I’ve done a pretty good job I think, all the videos have been replaced with embedded YouTube players, as I don’t really see the point in hosting the videos myself now that I can post videos of arbitrary length on YouTube, and all the images have been replaced as well.

If you find any broken links or missing content, be sure to let me know so I can get that fixed right up.

Update 5-1-2012: I managed to find copies of the Torchlight screenshots and the Nostalgia poster. All content should now be restored!