When I first started writing Lodestar, I had no idea what I was doing. I read everything related to first-time game creation that I could get my hands on. One of the recurring themes that was thrown at me was: if you want to make a game, don’t write a game engine.
When I read, “Don’t make a game engine!”, regardless of the reasons provided, all I heard was, “You can’t do it!” I felt outraged, like I had to prove that I could do it, that I was smart enough or talented enough, and it was at that point that I decided that I would write my own engine for Lodestar. I told myself, and anyone who asked, that I was doing it because I wanted to learn as much as I could about game engine practices and technology. In retrospect, it would be more truthful to say that I felt like I was the exception to the rule, like I was better or smarter or faster than everyone else who had come before, and, because of that, I could pretentiously disregard the wisdom of my predecessors.
In life, it’s important to challenge yourself and prove to yourself that you are capable, but it’s more important to take what you’ve learned from those personal challenges and use that to your advantage in the future. I’m not just talking about technical skills either. I’m talking about the things you learn about yourself.
Developing an engine has taught me many things, not just about game engines, or the technology involved, but also about myself and my limitations. The most important thing that I learned from my time spent creating an engine is that no matter how smart or fast or talented that I think I am, I am still only one person; the time I have here is finite.
The people that state you should not make a game engine if you want to make games, they aren’t saying that you’re not capable. They are saying don’t waste your time reinventing the wheel. Any wheel you create is not likely to be better than a wheel created and refined by many people who are dedicated to making better wheels.
I made an engine, and I’m happy with it and proud of it. I definitely don’t regret the experience, but what happens when it stops working on X system? I can’t just wait for the next update, “’cause those people are on it.” I have to stop whatever I’m doing and do more engine coding. Sure, I can do it, but the real question is: do I want to spend the time to keep doing it?
Just because you can, or need to prove that you can, doesn’t mean that you should; it doesn’t mean that would be the best way to apply your time. So, before you dive in and go creating the next CryENGINE to power that game, question your motives and be honest with yourself; now is the only time you’ll ever get. Do you want to spend your precious hours making a game or making a game engine? – make your time count.
The size of our team has recently grown and team and data management got pretty wild. Since we’re just about finished with engine development and ready to move into the alpha phase of the game, I figured this would be a good time to set up a server to centralize our resources and services and automatically perform local and offsite backups.
The organization of work items is crucial to maintaining a forward momentum in any project. Being a big fan of YouTrack’s in-browser, keyboard oriented interface, my top choice was a no-brainer. YouTrack provides a free, 10-user agile issue tracking server that can be hosted publicly in the cloud, or downloaded and hosted privately on your own server. We opted to use the downloadable, stand-alone pack and host it on our new server. It was a breeze to set up and will make a powerful addition to our in-house services.
We find it essential to maintain easily accessible and easily editable, in-house documentation. I’ve used MediaWiki in the past and have had a reasonably positive experience with it, but we felt like it was not only overkill, but also not very portable. In my search for a portable, lightweight solution, I ran across DokuWiki. DokuWiki is very portable and, at first, we were able to set it up on a flash drive and just pass it around. With the arrival of a centralized server, we were easily able to move the wiki to the new box, make a couple of modifications, and start using it.
A couple of years ago I wrote a web app with almost the same functionality as the old delicio.us bookmarking and bookmark sharing service. Some of the features of the app include saving urls, tagging urls, sharing urls, networking with other users, and searching urls via tags. It’s very powerful and I thought it would make a good addition to any small team or company that does any kind of research on the web. Users can save their bookmarks, easily locate collections based on subject tags, and network with others with similar interests or who are researching similar topics. After removing several dependencies on an asynchronous job processor from Thistle’s codebase, it was a breeze to integrate into our new server.
To match the new website design we have in the works, we wanted to create a new, unique theme for our forum software, but didn’t want to hassle with developing on the live site. Having a local server with a database and web services made it easy to quickly copy and install a development version of any of our live web software.
A lot of developers prefer to use a familiar visual interface when using MySQL and we’re no different. Since we don’t have a dedicated database tech on hand, we use phpMyAdmin to cut down the time we have to spend looking up query syntax. The visual interface makes MySQL management a breeze.
This category simply allows us to view various logs of interest.
If you’re working with a lot of code, you need version control. Period. We’ve had experience using SVN, Git, and Mercurial, but wanted something different for a long term, scalable solution that is easy to use for everyone, not just programmers. We also needed a solution that would provide access control via a file checkout mechanism. Perforce meets all our needs and provides an excellent visual interface and advanced version management of different file types. We’ve since been able to put all of our code and assets under Perforce version control.
We use Samba to provide a simple group of network accessible folders on the server that we can back up with everything else.
Backups are absolutely necessary. Our system is set up to backup all of our important data locally to a secondary hard disk. From there, the data is duplicated on to a removable USB drive. This is just in case there is an emergency that threatens the server (ie. fire) and someone is on-site who can quickly grab the portable drive. Additionally we encrypt all of our backups and send them to Amazon’s S3.
With the addition of these centralized resources, we will improve our workflow and communication, reduce overhead time, and get down to what we enjoy doing: making games!
When I first started writing the engine for the game, I looked at several different distribution options. Among the top candidates were Desura, BMTMicro, and a DIY approach like Minecraft uses. Ultimately, and quite possibly naively, we chose an in-house DIY approach, not just because it sounded like fun to build, but also because it felt like it would offer us the most flexibility and control.
We picked PayPal because many people seem to trust the service, feel confident using it to make purchases, and we wanted no part in storing sensitive financial data on our servers. After reading horror stories about PayPal and indie game developers, we decided that it would be best if we offered immediate download of the game in it’s current state. That way, PayPal wasn’t likely to freeze our account for review due to pre-orders.
Our system requires the player to create an account, verify by email, purchase Lodestar through PayPal and download the pre-launcher. Next, the player needs to run the pre-launcher. The pre-launcher checks locally and with the server to ensure the player had the latest launcher. The updated launcher then fires up and the player is required to login with their account to download or update the game files. Finally, the updated game launches.
This is currently working great, but I have recently begun to question several aspects of this approach, namely the maintainability, long-term sustainability of the system, and the end user experience.
Every time I receive an error notification from the system, my blood boils and my hair falls out. I get so stressed with the immediacy of the situation that I can barely breathe. Sleep is lost and meals are skipped. People are paying for this and if it’s having a problem, it must be rectified yesterday!
Let’s say enough people purchase the game to keep the servers running for a year, and nobody ever buys the game again. If those people continue to play the game, logging in and updating, long after that year is up, where does the money come from to sustain the server? Additionally, where does the time and money for system maintenance come from? More than likely it comes from the developers pockets, our pockets.
Next up for scrutiny is DRM and the end user experience. As a developer I have mixed feelings about DRM and piracy. I’m not going to digress into debating piracy as this is more about the end user experience. The current distribution and update system was designed with goal of being as seamless as possible. Meaning, the user would download one file, place it anywhere, and go. After the initial download the user would almost never have to worry about manually updating the game. Obviously we wanted to restrict access to the updates to only those who had paid for the game, and that’s where the account system came into play. For some, however, this is a hassle. Surely I would not want to have an account for every game that I play.
The last thing we questioned heavily: does the system restrict opportunity? Yes. Using this system, it would be difficult to participate in the Humble Bundle or IndieGameStand and it would probably be impossible to get on Steam or sell through Desura or any number of other indie game distribution portals. This severely limits our reach right out of the gate.
These thoughts and discussions have led us to the conclusion that we need to disconnect Lodestar from the system, make it stand alone. We have already spent two years developing the engine for the game, and now, we want to develop the game. We want to minimize the time spent on web code, distribution systems, point of sale systems, account systems, system maintenance, etc.
We have already started altering code to this end. Surprisingly we’ve had to alter a significant amount of code where the storage of player data is concerned. We are also working on some other exciting things! We’ll post about those soon.
Several new engine features were added in this version. You’ll notice that there is some placeholder audio to demonstrate the new audio support and, when you transport to a planet surface, there is a high amount of fog/dust and the controllable unit is on fire.
Lodestar Engine: + Support for transparent objects + Support for fog + Integrated particle engine + Soft particles + 3D positional audio * Fixed point light clipping as camera transitions into it
In this update I’ve added ‘dungeons’. I’m calling them dungeons for lack of a better word. Maybe sub-area? Anyway, I’ve left the controllable unit speed hack in place so you can move around and check things out quickly. In the future, the unit definitely won’t move as fast, but there are things…
Initially I decided to expose game data via scripts, or rather through a Java api. The scripts were just java classes that got loaded dynamically at run-time. Now keep in mind I’m just talking about data, not logic. This seemed like an awesome idea at first. Then I started using it.
It quickly became apparent that there was too much overhead, boiler-plate, cruft-shifting type coding going on. If I wanted to add a property to something, first I had to define it in the API, then go write the code to handle populating the value in-game, and finally, go modify the script. On top of that, there was the Java-doc for the API that would have to be kept up to date, not only for the data mapping methods, but also for the logic.
If I have a game entity that has four values, I don’t want to have to define a package, define imports, think of a clever class name (or concoct a new naming convention), write an interface in the API, write the class loading code, write the definition handling code, update the java-doc… ugh. Monolithic Sisyphus syndrome.
After a little thought, I decided to split the data definition from the scripting altogether. Scripts will now simply exist for logic and data will be defined without logic. Not to say that data will be generated illogically. A sniper? Let’s give her a hand-to-hand combat bonus. What? I didn’t see an ‘if-then’! No no… I digress.
The first tech that came to mind was XML. I played about with XML for a bit and then moved on to JSON. XML felt too cumbersome for what I imagined and JSON was a move in the right direction. Google has a pretty robust, open-source Java JSON lib called Gson, and I really liked how easy it was to use and extend. Then I ran across TML…
Thought I’d share my stats on the entire project so far. This count includes the web api, web app, web core, web backend, game client, game server, game pre-launcher, and game launcher. I took care to exclude the PHP libraries that I did not write.
The web core is code shared between the web app and web backend. The web app handles player registration and account maintenance. The game pre-launcher updates the launcher and the launcher handles player authentication and game file updates; both use the web api. The game client and game server authenticate to each other and to the web app via the web api.