Our target demographic is everyone. It's simple enough that kids can play and enjoy, but isn't limited to any one age group - especially once the game gets rolling as the match progresses.

I'm sorry I broke your hands

We've just finished a one month long project - Kitten Kitchen.

It's a simple HTML5 game built for mobile web and PC and we couldn't be happier with the results!

Play a round or two and tell us what you think! Just click the banner above to get started.

I build my games in a dynamic placement/scaling system I designed. It allows the game to display properly and at full size on any device.

Here's a thread about it with both the dynamic scaling demo and the resutil tool that will help you understand how a game will display on any device.

I'm planning on doing a blog writeup soon on how I did this technique, so hopefully it will be of use to many, as this problem is a common and widespread one.

Thanks for reading through and providing feedback!

— We had made the same mistake as well with BGs taking up waaay too much space, and by the time we realized, it was too late. We elected to reduce BG size rather than recreate them all using different techniques. It wasn't funny for us either

I'm still expanding my knowledge on the whole RAM thing, and am curious about the different image compression in RAM techniques that I didn't know existed at the time of writing the post. If C2 could leverage PVRTC and like methods on a broader scale, it could drastically improve the performance of all games. C2 does some RAM magic on export, but from what I've read the criteria the image has to meet is narrow, so most are rendered 32-bit, and from what I remember I think it doesn't go lower than 16-bit. I'd be interested in being able to get images from 32bpp to 2bpp, taking up 1/16 the space in RAM, especially since most of our artwork is cartoony and would not suffer from lossy compression methods like a photo would.

That said, I know there isn't a standard compression method across platforms, and those images would have to meet a narrow criteria across the board to be utilized in RAM that way, so it wouldn't be an easy implementation. Fun idea to entertain though.

There are a multitude of concepts that people miss when jumping into programming, especially with a streamlined engine like Construct 2!

Ashley and everyone else on this site really come together to help explain these concepts, but sometimes we don't realize we've missed something until it's too late.

In the case of our team, we missed the concept of image RAM and how it affects stability of your app. We designed our first app for the iPad only to realize 90% into the project, our game crashed nonstop. This was because our images took up over 300MB in RAM! It's a miracle it even ran at all.

So what we had to do then was audit and cut back where we could to get our app down to a reasonable size. We were able to cut it down to just under 100MB, but at the cost of image quality reductions, and the end stability still wasn't where we had wanted it.

What I aim to do with this blog post is set people on the right path from the get go with how image RAM works and to provide you the system I used to audit my image RAM. This should help you to get a good visual overview of which of your images are wasting the most RAM and where you can cut the fat.

You can plug in the image asset list from your exported project and the sheet will give you some nice color coded information that isn't too hard on the eyes.

Just click the banner above or, you can click this link too: http://pangolingames.com/how-to-audit-image-ram/

There is a RAM vs Storage overview before it gets to the utility itself, that should hopefully help explain how image download size and image size in RAM are not the same thing.

In any case, I hope you find it an enjoyable and enlightening read!

A0Nasser Of course! And that is a good idea, I had not thought to do a post about the scrolling background technique, it is actual quite simple code and so I will do a blog post about it as well during June.

I am very interested in the graphic side of things and enjoy making special effects, so I will be sure to share what I can about my techniques with the forums to help those who do not understand.

I have always been very picky about graphic technologies in video games I have played, and it seems to be paying off now as I make my own!

— I know that many people struggle with aspect ratios and resolution problems, I decided to tackle the problem once and for all when I realized that games would display differently not only on different devices, but they will also display differently on the same device depending on if there is address bars, and other software bars.

I think the approach I have used is one of the most viable ways of handling this issue as once you implement the base code it is pretty straight forward to be able to place elements on the screen - you must do it by code however - I am not sure if that is how most people do it, but I rarely position objects using the layout editor. The only other limitation I can think of the system is that you cannot use "Is on Layout" behavior, because the layout is always on the left and does not change from it's initial pixel value.

Here is what I mean in case it isn't clear. The red outline represents where the actual layout is at a layout size of 320x480, and the window is stretched to something larger (I think 976x558 px). This is using scale outer for the project setting "Fullscreen in browser" for reference.

And in the meantime until I am able to write up the blog post on the technique, you can try ResUtil. I am not sure if it will help or not for your specific situation, but I built this utility earlier this month to help to visualize which aspect ratios and resolutions to target based on whatever device you load it on, and seeing how your game will scale. Just go to the URL on any device you want to test and it can show you some useful information.

You can test any size on PC by resizing your browser and setting custom sizes.

I hope you find it useful! I also hope that I am not annoying anyone by posting these links in many topics, I want to offer help where I can.

A0Nasser Alright, if I can help even one person, I will put in the time!

I don't have a time frame for it just yet, as I'm not too sure how involved I'll need to make it. Hopefully sometime within June as I have some catching up to do on code first!

DatapawWolf Glad you like it! I just updated it to include the original file I used, so you can compare your work or work off of that file while you go through it.

I'll be writing similar, graphic-based blog posts in the future and actually have intentions to write one about how to fit your game to any size screen/aspect ratio coming up here within a month or so - so stay tuned!

UPDATED: 7/28/14

Now that I am for certain going to be doing a write up on the technical aspects, I've decided to update my progress in the OP.

I know that trying to target any specific resolution or aspect ratio can be infuriating, which is why I designed this object positioning/scaling technique in the first place. Now that I've had a few months to iron out problems, I want to get it in your hands so you can stop worrying about it too!

Here's a demo showing what the dynamic scaling technique does. You can test scaling by stretching the window to any width and height you want and the filler will spawn as necessary, both above/below and to the left/right depending on if the aspect ratio is taller than 3:2 or wider than 3:2.

In anticipation of the dynamic scaling technique write up, you can read some preliminary info about how images scale so that you'll have a better grasp as to what to expect using dynamic scaling.

This blog post was written as an intro to the dynamic scaling post and got out of hand, so it became its own post. If you want a relatively easy to digest run down on what happens when your images are scaled (dynamically or not) then start here!

The next post will describe the actual techniques used in the Dragonfly Zero scaling demo and how to replicate them. That should be ready here sooner rather than later, I hope to have it done within the next month. Sadly it keeps getting postponed due to development projects, school, and my internet being down for a good part of July.

However, the development project keeping me from writing up the dynamic scaling post is also heavily focused on the expansion of the dynamic scaling technique so that it will be able to rotate orientation and reposition objects on the fly. So while I hate to delay it further, by the time I get to the write-up, the technique will be well rounded.

Hey guys!

I've been working on animations for our upcoming game, Dragonfly Zero, and wanted to share the process I used to create the weapon firing animations.

Wasn't sure which subforum to put this in, as it pertains heavily to art. However, it does include a good deal of technical aspects of making the art, so this subforum should work as well as any!

The write-up ended up being pretty long, but I added in pictures and humor where I could to make it more accessible. This post should be useful for artists and non-artists alike!

You can either click the banner at the top, or click this URL: How To: Animate and Light Weapons

Let me know what you guys think!

A few of the animations:

Jayjay Ah, thanks for the example!

If there is anything you guys would like to see it modified to do, I can take a swing at it as well. It's an ongoing project