I stayed up far too late last night tinkering with a side project, which, I’m happy to say, is working! It’s a little PHP app that simply takes incoming POST data from a GitLab webhook triggered when you git push, parses the commit messages, and executes YouTrack commands via their API. Today I spent a little time bug-fixing and a lot of time working on mockups for the GUI in Pencil.
After thinking a little bit about the equipment assignment solution that I came up with yesterday, I noticed a glaring flaw. I forgot to include non-player entities in the problem domain. The system that governs the players’ inventory manages the `InventoryItemID`, which is basically just a long assigned to an item entity upon addition to the inventory. The item ID is then used as a reference by the system that governs units equipment slots. This works awesome! For players.
I haven’t updated in a while because I haven’t written any code or produced any flashy images.
Instead, I decided that it was high time I sat down and wrote a document outlining the inner workings of absolutely every mechanic and all the math required to support those mechanics.
We now have a 63 page game mechanics document! Over sixty pages of rules, tables, lists and math!
I have no doubt that everything will need to be tweaked, massaged, and finessed before an accurate final version can be announced, but having this document will dramatically decrease development time. I found that without a clear definition of mechanics, I was spending too much time redesigning and refactoring; one step forward, slip and fall on face.
If you hit the ground running and have no clear destination, you’re likely to run in the wrong direction. Knowing roughly where you’re going is more important than knowing how you’re going to get there.
I’ve said it before, but this is a reminder to have a look at SudoPlay Games’ Lodestar.
Exploring the blog as a game player, you can see there’s something big going on here, with network and exploration elements, a distinct take on voxel art, full website and forums, and the ability to buy the game and play early alphas.
Looking around as a game dev, the project is stunning. It looks to have amassed a huge arsenal of development tools, while bringing in every game engine feature and rendering technique you’ve ever heard of and always looking great.
I’ve been following the progress of this project for years. Despite having made the same mistake I did (don’t write a game engine!), the project has endured, going through at least two game engines and three different UI libraries. I steal liberally from the juicy graphics programming tips that lead dev Jason occasionally posts. For a while we were having a lines-of-code race, but then I switched projects and lost. (His language is Java and mine is usually C; I was doomed from the outset.)
Go see what’s going on, and maybe give it a poke. It’s been six months since the last build and the project deserves some supporter love.
The other night, over dinner, Susie and I hand a nice, long, productive discussion about currency in the Lodestar universe; mostly its purpose as a game component and how it integrates into the setting.
In the Beginning
After many generations of space travel, the Sisyphus landed on the surface of Protos and buried itself deep below the surface of the planet. It currently rests near the core, far enough below the surface where the stellar ejecta from the system’s rare ternary stars cannot reach it. This rare system and its radiation is the reason the ship was drawn to this planet in the first place.
Using the warmth from its proximity to the planet’s core, the ship’s governing system was able to shut down most of the energy flow used to keep the symbiant species, humans, alive. The energy used to warm the habitat and fly the ship was redirected to the surface to power the alien sub-quantum nanotech and build an initial paraterraforming dome. The structure not only acts as a terraforming dome and radiation shield, it also collects the radiation and other stellar particles from the frequent novae bursts that Protos must endure. This collected energy is then processed and refined into a form that can power the terraforming technology inside the dome.
Once the terraforming of the first collector dome was complete, people were sent to the surface to establish an outpost. The established outpost used the energy collected to power its various bits of technology like the Sub-quantum Location Interchange Protocol (SLIP) transport and the Matter Replication and Assembly Tools (M-RATs).
When the game begins, the player is sent to the surface with a small team of people to discover why communication with the outpost has been lost. Energy flow appears as a percentage of the capacity of the system. In the beginning the energy flow is minimal as energy is flowing from only one collector. As the player explores sectors, they will find other collectors that have finished terraforming and they can divert the energy flow from the terraforming process to their outpost. Energy collectors appear on the surface of Protos and only one can be found per sector. Diverting energy flow from collectors will increase the energy flow at the player’s outpost and allow them to create more items, create better items, and transport farther away. Players will be able to transport from the outpost to any of the diverted collectors.
Energy does not go away when it’s used, it’s merely an indication of the available power level. It can be stored in energy tanks that are refilled at the outpost. The larger energy tanks take a higher energy flow to fill, but last longer in the field. Energy tanks are used to power vehicles which, in turn, allow the player to move over terrain at an increased speed. Energy may also be used to power other things.
Periodically energy collectors that have been previously diverted may come under attack or fall into disrepair. When this happens, an event will trigger and the player will be notified. If the player chooses, they can participate in the event and defend or repair the collector in question. If a collector is lost, its contribution to the outpost’s energy flow is also lost. The player would then have to travel back to the collector and repair it to regain the energy flow.
Once enough energy collectors have been diverted and the outpost’s energy flow is at maximum, the collector’s defense and repair systems come online and it is no longer necessary to protect or repair them. By this time, the player should be close to leaving the first planet, Protos, to explore the other celestial bodies in the system.
Matter is Lodestar’s currency. Instead of buying items with it, however, the player consumes it when replicating items from blueprints. The player must have the required blueprint, matter and energy level to replicate an item.
While the energy collectors are found above ground, as a direct result of the terraforming domes, matter is found underground in caves and tunnels and comes in varying degrees of quality. Low quality matter is contaminated with non-usable material, but can be refined into a higher quality of matter. Players can also trade matter and items with each other and matter can sometimes be found at the end of encounters.
In the beginning of the game, the player has access to all of the blueprints in the Sisyphus’ database. After the player leaves the first planet, they will have the opportunity to discover new items and scan them into the ship’s database. In addition, the planets that become available as the game progresses offer higher quality matter. When an item is scanned, the item is consumed and a new blueprint is created. The blueprint can then be used by any player in the game and it never goes away.
grabbed your beta today, dont really know what im doing but it's still pretty cool
Awesome! Thanks for your support! Yeah, I haven’t updated in about four months… so much has changed and I’m working on getting it stable to distribute again; real close. In the version you have, there’s really not much to do, just walk around and find dungeon entrances (large purplish cubes). I’m still working on getting all the systems in place.
I’m interested in playing Deko Dungeons, when will it be available?
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…