Yay! Another screenshot – looks like I could make #ScreenshotSaturday a habit! Of course I will, but the game is still in-game mechanics tuning stage, so it does not lend itself very well to fancy screenshots. Rest assured, there will be much more revealed about the game once we get into the art finalization.
Since the last post the game has sprung from being a prototype into a full-fledged game-in-development. I’m very satisfied with the progress – of which a big part is my progress, meaning how well I progress in becoming a game developer. I think I got both Cocos2D and Box2D pretty well under control by now so I can concentrate more on the game mechanics tuning itself instead of figuring out objects and classes of the said frameworks. I’ve got no formal (commercial) experience with game design & programming so I’m still a bit vary about how my ideas will be on-screen. As a game concept designer, however, I have no reservations of my talent, none whatsoever. I’m most awesome in that, hence the jump into independent game development, right? 🙂
Small digression permitted, I looked into Sprite Kit which comes with iOS7. Apple has clearly noticed that their platform is excellent for gaming and to push in a nice 2D framework for game making is an excellent move. I’m not overly happy with the lack of documentation for Cocos2D, and what I’ve read on Apple’s site, Sprite Kit is essentially a full Cocos2D-like framework with nice, vast documentation and most important, excellent integration of the other iOS parts – as an example the touch input handling, which seems to be kind of a hack in Cocos2D. I mean, the touch moves like two-finger rotate, pinch, zoom-out, multi-finger swipes, are all a central part of the Cocoa framwork and hence they should be easily available also for games. Ending this digression, I have a new game idea which I’m eager to start coding on, and with the introduction of Sprite Kit, I decided that it will be my next game while I want to get my feet wet with Sprite Kit. May my other ten-or-so awesome game ideas forgive me and stay put on my To Do-list.
Oh, I almost forgot the screenshot!
This week’s coding had me improve the shapes of the playfield in Box2D. By building the playfield out of sturdy polygons instead of b2EdgeShapes I got rid of an annoying issue, known to many – the “tunneling” of sprites though the walls, if they are shot against one with enough speed. You can also see a timer on the left, with a particle effect, one of the basic features I have been tinkering with. I bought Particle Designer 2.0 as the integration of particle effects it produces is so straight forward. So far so good, but none of the added FX are final, and there are many more to do. You can also see partly faded-out score multiplier sprites if you pay attention – also a basic feature (not only for this game, but for game programming in general), which I needed to get my head around.
I also programmed some game state logic (welcome back to my life, singletons!) which allows me to test the game mechanics more thoroughly – there are rudimentary “game starting” and “game over”, and some in-between states so the game is, for the first time, playable. Big milestone, pop the champagne!
The game mechanics still need tuning. A lot. Seems like the game would be much more fast-paced than I anticipated, but it might just be my parameter setup playing a prank on me. Luckily this game is no up-front-written-specifications-monster – I go with the flow. That has already resulted in a few completely new, nice features which most likely go into the final game.
I love the creative freedom. Peace and out!