Merry Christmas and a Happy New Year!

To all readers! Merry Xmas and a Happy New Year,

As you're all probably aware, I've taken a bit of a break from tutorials etc for the time being but let me assure you come the new year I'll be starting them up again!

Thanks for your ongoing support and for those members that have joined up to my YouTube channel!

Cheers,

David.

Blog Update

Really quick post - updated the look of the blog (as you can obviously see.) I've also put in some links across the top bar, you can now visit the youtube channel directly if you want to watch a series of movies one after the other, and I've also made another page which has each of the tutorials listed, incase you wanted to watch a specific tutorial again.

Cheers,

David

Nape and Flash Develop - Tutorial 2: Sprites!

Hey guys,

Here's the second part in the series of tutorials I'm running on Nape physics engine, this tutorial goes over sprites and how to get them into your game!



Let me know what you all think and as I say at the end of this movie, part three is going to deal with joints and moving objects with the mouse!

Thanks guys,

David

Box2D and Flash Develop - Tutorial 2: Sprites

Hey guys, here's the second part in my Box2D tutorial series, it's fairly short, but goes over the important method of how to give physics bodies a physical representation!




As always if you go to my youtube page you'll get the link to the github repo to download source code if you're lazy and don't want to type it out yourself! :P As I say in the movie, part three will be out soon enough with how to do joints! Thanks guys! David

PxlSmshBox2D

Hey guys, here's a video that I've been wanting to post up for quite some time about Pixel Smash, a funky little thing developed by the guys over at Photon Storm, basically it couples pixel art with the ability to back it with physics. Makes for some really cool effects etc. I've taken some time to develop out the code into Box2D and have put it onto my GitHub account here.

I hinted that I was going to write a video about this last time and here it is:




I'm working on pulling down the amount of "uuuuums" and "aaaaahs" that I say, but bear with me, I'm not used to recording what I do :).

I'm going to be working on this project till I figure out it's either impossible or what's wrong with it, I'm hoping I come across the latter, and am able to produce a fully working version for you all.

Thanks heaps!

David.

Musings of a occupational nature.

Hey team,

Just wanted to post up a little bit of info on why there's been a massive gap in-between posts (again.) Well, to put it plainly, daddy needs a job, or I can't buy nice things. As I'm sure some of you have dealt with first hand - the games industry within Australia is very very very small, and getting smaller by the day. And subsequently, the skillset that one possesses in order to become a successful applicant of the games studios left in Melbourne is getting bigger and bigger, almost beyond what one person can learn and demonstrate with no proir experience within the industry.

This poses a Catch 22 problem (my favorite,) one is unable to obtain a job as one doesn't have experience within the industry, and yet, the only jobs that are obtainable to gain said experience, themselves request that experience within the industry be had as a requisite for applying.

As such, it's come to my attention that the games industry, by and large is NOT the way that any young programmer / designer / smart guy should look. And that's not to say that any readers should be perturbed from reading further, don't lose faith just yet. I haven't finished. As I said - the issue is that to earn a LIVING off of creating computer games, is next to impossible. And for myself, that's certainly something that's very hard to let go of, from day one of Uni I've thought of working in a team of professionals creating the next big game, and in reality, it's just not happening any more. So - where do you go from here? I'm putting games to the back of my mind, into the drawer marked "one day, but not today." Because I know that there are a lot of good ideas swimming around out there, in the ether, and certainly many in my own head. But in the mean time, I need to focus in on what is important, and that's getting a job.

As a consequence (I say that, but it's not really,) I'm going to be pushing out a new Flash program which I'm yet to name. The purpose of the program is to allow mobile app developers that have selected the Flash environment to monetize their app. There are a huge number of mobile networks to chose from - InMobi, AdMob, Millennial Media, Tapjoy, JumpTap, Inner-Active - the list goes on and on and on and on. What I intend to create is a method by which, a user can simple enter in which network their app is to choose and then issue a simple call which will display the ad at a given location.

I will be developing this as an open source project and would love for anyone that thinks they have something important to input to take part. This will be the first step, developing this "Network Selector." Where I plan to go with it? Well, suffice to say, Australia is yet to have a fully Developed Mobile Network, and it's a very lucrative and economically advantageous thing to take part in.

Stay tuned.

David.

P.S. I won't stop with my physics engine tutorials, I started them and intend to continue, if you have a good idea for a tutorial, email me!

Box2D Pixel Smash... Or not.

Hey guys,

A while ago I came across this awesome little program made by Photon Storm called Pixel Smash, which is essentially a really cool way to mix pixel 8-bit like games with modern day graphics. Check it out here, as you can see, there are quite a number of possibilities that come to mind when you've got what is essentially a destructible pixel environment (think Modern Warfare 2D or similar) how cool!!?

One thing that this particular demo got me on to was of course Nape, as this is the engine that is powering it. However, as many flash developers are aware, the major physics engine of favor in and among game titles is of course Box2D, so I went about porting the Nape Pixel Smash example over to Box2D, with outstandingly disappointing results, I use a simple plugin class called "stats" which was developed by a guy called Mr Doob, and can be githubbed here, which gives you an awesome looking run down of what framerate you're running, how many objects you've got in your scene and also monitors memory and even refresh rates.

Here's the annoying thing though, the Pixel Smash Nape demo gave me a steady 60fps, with 1017 objects and a refresh rate of around 17ms. Now, when I run my Box2D version of it:









Suffice to say, pretty disappointing, and this is with an image that only generates 236 objects! For the purpose of this I've opened up a github account and y'all can browse and pickup the code there.

https://github.com/SPGamesStudio/Pixel-Smash-Box2D

Be gentle with me, still learning all the stuff that goes with github, so I hope it's all working.

Anyway, basically, the major problem with the Box2D version (I think) is that when the objects spawn into the world, they are all colliding off of one another. So if every object has 8 objects surrounding it, all colliding together, then that's a problem and very computationally hard.

So, with that, I am still at a loss as to how to improve the performance of the Box2D version, if you feel so inclined, feel free to grab the code off of github. And remember, credit given where it's due, this isn't my code to start with, I simple ported it. It's really Rich Daveys' from Photon Storm, I just played with it and got it to Box2D. I'm now in the process of re-writing the code in Nape with the most recent milestone, and will probably end up making a little movie out of it, we shall see.

In the mean time, yeah, get on it! Github it up people!!!

David

Nape and Flash Develop - Tutorial 1: Hello Nape World

Hey guys, Just made another movie for ya'll, this one is a implementation of the much lighter physics engine Nape, here it is! Let me know your thoughts!

 

package 
{
 import flash.display.Sprite;
 import flash.events.Event;
 import nape.geom.Vec2;
 import nape.phys.Body;
 import nape.phys.BodyType;
 import nape.shape.Polygon;
 import nape.space.Space;
 import nape.util.ShapeDebug;
 
 /**
  * ...
  * @author Sp Games
  */
 public class Main extends Sprite 
 {  
  public function Main():void 
  {
   var space:Space = new Space(new Vec2(0, 600));
   
   var debug:ShapeDebug = new ShapeDebug(600, 600, 0x333333);
   addChild(debug.display);
   
   var border:Body = new Body(BodyType.STATIC);
    border.shapes.add(new Polygon(Polygon.rect(0, 0, -40, 600)));
    border.shapes.add(new Polygon(Polygon.rect(600,0,40,600)));
    border.shapes.add(new Polygon(Polygon.rect(0,0,600,-40)));
    border.shapes.add(new Polygon(Polygon.rect(0, 600, 600, 40)));
   border.space = space;
   
   var block:Polygon = new Polygon(Polygon.box(50, 50));
   var body:Body = new Body(BodyType.DYNAMIC);
   
   body.shapes.add(block);
   body.position.setxy(stage.stageWidth / 2, stage.stageHeight / 2);
   body.space = space;
   
   addEventListener(Event.ENTER_FRAME, function (_:Event):void {
    debug.clear();
    space.step(1 / stage.frameRate, 10, 10);
    debug.draw(space);
    debug.flush();
   });
  }  
 }
 
}

Thanks again guys.

Tutorial 1: Hello Box World!

Hey Team, Here is the first in my series of Flash Develop Tutorials, this is entitled: Box2D Hello Box World! Super excited to be hearing my voice on the YouTubes. It was only a matter of time...

  Here is the source code that you will end up with once you have finished this tutorial. In the future, and as the tutorials get bigger, I'll get a github account to upload to otherwise my blogs are going to get even longer :O.

package 
{
 import Box2D.Collision.Shapes.b2CircleShape;
 import Box2D.Common.Math.b2Vec2;
 import Box2D.Dynamics.b2BodyDef;
 import Box2D.Dynamics.b2Body;
 import Box2D.Dynamics.b2DebugDraw;
 import Box2D.Dynamics.b2FixtureDef;
 import Box2D.Dynamics.b2World;
 import flash.display.Sprite;
 import flash.events.Event;
 
 /**
  * ...
  * @author Sp Games
  */
 public class Main extends Sprite 
 {
  public var world_scale:Number = 30;
  public var world:b2World = new b2World(new b2Vec2(0, 9.8), true);
  
  public function Main():void 
  {
   addEventListener(Event.ENTER_FRAME, update);
   add_circle();
   debug_draw();
  }
  
  public function add_circle():void 
  {
   var my_body:b2BodyDef = new b2BodyDef();
   my_body.position.Set((stage.stageWidth / 2) / world_scale, 
                                                        (stage.stageHeight / 2) / world_scale);
   my_body.type = b2Body.b2_dynamicBody;
   var my_circle:b2CircleShape = new b2CircleShape(10 / world_scale);
   var my_fixture:b2FixtureDef = new b2FixtureDef();
   my_fixture.shape = my_circle;
   my_fixture.density = 1.0;
   my_fixture.friction = 1;
   var body:b2Body = world.CreateBody(my_body);
   body.CreateFixture(my_fixture);
  }
  
  
  public function debug_draw():void {    
   var debug_draw:b2DebugDraw = new b2DebugDraw();
   var debug_sprite:Sprite = new Sprite();
   addChild(debug_sprite);
   debug_draw.SetSprite(debug_sprite);
   debug_draw.SetDrawScale(world_scale);
   debug_draw.SetFlags(b2DebugDraw.e_shapeBit);
   world.SetDebugDraw(debug_draw);   
  }
  
  private function update(e:Event):void 
  {
   world.Step(1 / 30, 10, 10);
   world.ClearForces();
   world.DrawDebugData();
  }
  
 }
 
}

Radio Silence

Hey gang,

This is going to be a pretty long post as there is quite a lot to cover and I want to go over everything. So, as anyone who reads my blog is aware, there has been a long time since the last post, there has also been a lot of things happening on my end but I won't make up excuses, I've been lazy. I've also been flagging at my app idea, which, unfortunately, is now in the trash can until such times that I can be bothered to pick it back up again.

The issue with Flip the Switch (it got a name!) was that it was structurally broken from day 1, there are so many holes in the code as we speak that the more efficient way for me to fix it would be for me to start again - which, co-incidentally I'm doing! My major gripes so far with developing for Android with Flash, and anyone who is thinking of getting into the market as well, please consider this list before you get started, as it'll save you a lot of time in the long run.

 - Flash to Android debugging; is a really annoying thing to set up and to run in the background whilst you micro-manage code. It's fiddly and if you run a few harddrives on your computer like me, you can spend ages with annoying error codes in Flash Builder as one thing can't see another thing etc. etc.

- Android Manifest.xml editing; this one is slightly my fault, I will admit, but I'm yet to come to a suitable fix for the issue as well. There is one thing that will always get game developers when you start developing for android - you have to deal with different resolutions, different dpi's and different hardware. The first two are the most concerning, because anything that you code into your game in pixels is going to come out different screen to screen, it's possible to make this a little easier on yourself through some pretty complex Flash coding - which I'll be posting up here in the vain attempt to get a little more traffic through, but all in all, it's pretty damn hard to get the swf file to scale to different dpi's and screen sizes and not have issues with sprites being cut off.

- AMAZING ANDROID 2D BOX COCO ENGINES! This is something, that I have to say, after almost a month of going through has irked me more than anything. I don't know if it's a personal trait, or if it's a global problem that the world suffers, but in the last month, I've tried to learn to use no less then seven engines for Android, most of which, obviously are based in Java, but boast "Amazingly easy to learn!" & "Instant integration!" I've got to say, it's saddening to see things like this. I'll be honest with you, it's great if you're able to get your hands on a fully fledged game engine and just start pumping out games - but realistically, the chances of you being able to just pick one up, and unassisted (most documentation is pretty lax) just start to churn out great game ideas, are not great.

This has been the single biggest time-waster that I've had - I come across a problem with my current code, go searching and the only support that I find goes something akin to this "Oh, I had this problem, and then I started using engine X and all my problems were fixed and I found five bucks!"

I've come to the conclusion that if you feel the need to use an external game engine you're one of two things:

 - Lazy
 - Shouldn't be programming games.

Getting help phoned in is (I feel) cheating, if there is something that the game engine does that you don't understand (it just does something magic and you get a game out the other end) then you shouldn't be using it, I've started to program a new game, and I'm essentially laying out a fully functional game engine to go along with it, and I'm going to take the long road and learn how all the parts fit into each other - it's going to be harder and probably more frustrating then going and picking up one of the many free engines, but when I'm through with it, you know what? I'll have my own game engine that I know back to front and can manipulate as I see fit, and no open source, free, paid for, whatever, engine out there can say that for each individual user.

As you can see there's been a bit of a block in the creative flow of my programming, which has largely been caused by needing help and being confronted by a bunch of mindless Zombies reeling off engine names at me -.-

But, there has been other things that I have come across that I feel contributed to Flip the Switch going onto hold. Such as the fact that in all reality, I was finding it very difficult to code anything new into the game and as such wasn't getting any closer to putting something onto the market, and this is the big thing! What I want is something that is going to be quick to develop (relatively) can support itself (ad support) and will ultimately give me a good idea of what it's like to receive feedback and change and update a game depending on what the users have to say.

Those three points listed above are something that I want to talk about too; having something that is quick to develop from idea to prototype to beta to release is CRUCIAL in the app field, because if you've thought of it, you can almost guarantee that there is someone else that has thought of it too and might be quicker at coding then you, or have a team of monkeys with him to help. So the simplest ideas are often the best - and when I first sat down to think of ideas, Flip the Switch seemed simple, I was thinking of all of the elements that I was going to implement, and now on the other side I can appreciate more then ever exactly what goes into a games development.

Having an app that supports itself is something that is very important too - and it's a real problem for people that are developing through AIR for Android as there is pretty much only one choice - AdMob, which you can put as a overlay on your game, app or whatever and just sit there. The real problem with that is that AdMob isn't exactly know for it's great income, and the mobile advertising market is something that belongs in a complete other blog post (yes, I'll do one, I promise.) But the major companies that are doing advertising that you can use in an app are things like Millennial Media & TapJoy - both of which only offer a Android SDK - which of course is in Java, and totally unusable by myself. So admittedly, from an income perspective, Flash - not the way to go until such times as there is support for people such as myself (when it happens, it will be a happy day!) This then leads me back to my freemium post which I made a while back, but I'll cover again in another post.

Finally there's the feedback that people that use your app will give - negative, positive, anything that a person says about any app that is made will change what is done to it in future updates, and as such, having a total of 0 apps on the market, means that I have NO idea if any of my game ideas are going to sell well, if at all!

Well, that's pretty much all that I've learned about the fickle mistress that is the Android App Market since you last heard from me. Where am I going from here? Well, I'm going to cut a lot of the fat away from what I've been developing over the past month, it's been in drips and drabs, and ultimately has led nowhere so I want to perk things up and start afresh and see how that gets me going. I'm starting on a new game, but am taking a real solid interest on getting the game engine and logic side of things right so that should I get to completion of the game I'll then be able to use that knowledge, and even perhaps some code on new projects that I start.

The game that I'll be making (and I know it's already on the market, doesn't mean I'm not going to make it) is a simple constant scrolling game, using the accelerometers in the phone or keyboard input move your player back and forth to drop down slots to avoid being pulled off the top of the screen - simple idea and with a bit of polish can go far. I'm not going to try and aggrandize this idea with anything else at this point - I'm going to release it with a easy, medium and hard difficulty, a scoring system and that's it.

I'm not expecting it to go far, but what I do want to do is get it out there! And then once I have, start working on more additions to it to get people coming back (think new power-ups etc etc.) But for the mean time, I'm working on this simple idea and am sticking to it till it's done.

Another thing that I wanted to do was to organize starting to create some tutorials for any aspiring app creators that might happen on my blog (I dunno, they might :S) But I'm going to try and put a few together with my own personal spin on them for people looking to make games with android using just a simple physics engine and their own know - how.

In the mean time though, it's three in the morning and I need some sleep I think... Maybe.

A lesson in version control

Hey guys, just a really quick post about version control. This was something that was touted to me during uni and I never really understood what it meant until this week. So I was set to make some major changes to the game and set about introducing some singleton pattern classes to reduce some of the load.

I however didn't think to save a new version of everything before starting to make changes - this was the first mistake as when I then found that a lot of the changes that I had made didn't work, I had nothing to fall back on, no backup - the only thing that I could do was reverse engineer all the work that I had done to get back to what I had started with.

The lesson: MAKE BACKUPS!!!

David.

Alpha v0.0.4

Hey team,

Well it's been a while and there has been a lot of things happening on my end in terms of app programming and the like.

I've started up a new app idea, and have also made some changes to my game.

The camera function should now be working fully - which is exciting. I've also got a back and forth switch which allows the user to change gravity back and forth. I am now working on developing the game flow so that when the user reaches the end of the level, you can actually move to the second level. I will then work on balancing and then developing out the levels in full.

It's all rather exciting. The biggest thing that I've wanted to get out and done with is the Google analytics and the AdMob - for those of you that don't know the market for apps very well, or haven't really thought about it before. Ever really wonder why there are two versions of most games? A free one and then one to purchase - with the free one you have to suffer through ad screens whilst the paid apps will sometimes give you extra features / content to allow you to have a richer game experience.

It's my general understanding that the main reason behind this for most app companies is that the revenue that can be raised from having ads in a game is equal to or greater than the revenue raised from a paid app - and the most important factor of this is that everyone will immediately go to buy the free app first - it's free... And each time that the user clicks on an ad inside that app - it might make the developer five cents. Now, lets expand on that a little, Angry Birds, for the sake of the argument has had around six million installs for it's free version of the game. the possibility of someone clicking on an ad is not high, I know that I rarely click ads, and if I do, it's usually by mistake, but if there was six million of me all playing at the one time, well, you get the idea - monkeys and Shakespeare etc. etc.

And then once you go and finish the free version of the app and want a second taste, you can go ahead and get the paid version, which again means another payment in the pocket of the developer. This all sounds pretty grim, but to the consumer and to the companies that are using the advertising services there isn't too much to be sad about, typically speaking, this will mean that we are going to see more and more apps come in for free onto the market, this will give the market a much richer breadth of games as well as all around apps, and for the advertisers, this will mean better product exposure and a better return on investment.

To anyone who reads this blog and has any input on how you think the industry, in particular the app industry is going, let me know your thoughts! It'd be great to hear from some people as to what you think of the "freemium" way that the market is shaping into.

Finally, I'll give you all a bit of a bullet point list on what I'm hoping to accomplish in the next week or so with the game:

 - A level select menu - with around 5 levels to play.
- AdMob integration & Google Analytics
 - A clean method for destroying and selecting levels.
 - Better feedback about gravity and which way up you are - the reason that I raise this one is that it can be a little confusing as to which way is up, as at the moment, constant mashing of the gravity switch button can put you into limbo and up is east, or something. So I'm wanting to introduce a funky new method which will allow me to "flip" the world so that the gravity is always the right way up, but the level rotates to accommodate for "flipping"
 - A limit on the amount of times you can "flip." This will be dynamic from level to level. This really introduces a puzzle element as it requires you to think about the your next move before you make it as you have a limited amount of times you can flip.
 - Scores and points - this is a point of contention for me, I'm not really sure which way I should go on it. A lot of me thinks that perhaps the best way for the scores to work is for it to be timed, but then I don't really want the game to be rushed, I want players to have to take their time in playing. But then I'm only really left with the option of having a limit on the amount of times you can "flip" and if you have remainders, you are scored on that. Something similar to Angry Birds etc. etc, where by being awesome and taking short-cuts, you're rewarded with better points. What do you all think? For the time being, I think I'll probably go with just a simple timed interface.

This is just the start, however.

I wish I could show you all a little of how the game is playing at the moment, but I'm still working on getting a video capture feed onto my phone, once I do, I'll start to post up "progress" videos so that you can see where I'm at with it all.

Here are some screen shots to show you what I'm up to, I'll go into a little detail about the camera too:

This is the first image - the black circle is a placeholder image for the switch which will invert gravity back and forth. The text reads "Gravity Normal."

This is the game after gravity has becoming inverted  - this is where the beauty of the camera class that I developed has come into it's own. I've made it so that when a level is drawn, it's drawn on a canvas that has a canvas on-top of it, for anyone that has worked with flash - I have made a display object container that contains a object container, the physical game world is drawn on the bottom most layer, and then the UI is drawn on the upper most layer. 

This means that things that affect the viewable section of the bottom most layer don't affect the uppermost as they act independently of one another, the bottom most inherits the top most features, but changes to the bottom most won't affect the upper. That's a lot of bottom and upper, but when I draw a level I hand the camera class a x and a y value, which are the dimensions of the level - the camera interprets these as bounds and will never go beyond them - the ball will try and remain in the screen unless the view port bumps up against the edge of the level and then you get a nice fading affect which allows for a much smoother look.

Anyway, I have lots of work on,

David Out.

Alpha v0.0.3

Hey guys, a little update on how the game is going.

I've been experimenting with cameras and the like, and I've got to be honest, the maths is mind-boggling. Anyone that's dealt with coding and knows about x co-ords and y co-ords I feel you.

I've run through a few tutorials from various locations with no avail, the issue that I'm facing is that I am trying to get the interface overlying the background which contains the box2d world.

This sounds fairly simple, but is overtly complex... I'm now trying a few different types of cameras to get things working properly. On another note I have been putting a lot of research into advertising and revenue within the game, the plan is to release two versions of the game once it goes live, one for a one off payment from the market and one free from the market which contains ads in order to keep revenue.

In the mean time, let me give you a bit of an update on how things are going and where I'm at with everything. I have got the collision detection down pat, I now have an efficient way in which to instantly check between two objects and issue a boolean to be one or the other. That sounds complex, but basically means at any point in the code I can essentially write:

isCollision(objectA, objectB) -> do somefunction().

This means that I can do a variety of checks for collisions with the various parts of the level, the major updates that I have in mind will include some interesting things with gravity and magnets (HOW DO THEY WORK?!)

In the mean time, I don't have anything to deploy to the market yet, but I'm hoping that once I put the camera into code I'll have something that I feel is solid enough to put up as a download for all ya'l peeps!!!

David out.

Alpha v0.0.2

Ok - so since my last post there has been only a few changes to the build - I'll be honest with you, what shows up on the screen isn't very different. But the back end has been modified pretty heavily to allow for an expanding range of levels etc.

The major thing that is included within this build is the ability to play it on a Android phone. I've made a Accelerometer listener which will change the force applied to the player (ball) and tapping the screen repeatedly will now make the player 'float', which I will soon be modifying into a jump function.

Another addition is camera panning and scrolling with the players movement, I'm still tweaking, and it's a bit of a mind bending thing to try and work out. I think that the best way for me to go about this is for each level to have an x and y bound that will restrict the camera when the player reaches the edge of the level. Otherwise the player will try and stay in the centre of the screen.

Finally, I've also signed up to be a developer with Google, it's $25 and for ever. The only thing that I haven't done in order to get my game up onto the market is to get some icon graphics and some screen shots.

I'm not uploading any variations to the market just yet, as I want to keep some cards close to my chest as it were, in the mean time, here are some screen shots to show you what's happened to the game so far. As I keep on re-iterating; there are a lot of back end changes that are happening at the moment to ensure that when the times comes to develop levels and to make the game into a fully fledged program.

Next update will come when I've had some more time to work on the structure of the levels and the end - of - game event listener.

Thanks all for your time.

David

Where are we at?

Hey guys,

This is going to be a pretty long post because there is a lot of stuff that I want to go over and a lot of new things that I'm going to bring to the table. For those of you that have known about my gaming endeavours in the past, you may have remembered I was hoping to create some form of 2.5D side-scrolling platformer for something or rather.

Well - let me tell you something, that's not the easiest, especially when you're working with a language that you're not familiar with - at all. So - where did that leave me? A language that I didn't know and a game that was really awesome in my head and pretty much impossible to get down onto paper.

So, over the past months, whilst working at a real job, I've been devising a way in which I can both develop games in a form that I'm comfortable with as well as be able to produce it in such a way that it is deployable to a mass market. The more astute of you have probably realised where I'm going with this already hey?

Mobile Apps - the obvious solution to my issues. A massive market and a simple delivery system. Only one problem with it. iPhones want me to program in progressive C - i'd rather eat balsa-wood. And android is programmed in Java, a language that I've heard a lot about, and is OOP, but never actually touched. Well - after a little digging and a few advances in certain programming suites, I cam across this nifty fact - Adobes new Flash builder 4.5 has the functionality to package a Flash game up into a .apk (android application file) and what's more then that, deploy it to a device.

So - this was great! I'm going to able to program away to my hearts content in a language that I understand and am competent at and then be able to test it out on my handy nexus. The only thing that's left to do is come up with some good ideas.

I'll lay it out to you all, I have millions of good ideas for games some of which are way out of my ability to program, but also out of the technical capability of the devices I'm hoping to deploy too. I've managed to narrow my search down to just a few good ideas.
Again, those of you that have been around for a while will know that I made a fairly simplistic and overall hacked code piece of work called "Under Pressure" as part of a uni course a few years back - the engine that I used behind that game - Box2D has grown in leaps and bounds in the time that I've been away from games. Something that I'm glad about, it's that much easier to use now and coding time for it's various functions has been cut drastically from previous versions.

My time spent programming Under Pressure got me very well acquainted with most of the functionality that Box2D has to offer, and now that I have found that you can make Android apps that are built in Flash - why wouldn't I?!

For those playing at home, the three ideas that I have, which, in my head seem programmatically possible are:

1 - Side-scrolling puzzle platformer; Codename "Rain." This was the idea that I was working on in UDK all that time ago for the 2.5D game - I figured that it's still theoretically doable in a 2D physics engine.

2 - Rocket Shooter; I have seen this game somewhere before, but the delivery was somewhat lacking. Think of it this way: shooting a rocket from earth to another planet, or a goal location. Easy hey? What if I put a planet in the way? Then what? Well, as we all know from Apollo 13, you can do some pretty funky things with gravity and the like, so, this is the premise that I am basing this idea off, sort of inter-stellar golf (Futurama anyone??). With the added feature of planets that will try and suck your ball (ship) off course.

3 - Gravity mind-f*ckarama side/floor/roof scroller.

I like this one - I have to tell you, I like this one better then the others, which is why I'm digging into this idea first before I go anywhere else with it. So, think of this: point A -> B game, BUT! Activating certain powerups will flip gravity, upside-down, to the left, to the right etc. A puzzle format game so that you have to premeditate your next move, but essentially the idea is that you can't finish levels unless you do some gravity switching.

These ideas are currently in the works, and I'm sure will all go through refinement over time, for those of you that have any good ideas like the ones above, let me know! Or if you've seen these games made before.

Now - where am I at the moment? Well, I've got my programming pipeline sorted, so that's the first hurdle out of the way, I'm currently working with the new functions that working with a mobile device has given me, for example, accelerometer input, multitouch etc. I'm using the most recent version of Box2D, which is 2.1 at the time of writing this, it's in Alpha stages.

Figure 1: FlipTheSwitch Alpha 0.0.1

I say alpha like that's a joke, but it's actually kinda true - this is the game in it's most basic form. The above screen shot features a few elements. For those of you that have had any experience with Box2D, heck, for those that haven't too - I'm no artist, I admit that first and foremost - I am terrible at drawing anything, especially on computers. So I use Box2D's funky little debugDraw function which renders everything in nice basic colors for me so I can see what I'm about.

The above screenshot features three Box2D elements, for the sake of the argument, the circle is the player - very imaginative I know, but it gives the game a little variety, plus it rolls nicely when the accelerometer receives input. The green blocks in the corners are gravity "switchs" the Box2D collision detection picks up when the player hits one of these boxes, and will flip gravity in any of the four directions, for the sake of my sanity, and to not confuse myself, they're North, South, East and West in the back end.
.
The last element, is of course the walls - yay! Without them, the ball would just roll off the screen and onto the floor... And then out the door.

Well - what's in store for this game? What's next on the smorgasbord for this little nifty thing? Well, I'm currently working on input logic to detect when the user taps the screen, I know that there is inbuilt functionality, and will post up a working APK file once I have figured it out, but that is essentially what's next.

The biggest feature that I want to implement, and the one that poses the biggest logistical problem is this: when the player entity rolls over the say North gravity switch (this will send gravity's downforce north, or reverse it for those of you playing at home.) The entire screen should rotate so that the new gravity is represented as the downward direction. Yeah - that's what I said too :S, the biggest problem that I think I'll have with doing this is that when the borders of the world flick around, then they can and will impart some sort of force on the player - I don't want that. It is possible perhaps to make the player a static object for the duration of the rotation (heh, that rhymed) but finding out how long the rotation will take, being able to detect that... It's all a bit crazy.

I will keep you all updated as things progress on that front, but in the mean time, I'm going to finish up with the input features that I would like to get going with the phone and then I'm going to start work on developing some form of level building device so that I can chop and change as I see fit.

The biggest mistake that I made with Under Pressure was to use the Flash Professional suite in conjunction with Flash Develop - developing in two separate programs was both time consuming and led to problems I also built the individual levels of Under Pressure visually using Flash Professional, which meant that come time to change level in the game, the entire old level had to go through the rather expensive process of being pushed into an array and then destroyed whilst the new level was drawn all from one big function - not very good coding nature I know. And certainly not something that I want to include in a build for a mobile game. What I DO want to do however, is to have a levels "Class" which is called when the game wants a new level, this means that I'm not iterating over hundreds of lines of code to find the code to draw a level up.

Anyway, I'm prattling on about nothing now, so I'll sign off and give everyone an update and a working version of the APK file (it's not going to be stunning, I assure you, in the near future.

Thanks for reading all this if you got this far, you're a true hero :).

Dibs out.

A new blog, a new development idea.

Hey guys, so this is the new blog that I'll be using to develop my games on from now on. I have previously been posting under the title of Punch Card Studio, but have recently renamed with the intent of starting a new game.

I will be making a Flash based game with a box2d physics background.

But further from my last blog, I'm going to start off by producing some written tutorials on how to set up a programming environment and the typical Hello World program that many new programmers will want to complete when getting their hands on a new API.

I am currently downloading box2d. And will start on a tutorial on how to get it set up and integrated into Flash before too long.

David Out.