Reviews of my Ludum Dare 32 game Deserializer are going well! Feedback has been very positive, but has also provided some useful critiques. I’m looking forward to the rankings being finalized and published Monday evening.
But I haven’t been sitting still. Although I’m proud of what I accomplished in three days, I know that the game is far from perfect. I believe that the core mechanic of a Frogger-style play field and movement plus pattern-matching is solid, but the specific type of pattern matching and its associated mechanics are definitely not ideal. So yesterday I spent some time away from the computer doing some paper prototyping. After a few iterations of conjuring up and tweaking new rules, I believe I’ve found a game objective that will work better. Allow me to describe a bit of the process I went through. (more…)
Time to take a break from Worldbuilder development, for it is once again a Ludum Dare weekend! This time I’m going to try out Unity 5.0. I’ve dabbled in Unity 4.x in the past, but never quite felt comfortable enough with it to use it for rapid prototyping. I’m looking to remedy that by subjecting my inexperience to the fires of game jam hell.
But before Ludum Dare 32 officially starts, I did want to make sure I am capable of producing at least something playable in Unity in a short period of time, so I made a tiny little vertical shooter. Took around five lazy hours, so I’d say that’s a good sign that I’ll be able to pump something out over a 72-hour timespan. As long as I don’t get paralyzed by game design brain farts.
The game can be played using the experimental WebGL build or the Unity Web Player, and you can grab a Windows build, in 64-bit or 32-bit form. Controls are basic; AD/arrow keys to move left/right, and spacebar/left mouse button to fire. The points you get for each enemy destroyed are proportional to the number of enemies on the screen.
Today I back-ported some of my flat map code from Worldbuilder to the planet generator prototype that I made last year. So for anyone who has been wanting to view a flat map rendition of those really cool planets, but isn’t ready to spend $4 on my Worldbuilder early supporter discount offer, you can give the new version of the old prototype a spin. No procedural generation code was altered, so seeds from the original version will work in this one, generating the same planets as before.
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.
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…)
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…)
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.
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…)
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…)