Okay, after a few nights of good sleep and days not thinking about coding, it’s time for a reflection on my efforts during this past weekend’s Ludum Dare. (For reference, my entry can be viewed here and played here).
As was evident in my earlier posts, I didn’t really have a clear idea of where I was going, design-wise. Even on the last day, I wasn’t quite sure where I would end up, though it was of course much clearer how little time I had left to add any additional mechanics. But I didn’t let that lack of direction prevent me from continuing onward anyway, so that was a success of sorts. All too often, if I don’t know where I’m going, I fail to go anywhere at all. (more…)
Our Ludum Dare 31 entry is finally complete! For some loose definition of complete, anyway. It’s submitted and can poked and prodded, at the very least. Changes since the prior version were minor; I handled the game over state, added a little bit of variation to the pitch to visually indicate if it’s likely to be a ball or strike, included more animations for the runners to take them from 2nd to 3rd to home, and did some minor bug fixing. Haven’t yet discovered what rockets the ball into the sky every once in a while after hitting the back wall. Oh well, someone might find it amusing.
Two more iterations today. Number seven added runners that actually run one base at a time, as well as foul balls and textual announcements of pertinent events. Number eight added regions to the play field that determine the type of play depending upon where the ball comes to rest.
I also have an amazing bug where the ball occasionally flies off into the stratosphere whenever it bounces off of the back wall, or otherwise magically teleports to a different spot on the field. I don’t think my code or my math could survive another day of game jamming. Good thing it’s over soon!
For my sixth iteration, I have added a short wind up animation for the invisible pitcher, to give the player a small heads up that the pitch is happening. I’ve also thrown in some occasionally buggy code to cause the ball to actually bounce off of the back wall, which happens to be infinitely high, despite appearances to the contrary. Sorry, no home runs.
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…)
Out of control elliptical base runners. Who needs rules?
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…)
Physical prototype with Risk cubes and LEGO axles.
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.
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…)
Jesse Schell recently requested brief videos from anyone who likes his book The Art of Game Design. As is obvious from other content on my site, I’m a big fan of the book, so I took the time to begin learning a new skill and recorded a two minute video. It summarizes two key features of the book that have helped me overcome periods of demotivation: guidance on where a designer’s focus should be (helping me to get past a misplaced focus), and fresh perspectives to take advantage of the mental space freed up by stepping away from a ill-chosen focus. Without completely repeating the short video in text, here it is (or view it on YouTube): (more…)
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.