The Graduate Mechanism a doe-eyed developer-designer in NYC

30Jun/110

Finishing Touched (Sorta)

So I got my four planets, my two suns and my three backgrounds plus menus! Not too shabby especially considering I got all three damage states for each planet. However all that art took a long time so looks like sound, options and level tracking will be left on the cutting room floor for this release. I plan on getting it to at least a couple friends tomorrow to at least write about what improvements should be made even if I can't make them. Hopefully there'll be a few minor ones I can implement realistically.

I think I should have time to create a pause menu that will come up when you click on the sun in the scene. Clever huh. Of course I don't really have time to create a tutorial screen though maybe I'll have a simple label window pop up when you hit config? We'll see what I have time for.

My main problem has been staying focused on the project since I'm doing everything myself. If I were just responsible for the code or art it would be much easier. But since I have to do everything, I find it hard to get started since its so overwhelming and across the board kind of work. Especially now that I'm trying to get everything to a presentable level. I feel like at the moment the game might be too difficult/easy since there's only the one weapons and I've had to make the planets a lot smaller to allow more than a couple on screen. If I had more time, I'd make sever sized versions of each so as you progress the scale starts to feel larger and larger even though the navigation remains fixed. This should be pretty easy to do down the line but its tedious time consuming work I don't have time for right now. I remember a lot of my time at Mindsnacks was just dealing with scaling, reformatting, renaming the assets I created. Thank god for Automator but it was still tedious.

Sadly my Mac is on its last legs. The laptop display is pretty much unusable so I'm restricted to my external monitor alone. Hoping to get an Asus Eee Slate if Microsoft stocks them back in their store so I can get a free 360 (it's part of their back to college deal and I still have a edu address: shhh don't tell!).

After I finish this, hopefully tonight, I'll have to really cram on my independent study but that's just a pass/fail elective so I'm not too worried. I figure as long as I show I worked on it it should be fine since I decided to invest my time in this project which actually matters to me, my grade and my major.

Oh one interesting art note that cropped up during design which I hadn't considered: what angle should the planets be viewed from? Obviously the game itself is in a top down perspective on the system. However my assets are all side on since its more interesting and easier to discern. I figured seeing a bunch of polar caps and concentric circles wouldn't be very interesting so I guess I every system you're destroying has a wonky Uranus like axial tilt (which is parallel to the solar plane). Hell, maybe that's why you're destroying them! Ha!

Filed under: Uncategorized No Comments
25Jun/110

NYC and Art

Almost done with the asset production. Got two suns done. And now I just need to do the planets and finish up the post level menu and I'll be done. Then throwing the assets in should be fairly simple. Finally I'd like to run the "final" product by a couple of people, get some feedback and tweak some odds 'n' ends. Onto work tomorrow and then my voxel renderer.

Filed under: Uncategorized No Comments
16Jun/110

Design Begins

So finally got to the design! And now I'm super rushed so I really don't have as much time as I'd like so I'm just figuring it out as I go. I scrapped the cool vector/neon over realism feel I had in my initial mockups since it requires a lot more precise design and because I have many fewer screen elements in the current version of the game (no weapons, navigation, etc). Maybe in future versions I can go back to that but for the moment I've gone with something easy and that I know: grungy Sci-fi a la Gears of War. Looks good but I've never been a fan of games that go for the "realistic" look on these small platforms since they never come across very well (with rare exceptions of course). But again, doing anything else would require more time on my part to develop and implement a style. Maybe some day in the future.

 

Here's a video showing how it functions and some pics so you can actually see it, damn camera! However, I found that turning the FPS to 15 decreased that annoying flicker. Cheers!

 

As for the back story I mentioned in the above video here it is roughly:

Your home planet, cradle to a great and advanced civilization, has developed a method for getting unlimited energy from its Sun by harvesting it directly from the star itself! However, no one knew that that such cannibalism carried a heavy cost. After centuries of this practice and a rocketing population, your sun is beginning to behave strangely, affecting the environment on the planets in your capital system. Not to mention the increased solar flare activity which has been rocketing the many large orbiting satellite colonies in the system.

You are the vanguard of an effort to stop this runaway disaster. As part of a fleet of sun-eating ships, it is your job to clear away all the planets in the target systems so that the other larger sun-eaters can siphon energy off of the stars for your home system. The sun-eating tech requires a lot of room and no disturbance, so the planets must be demolished or, better yet, fed to their star. However, the sun-eaters are still many lightyears away. Your simply clearing a path on orders. Parked in deep orbit in each system's Oort cloud (that's the cloud of asteroids and crap in deep orbit around our Sun), you gather the detritus of each system's ancient birth and hurl them with unimaginable force at each planet to destroy each, one by one. When your work is done, you move on to the next system, never questioning your orders.

Little do you know your mission was compromised decades ago as time sped by as you flew from your home, faster than light...relativity's a bitch. Something sinister is at work, the only evidence; dust and dead suns.

I like this story arc though I doubt I'll be able to work it into this early version of the game. However, it's great since sequels could easily involve the other major ships: the Sun-Eaters (in this one your a Sun-Smasher obviously), combat and more. God I love my imagination sometimes, I go very cool places!

Filed under: Uncategorized No Comments
14Jun/110

Mechanics Are Done

Well I'm going to call it people! The game mechanics are working just fine. I'm going to now try to get it on the device tonight and make sure it runs all right. I'll also put it through the analyzer to make sure there are no major memory issues or the like. I have today and tomorrow to work on the assets. Then it'll take around a day or so to throw them all in along with any basic sprite animations I might want to consider (e,g rotations, scaling and translation -- no actual animation for now). If I have time I might try and implement some layered sprites (planet and shadow for instance). Sound is a whole other beast however.

Some other features that I may reasonably be able to implement but am leaving on the cutting room floor for now:

  • Storing your high score
  • Level selection
  • Options (don't know what I'd put on there though)
  • Pause Menu

As much as I'd like to add sound, I'm a little afraid of all the extra tweaking that will require. However, if it turns out to be easy I might go ahead and do it. At the very least I'll try and find some spacey Creative Commons licensed music to play at all times. The options menu could allow you to turn it off and on.

Concerning the style/design, I am quite fond of the realistic style I showed during the Alpha. Bonus: I already have three assets to throw in after some tweaking. Con: They'll have to be static aside from maybe some rotation which means the shadows, which are what make them look so good, are going to have to either be stationary or removed and added later as a transparent sprite over top. Obviously the latter would be a good deal of work. For now I think I'll just Have the static shadows but make my files so its easy to remove them and save separately if I can figure out animating the shadows. I feel like having the planet rotate under a static shadow I align to point away from the Sun could look awesome!

For now my goal is to create:

  • 4-5 Planets each with 1-3 damage states
  • 2 Suns possibly with a glow or flare layer to animate on top
  • 3 Outer space backgrounds (Deep Space, Meteor Belt, Nebula)
  • 1 Ship/Turret that points towards your shot
  • 2 Bullets (abstract glowing photon torpedo kind of things)
  • Main Menu buttons - Play, Level Select, Options (only Play will work for now and the background can be one of the space images)

Please enjoy this video of the game mechanics below! The reason you see levels "over lapping" like that is because I have no background set. Easily fixed. I would like to find out if I can have everything shift over as if we are warping from one part of space to the other.

Filed under: Uncategorized No Comments
13Jun/111

Sweet Sweet Progress

Splendid progress going on. Quick post as to not break my workflow. Collisions are now finished. The handlers were pretty easy to set up since Chipmunk takes care of a lot of stuff for you. I extended the shape class to simply have an extra "life" float that I can deduct from and when it reaches 0, the planet is destroyed. Later I could even do cool stuff like calculate damage based on the force exerted in contact. For now each shot or contact with another planet deducts a set amount of life so each planet can take about three hits. The hardest part was figuring out how to clean out all three parts of each planetoid: the sprite, body and shape. My subclass Planetoid worked great since I wrote my own dealloc method that took care of everything for me on every call (however for collisions I had to do it manually since they only return the shape. Note to self for future reference, shapes store their related object and sprite mainly negating the benefit of Planetoid).

I'm now working on level generation using a .plist since it seems the simplest to implement. Its a small XML based text file bundled with the app and in it I'm storing two arrays: "High Scores" and "Levels." "Levels" contains sub-arrays filled with yet further sub-arrays of planets and their properties. And "High Scores" contains, you guessed it, the high scores feature which I am as of yet to implement. However, I'm already calculating the total number of shots fired and the number of planets is evident. I'll probably work out some sort of scoring function as a product of the two variables. I think I good scoring function is as follows (where 'n' is the number of planets in the level and 'm' is the number of shots fired over the course).

  • 100% : m <= n + 2
  • 0% : m > 3n

I think its safe to assume that on most levels, if you do it right, you should be able to get all planets down in about one shot per planet give or take two shots. Likewise if you hit each planet three times to destroy it that's the worst solution. One edge case scenario I haven't yet considered is what happens if a planet gets knocked into a high or highly eccentric orbit such that it's never on screen? I assume this should count as a planet destroyed but its a hard edge-case to check for.

I've had some drawing issues since I'm currently drawing the bullet path using OpenGL directly. I'd like to be able to have this path be low opacity but changing the alpha blending function then messes with the sprite 2D texturing causing them to become boxes. For now I'm going to try adjusting the colors to look like they're blending or I might try spawning sprites instead of drawing, however I feel like that would be way to costly.

Gameplay-wise I've been thinking I'll shift the entire puzzle part over and away from the firing spot to make it a bit more challenging. Plus I think a neat future ability would be to warp to the other side of the solar system for left/right handed people or to get a well aligned shot off. Now that I'm coming to the end, at least for now, of the game mechanic implementation I'd like to enumerate some future features that probably won't make it into my turned in version:

  1. Multiple weapons (laser, shotgun, explosives, etc.)
  2. Control over scene view (magnification, panning, etc.)
  3. Shrapnel on planet destruction (not in Sun)
  4. Dynamic damage based on impact strength and other forces (bullet speed -> using gravity to increase damage!)
  5. Game Center High Scores
  6. Animated sprites (explosions, sun flares, meteors, etc.)

I'm still hoping I'll have enough time to add some basic sounds and such. It really depends on how long the asset creation and then implementation takes. I really want to do some basic sprite animation using the cocos2 actions which are a breeze but will take a good chunk of time. Plus I still need to code in the whole post-level score screen dialogue and a tutorial of some description. Once I have my .plist integration working I'm going to try getting in on the device and seeing how smoothly it runs before getting into further level and asset creation. If only I'd worked this hard the entire time!!! Thank god I didn't try and finish during the year however, would've been a nightmare.

PS: I hope Joe or Norm is reading this. I'm moving to NYC on the 17th but my apartment doesn't have internet set up so it'll be at least a few days before I can start really working again which is why I want to be more or less done by then. I'm hoping to have internet there by the end of that following week but between that, setting up in a new place and my independent credit (god help me) I'm not sure what will happen. My hope is to at least get it into a few friends hands and get some feedback/questionnaires out for the data portion of the project. I'm mainly worried about the independent credit since I really need to do it on my PC and without internet I'm afraid of the intractable problems I might run into. Wish me luck!

Filed under: Update 1 Comment
11Jun/110

To Say Becomes To Do

Well good news! Got my planetoid class up and working and can easily add and delete objects, bullets and planets, from the map. Also, debugged bullet tracking a bit so now it doesn't crash. However it's still drawing the ends of the paths from bullets before so the way I'm resetting my drawing index for the stored vertices must be wrong. O nos! I'll try clearing the arrays all together, should work.

Filed under: Uncategorized No Comments
11Jun/110

Formalized Attire

Keep taking days "off" when I shouldn't. Getting down to the wire. Especially when I consider I've only got two more weeks in whole, I need to do my independent study and to top it all off I'll probably be sans-internet for a good while when I get to NYC since my roommate and I haven't set up the network yet (since he's rarely there and wants to wait till I'm there). Getting nervous.

So I've set about formalizing my messy code into something more organized and modular. Made the mass bodies into a separate class Planetoid which took a stupid amount of time to figure out as it was the first Objective C class I tried to write from scratch. Failing that completely (well my instances couldn't find their methods) I had to copy a basic, and I mean BASIC, example class from a "Learn Cocoa" webpage and paste in my info. I'm guessing I was missing some semicolon or some other minutiae the debugger didn't pick up on. Aw the joys of a new language!

Anyways, everything's back up and working though I still haven't gotten seen removal to work cleanly but I built it into the dealloc method for planetoids so should work nicely. Also there seems to be a bug with my path tracking (the dots behind bullets) but I did hack that together pretty quick. Seems that the array of X and Y coordinates isn't getting passed down to the draw method properly after a few shots...though their global variables so I don't know. My hacky method was to simply store two C arrays (since Objective C arrays are so complex to use for me still) for the last 40 X and Y points logged from the last bullet fired (every 0.01 seconds). Every time a bullets fired, the drawing index is reset.

Hopefully I'll have all this stuff done ASAP since I need to get to level generation, assets and then animations/sound really quickly. Hoping to have at least a week of extra time (while working on extra credit) to debug and game test. Don't know if I'll have time this month but in the future, I could definitely see myself smoothing out the gameplay experience with more animations, score and more. For now I'm trying to keep my goals as realistic as possible while still delivering a fun game experience. Wish me luck!

Filed under: Uncategorized No Comments
9Jun/110

Gameplay Changes

So after a long talk with Jared the other night I've whittled down the gameplay to make it tighter and simpler. So now the player can only shoot from one side in the middle of the screen a la "Snood." Also I got bullet path tracking a la "Angry Birds" working and I have the game draw a circle where you last touched so you can see where exactly you aimed and where it went. See screen shot below.

Still a bit buggy

Hacked together Path Tracking

Currently having some trouble figuring out how to remove an object from the scene since each object consists of a sprite, body and shape for the graphics, physics and collisions respectively. Linking the three so all are deleted at once has proven difficult since they don't seem to have an id property. Trying to create a class and pass an instance of it to the destructor.

Also, upgraded to XCode 4 and got my certificates all sorted out. Haven't tried building onto a device yet since its still a little unstable. Will do soon. XCode 4 is miles away better than 3; the debugging is actually useful!

Filed under: Uncategorized No Comments
8Jun/110

Game Mechanics

I have start off by saying: God I love Cocos2d! It's been a breeze getting my mechanics up and running. I already have the gameplay pretty much done. See the screenshots below. For now I'm going to try and get this basic version done. All I have left to reach a good gameplay test point is collisions. The built in physics collisions are already working so projectiles can hit planets and alter their orbit. Just need to make it so planets will get destroyed after enough projectiles hit them or when they hit the Sun. Then the last real gameplay hurdle will be implementing the procedural level generation from some file.

Firing a Projectile

3 Projectiles in motion with another on the way

I've discussed the game mechanics with Karl (my @Mindsnacks developer friend) and he gave me some great ideas for how the weapons can work to make the gameplay more feasible. The main problem right now is that actually hitting targets with these tiny projectiles will be difficult and making the projectiles larger lessens the scale of the game scene. So we discuss some alternative projectile types. For instance what if each shot fired multiple projectiles like a shot gun?  Another idea I really liked was a laser weapons which shoots a beam in a straight line for a short duration to hit those pesky moving targets. Lastly I would like to implement some kind of explosive but that would not only require a good bit more work but also even more instruction to the player since there would have to be some way of detonating it. At the moment each projectile will have a limited lifetime after which it is removed from the scene.

I don't know if I'll get around to having planets create shrapnel upon destruction (except in the sun of course). It would be hard to implement and might make the game to easy if shrapnel is flying around everywhere. With appropriate balance (aka shrapnel lasts a very short time) it might work but I'll save that till after a first play test.

All in all I feel like a have some good player interaction going. As the player drags out a projectile vector with a touch and drag gesture, the color of the shot source areas goes from blue to red and the vector line itself gets thicker (good old interpolation!). I'm anxious to put it on a device and see if having your finger in the way will be a serious problem when trying to hit targets.

Segue: my (future) boss hooked me up with developer access! I'm going to start downloading  XCode 4 tonight and upgrade once its done (its a huge file and we only have DSL sadly), hopefully it won't break anything too seriously. Plus I can now easily put my game on a device...once I figure out how to use the credentials. Woot!

Filed under: Images, Update No Comments
4Jun/110

Coming Together into a Whole

So did a bit more work this afternoon and got a bare bones menu transitioning into my test scene. RESULT! Talked to my developer friend about overall layout for levels etc. He recommended JSON or CSV as good tools for storing level data. Its either that or create my own (probably just a .txt file) which I'll parse for each level's planet configuration.

Also, I've been thinking more about game play and have come to the conclusion that interacting with the planets directly is a silly and infeasible idea. Every design idea I came up with along that path resulted in "Osmosis" leading me to believe that their design solution is the optimal one for such an experience. Instead, I've come up with the idea of a more "Break Out" or "Asteroids" style of turn based game play. This also makes my job a bit easier since I don't have to worry as much about the planets themselves.

Instead of altering the planetary paths, the player will fire projectiles into the level from specified points. At the moment I feel that a layout along the lines of the sketch below would be the best:

Two Versions

Alternative interaction methods in landscape

There is the persistent problem of scale. Having to zoom the levels in and out will be difficult if not impossible (tomorrow's challenge?). Furthermore, it would demand that projectiles can be fired from a variety of distances when a fixed location makes more sense. However that's why I feel that restricting the firing range to one side would be best. Then, no matter what scale the player is at, the projectile will fire from that side of the screen. Of course then there's the issue of timing the flight of a projectile where you don't know what distance it's being fired from. This could be resolved by yet another change: one tap to fire and another to explode the projectile. Different projectiles could have different areas of effect or even different properties if I want to get fancy.

 

One of the benefits of such a change is that if makes scoring performance much easier. The more shots it takes, the worse your score. If you manage to destroy multiple planets with one shot, bonus. Etc.

Filed under: Uncategorized No Comments