Something is starting to come together, although that “something” is yet to be a game exactly. My fifth published iteration now has score keeping, bouncing balls, a pitching/swinging mechanic, and a wall at the end of the outfield (which magically doesn’t stop balls). It works again on mobile too, though the touch event lag that most browsers introduce causes a serious amount of annoyance when batting.
Beginning to get some mechanics in, though I don’t like the feel of them yet. The third prototype introduced new base runner sprites from Jeremy, a “Bat” button, and a non-functional ability to specify which area of the field you wish to target for batting. The fourth prototype made the batting target functional, and added some priority options for batting: chance to hit the ball at all, the power of the hit, and the precision with which it is hit. In the background, strikes, balls, outs, and innings are being tracked, but not the score. And I seem to have broken the mobile touch interface; it will come back in a future version. (more…)
Last night’s brainstorm resulted in very little that was inspiring. “Entire game on one screen” wasn’t exactly a creatively compelling theme. But Jeremy and I chose to go with a baseball-esque theme, with no scrolling of the ball field or extra panels for information. I was hoping I’d be able to come up with some abstraction and modification of baseball mechanics that still retained a core element of fun, but my design efforts didn’t result in many promising thoughts. Before I went to bed, however, I insisted I throw together a tech demo of the ball/shadow graphics that Jeremy recommended. You can view that in my first prototype (just click, touch, or press spacebar to launch baseballs with random trajectories).
In order to give Jeremy something solid to work with for creating some sprites for the players, I added a diamond and some blue elliptical base runners, and subtly improved the size and shadowing of the balls. You can see that in the second prototype.
Now it’s time to actually add some legitimate game mechanics, while Jeremy works on sprites.
Only three hours remaining until the theme for Ludum Dare 31 is announced. I’m gonna have a go at it again, preferably with far more success than Ludum Dare 30. I’ve been in a rather good mental state this past week, and am well rested, so I’m optimistic. And the possibility that the Unicode Snowman will be the chosen theme doesn’t scare me. Not that I have any idea for what I’d make for that theme or any other. I’m fully in the just-wing-it mode of thinking for this one. We’ll see how that goes.
I’m assisted this time by Jeremy Breau of Antithesis Design. The media assets he’ll be creating will no doubt be far better than any weak vector art I would throw together, and having a partner with whom to share the design efforts is always rad.
Meanwhile, the very encouraging interest from Hacker News and reddit this past week, along with a very insightful business suggestion from a friend, has me reconsidering my plans regarding my planet generator. (more…)
I tweeted about a month ago about an “interactive storyboard” that I was working on for my city builder design. But I only made it halfway through my intended development before I got distracted with my planet generation and turn based strategy shenanigans. The result was that I never got it to the point where I was planning to blog about it. Since it is apparently delayed indefinitely, maybe I should at least show what I do have available.
You can try it out yourself here, though be warned that the UI and overall user experience is far from perfect. This was in part an experiment to get a feel for how the interface would function (or not) after all! (more…)
A lot of different steps go into generating the planet, utilizing a variety of algorithms and techniques. They’re not perfect, and some of them are in fact quite finicky, requiring a lot of cautious tweaking of parameters and behaviors. Some of them are bad enough to make me cringe. But they work. At least well enough to make some pretty pictures, and some planets with enough variety that they might be a half decent foundation for some strategy mechanics. So in case anyone might be able to glean some useful ideas from my work, allow me to delve into some of the details (and include tons of colorful pictures along the way). (more…)
Not that there’s much on which to retrospect, since I threw in the towel less than a day into the game jam. My brain simply was unable to appropriately concentrate on the task at hand, no matter how much I tried. Eventually I decided to simply cut my mental losses and not burn an entire weekend on a stressful activity that was clearly going nowhere.
Part of the problem was certainly that I had some personal stuff on my mind. While that overall fact obviously impacted my efficacy with the jam, the details are irrelevant. But there were some aspects of my mental processes that are very relevant to a retrospective. First, and of course most notably, I’ll cover what went poorly, followed by those few elements that actually went well. Such as the physical prototyping you see here on the right. (more…)
It’s time for the Ludum Dare game jam, once again. This trimester I’ll be doing the 3-day jam rather than the 2-day competition, since I might have some outside assistance, and my schedule doesn’t really line up well with a Sunday evening deadline.
Although I’ll note that I’m tempted by the recent release of the Unity 4.6 public beta, and the new GUI contained within. Trouble is, I’m not very proficient with Unity, so it would definitely slow me down during a jam. For some reason, every time I use Unity, I very quickly find myself confused by urges to fight the engine, rather than work with it. So if I go the Unity route, the entire purpose of the jam will simply be to have any game completed to a playable state, whether innovative, fun, or otherwise.
If I focus on game mechanics, however, innovation is generally my objective. This time around, I’m toying with a game style inspired by collectible card games like Magic: The Gathering or Hearthstone. Note the word “inspired”, as I don’t intend to literally create a card game. But there are a lot of fascinating elements that I think can carry over into other game styles, and I’ve recently been working on doing that with some of my larger projects. I don’t have anything to show for those larger projects yet, though, so this might push me to test the waters with some concrete functionality. Always a valuable benefit of doing a game jam.
(crossposted to ludumdare.com)
A few weeks ago I introduced you to what I felt was an impressive little data structure that can provide constant time complexity for the standard operations, stores data contiguously, and provides stable handles that remain valid across all operations other than removing the referenced items themselves. Today I want to extend the basic data structure with some additional functionality which will be focused on iterating over the contiguous items in order. While iterating, we may wish to modify the collection as we go (such as conditionally removing some items). We may also wish to rearrange the items so that a simple linear traversal will also happen to hit the items in a particular order (such as sorting 3D objects from front to back to take advantage of a depth buffer and reduce fill-rate). (more…)
I recently had a spontaneous idea for a card game while reading a game design book (Game Design Workshop: A Playcentric Approach to Creating Innovative Games, very good, highly recommended). After some playtesting, experimentation, and tweaking of the rules, I decided to write up the rules. Regrettably, most of the rule tweaks seemed to fail at improving the gameplay experience, so what I ended up with feels only mildly intriguing, not excellent. But perhaps someone else might be inspired and find a clever way to improve it. (more…)
I recently ran across a couple of blog articles describing a data structure that provides a set of properties that I often am seeking:
- Contiguous data storage, good for linear iteration and maximizing cache utilization
- Constant-time insertion, deletion, and relocation of elements
- Stable external references to elements regardless of internal relocation
- Constant-time look-up from external references without hashing
(The two articles were from the makers of the Molecule Engine and the BitSquid engine, respectively.)
Ludum Dare is over, and my entry, Symptomatic, can be viewed here. (If you want to judge the entry on the Ludum Dare site, you can find it here.) The non-competition jammers are probably wrapping up their 72-hour game jam entries as I type, but having done the 48-hour competition, I’ve had the luxury of relaxing for a full 24 hour already. Time to look back and reflect. (more…)
More than halfway through the competition, and I can only now finally interact with the program. I guess I’ve gotten to the point where I’ve made the toy. And I’ll admit, it’s kinda fund just doodling around with the path. A little confusing at times, though; it isn’t the most intuitive interface. Ah well.
Now to add in the disease and symptoms, in order to give the player some information to go off of, in order to guess at the actual channel arrangements.
I now have a notion of a game world, consisting of both the actual state of cells and their channel arrangements, as well as the player’s guessed arrangements. (Not that there’s yet any interface to let the player guess.) Here’s the latest screenshot; click for a full-size version.
To be honest, I’m surprised that there aren’t too many small cycles. Pure randomness already does a decent job of generating long meandering paths. I was worried that I might need to massage the random data some to get it into a more useful form, but I might be able to work with this as is.
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.
Ludum Dare #29 just started, and I’m jumpin’ in by blogging my first thoughts. The theme is “Beneath the Surface”. (more…)
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…)