I wrote up a long devlog post for the TIGSource forums that I might as well post here.
BackgroundWay way way back as an intern, when I was a fresh faced technical artist wannabe (before I local industry realities sunk in) I had built a
tilemap painting script for 3DS Max after observing an artist build Animal Crossing style environments by laboriously UV mapping each face to a tile. I never took it further than that early prototype but the idea has stuck with me all this time.
Flash forward to sometime last year when I saw Crocotile and it was all that I had wanted all this time! Except… in the intervening years I've grown very fond of Blender and I wanted those tilemap tools inside my Blender workflow.
DevelopmentI started development in the end of October 2016 and had a functional tool around mid November. It turned out that I started work on Sprytile at a fortuitous time because support for a fast mesh raycast function had just been recently rolled into Blender.
To figure out the workflow and bugs in Sprytile, I ate my own dogfood by building the model below.
Clicky to view the model in SketchfabI had free time over the 2016 holidays so a lot of critical work on Sprytile was completed then. Then my actual job got hectic early in 2017 so work on Sprytile slowed quite a bit. Nice thing about doing this project on GitHub? Automatic work graphs!
I had gotten Sprytile to a level where I was confident with its functionality around the end of January, and had actually wanted to have it out for the Global Game Jam but I knew I was missing something important for Sprytile to get any traction at all. I needed docs and tutorials!
Over February and March, I was making small iterative improvements to Sprytile while wrestling with the documentation and tutorials. At first I tried jumping straight into making a video tutorial but that really did not end up well. So many wasted hours getting frustrated with myself.
What ended up working better for me was putting together a written
quick start tutorial and then making the tutorial video based off that. Production of the video tutorial was still a pain and I'm not entirely happy with it especially with the sound quality and my speech, but by this time I was letting perfect become the enemy of good enough and I really wanted to get Sprytile out the door.
ReleaseI decided my self imposed deadline for release would be March 30. All this time I've had an itch.io page created and parked and have been pecking away at it over the course of the development.
Some things that took me a while to figure out with presentation on itch:
- If you're uploading gifs, the first frame should be an interesting image since they start out paused.
- Check how the site looks on mobile! A lot of visitors come in by mobile. Itch has a great responsive design, but test anyway.
- If you're going to use itch.io's message boards, create some topics ahead of time to set the tone and invite others to use it.
With my tutorials and page done the best I could, I made the itch.io page public and got to work promoting Sprytile.
My first stop was over to Twitter where I didn't really have a following but I figured #hashtags would help. After Twitter, I hit a few relevant subreddits to promote Sprytile there too. There was a snag with r/gamedev since links to itch.io are auto flagged by their bot but a few PMs with their helpful moderators sorted it out.
I'm not sure what I expected (not having goals set is probably bad) but the reception on the first day of release was so lukewarm it bummed me out.
Until
@metkis on Twitter
made a great looking render with Sprytile.
His tweet helped organically promote Sprytile on Twitter. I'm not even sure how he found Sprytile but I'm so grateful he did. It briefly made my notifications a nice mess and according to analytics, has made Twitter the greatest driver of traffic to my itch.io page.
Project ManagementOne great thing about making Sprytile an opensource project is the ecosystem surrounding OSS. For feature and bug tracking, I use
GitHub issues. This is further
augmented by waffle.io which turns GitHub issues into a nice Trello-like kanban board.
Surprisingly, GitHub has driven roughly the same amount of traffic to itch.io as my highest traffic reddit post.
Tech Support and DocumentationTechnical support for users has been a mishmash of social media and github so far. It would be nice to have it centralized in GitHub issues but I understand that that's not really an attractive proposition for non technical users.
I've fixed a couple of egregious bugs and low hanging fruit features since release based on user feedback so support is working at least.
To make it easier to keep the addon up to date, I've also implemented an opensource blender update system.
Some of the interactions I've had with users also reinforced the importance of good documentation and tutorials and where my current ones are lacking. For example, the GameFromScratch YouTube channel
covered Sprytile and started out as an even better tutorial video than my own until later when my documentation clearly failed the user.
Future Feature DevelopmentFrom my own personal use of Sprytile, I already have some ideas for tools that would speed up the process of building with tile maps. But with Sprytile's release, feature development now needs to be balanced between writing docs/tutorials, bug fixes, and features that users want. The highest priority for now is to implement other tile map editor tools before the more specialized features that I have in mind.
Development has been relatively speedy since release but I suspect that's just momentum, I probably can't keep up this pace for the entire cycle. Sprytile is a side project that I work on after actual job and over the weekends.
I'm not sure when I would consider Sprytile complete but I'm very excited to see what people can make with it!
