I just finished my entry for A Game By Its Cover 2012! It’s called Pink! Pink! Bento Machine and you can download it on the project page.
Updated my games page and added a separate page for compo entries? Check.
Didn’t do any work on my AGBIC entry? Check.
The changes to v1.01 include:
- Added new options menu called “Game” which has a few new game-specific options.
- Added the option to disable the CRT simulation. In this mode, the game will be stretched across the entire screen or window with no regard for aspect ratio.
- Added a handful of options for adjusting the CRT simulation. The brightness of the monitor border can be adjusted, and the border can be toggled off completely. The reflective glare can be adjusted as well.
- Added an alternate control mode for down-jumping. In this mode, you hold down and then press jump to jump down.
- Added an icon that appears anytime the game is saved. This can also be toggled in the game options menu.
- Blocked off exits to rooms that weren’t supposed to be accessible.
- Updated decorations in a handful of rooms.
- Finished code-side localization support. Not yet functional for end users, though.
- Disabled anonymous stats collection.
I also compiled a world map. Be warned; it contains spoilers if you haven’t finished the game yet!
Finally, I finished parsing anonymous user stats for the first two weeks’ activity. In this time, I collected stats from 2933 unique users across 6419 reported sessions. The complete report is available here, but here are some of the highlights (cont.):
It’s done! Go download it!
omg im like ever going to finish a game
I mean, I’ve done a couple of TIGSource compo entries here and there and started countless projects that never really took off, but the last game I finished was Arc, and that was almost four years ago. YHtWtG is this close to being done, though I’m probably going to sit on it for a little while and let my friends and coworkers test it in person before I release it into the wild.
I had been thinking about taking a break from hobby development for a while after this, and I’m certainly going to make an effort to spend more time at the gym (crunching both at work and at home put the kibosh on regular exercise months ago), but I’ve been getting excited about what I could do next.
I’m thinking about going back to a filmic style like what I was aiming for on Arc. For years, I’ve also been wanting to do something kind of abstract and artsy and zen and not-even-really-a-game. (In fact, most of what I enjoyed about Arc, which got a little lost in the shipping version, was just drifting around the environment with the particles floating in waves and the steady static drone swelling and fading in response to the motion.) I’ve been wanting to do something spacey and sci-fi, or maybe sci-fi horror (though I suppose horror and zen might be at odds), but this might be the right project to utilize some of those concepts. After how long it’s taken me to build a relatively small world for YHtWtG, I’m pretty sure I’m ready to go back to the procedural generation well, but I’ve also been toying with the idea of incorporating some sort of hidden asynchronous multiplayer component to a singleplayer game as a way of producing surprising results or automatically compensating for and forcing a shift in patterns and strategies. That feels like an exciting promise and an interesting technical challenge, but I’m always wary of anything that hinges too heavily on player participation (and doubly for so anything requiring constant participation), since that’s such a wildcard for dinky little hobby games like mine. Still could be a fun goal to pursue.
The following is a slightly modified version of a post I made on another forum in regard to the jumping physics in YHtWtG(tBtGWWtG):
I’ve been told the gravity feels a little strong. It’s definitely not a big springy jump, and combined with the moderate walk speed, it’s maybe not as satisfying as getting a big running start and jumping really high and really far in a Mario game or whatever, but for the size of the environments and the fact that the levels don’t scroll, I think it makes sense. I feel like the character has a pretty good sense of weight because of it, but I can’t really be objective there.
You’ll jump a little higher if you keep the button held down, and you can also double jump, although the second jump is significantly shorter.
I spent a while working out the mathematics of jumping. The easiest way to make a character jump in a game is to give him an upward velocity when you press the button and then have some gravitational constant to pull you back down in a smooth parabolic motion. This is easy to implement in code but bad for design work. Velocity and gravitational acceleration are too abstract. I’d much rather say, “I want to be able to jump 4 blocks high and 6 blocks to the side,” or, “I want to jump 4 blocks high in half a second,” or whatever my parameters are and work out the actual velocity and gravitational constants you’ll need from there.
So that’s not too bad. Where it gets trickier is in supporting variable height jumping depending on how long you hold down the button. I debated cutting this feature, but it’s such a staple of platformers that it really felt wrong without it. The problem is that fundamentally, it’s physically impossible. Given a fixed upward velocity and a fixed downward acceleration, you’ll always reach the same height. In order to achieve a different height by keeping the button held down, we have two options. We can either continue to apply a diminishing velocity over time, or we can alter gravity over time. Actually these are nearly synonymous solutions depending on how they’re implemented, but the gravity one feels mathematically nicer to me. So what I do is as long as you keep the button held down, one gravitational constant is used, and if you release the button, a different, larger gravitational constant is used so you’ll get pulled back down sooner.
Some games use separate gravity values for the rise and fall of the jump. The Mario series has always done this, and SMB1 in particular shows it off pretty well. Mario rises to the peak of his jump fairly slowly and then suddenly drops like a stone. Personally, I’m not a big fan of this behavior. It does happen by necessity as part of releasing a jump early and altering gravity, but in general, I prefer a perfect parabolic jump, so I tried to get as close to this as I could even when releasing the button early.
I also made the decision to not put any friction or acceleration on lateral motion. Lateral acceleration is another part of what gives Mario his distinct feel; he has a lot of ramp-up time before he reaches his maximum speed. For some games, that feels good, and I had initially implemented movement this way, but since this game is all about landing jumps with precision, it felt better to me to have an immediate and predictable response. This is actually pretty common in games, too; the Mega Man series notably has never had lateral friction or acceleration. It tends to give the character a very “stable” feel, for lack of a better word (although if the movement speed is very high, it can feel “papery” or “fluttery”).
If you’re interested in this kind of stuff, I’d recommend checking out “Game Feel” by Steve Swink ( http://www.game-feel.com/ ). It’s a pretty thorough overview of exactly these sorts of issues.
Hobby development was a lot more fun before I was trying to make full games, when I was just messing around with random tech demos. Sure, there was always some distant goal of eventually turning one of these into a game, but it almost never happened. And I kind of think I should embrace that.
I rambled about jump physics on the TIGS forum throughout the day. Here is a link.
I also wrote up some pseudocode for how to easily improve numerical integration with Velocity Verlet here.
Sometime last month (or was it September? I’ve lost track of time…), I undertook a large engine refactoring task. After a few weeks of intermittent work, I had a 73-file changelist that didn’t compile and would have taken a good deal more work to finish. I made a local copy of the changes and then reverted them.
A couple days ago, I began this refactoring process a second time, but with a couple of clear goals to avoid another disaster. I would keep my changelists to a minimum, changing one thing at a time, and resolving any issues it created, and insofar as I were able, I would not make changes that would require me to rewrite large amounts of game code, unless the rewrites were to simplify the implementation.
So far, this is going well. I’ve implemented the concept of instanced renderables without requiring each renderable to be instanced, so existing code can remain intact. The next step will be to implement a system by which things which set shader parameters can defer to other things which set shader parameters. In this way, I’ll be able to decouple the renderable from its physical state. This will in turn allow me to move the renderable and the physical state each into its own component. The collision code I wrote for Antikythera and later brought over to The Understory is already built in a way that should be conducive to an entity/component model, so I don’t anticipate much work there.
Once I have the visual and physical elements split out into components, I should be able to deprecate my old “world object” class. This class was derived from the renderable, but it also contained physical information, as it was necessary to have these elements localized to the same object in the past. I don’t intend to delete this class, as many of my existing projects depend on it, but it will no longer be the correct supported path for game objects in the future.
I’ll need to revisit some changes I was making to the component-based entity system in my local copy. The version that’s checked in is mostly a stub; I had done some work to improve the interface for creating and accessing components. One of the issues I’m still looking into is whether I want to allow entities to have more than one component of a given type, as this could cause ambiguities if I try to get components by type.
I’ve been working on most of these changes in Drome, since that gives me a decent amount of test cases so I can make sure I’m not breaking stuff, but once I get into the new tech that won’t affect old projects, I’ll probably switch over to something else. I’m kind of liking the idea of a simple platformer…