The PullableView class tries to mimic the behaviour of the Notification Center view as closely as possible, and is very flexible. You can define and style your handle area, and the view can be pulled from any direction in the X or Y axes. To define the “open” and “closed” states you simply set the center point for the view at these states; if both points have the same X coordinate the sliding will happen in the vertical axis, or the horizontal axis if the Y coordinates are equal. You can also set a flag indicating if the view state should be toggled by simply tapping the handle area.

The sample project includes a view controller which uses 3 pullable views demonstrating many usage scenarios, but if you have additional questions or want to report a bug add a comment to this post.

You can download the source code from our Github repo. I’ve also added this component to the Cocoa Controls website. Hope you find it useful!

When Project A had its first incarnation, 10 years ago, 16-bit color graphics were already pretty common, but in general screen mode 13h (320×200, 256 colors) was all the rage amongst indie developers (at least in the BASIC scene). In that screen mode, and actually in any mode with indexed colors, there’s a neat trick you can use to simulate effects of flow (water, smoke, etc.) called palette rotation or cycling, where the pixels in the image itself remain static, but a range of colors from the palette is cycled in an interval, giving the image a really smooth sense of movement. This web application (requires a canvas enabled browser) shows how effective and beautiful the technique can be when allied to great artistic skill.

So 10 years ago we already wanted the water effects in the game to have a special place, and with the revival of Project A I found myself again experimenting a lot trying to create a cool water animation. 8-bit color modes can be a bit restrictive, so the effect should work on true color modes. Being an iPad app, our options were shaders, standard sprite animation or particle effects. I wanted to avoid shaders since the framework we are using (cocos2d) does not support them (at least yet, support for OpenGL ES2 is already available on test releases) and sprite animations can take a ton of work to look smooth and tileable. So I began experimenting with particle systems.

My first attempt was a full-screen particle system which would stay on a layer with lower z-order than the tilemap, and would move in sync with the camera. While it worked, the performance was dreadful, the water could only flow in one direction and it seemed like such a waste to have a full-screen particle system when it would be obscured by the tilemap most of the time. So I tried a new approach, having smaller particle systems along the water path with various flow directions, and that worked pretty well. After a lot of tweaking to find the balance between number of particles and performance, I added a blue gradient beneath the water layer that stays locked in relation to the camera (a trick I first saw used on the world map in Suikoden 2) and arrived at the effect you can see in the video below (watch it in HD if you can).

There are still problems such as the intersection between the shore and the water (right now things are still a bit “floaty”), but overall I am very pleased with the result. Combined with the positional audio tricks I mentioned in a previous post, the river brings a lot more character to the main village in the game and helps bring it to life, which is always good

Unfortunately, we had no time to write a proper developer diary for this post either, so instead we’ll show you guys a handful of screenshots from the game, illustrating how things are progressing. As always, keep in mind that all of this is still work in progress (and very much so), and therefore there are some things which are pretty finalized (menus, character portraits), while other need a ton more work (environments, enemy sprites). In any case, hope you enjoy! Click the thumbnails to see the images in full size.

The sample project on GitHub has been updated to include this new class and show its usage.

The video

Recording from the iPad – some tips

Ever since we decided to make this video I’ve been reading a lot about ways to capture video from an iPad. The most convenient method would be to record straight from the simulator, but everyone who tried that knows that your game’s performance suffers badly (Project A goes from near constant 60 FPS on the device down to 12-20 FPS on the simulator). An useful tip from lap.felix on the cocos2d forum pointed me in the right direction: I could record the game running five times slower and then speed up the video later. That would work for me, so I proceeded to set up the recording, until I remembered another hurdle…

My development machine is a white 13′ Macbook, and the iPad simulator does not fit the screen at its native resolution (1280×800), even if it is just by a little bit. I went back to the internet to try and find a way to maximize the screen real state, and that’s when I found this great tip on how to hide the menu bar for certain applications. So I did that for the iOS Simulator app and the space savings were just enough for me to be able to capture the full iPad screen size. Hooray!

I ended up liking that menu bar hiding trick so much that I have even been using it even for other apps. By the way, that procedure was tested by me on Snow Leopard, so I don’t know if it still works for Lion. If you manage to test it, please let me know if it works!

Work on our RPG, Project A, has hit a major stride and as we work relentlessly everything is starting to come into place, with the result looking more and more like a game every day, instead of a big mash of components and tests. Today I will share with you some of what has been going on since the last entry on this dev diary.

Also, this post is our foray into the new iDevBlogADay schedule, where we are now assigned to the Monday slot (even tough the schedule is much more loose now, I will still try to post always on Mondays every two weeks). Be sure to check out the iDevBlogADay website, @mysterycoconut has done an absolutely amazing job with it’s renewal.

This is music to my ears

The first thing we are excited to show you is some of the music we have been working on. This piece is played during the game’s first cutscene, and it’s supposed to set an ominous atmosphere while the events unfold, followed by a more introspective second part to go along with the scene as it progresses. There is still a lot of things to tweak and improve, but the general structure of the song is pretty much done.

Here is an Youtube video where you can listen to the song along some screenshots from the intro cutscene at its current state:

Moar screenshots!

Two game systems have evolved a lot these past two weeks, the battle system and the controllable scenes where you can move the player around and interact with NPCs (non-playable characters, for those unfamiliar with the terminology) and elements of the scenery.

Plants and snakes vs. clones!

Battles now are fully playable, including turn order, skills and usage of consumable items. The battle sprite for the main character Andrew is also fully animated in its base stances, along with some common enemies. With the main workflow completed, we are now focusing on enemy AI, UI improvements and overall visual effects.

Nothin' wrong in having a chat with fire!

The dialogue system is completed (based on the text layer and decorated box classes I posted here not so long ago), and this screenshot also shows the first full-size character portrait for Andrew.

That’s it for today! Next time we hope to have some video content to show you guys. Hope some of you are as excited as we are about this game

• Retina display support
• Tweaked user interface and new visual effects
• You can now drag the piece directly from the selector
• Rotation of a piece through the button is now animated

Go check it out and enjoy

…PROJECT A!

(Sorry about that, we do have a name in mind for the game, but we are not ready to release that just yet )

As you may have noticed, the code examples I’ve been publishing for a while are pretty much the basic building blocks for this project, and I now feel confident that we have built enough to start sharing with you guys. Since this is only the first post, I’ll start by showing some concept art and one screenshot of where things stand at the moment. But first, we need to go deeper.

Inception

The year was 2001. Both of us here at Crocodella were finishing the last year of high school, and we were pretty sure of what we wanted to do next: games! Things didn’t quite worked like that immediately, but I’m getting ahead of myself. We had talked a lot about what kind of projects we’d like to work on, and kept getting back to the same point: an old-fashioned JRPG. We grew up playing the greatest masterpieces of the genre on the SNES and Playstation, hell we even met during a tabletop RPG session (GURPS, anyone still plays that?), so the idea of what a great JRPG game should be like was clear in our minds. At the time I was still on my QBASIC days, so that is what we chose to build our game. I focused on the engine and art mostly, while my partner worked on the script and game system details. By the end of the year we had a pretty complete demo/prototype (and pretty advanced as well, with multiple tilemap layers, per-pixel collision and a crude scripting engine), which we sent to some QBASIC related websites, and the feedback was great. And that was the end of it, at least at that time.

We then graduated and went on to our Computer Science courses, and the project went into deep sleep. Fast-forward to 2010. Crocodella Software was already established, and with a few products already under our belt, we decided: it’s time to bring our dream to life! And so the work began anew on Project A, this time targeting the iPad at first. Creating an ambitious RPG from scratch is already quite an undertaking when only two people are involved, so in order to avoid a pitfall of working forever and never releasing anything, we decided to split the game into episodes. And since then we have been working as much as we can on the first episode of the game, which should cover almost the same ground history-wise as the old prototype, but much expanded and improved.

The concept art

Here are two bits of concept art for two of the main characters. These were sketched in a small pad while I was on a plane returning from my honeymoon, and then I took a picture of them with my crappy old Android phone, so pardon the quality

Andrew, stepping on a rock and pointing cheerfully ahead

The first character is Andrew, and he is the “main” character of the game. as well as the focus of the first couple of episodes. He is of royal origin and has a hard destiny to endure (not simply saving the world from an evil lord, we are above that kind of cliche ).

Evan, not really up to much

This is Evan, Andrew’s best friend and mischief companion. Following on the footsteps of his father he is an alchemist/pharmacist wannabe, but with his concoctions causing more harm than good, he still has got a long way to go.

And there you have it, two of the main characters for the first episode of Project A. We’ll get to know more of them in the next installment of this “diary”. Next, a screenshot from the intro cutscene at its current state. The characters and tiles are pretty much finalized, with the exception of some shadows and that glaring dirt patch which needs to be redone, and the fire particle effect is still not ready for prime time. Regardless, here it is:

"Some lizards just want to watch the world burn"

Well, that concludes our first look into Project A. Hope you enjoyed and stay tuned for more details as we make progress in developing the best JRPG since Chrono Trigger

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Pretty box!

This can be used to create a background for menus, dialog boxes, prompts, buttons or any other element in your cocos2d game. It also works wonderfully as a background for the RPG-like text box we introduced earlier.

How it works

The first thing needed is an image to be used as the texture for the box. This image will be broken down into a 3×3 grid of blocks which will be tiled as needed to create a box with any size. The image below illustrates how the image provided in the sample project is divided:

Components of the base texture

The sections marked as “repeats” will be tiled to cover the whole width or height of the box. This is a similar concept to Apple’s own stretchable images, with the difference that in the UIImage implementation the area which repeats is 1-pixel wide, limiting its usage for textured backgrounds.

The DecoratedBox is a subclass of CCSpriteBatchNode, therefore the whole box will be drawn in a single OpenGL call, which should make it pretty efficient. For this particular implementation the image must be a square, and it’s dimensions should be multiples of 3, otherwise you may get some artifacts or seams in the box.

Usage

To create a DecoratedBox you call it’s constructor passing the image to be used and a width and height for your box. Due to the way the box is assembled, the width and height must be multiples of the section size (image size divided by 3). If that is not the case, the dimensions will be rounded down to the nearest valid sizes.

DecoratedBox *box = [DecoratedBox
	decoratedBoxWithFile:@"box.png" width:256 height:128];

If you need to resize the box after it has been created, you can call the resizeToWidth:height: method with the new dimensions. Keep in mind though that this is an expensive operation (all the sprites used to draw the box will be thrown away and recreated) so you should avoid using it in real time situations, such as animations.

The code

A sample project is available on our GitHub, which includes the source code for the DecoratedBox class and a simple CCScene showing its usage by adding two boxes to the scene. As always, any questions, bug reports or improvements can be sent through a comment in this post or any other contact method