Random

A Farewell to Fossil Version Control

| Taro Omiya

Feature image courtesy of Wikipedia.

As mentioned earlier, this is one of those very technical blog posts about version controls.

I just recently migrated all of my Fossil repositories to Mercurial, and I wanted to post some notes about why I used the version control from the first place, and why I’m moving away from it. Believe it or not, I still love what Fossil does, and highly recommend it to anyone who needs to setup their own personal version control server. There were a few flaws with it, though, I couldn’t accept that ultimately lead to this decision.

When Fossil is awesome

A colleague once told me, if you’re going to start your own software company, you’re going to need at least 3 things to go with your company server: a version control, task manager, and wiki. Lo and behold, Fossil is all three bundled into a portable package. Fossil’s developers even show off this capability by serving their webpage with a Fossil wiki!

So how does one go about setting up a Fossil website? If you have a personal Linux web server with Fossil installed and serving CGI scripts, it’s incredibly simple. Create a repository with this familiar command (where [filename] is the name of the repository):

fossil init [filename]

Make sure you give this new file read, write, and executable permissions for the web server. Lastly, write a quick CGI script containing the following lines (where [path] is the full path to the new repository):


#!/usr/bin/fossil
repository: [path]

Now that the hard part is over, you can access this CGI script with your favorite web browser to get to the project’s wiki. From that website, you can configure the repository’s name, users, permissions, wiki, task manager, etc. It’s amazingly simple.

What about using Fossil? After all, an easy configuration is nothing if the application is difficult to use or hardly functional. Well, Fossil is a distributed revision control, much like Git and Mercurial. Compared to a centralized revision controls like Subversion, distributed revision controls has several differences, including better merging, easier branching and tagging, and offline support at a cost of requiring two commands instead of one to commit or update files from the server. The last fact tends to make it a bit intimidating for users who come from Subversion (currently the industry standard). Fossil, however, finds a very good medium between these 2 systems. By default, Fossil has autosync mode on: that means simply running fossil commit or fossil update will automatically push or pull files to the server. This works great even when you’re offline: when you run fossil commit, Fossil will notice that the connection isn’t there, and will prompt you whether to continue the commit. Saying yes will save the changes locally, in which you can just run fossil sync later to synchronize your changes to the server. Of course, for Git and Mercurial users, they can simply turn off autosync with fossil settings autosync off to have their fossil push and fossil pull back. It’s a very elegant solution that I’m surprised I haven’t found any other version controls copying this idea.

Having offline support is boon with the wiki and bug tracker as well. Running fossil server on your own computer lets you open and edit both the wiki and bug tracker on your own computer, even if it’s offline. You can later sync those changes when you get online back again, making the all-in-one application incredibly portable.

Other than that, branching, tagging, and merging are all comparable to Git: excellent. I haven’t had a single conflict at all using those features (to be fair, I’m the only person accessing the repository, so conflicts are unlikely) and it all just worked. The recursive fossil addremove command is also very useful. It searches for any unversioned and missing files to add or remove respectively. The command only got awkward when used before fossil rename, which renames a file (critical for merging files later). Finally, the program performance quite quickly, which is great. Overall, my experience with Fossil has been a very pleasant one…until it crashed.

When Fossil is not awesome

I use Unity, and I import a lot of things from the Unity Asset Store. Importing things from the asset store sadly proved to be a gigantic problem for Fossil. See, Fossil is not only terrible at dealing with large files (like most distributed revision controls are), but also terrible at dealing with very large commits. Perhaps the problem occurs because Fossil puts every revision into a single file, and when you have a ton of file to pack into a single file, it exceeds the computer memory. Regardless of reason, dealing with this problem was aggravating. Sometimes, committing a bunch of small image files would make Fossil crash. That often forced me to make commit in parts. Sometimes, pushing the cloned repository to the server will crash because a commit in your history was too large. This was especially problematic because Fossil has no rebase command to change its history. While I favor the lack of the command, it makes the problem practically unsolvable. This problem alone was enough for me to start looking into alternatives that handles large files.

Other problems I had with Fossil include a bizarre way of creating new wiki pages, which required going to the “Wiki” tab and selecting “Add Wiki”. Creating a list of tickets was awful as well, since the only way to filter and sort your tickets was actually passing in the SQL command to retrieve them. There also isn’t a single-button way to switch the default settings of permissions to the repository from open-source (default) to private, corporate use. Lastly, there isn’t a Tortoise equivalent to Fossil…yet.

When Fossil is…weird

I’ve mentioned earlier that Fossil repositories are all compressed into a single file. This makes cloning in Fossil…weird. To clone a repository served by a CGI script, http://mycompany/repo.cgi, you have to type in the following commands:


fossil clone http://mycompany/repo.cgi repo.fossil
fossil open repo.fossil

It feels weird to have a version control where running fossil clone doesn’t automatically uncompress the files contained in that repository. Still, it does have its advantages. For example, on the the same repo.fossil, you can run fossil close to compress the repository back to a single file, and move the file into a flash drive along with the tiny Fossil executable. From there, just plop the flash drive onto a different computer, move the repository and executable locally, and run fossil open repo.fossil again to continue your work from that computer. I have actually utilized this a few times with Touch Yoga to borrow my colleagues tools. It’s a neat feature, but I question the validity of it.

Hello Mercurial

In any case, I’ve decided to use Mercurial with Redmine wiki and bugtracker moving forward. It handles offline well (useful for traveling), has extensions including one pre-installed extension called largefiles, and even has TortoiseHg for happy Windows users. Converting from Fossil to Mercurial has been pretty easy (though required a bizarre work-around), and making large commits from imported assets is working very smoothly. So far, I’m a happy camper.

P.S. Speaking of Fossil, from what I understand Veracity is a very similar alternative that, on top of a version control, wiki, and task manager, it also comes with an automated build system as well.

Goals and Inspiration

| Taro Omiya

One thing I haven’t done much is make a lot of blog posts. Hopefully this year, I’ll amend that with a lot of technical posts about using Unity and other tools to make this company operate.

First thing, though, I realized I haven’t actually stated anywhere what my main goal and inspiration for making games are. While it’s pretty clear on all the short games I’ve created, it might be a good time to put it into words. I’m personally most inspired by Shigeru Miyamoto and Keita Takahashi for creating entire new game genres, and I really want to follow their footsteps in creating never-before-seen games. Even old game genres still have many different ways to modify and make new again. This has been a common trend with the games I’ve made so far, utilizing a unique or bizarre game mechanic to make the boring old formula feel fresh again. We clearly have a lot more room for new game genres, if endless runners, not-games, and clumsimulations proves anything. I really want to be a part of that, and will inspire to do so these coming years.

Global Game Jam 2014: Do’s and don’ts

| Taro Omiya

Global Game Jam 2014 is just around the corner (this coming Friday, as of when this article was written), so I’m here to make a list of what you should do and shouldn’t do in this wonderfully chaotic event.

Wait, what is Global Game Jam?

Ah, great question! Global Game Jam is an event that takes place around the world where participants team up and make a game (video games, board games, and card games accepted) based on a presented theme within 48 hours. I emphasize that Global Game Jam is a social event, not a competition. Finally, I’ll leave it to Kevin James Wong’s excellent article on why everyone should participate in the Global Game Jam.

Now onto the list!

The Do’s

Do study up on your tools before the Global Game Jam

Time is paramount in Global Game Jam, and anything to reduce it is super-valuable. Learning how to use your tools is one excellent way to reduce the time spent on developing your games. Want to make a 3D video game? You should get started on learning Blender so you can make 3D assets. At minimum, I recommend everyone making video games to learn at least one game engine, such as Unity and GameMaker. On a similar note…

Do bring your laptop and other physical tools

While many sites may have their own computers and craft tools to make board games and card games, I highly recommend bringing your own, anyways. This is especially critical for audio people who likes to bring their own keyboard and synthesizers. The sooner your tools are catered towards your needs, the better.

Do socialize with people

Most sites have a time period in the beginning and at the end of the event where they’ll let you freely socialize with everyone who came. While most of them are going to be strangers, don’t be afraid. This is the perfect time to network, make friends, and even exchange business cards (if you’re into that stuff yet). Most importantly, this is a good time to gauge what you’re getting into. It’s good to know whether the majority of the participants are artists, musicians, programmers, game designers, students, or professionals, to better plan for what team you’re going to build.

Do come up with a crazy game idea

Game jams are the best places to come up with a new game idea. Plus they make great crowd pleasers. I mean, who wouldn’t want to play a game about romantic zombie dinner parties, robotic microbes bent around taking over Canada, observing ice cubes melt in Zimbabwe, or existential horror on an intelligent cat on leash?

Do team up with strangers

I encourage working with people you aren’t familiar with just as much as people you are familiar with. The best teams are those who share the same vision for the game, rather than people who know each other well.

Do take shortcuts and save time

As mentioned before, time is at a premium. You’ll want to use every hack, technique, shortcuts, illusions, and other neat tricks to make your game faster. Don’t worry too much about the quality. All the games from game jams are very shoddy at best. Instead, focus on the vision, the idea you want to convey through the game.

Do show off your game, even if it’s unfinished

No matter how buggy it is, you’ve made a huge achievement within a super-short amount of time. You should be proud, and you should show it. Show off your game, no matter how incomplete. The results may surprise you: someone is going to like it!

Do play with other games

Everyone else is as proud of their own game as you are, and it’s only respectful that you play it and critique it. This is yet another great opportunity to socialize, and more importantly, learn from other people how they made their games. Feel free to share what you like about their game, and what you didn’t. Remember to always provide a reason to your opinion.

The Don’ts

Don’t skip on sleeping or eating

It’s very tempting to skip eating and sleeping when you’re working on a tight deadline, but your health should take a bigger priority. Do sleep and eat. It’s a lot harder than it sounds.

Don’t hate on ideas or completed games

As mentioned before, game jams are the best place to come up with a fresh, new idea. Don’t hurt that by openly rejecting other people’s ideas. That’s both mean and destructive. Instead, provide a reason to why an idea may not be ideal to this situation. Be prepared to listen to any disagreements. They just might be right.

Don’t make a multi-million dollar AAA game

Yes, I know your favorite game is this one super-big budget console/PC game. Me too. But those games takes a very large amount of time and people (typically years), whereas you have only 48 hours. It’s only logical that games of much smaller scope are more ideal for this event.

Don’t leave a mess while working

Since you’ll most likely work in a team, be respectful of them and clean up after yourself. Time-saving is critical, but that is no excuse for terrible hygiene.

Don’t steal assets online and not give credit

It’s highly encouraged in many game jams to use assets online to save time. Remember, though, that you want to check if the asset is licensed for your own non-profit purposes when you take something from the internet. Even if it is, I highly recommend giving the person some credit in your game. They might thank you.

Don’t give up

I won’t lie, Global Game Jam can be very stressful. Finishing a game, though, is incredibly rewarding, one that’s very difficult to describe. The ride might be hell, but trust me, it’s definitely worth it.

Happy New Year, 2015!

| Taro Omiya

Yay, Happy New Years, everyone! It’s time we talk about what to look forward to for 2015!

This month, we have two games coming up. First, Letters From Secret Santa will finally have a public release on January 7th. Second, Global Game Jam is rolling in between the 23rd and 25th, and in fact, we’ll be in MAGFest making our next #OneGameAMonth!

How about some past projects? Well, it looks like we’re delaying Prototype: Murakami again, but not by much. We’re still gearing up from the holiday seasons, but we have started on developing the game again. We’ll be posting some updates about it very, very soon. Lastly, we are considering a fleshed out, full release of Not A Clone for mobile. We’re still looking into the details, but we’ll have more information about it very soon.

Other than that, we’re still committed to the one game every month resolution, so expect coming very, very soon!

Happy 4th of July

| Taro Omiya

Hello, everyone, and Happy 4th of July for us in the US. In the past few weeks, I was swamped by another project with meeting the IndieCade deadline, but it’s fine time I get serious and finish a game this month! I promise more updates will follow in the coming days.

Until then, have fun, and enjoy the fireworks!

In Finding A Niche

| Taro Omiya

I wanted to ask for some advice.  In many game development advice sites, such as the WhatGamesAre.com blog, it’s highly recommended to seek out and join niches (or tribes) that you are interested in.  The theory is simple: not only do you get to make the game you want to make, you’ve also got an audience that will want to play it, and may even volunteer to market it.  It’s worth noting that this strategy doesn’t work for all niches (arguably, most) — which the article above does a wonderful job at identifying which ones wouldn’t work — but I’m pretty confident that the niche I’m in search of are pretty faithful.  I just don’t know where to start.

See, most game genres — and consequently, niches — are defined by gameplay (platformer, first-person shooter, survival horror, need I say more?).  My interest, however, lies not in how the game is played, but rather, how the game feels like when playing.  I’m a huge fan of surrealism.  While I like my fair-share of platformers and first-person shooters, I like it even better when something about feels a little off.  Like how Portalis kind-of, sort-of, not-really first-person shooter, Pikmin is kind-of, sort-of, not-really real-time strategy, Stanley Parable is kind-of, sort-of, not-really not-game, and Katamari Damacy is…Katamari Damacy.  I find those games very appealing, enjoyable, and most importantly, memorable (especially the Stanley Parable).  I’m seeking for a niche that takes interests in those kinds of games.

The only “genre” I can think of that might fit into this definition is WJG: Weird Japanese Games.  Obviously, there’s a niche for anything Japanese, but I’m debating if there might be a similar niche that appreciates weird games made outside of Japan.

Anyway, the first important question is, do you think there is a passionate and large enough niche for these kind of games (i.e. is it worth developing for)?  Second, if there is, where might be a good source to find them (online and offline)?

Thanks in advance for all the help!