Art, scope, level design…

Last post, I mentioned my personal debate regarding the art in Automute.  After googling for some images, I found some fairly nice photos I’m going to use.  I just like that idea for some reason, instead of trying to go all pixel-art.  We’ll see, I have yet to try it, but I think it might work well.

That said, the other point I made about going into absurdity.  The more I think about it the more I’m going to spin that off into another game.  Maybe similar mechanics (tap to destroy), but instead moving left/right and with audio as part of the elemental concept, I’m going just go hog-wild and not even worry about “plot” necessarily.  I’m just gonna get nuts and do crazy shit.  Each level should have a consistency, of course, so a desert theme, ice theme.  Picture Mario’s levels or whatever…  You know the stereotypical stuff.  But just get nuts and see what I can throw in to make it as silly and weird as possible…

Scope… This leads me to my original point.  Automute was supposed to be a simple game.  This means I need to get back to that point.  In fact, even easier than my original concept.  I was going to make discrete levels and plot it out, but I think I’m going to go back to programmatically spawning the objects.  I will have “levels” but that’s really just going to be more like Super Hexagon style, after you hit a certain point a new level spawns, with more faster objects, maybe time speeds up, etc… but there won’t be separate points.  Just faster and faster.

Of course this leads to the question: what is failure in this regards?

I don’t know, I’ll have to think about it.  Maybe X missed hits (or x vehicles escape to the other side).  Is this the threshold for movign to the next level – X total vehicles, must destroy a minimum of X to get to the next level, if you miss X you fail the current level, if you destroy more than X through you get bonus stars which you can use as multipliers? or???  Maybe they count towards your future fails, as a “save”… Like, you miss but your previous level you had gone beyond the minimum, which gave you a star to basically blot out the failed shot.  The better you do in early levels, the more you can “spend” to cancel failed in later levels.
Anyways, dynamic generation, not planned levels, I think this makes the most sense for quick gameplay.  Once I get that in, and the vehicles in, I’ll just have to play with the speeds, rates, spawn rates, vehicle types per level and once that’s done, build the menus/UI/high score table, and release 1.0

Scope: Killing Horizon… Going back to scope.  I realized that maybe I should just say fuck it to the deep plot of killing horizon.  Or rather, the deep mechanics.  Forget the achievements concept, the scoring choice system.  I may still keep the Research points, but instead of 4 separate types, I’ll just give one basic point type.  Then the “tree” will just be a set of options each level to pick a new power.

Scope, simplify.  Reduce unnecessary comlexity.  Occam’s Razor shaving all the crud off the games.  Get that shit pushed into the world  No more fucking around, no more playing around, no more wasting time worrying about this or that perfect design concept.  Fuck that noise.  Make a game.  GO!

One small algorithm for man…

So after being in a slump between being sick for the past couple weeks and then just existential/midlife crises…  But in the back of my mind I haven’t stopped mulling the issue around, and last night as I sat down with notebook and pen in hand started to work on the idea, but ended up distracted by stuff online.  But I had a foundation.

Today during my lunch break I sat down and did it, and damn it wasn’t nearly as hard as I was making it out to be.

The problem was the second part of my joystick movement.  My friend helped me figure out which direction to move.  The issue then is that I need to ease in and ease out between where my ship is and where the joystick is located on the circle, otherwise it’s jarring, or I can only move 1 degree per unit of time which is agonizingly slow.

I found Robert Penner’s easing equations along with some other resources on the topic.  The main issue is finding out… well essentially I’m creating a Vector2… A direction and a single magnitude.  The direction I have from my friend’s help, but the magnitude is simply the difference in position between the joystick and the ship.  Oh great!  Until you realize that the shortest way to travel will get you to travel over the starting point on a circle (i.e. moving left  from 360 degrees back to 0) so you can’t just subtract because you’ll have an obvious problem at that juncture.  You have to take that into account.

The solution is different depending on whether you’re traveling left or right towards the joystick…

I tried to think it out and last night I started to draw what amounts to a logic/truth table.  Just two columns: direction.

Then two rows for each column: Ship.position < Joy.position and ship.position > joy.position.

Drew it out, played a bit and within a few minutes had what I think is the solution.
Now to implement it tonight and see how it really turns out, but I got a good feeling about this, and a good feeling about getting back on track on this game…

I have a feeling there’s a more algorithmic solution, after googling and seeing some trigonometric type answers.  But for my purposes I think my solution will be fast enough.  If it isn’t, I’ll try to figure out a better solution.

Joystick and Angular Rotation SLERPing

I was able to get a generic quasi-working  proof of the joystick rotation code as you saw in the last post.  I was able to move towards the joystick location via one direction or another depending on the “moveDirection” variable I created…

One thing that needed to be done was to come up with an algorithm about which way to rotate depending on how close the ship is to the current joystick location.  This is tricky, because a circle “resets” itself.  You can’t just say “if the ship angle is less than joystick, move left; if it’s greater, move right (from the ship’s perspective).  Because if the ship is at 350 degrees (10 degrees “south-east” of pure “east” (which is 0 degrees)) and your joystick is 5 degrees (5 degrees “north east” of the pure 0 degrees east), you would think “oh, it’s greater than 5, so move to the right (i.e. clockwise)… But that’s the long way around; You actually need to determine not merely whether it is greater or lesser, but how close it is to you, and that can be tricky when you have a value that is less than in some instances and more than in others (for example, 356 degrees on the joystick position (instead of 10 as above) would still require my ship to move counterclockwise…  You have to figure out whether the item is within the left or right semicircle from your position first then set your move direction based upon that information.

With the help of a friend we got that fairly simple algorithm figured out…

Then, however…

However, due to the need for a given speed of rotation, I may overshoot the location of the joystick.  That is to say, if I move, say, 4 units of rotation, it’s obvious I may end up going from 3->7 degrees, when the joystick is located at, say, 5 degrees.

One way I could resolve that would be to compensate by going backwards after overshooting, but that’s clearly dumb.  How would you feel if you move forward, overshoot your position and the game automatically “corrects” it for you…  Nope, no dice on that one.

OK, so my next train of thought was to figure out how close I’m getting to the end position then try to reduce my move speed by a certain amount and make sure not to overshoot it.  That’s potentially doable, and in fact, what I’m ultimately going for is a more proper variant.

In fact, there’s this wonderful resource about the technique called “easing”, which is a way to take a stop and end point and apply various functions to determine how an object speeds up/slows down (i.e. easing it’s motion toward the end).  You can do some fancy effects such as bouncing with this.

Unfortunately the code to do this is very linear.  You have point A and point B and you transition between them and apply certain modifiers if you’re at the beginning or ending of the process to reflect the particular effect you’re after.  That’s great and dandy, however, rotation (in particular, rotating around an object) isn’t as clean cut as this page and it’s resources would lead you to believe.  It does provide the basics, but you need to figure out more details about the angles and directions.

Thankfully, someone else had a similar problem/question and the Unity forums provided a starting point to resolve this problem.  “Easing a rotation of RotateAround” gives a couple different ways to attempt to ease a rotation from one point to another.

The problem with that code is that it takes a rotateAmount and a rotateTime.  This will require me to calculate the rotateamount as derived from the position of the ship and the joystick.  The time will necessarily be the total amount of time I want a complete circle’s revolution to be divided by 360.  I will then multiply that value by the total difference between the ship and joystick location to give me the proper amount of time to complete that number of degrees of movement.

I have yet to do this, but I believe one issue that will come up is due to that split  between 359° and 0°.  In addition to merely checking for which direction is the shorter path  to take to the given joystick location, I believe I will have to account for the shift in greater than or lesser than comparisons when shifting between those two values.  I am not sure that is the case, but it’s something I’m preparing myself for in case the need arises.

In the meantime I’m going to figure out the code to determine the amount of  and time for the turn and try to apply it to my joystick/ship positioning code, and see if it gives me a solid approximation of what I’m going for.

One thing I’m not quite certain of right now is what the value of “rotateAmount” is in that rotateAround easing code above.  It may just be 1.0 = 1 full rotation around the circle…  Though thinking about it now, it seems when I played with it, that was related to the “speed” of the rotating object.  Working on code after coming back from a holiday weekend and a few hour drive doesn’t make for the clearest focus on the code, but I think I’m getting there.