Tag: Screenshots

Fast Forward

Either I have become a lot better at game dev, or then Cocos2D v3.3 is awesome.

To be fair, I’ll give the biggest kudos to the Cocos2D team. Compared with version 2, the version 3 line, currently stable at 3.3 with beta of 3.4 coming out any time now, the engine has become excellent. I’ve had some epiphanies about game dev lately, but those come so much easier when working with a clean code base – and Cocos2D lets you have a clean code base now.

Being an old man, I rather do my games in good old code, meaning, I’m not much for drag & drop IDEs like SpriteBuilder, which is the vessel Cocos2D comes nowadays in. Not that those are bad in any way, I’m just used to hack at actual code. And also here: when the engine is as easy as Cocos2D, I don’t think using an IDE is much faster. Any real coder knows anyway, that it’s not the writing of the code which is the big part in the project, but the time between coding, when you’re brainstorming, testing, and planning what’s next to code.

I’ve been doing various tests on the basic game play of Pixelem, and once I got that to a certain point, I got stuck, so my brain decided to “take a quick look on Jungled Baron“. ADD, anyone? To cut a short story even shorter, I got a working prototype of it made in mere three days. It’s actually playable! And seems like fun, even if there are major parts still to be prototyped (such as the power ups).

JungledBaron-ipadProto002

Well, to be fair here also, big kudos to my intern Elma, who is working more or less constantly in the background on the art. This week we’ve been drafting some animations, and there’s a lot of those to be done in the coming weeks. First two animation drafts are already in the prototype, as I was able to whip the character workflows into a fully working shape already.

Furthermore, I had a few hours to think about the scope of Jungled Baron. Came up with some awesome ideas, in my own humble opinion. I need to think about these things all the time, because Elma is on a fixed contract, so I need to scope the artwork so that the time she spends at Sneeweis makes sense. The master plan is to try to finish as much as possible of the actual game (i.e. start scene + playfield scene), and separate out the “additional” stuff for later. This way we will end up with a fully demonstrable version of the game, and think about the implementation of the monetization strategy, additional fun stuff, etc., at a separate step.

The Global Game Jam is on the coming weekend. There will be the Finnish Game Jam version of it at the school which Elma attends. Gonna check it out as a hang-around (…no time to attend the actual game jam…)!

Late Night with Jungled Baron

Nothing good on TV equals good stuff on the computer. Rushed in some concept art into a freshly pressed Cocos2D v3.3 project, just out of curiosity, and naturally to help the artist along. She’ll probably look into color things and such. I’m just pretending the game works already on my iPhone. Beep beep, pew pew, pow! Tee hee, awesome, got a power-up…

First-screenshot-JungedBaron
The sprites don’t actually move, but my imagination doesn’t care.

 

I Almost Scored

For the last two weeks I’ve added a lot of visual stuff into the game, most notably the High Scores screen and several “for fun” animations to all of the screens. Adding those in makes wonders – now I starts to feel like the game I once was designing. And definitely fun to make this stuff. Small stuff, but gives a lot of character to the game. And it’s surprisingly fast and easy to implement!

We’re on the final stretch now, just a few features missing – most prominently the Game Center integration and the small in-game animations. I finally googled smart enough to find out why the animations kept crashing the game, so now all that’s left on that front is to include the proper sprites and animation sequences into the game.

On the Game Center integration front I started with the local score handling. A few minor bug fixes and that’ll be a wrap, after which the Game Center stuff will go in. For that I need to activate the Game Center leaderboards and achievements in my iTunes Connect account, alas I want to do the whole feature separated from other stuff. The testing of it requires also sandbox testing towards the Game Center test servers.

In the meantime I’ll treat you to Screenshot Saturday #4 even if it’s not Saturday!

highscores-screenshot1

For fun

Had I hard week developing your game? Does it once again feel like it’s going to tank? Let a tiny test group play around with non-game-related features, that’ll cheer you up!

Game Over- and High Scores-screen “for fun” animations in an actual test scnenario.

PS. No, “Gangnam Style” is not on the official soundtrack of the game.

Learning To Teach

As I mentioned in the last blog post, I’ve come to realize one really needs to teach one’s customers to use the product. For the last week the tutorial portion of Oggipital has been under construction, and right now it is somewhere between first draft and final implementation. It still lacks the final art, but looking good enough to be used. I want to get one part implemented still, the “Level Up”.

I’ve been quite secretive about the game – not on purpose, though. There’s just not that much to show each Screenshot Saturday in a game with static screens. But as more and more features gets finalized, I will post more and more information about the game here. And I’ve heard Vine is the latest dogs bollocks in social media marketing for indie game developers, so here’s a taste of the tutorial system, revealing a whopping six seconds of the game play idea!

Yes, the video is supposed to loop indefinitely on a 6 second clip in that quality.

Feedback, Schmeedback

“That’s a great milestone!” someone replied to me on Twitter when I was making the announcement of Oggipital, and mentioned it went into beta testing at the same time. Well, beta and beta. Very early beta. But who cares about the wordings of development phases in a small indie game studio anyway.

It is, of course, a great milestone. WIth the announcement and distribution of the game to outside players, it’s kind of the point of no return. If I back out of this NOW…that’ll be embarrassing . Actually, it wouldn’t be in normal circumstances, but my intention is to be – become – a game developer full-time, and for the time well into the future. Plus, my motto is to make games I want to play, so it would be silly to not develop such a game. When I already started to.

But apart from a great milestone it’s a very stressful situation, too. Maybe it is just because it’s my first game announcement, but I had that awful nagging feeling for a full three-four days and nights, “what if this is complete crap, what if I have a really bad bug in there for the testers?”. Even though one should just take it easy and announce games early on and take the feedback from the audience – be it a closed test group, Twitter, or readers of a blog – as constructive criticism, humans seldom work like this. So it’s pretty nerve-wracking to wait for the first real feedback on a game.

Thank Darwin I started the testing with external people. In retrospect I should have done it earlier but I always feel like I need to have some parts of the game near final before I do it. In this case it was the core game mechanics. I closed some serious bugs the last week before beta and did some very needed adjustments to the core mechanics.

And I got immediate and good feedback – first, I was naturally like “screw this!”, but it didn’t take me many hours to see what needs to be done, and then I was back in the creative loop I so love about game development. The feedback was unanimous: the game’s impossible to comprehend without a wayyy clearer way to show beginners how it’s done. And it’s correct – the game has rules which are not logically derivable. Even if there aren’t many rules, not getting the main ones will result in complete player frustration. By “not derivable” I mean rules like “you must cut like this, but you cannot cut like that”, and the “cannot” being just due to a rule I made up, one that you cannot visually spot in the game.

I had only first-revision help pages in the game, available only in-play behind a “?” button. Pushed by the feedback of my testers, I am now implementing an active/interactive tutorial, which is offered as the first thing a new player should do before playing a real round. In addition to being really fun to implement, it teaches me also a way of looking at the game, and gives a fresh view on the gameplay. AND I get really accustomed to Cocos2D animation functions. 🙂

I’m working with draft art on the tutorial still, but for the sake of Screenshot Saturday, enjoy this complimentary shot of the tutorial. It’s on the house!

Oggipital-tutorial-screenshot1
Please pay attention. You there, in the back row! Rought night, last night, eh?

Screenshot Saturday #3 and Various Ramblings

I’ve realized I haven’t really spilled any beans on the first game I’m making. There’s a whole science behind how and when indie developers should announce their game and the general consensus is “as early as possible”, while the other angle being “if I now tell my awesome idea to the public, there will be someone ripping me off and releasing a clone of my game earlier than I can push it out”. Valid points, both of them – just look at the mess the awesome Dutch game studio Vlambeer has been facing. I gotta admit, I have a slight, irrational fear of losing the worth of my work by some a-hole cloning my game idea and releasing it faster than the original. I say irrational, while it is clear I have no real traction in the game development community (YET!) and who the heck would actually stumble upon my idea and decide to clone it. But the issue is a bit deeper than this – my fear is not so much a fear, but a realistic computation of when it actually makes sense to spill my beans. It has to do with the equation of how much I have implemented right now, and how much I have left to do: in case the game announcement gets traction in the press, I, just like anyone, would like to be sure I can push through and get the game out there in due time. Hopefully faster than any competitor. Another factor for me is the state of the art [sic] – I prefer to have the grand part of the graphics of the game finalized/near finalization before making the official announcement. Kind of “having something to show for real”. This could be a Finnish mentality thingy. And perhaps something I drag along from my previous work in a bit heavier financial IT projects.

But I’m sure the announcement and releasing of the next game will be different in the positive meaning. This slight irrational fear is bound to go away when I am more seasoned in game development, I am sure.

Well, the previous post certainly left us with hopes for a more informative blog post. Describing the developer side of the game making is probably interesting mostly to the fellow developers. And there was some features I forgot completely I had actually implemented when I posted the previous post!

Let’s take a look on a more recent screenshot. Please keep in mind that the art is still only mockups. And don’t mind the debug texts there, they are for testing the scene transitions.

The feature I forgot to mention is that red/black bonehead of a guy you see in the screenshot above. Yes, da Oggiput, he’s now in the game, and messing it up but only if you mess up first – he pops into the playfield when the player does an erroneous move. The usage of him has evolved a bit from the original idea: I think I will use him as “lives” in the game, in the traditional “three lives and you’re out” kind of way. That way the game gets a bit more dynamics into it – but rest assured, it is still very unforgiving about errors and will pop up that Game Over screen in no time.

There is only one finalized feature you see in the screenshot – the timer bar on the left. No, the particle effect on it is not finalized. The timer, or “burndown” as I also call it, has a few other uses in the game than just a timer. Surely it will remind you that the time is up once it burns down to the bottom, but if you pay attention to the gradient colors of it, you may see that the gradient’s color, order, and relative size seems to correlate with the Kisau Veelas on the playfield. Wink, wink. This was a fun thing to code, BTW.

Screenshot-level-up

Let’s treat you to another screenshot as I spoke so vastly about scenes and layers in the previous post. The “Level Up” is a feature I came up with while testing the initial prototype of the game and I think this feature gives the game much more longevity. We have, with Pietari, a certain minimalistic take on the game so I have to be careful not to overdo it with new features, but this one is certainly going in. Ta daa, hereby follows the official beanspilling of the goal of the game: to get a high score. Yes, how disappointing. All this just to get some points? Well, arcade games are quite often like that.

And for that purpose the Level Up is a good feature. With only the “Level Up” text and the Play and Menu button as finalized art, you can get a sense of leveling up meaning to get another Kisau Veela into play for the next round, thus making the next round harder. How many you will start with and how many you will end with is still up for tuning on my side, but most likely I’ll go for four Kisau Veelas to start, and six for the last round, thus making three levels in the game. So, in these three levels you’re chasing that highscore to brag with among your friends. A pretty pure gaming experience, in my humble opinion.

Screenshot Saturday #2

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!

kisauveela-proto-screenshot2.png
Box2D debug lines are STILL sexy!

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!

Screenshot Saturday #1

Ah, my first #ScreenshotSaturday! I remember it like it was yesterday…

The drafts from the game art experiments are only for trying out game mechanics. And the prototype is not THAT far yet, alas, I present you one lame…ish screenshot from the prototype! There’s not much you can conclude from this screenshot but let’s leave it like that – future posts will present the game in much more detail. I haven’t even released the name of the game yet!

kisauveela-proto-screenshot1
Box2D debug lines are fancy!

This week I’ve been playing around with TexturePacker and importing the sprite sheets into the build. Excellent tool, by the way, highly recommended if you’re into 2D game development. I particularly like the take the guys from Frogmind have; use as much as possible existing tools, don’t bother developing your own (unless you are aiming to be a tool developer, duh). This is particularly important for small indie teams. Focus on the game mechanics, storytelling, and game polish.

Now that I have a company there is also another aspect of these supporting tools. And that is the supporting of the tools. I’ve gone the whole circle of using warez only (in my early days), moving to free/open source (last 10 years), and now, finally, buying proper licenses. I mean – I can charge like $80 and hour when doing some subcontracting in my previous industry – what kind of excuses can I have for not buying a great tool for $29? Or for $119 for that matter? None. On top of feeling great by supporting fellow coders, there is one ethical rule that trumps everything in this matter: if you are a developer and aim to get your livelihood thru your coding, you cannot use pirated software to do your coding. Especially if you’re a company. Else, that would be like, uh, dunno, awkward and double morals and bad stuff. So buy your licenses or I bomb your country!!1!

Furthermore, this week has been a bit of “architecture” and clean-up. Think “what should I put into a new class, what should I just dump into this big ugly Layer class? I need to get this prototype further – quickly“. So I ended up moving around and renaming properties and classes – having that “HelloWorldLayer.mm” in there is a bit embarrassing. However, every coder knows it’ll ruin the night if you cannot get anything visible done. So I got also a Box2D body moving around according to some states in the game. Felt better immediately!

Alrighty then. I’ll remain with best regards, chilling, coding, and hey, follow us on Twitter! Please! Please? Thanks, dude, you’re awesome! Just like me. We’re awesome, we should hang out together! On Twitter!