BattleTop

Finishing Things – Intermezzo part 2 of 2

2015-05-232015-05-23 Jeroen

So, like I wrote, Google is “bidding farewell to Google Code“. So my recently “wrapped” up projects needed some post-wrapping-wrap-up (you still with me?!). I’m using this as a good excuse to partially move from Mercurial to Git, because I suspect Google Code’s export to GitHub is probably the migration path they’ve put most effort in.

So, here’s my first (active) day at GitHub:

I’m a little afraid that -given GitHub’s popularity- many will see this and consider it to be my current status on code hosting services (disregarding commits to those repo’s being done over a larger time span, and disregarding activity on CodePlex). However -given GitHub’s popularity- I guess my GitHub activity will increase anyways over the coming years.

As a related side note: moving projects from Google Code to GitHub was extremely easy. The web-based tool required nothing besides a link to my Google Code project, and me authorizing Google Code in GitHub through OAuth. The only downsides I personally found during this automated conversion:

My old commits in the migrated GitHub repo’s don’t get attributed to my GitHub account, because the user details were different. Also, apparently TortoiseHg “helped” me commit unwittingly as “jeroenheijmans <jeroenheijmans@localhost>”. I guess if I’d payed attention I (sh/w)ould’ve at least used a valid e-mail address. (Yes, given that probably no one has cloned my repo’s (yet) I could probably rewrite history to change this, but it’s not that big a deal I guess…)
My repository includes some Mercurial-specific files, i.e. a .hgignore file. I might’ve stripped that if I had done the Hg-Git conversion manually.
The project home page from Google Code was not automatically added as a README.md file in the GitHub repo. I think that would’ve been nice. Then again, this omission gave me a chance to check out Git(Hub).

And so my move to Git(Hub) begins. I’ve already enjoyed reading through other people’s thoughts on (Git) commit messages, had my first dealings with Atlassian SourceTree, as well as a combination of the two. You’d almost wonder how I got the actual migration done at all.

I feel excited about getting to know more about SourceTree, Git, and GitHub. However, I’m also still very determined to finish Bieb, which will remain on CodePlex. We’ll see how that plays out in the coming weeks / months. Stay tuned.

Finishing BattleTop

2015-01-182017-09-02 Jeroen

Okay, the title is about as uninspired as topping a vanilla ice cream dessert with chocolate sauce. But it’s to the point! Also, with slight OCD, it’s nice that my archives will show nicely aligned “Finishing …” titles. This is important for many reasons!

Anyhow, as I’ve announced recently, I had already ~~finished~~ wrapped up one project: BattleTop. Have a peek at the Source, or check out the Live Version.

Elevator Pitch

What would’ve been the Elevator Pitch if I had made one when I started? Something like this:

I’m developing an app for keeping combat initiative so tabletop RPG groups can skip the tedious parts and share the initiative state easily, using (mobile) devices that are present in sessions anyways.

Writing elevator pitches is far from my specialty, perhaps I should’ve said something about “the competition” too: I’ve actually looked for existing apps, and tried a few from the Android Play Store. Only a few existed at the time, and they were very unsatisfactory.

What’s it built with?

I’ll be honest: from the subset of suitable technologies, I didn’t choose based on “best for the job”. Instead, I chose two technologies that I wanted to learn more about, and stayed in my comfort zone when choosing the rest.

The initial prototype was built with:

Html5, because at the time I loved tinkering with the new semantic tags. Also, I intended to ~~learn all about~~ tinker with LocalStorage for saving state between (possibly accidental) page refreshes.
Custom CSS, because it’s “good enough” for a prototype, and switching to SASS or LESS later on is easy.
jQuery, because I thought I wanted to learn how to write jQuery plugins.

Only two days / 11 commits after I had started did I branch off to rewrite things MVVM style with KnockoutJS. I’ve not looked back since. It also paved the way for easy unit testing, allowing me to experiment with QUnit.

How’s it wrapped up?

The frequency with which our group did RPG sessions had dropped dramatically. This removes the need to have a tool, the motivation to keep developing it, and the ability to test it. And this is okay with me. I learned some cool new things, and heck: it even got it to a functional beta version.

To wrap it up I just reviewed all of my code. Unit tests had already been done in August, and even though the code isn’t the fanciest ever, it didn’t have any obvious loose ends or idiotic bugs. So after some minor changes I just added a “discontinued” warning to the code, the live version, and the project site, and that’s that: closure!

Any future for BattleTop?

Not very likely. I think I prefer to focus effort on one certain other project, and after that probably even start new projects before picking up BattleTop again.

But like I said: I’m okay with that.

Finishing Things

2015-01-142015-01-14 Jeroen

Nearly without exception have I used Title Case in my post titles. This time though, it’s more appropriate than ever. The “Things” I speak of are my “open” Projects. Unfinished things that feel Big, but that can either be small, or at least be done in small pieces.

Yes, you’ve guessed correctly, I’ve made my choice: I’m going to finish and/or wrap up loose ends.

You know what? I’ve already started. In fact, I’ve already wrapped up the first project, which probably means that I’ll write (after months of silence) a third post in one week.

But let’s not get ahead of myself. The set of projects I want to wrap up is this subset of projects you can find on my www:

BattleTop. My RPG initiative app. Reached fully-functional beta status. However, with less and less Table Top RPG sessions, it’s hard to fully test and further develop the app. Gonna Wrap It Up!
TimeLine. An app to visualize grouped timelines, though in honesty a personal playground for new html5 semantic elements. Did not get past prototype status. Gonna Wrap It Up!
DotaGrid. A pragmatic tool hacked together to customize the Dota 2 hero picker. Reached beta status, but wasn’t really meant to go beyond that anyways: heck, the code is grouped in a file called “MyMonolithicApp.js”. Gonna Wrap It Up, though I might update it occasionally with new heroes if I feel like it.
Bieb. A somewhat bigger project to create a website showcasing books you have in your own library. Not even in alpha status yet, will have to see how I will Wrap It Up…

That’s it! I’m looking forward to wrapping those projects up. Hopefully it’ll give me some closure, and by side effect some energy to start new projects!

Stay tuned for the first wrap-up-post.

2013-02-182017-09-02 Jeroen

Exactly one month ago I wrote about Google Code hosting. At the time I wasn’t ready to divulge the project I was using to test it, but today’s different. Today, I have decided to put BattleTop in Beta!

BattleTop is a responsive single-page web application to assist in bookkeeping things like Characters, Initiative, Hit Points, Conditions, et cetera, during D20-based table top RPG sessions.

BattleTop Beta Logo

You can view it, clone it, and provide pull requests for it at Google Code. Mind you, it is still in beta, meaning there’s many rough edges and bugs to be found. I have been and will be dogfooding it during our own table top RPG sessions, so I’ll be sharing your frustrations about bugs and time permitting I will be fixing things.

The current list of features:

Track characters. Add and remove monsters, NPCs, PCs, and environment initiatives. You can also reset the list to the party, or to a blank, new list.
Track initiative. Keep initiative and initiative modifiers, sort the list by initiative, keep track of ready and delay actions.
Track conditions. Each character has its own list of conditions which you can add, remove or change, with a number of turns to it (so they wear off automatically).
Track hit points. Each character optionally has a number of hit points. You can deal damage or apply healing to change the hit point amount.
Save/Load. Using the LocalStorage API BattleTop will save your state every 5 seconds. If you navigate away or re-open the page on your next play session the old state will be there.

Note: because BattleTop extensively uses many modern features (html5 semantic markup, css3 features, modern JS such as LocalStorage), only modern browsers will be supported.

Here’s a general view of what it currently looks like:

The horrifying state of free Android initiative-keeping apps was what triggered me to create BattleTop. I’ve decided on a HTML5 app as opposed to a native app because (a) it would be easier for me to create something in a short amount of time, and (b) to keep it portable across devices and operating systems with little effort. Hopefully BattleTop will help or inspire others as well.