As indicated in my previous post, I’m currently going for a game loosely inspired by Minesweeper and SpaceChem. So I have routes that an object will follow, as in SpaceChem, and these routes will be hidden by default, but the player will guess what they are based on other information, as in Minesweeper.
Colors don’t mean anything, but are just to help distinguish overlapping paths. I might remove them if I find that a single color or style is still sufficiently clear. Adding borders along the channel edges might be enough.
This was just rendering. Next step will be to get an actual concept of the game world created, and then determine my input model. After that, it’ll be time to introduce a pathogen.
Having decided to declare my latest project a prototype, and further to declare that it has outlived its usefulness (see my prior post), it’s time for a prototype retrospective.
As I described in my previous post, I failed to outline ahead of time the questions that the prototype would seek to answer, so it’s hard to say whether the prototype achieved its goals. But I can at least go back and infer what those questions might have been, given the answers I have acquired. (more…)
I think it is time to say goodbye to my first major prototype. It’s hard. I want to keep pushing through the hurdles, extending it to the point where it is a fully playable game, even if highly simplistic. I’ve been told that forcing myself to complete projects is important for gaining valuable experience, and I definitely still believe that. But perhaps I was applying that advice incorrectly. For a project that is meant to be shippable, it’s probably great advice. For a project that is meant to be a prototype, it’s important to be able to drop it when the time is right.
Up until now I’ve been ambiguous with myself about what I’ve been working on for the past two months. Was it the beginnings of a shippable game, or was it an early prototype that would inform a future project? I wanted it to be both, but I think now it is valuable to make a clear distinction: I’ve been working on a prototype, and it has now served its purpose and is beginning to outlive its usefulness. (more…)
Understand the data, and understand how it is used.
Over the past few weeks, I’ve been struggling to get past a point of excessive complexity in the simulation code for my city builder prototype. I went through a few different refactoring attempts trying and generally failing to manage the complexity. But the most recent attempt finally appears to have succeeded, and I think it has also has gotten me one step closer to properly grokking data oriented design. (more…)
In beginning the simulation code of my city builder over the past few weeks, I’ve run into some difficulties with integers that quite surprised me. For a variety of reasons, I want to ensure that the simulation code is absolutely completely deterministic, regardless of platform, compiler, machine, or any other variable. While I’d need to do further research to properly justify this statement in all its details, my impression is that this is much easier to guarantee if one sticks to integer computations, avoiding floating point representations of numbers.
Of course, if one uses just integers in all computations (or even the somewhat fancier fixed point variants), then loss of precision becomes more important to deal with, whereas with floating point numbers, one can often get by ignoring such details. Division in particular is the prime culprit. (more…)
Residential, commercial, and industrial zones along a few roads.
Two and a half weeks ago I found myself in a bit of a difficult situation. I was satisfied for the time being with the knowledge I had gained from my pathfinding experiments, and there had recently been some good discussion on Simtropolis regarding traffic simulations. I was left with the question, “What next?” It was a more difficult question than I had anticipated.
After flailing around for a few days, I decided two weeks ago to force myself to do some project planning; I obviously needed the guidance. I had to go through a few stages that I’ll describe below before I had any kind of actionable plan, but what I eventually ended up with was a three week plan. By the end of the three weeks I hoped to have a city builder prototype with what I considered incredibly primitive implementations of the most core elements of what I currently envision as the end product.
Project planning in software development (and other fields, I am sure) is notoriously difficult and unreliable. I’m sure people often question its value. When I came up with my three week plan, I noted on Twitter that it would probably be completely inaccurate by the time the three weeks were up. But even if that were true, it had real value because it gave me a place to start; it gave me traction when I had been spinning my wheels. I am now about half way through that plan, and things are going well. (more…)
After fighting with some silly bugs, and fiddling with map generation and the data structures used to represent the map, I finally reached the point last week where I could begin to assess performance. It was immediately obvious that the pathfinding algorithm was the bane of my program’s execution. Something absurd like 98% of the running time was dedicated to pathfinding. The subsequent operation of following the paths found and adding to congestion was trivial in comparison.
To more effectively focus on just pathfinding, I created a new project that was designed to run two different pathfinding algorithms over the exact same list of origin/destination pairs, and collect both timing data and algorithmic data on each. One of the pathfinding algorithms would generally be a baseline that I had already tested, and the second would involve some form of experimental tweaking.
The tweaks came in two flavors, which I’ll call technical and algorithmic. The technical tweaks were not intended to change behavior significantly, but were only for improving the performance of the operations already being done. The algorithmic tweaks on the other hand were intended to make the A* algorithm behave very differently, with the intention of making it intelligently consider fewer nodes along the way to finding an acceptable path. (Under normal operation for the types of maps I’m dealing with, a basic A* algorithm will consider a large number of nodes that it eventually decides aren’t part of the final best path. It would be nice to just ignore those nodes altogether, but to do that perfectly, the algorithm would need to see into the future.)
By the end, I was able to calculate around 12,000 paths per second on a grid-like map of highways, major roads, and minor roads that was roughly 100 square miles (260 square kilometers) in size. Each path on average was about 7 miles long, and took roughly 7.5 minutes to travel. Larger maps shouldn’t really affect the speed nearly as much as longer paths would. As long as most paths stay around 7 miles in length, the same speeds should remain achievable on larger maps. (The bigger difficulty would largely come from more paths needing to be computed, as there would probably be more people moving around.)
Below is a (perhaps excessively detailed) chronology of tweaks that I went through over the past week. As a summary, though, I’ll note the following takeaways: (more…)
The first regards performance: How long would you be willing to wait for the simulation to process one in-game year?
The second is about interface: What type of transit-related structures would you most like to see have a well designed interface?
The third concerns game mechanics: Which transit network features would you like to have mostly for aesthetic purposes, and which are desired primarily for behavioral control? Which ones are important for both reasons?
Over the past week, I’ve been working on a traffic simulation prototype in order gauge the feasibility of various levels of simulation detail, given typical computation and memory limits of a consumer computer. I’ve made some progress on getting an initial unoptimized representation of the data structures needed, and visualizing the results of basic pathfinding.
But as is usual for me, although my first attempt at writing the A* algorithm for this particular data representation doesn’t violate any legalities of following the graph edges, it most definitely does not reliably find an optimal path, as the image here demonstrates. Three quick right turns would be sufficient, but nope, it has to go through an intersection, make a left turn at another intersection, then a couple of right turns, go back through the intersection where it turned left, through the first intersection that it originally passed, right by its starting point, a final intersection right turn, and then it arrives at its destination. Brilliant!
You can examine some other silly paths on the prototype page. Now to find out what’s causing this absurdity.
This morning I introduced myself over at the city builder game community Simtropolis.com, and have started a discussion about my city builder project. In particular, my first focus is on what a proper implementation of multiplayer might look like. If you are a member of Simtropolis, join in on my intro post and multiplayer discussion, or feel free to post any thoughts here on my blog.
The game concept that has generated the greatest amount excitement for me thus far is a modern large-scale city builder, naturally inspired most strongly by the SimCity series. I have waffled on whether I should even try to make any progress on this project right now, as it is a large one, perhaps monumental, and it is arguably unwise to get bogged down on such a big project right out of the gate. But I gave myself a Christmas gift and allowed myself to take a pause from my other prototype projects and to begin digging into this one. No reason to fight one’s inspiration, and nothing wrong with having multiple projects ongoing. (more…)
The Artist has been added to the About page, as an additional role for which our games will be designed. Roles already listed were the engineer, the executive, and the scientist. Here is the blurb for artists:
Just as the construction of functionality can be fun, the creation of beauty can be immensely rewarding. We want to give our players the tools to realize their imaginations in dynamic virtual worlds, and the opportunities to share those creations with others. We know that our audience has a deep well of potential for creativity, and we hope to inspire such diverse artifacts as impressive cities, colonies, and civilizations, and empires, compelling player-generated narratives, quality in-game content, and fan art.
I was tempted to include a fifth role, The Storyteller, but that’s getting a little excessive. I chose to integrate that in with artistry. After all, the creation and presentation of a compelling narrative is indeed a form of art. (As a side note, this focus on narrative is different from that of most games which treat the player as audience, not as author as I wish to do.)
After recovering from Ludum Dare, I resumed work on my 4X space strategy prototypes. In particular, I wanted to rework the interface before continuing with mechanics, switching to a two-panel layout, with an overall galaxy map in one panel, and then a details panel for whatever object is selected in the galaxy map. I also chose to have some fun with higher quality graphics, using some of the knowledge I gained during Ludum Dare, and made with the assistance of POV-Ray. Prototype #3 was the result. (more…)
Over a week after completing my Ludum Dare entry, I think I’m finally ready to write up a postmortem. I needed that time, because the project wore me out. I’m not even sure I felt like I worked that aggressively, but I think my awareness of the deadline magnified the sense of exhaustion. It was my first game jam, though. Maybe next time I’ll be a bit better adapted to the experience. (more…)
Ludum Dare #28 has concluded, and our official version has been completed. You can head over to the Ludum Dare entry page to rate it. I didn’t get as far as I would have liked, but the important stuff made it in. Hearts, a gun, sound effects, music, a loading screen, and a couple more levels.
The music takes up a bit of space, so for convenience, this game comes in three variants:
Artist mockup. Alas, my “game engine”, if you can call it that, isn’t yet up to the task of fully reproducing this.
Our entry for Ludum Dare #28 reached a proper playable state today, and I’ve had the chance to integrate graphics from Joshua. Gone is my functional but primitive stick figure. Say hello to Mr. Blue Hair and Magenta Undies!
This is the ninth version so far. All versions have been preserved, and can be viewed on my Ludum Dare #28 page.