Bathtime: Breakout Bats and Unity Physics

Alright, since I need to blog more about development, AND talking to someone about my problems often helps me solve it, this will be the first of potentially many posts where I stream-of-consciousness about a problem until I run solve it or run out of steam. I’ll think of a clever title later.

Right now I’m making a breakout clone, titled Breakthrough until I think of something more original. To avoid programming the physics from scratch, I’m using Unity physics, which isn’t 100% intuitive to me.

Objects using the physics engine to control their motion require a collider and a ‘rigidbody’ component, both of which have several configurable settings. The ball has both of these components, and that’s simple. On a basic level, it just goes.

Blocks have no rigidbody but do have a collider. This means they get collision messages and the ball bounces off them, but they don’t move. That’s good.

The bat is were life gets tricky, since it’s motion is not dictated by the physics engine but by player input, but it has to interact with things that are solely controlled by the physics. So far, I’ve found a few options for dealing with this, some of which work. You can slap on a rigidbody and have player input apply forces to the object. That works, but has a problem, in that the ball bouncing off the bat pushes the bat down.

EUREKA: An idea I haven’t tried is having the bat rebound after it gets hit. This seems like it’d look cool and fix the problems. Not trivial to implement, so I’ll keep going and try it after finishing this post.

I’ve tried to solve this problem two ways. First is to turn on the rigidbody flags that restrict motion in particular directions. This turns out to be a terrible idea, because it apparently makes conservation of momentum break down and makes the ball stop moving.

EUREKA 2: I need to set up a minimum speed for the ball in addition to a max speed to keep unforseen physics quirks from tanking gameplay. Also enforce a minimum amount of the vector being vertical motion to keep from getting stuck in flat trajectories.

The second solution is to jack up the bat’s mass so that the vertical motion imparted upon it is utterly undetectable. That works, but it means you are hitting the ball, massing 1 kilogram, with a bat massing 1 million metric tons. Understandably this transfers a lot of momentum into the ball, making it hit my speed cap pretty hard. Not exactly ideal.

Alternately, I can tag the rigidbody as kinematic and directly manipulate its position. This works, but it feels like some of the bounces of the ball off the moving bat are wrong. This doesn’t particularly surprise me, but I’m not sure if it’s just perception or not. I’m also not sure what to do about it.

If the ball bounces off the immobile blocks when they don’t have rigidbodies, can I just pull the rigidbody off the bat? I haven’t tried that, but it seems as though it’d sacrifice some of the advantage of using the physics engine, namely the ability to impart sideways motion by hitting moving the bat as the ball hits it. This may not be any better or worse than a kinematic rigidbody. I’ll try it.

Turns out that seems to be the best solution. No sudden hyperballs, the bounces all seem right, and I feel like I have more control over where the ball goes than I did before. I guess the moral of the story is once again KISS.

Catching Up

There’s no real excusing the absence of activity here. Fast attack did get finished, you can play it on Kongregate at this link. I’ll be adding a local copy, but at present I don’t get paid in any way for traffic here, and in theory I do get paid for Kongregate traffic. At present that doesn’t amount to much, but as a general rule it seems wise to direct people there for now.

The march game didn’t happen. The April game also didn’t it on time, but something of it might see the light of day in may. A large part of these failures have been due to planning. A goal for may is to make more solid plans, in formalized format, for the games that I’d intended to make already. When I do so, I’ll post the documents here.

The good news is I have been learning. I’ve noticed some patterns to the tasks I have to do to make a game into a game, and I’ve figured out how to easily export Unity packages for re-use later. This will let me repeat myself less often in future games.

So, I’ve got a few more failures under my belt. All I can do is try again. Which is what I’ll do. Wish me luck.

Fast Attack Progress Report 2

Still going well, though not quite as fast as I’d like. Probably won’t have as much polish as the game deserves. Most of what I’ve got done is setting up the game’s code such that it’ll be easier to expand in the future, rather than adding content. But sound, some UI elements, player health, and changes to enemy behavior mean that the game isn’t trivial anymore, and can be lost. Sound also spruces it up quite a bit. It’s definitely a playable game now.

Read more to play the current version.

Continue reading

Fast Attack Progress Report

The goal of Fast Attack is to provide a sense of building speed. I now have a working prototype that hooks several systems into an adjustable acceleration curve, with plenty of room for extension. A playable prototype is embedded below the ‘continue reading’ link.

I like how the game is looking so far, though simple. I should have an minimum-acceptable-release version soon. Plenty of content and polish from there of course. Sound shouldn’t be a problem, but finding the right music for it will take some work. It is far, far closer to a game than Rebound was at this point, though it is a rather simpler game.

Continue reading

1GAM: January and February

I hearby declare my January failure in 1GAM. A declaration which itself is a bit late. This does not mean that I am done with 1GAM.

For me 1GAM is a challenge to my time management skills. Between the other things I want to do, and the things I must do, game development can languish. 1GAM forces me to face the fact that I can’t just put it off till tomorrow, because that doesn’t work. My failure this month does not surprise me, though it is a disappointment.

What now? I start work on my February game. Given that I am treating this as a time management challenge, it would be counterproductive to keep working on Rebound. I will start again and try to produce a game in a month. The very rough prototype of Rebound will have a place on this site until such time in the future as I see fit to revisit it, possibly even this year. But now, I move forward.

I’ve already started work on Fast Attack, a fairly simple top down shoot-em-up with the gimmick that the ship flies faster the longer you play. My goal is to create a sense of breakneck speed that I often find very fun in other games. More to come.

PS: When I rule the world, I’m renaming this month to Febuary.

January Game Update

Rebound has not entirely languished! I have had to cut down my plans some, but the core movement code has firmed up a lot since the initial prototype posted earlier. In fact, an updated prototype is available to be played at the same link as before(Here it is again)

The visuals are going to end up being quite simple. I’ve got what is probably close to final gradable surface art. Heres a screenshot of a level mockup including it with plenty of placeholder other stuff.Level1Prototype

I’ve decided that I won’t try to model, rig, and animate a human form this month. The player will be a bouncy ball, probably with some effects to indicate state. I’m also leaving my ideas of story by the wayside, and settling for just some pure gameplay.

Finally, I’m considering a new name. A game’s name should be somewhat searchable, if you stick it into google you shouldn’t get a wave of other info. Rebound has a fairly populated google result set. The chief alternative is Grab, Jump, Bounce, but I’m not super happy with it yet.

Ten days to go.

The January Game

One Game A Month

This year I have decided to participate in Christer Kaitila’s One Game A Month challenge (henceforth referred to as 1GAM), which means I will be attempting to produce 12 playable games, as finished and polished as possible, within this year. A tall order, but proven possible by some already last year. So lets talk a bit about my game for January.

I have started keeping a file with a list of game mechanics I want to use, and it grows pretty steadily. One of the prime candidates this month was Atomic Space Race, a sort of puzzle game building off of Orbit Toy that challenges the player to plot the fastest course through a star system that hits certain points. It’d build on the existing code and be a considerable step towards the goal of Atomic Space Navy. However, having worked on Orbit Toy pretty intensively lately and knowing that I have committed to 12 games this year, I decided to shelve that for later and find something else to focus on for January, so I skimmed my list and started sticking ideas together.

The result is Rebound, a 2D game about exploring the interior of a space station in freefall. You move by grabbing and ‘climbing’ along surfaces, or by leaping and bouncing off of walls. Since settling on this idea, I’ve worked out a very rough prototype of the movement, playable at this linked page.

I’m excited about this idea, but it has some large hurdles.

  • As I’m not aware of any other games with movement like this, it’s harder to tap the collective knowledge of the internet and find known-good solutions to problems, or even to learn from past failures.
  • More critically, this game demands some level of character animation. I’ve dabbled in character animation in the past, but never from a programmer’s perspective, nor with any of the tools currently available to me. Adding learning the tools to the burden of art production is an ominous prospect. I may be able to skimp on the art side some, but the point of 1GAM is to produce finished games, so that option can only be taken so far.
  • This type of game can live or die on level design. I’ve no practice here. Guess I’m going to get some by the end of the month. The results of my experimentation with this will decide whether Rebound is purely an exploration game, or if I need to include enemies and combat to liven things up.

Sound and music are also obstacles, but plenty of resources exist for those.

I will do my best to keep this blog updated as the game progresses.

Orbit Toy Release 0

SS_00023
The motion of Jupiter and its major moons (click to enlarge)

Orbit Toy is a program that allows you to simulate and view the interactions of celestial bodies over time, through both graphical and command-line interfaces. It began as proof-of-concept work for the Atomic Space Navy project, and will continue to advance along with it.

Orbit Toy can be considered pre-alpha work. It is not feature complete, and the features present have much room for improvement. But at this stage I consider it both usable and potentially useful, so I’m making it available for download. More detailed instructions can be found in the included readme file.

Please note that the command line version is absent from the OS-X version. This is due to my own lack of experience with the platform and current inability to test on it.

SS_00024
The motion of Saturn and it’s moon Titan. (click to enlarge)

The Blog

What This Blog Is About To Be

From here on out this blog shall be the home of my various game development endeavors, chief among them Atomic Space Navy(ASN). The first early steps of ASN should be up for download soon enough. The blog might undergo some mutations as I finally have reason to try to wrangle WordPress into the shape I want, but that remains to be seen

 

What Is Atomic Space Navy

Atomic Space Navy is an in-development game about battle on a solar system scale. It discards as many standard space opera conventions and simplifications as it can get away with, while still striving to make a fun and playable game. Atomic Space Navy itself is still far from ready, even for an alpha build, but some of the steps towards it might be interesting to people on their own. The first such step is Orbit Toy, a program that will simulate and display orbital motion from a user defined start state. An early Orbit Toy release is coming soon, and the plan is to update Orbit Toy as ASN development continues to reflect improvements and updates to the main game. In this way, Orbit Toy will serve as a test-bed for ASN’s UI and systems.

 

What Happened To All The Old Posts?

Before now this blog had some other posts on it, including some prelim ASN art. I’m not especially satisfied with any of the content in those posts, so I’ve removed them from public view for now. Sorry.