Wonders never cease – I actually managed to get the next part out less than a month after the previous one! If you’re new to this series on mobile game design patterns you might want to have a look at the previous two posts first.
Mobile Game Development: Design Patterns Part 1 – Introduction
Mobile Game Development: Design Patterns Part 2 – Simple State Navigation
Mobile Game Development: Design Patterns Part 3 – Advanced State Navigation
In the previous post I discussed how you would create the various states for a simple (but realistic) game. In this post I’m going to expand a bit on the simple design pattern and discuss a slightly more complicated state arrangement that is commonly found in physics type games, such as Angry Birds. These games are characterised by having a large number of separate levels, as opposed to levels that are characterised simply by a speed, length etc. change within the same game screen.
The diagram below illustrates this more advance game navigation. I’ve left out the states that are the same as those discussed in the previous post and just included the new ones that add the advanced level navigation that these games display.
When the player taps the “Play” button, they are presented with a selection of levels. Typically, a player can only play the first level when they start the game and the next level is only unlocked once they have completed the current level. Levels may also be grouped into somewhat arbitrary groups (usually just for display convenience) and often require a certain aggregate group score to progress to the next group (simply completing all the levels isn’t good enough). There are usually far more levels than can be displayed on the screen so the groups can either form part of a panorama display or be grouped into separate screens. The pause behaviour is also a bit more complicated and is used to also give the player the option to skip to a different level (usually one that they have already completed) or go back to the game menu. When the player completes a level they are given their score (usually based on a simple star system, not numeric) and given the option to replay the level, go to the next level, or go back to the game menu.
If you group your levels into sections you might want to merge the two levels of separation by displaying the individual levels within a designated group area (the various Angry Birds games use both methods).
That’s it for the high level overview of mobile game design patterns. I’ve obviously only just scratched the surface of the ins and outs of organizing the various moving parts of a game, but this is a good place to start and build from (covering every possibility is impossible and not a very good use of my time). I’d encourage you to play various mobile games and document the various design patterns that you pick up and keep them as a reference for your own games.
In the next post I’m going to cover how you would actually go about putting together a little framework to make the state management of a game a little easier, together with a simple reference game. Unfortunately, this has to be technology specific and I’m going to use ActionScript and the Starling Framework. The principles are still the same though and should be easily transferred to the development tool of your choice.
written by Paul
\\ tags: Android, Design Patterns, Game Development, Mobile, Starling
It’s been a long time since part one of this series (I got side-tracked a bit) but I’m finally back with part two.
Mobile Game Development: Design Patterns Part 1 – Introduction
Mobile Game Development: Design Patterns Part 2 – Simple State Navigation
Mobile Game Development: Design Patterns Part 3 – Advanced State Navigation
This part, and the next, will cover the state (screen) navigation of 2D mobile games at a high level. I selflessly played and analysed a number of popular Android games to come up with a collection of common state navigation design patterns and from those, extract what I consider a starting point design pattern that can be used to design the state navigation framework for a game. Before we go any further though, we need to be clear on exactly what a state is. In the context we are discussing, a state is a particular activity (not necessarily interactive) in the game. Examples of these are the actual game play, level selection, the settings screen, credits, the loading screen etc. Things like the pause state are also considered states because the game play is suspended and a new state is entered that usually has some kind on overlay that indicates that the game is paused. In other words, every “different” type of screen in the game is a state (at least one), and we use a state manager to allow the transition from one state to another. It’s often possible for more than one state to be visible at a time, but only one is usually active at a time (for example, the pause state, where the game is suspended but the pause overlay or dialog box is interactive and can be dismissed to resume the game). Having multiple active states at the same time is rare from a user perspective, but from a programming perspective it makes sense if you want to separate game logic into separate layers. For example, you might overlay the game state with a HUD (heads up display) state to display things like the score, level, lives and the pause button. In this case, both states are active and interactive.
The simple state navigation pattern that will be presented here is suitable for simple games that have a single game screen with either a single level or automatic progression to the next level, which is hosted in the same screen or state (from a technical perspective they may actually be different classes or objects). Some examples of this type of game are Bejewelled (or any matching type game, actually) and Tetris. Physics and puzzle games like Angry Birds will be considered in the advanced state navigation part because they have a more complicated level structure. The advanced pattern is, however, just an extension of the simple pattern, which can be considered a basis for all pattern variations (by adding or removing feature states). This is important because it will allow you to build a reusable game state framework to use in multiple games.
Continue reading »
written by Paul
\\ tags: Android, Design Patterns, Game Development, Mobile, Starling
The first (major) issue that I ran into when trying to write a game for Android using Starling was getting everything to display nicely without clipping and distortion. There are a number of samples and blog posts littered around but they all seem to have some issues under specific conditions. I’m not saying that my solution is perfect, but it works for me. There are a number of approaches to fitting content on the screen, but the simplest is just letter boxing. This is simply scaling the content while keeping the original aspect ratio so that it fits on the screen, with either vertical or horizontal whitespace if the screen aspect ratio differs from the game aspect ratio. If you want a really comprehensive overview of this topic, have a look here.
The code is actually quite simple, so no explanation is needed (I’m lazy). Please excuse the dodge code, it just serves to illustrate a solution to the screen size problem and isn’t meant to be the best way of structuring the game code.
Application Class
1: import flash.desktop.NativeApplication;
2: import flash.display.Sprite;
3: import flash.display.StageAlign;
4: import flash.display.StageScaleMode;
5: import flash.events.Event;
6: import flash.geom.Rectangle;
7: import starling.core.Starling;
8:
9: [SWF(width="480", height="800", frameRate="60", backgroundColor="#000000")]
10: public class MyGame extends Sprite
11: {
12: private var _starling: Starling;
13:
14: public function MyGame()
15: {
16: var viewPort:Rectangle = ConfigureViewPort(480, 800, false);
17:
18: _starling = new Starling(Game, stage, viewPort, null, "auto", "baseline");
19: _starling.simulateMultitouch = false;
20: _starling.enableErrorChecking = false;
21:
22: _starling.start();
23:
24: NativeApplication.nativeApplication.addEventListener(Event.ACTIVATE, function (e:Event):void { _starling.start(); });
25: NativeApplication.nativeApplication.addEventListener(Event.DEACTIVATE, function (e:Event):void { _starling.stop(); });
26: }
27:
28: private function ConfigureViewPort(gameWidth:Number, gameHeight:Number, centerVertically:Boolean = true) : Rectangle
29: {
30: stage.scaleMode = StageScaleMode.NO_SCALE;
31: stage.align = StageAlign.TOP_LEFT;
32:
33: Starling.multitouchEnabled = true;
34: Starling.handleLostContext = true;
35:
36: var viewPort: Rectangle = new Rectangle();
37: var xAspect:Number = stage.fullScreenWidth / gameWidth;
38: var yAspect:Number = stage.fullScreenHeight / gameHeight;
39:
40: if (xAspect > yAspect)
41: {
42: viewPort.height = int(gameHeight * yAspect);
43: viewPort.width = int(gameWidth * yAspect);
44: }
45: else
46: {
47: viewPort.height = int(gameHeight * xAspect);
48: viewPort.width = int(gameWidth * xAspect);
49: }
50:
51: viewPort.x = int((stage.fullScreenWidth - viewPort.width) / 2);
52:
53: if (centerVertically)
54: {
55: viewPort.y = int((stage.fullScreenHeight - viewPort.height) / 2);
56: }
57: else
58: {
59: viewPort.y = int(stage.fullScreenHeight - viewPort.height);
60: }
61:
62: return viewPort;
63: }
64: }
Game Class
1: import flash.display.Bitmap;
2: import starling.core.Starling;
3: import starling.display.Image;
4: import starling.display.Sprite;
5: import starling.textures.Texture;
6:
7: public class Game extends Sprite
8: {
9: private var _gameWidth:Number = 480;
10: private var _gameHeight:Number = 800;
11:
12: // A 480x800 background image.
13: [Embed(source="/background.png")]
14: private static const Background: Class;
15:
16: public function Game()
17: {
18: Starling.current.stage.stageWidth = _gameWidth;
19: Starling.current.stage.stageHeight = _gameHeight;
20:
21: var backgroundBitmap:Bitmap = new Background();
22: var texture:Texture = Texture.fromBitmap(backgroundBitmap);
23: var image:Image = new Image(texture);
24:
25: addChild(image);
26: }
27: }
That’s all there is to it! I might consider revisiting this to add a bit of an explanation…
written by Paul
\\ tags: Android, Flash, Game Development, Mobile, Starling
|
Nov 16
|
Android, CSS3, HTML5, iOS, Microsoft, Mobile, MVC3, ReSharper, Silverlight, Windows 8, Windows Phone
|
This is just a slight detour from my usual detours. I was thinking about what I consider the “essentials” if a person wanted to set up shop developing software for the Microsoft stack (i.e. Windows, Xbox, Windows Phone, web). I’m not necessarily going cheap here, I’m just interested in the essential software and tools to make development comfortable (I don’t think that trying to go free for everything is particularly smart). Hardware is a personal choice, that’s up to you.
MSDN Professional
There’s no wiggle room here. Sure, you could go with the free Express version, but then you have to do without Visual Studio addins (like ReSharper). MSDN Professional gets you Visual Studio Professional (2010 and 2012), Expression Blend, developer versions of SQL Server and version versions of Windows and Windows Server. You really can’t do without this. The other bits, such as ASP.NET MVC, XNA, Silverlight etc. are all bundled in or available as free downloads. The more expensive subscriptions are nice, but I don’t think that they offer any additional value that you can’t do without (apart from Office, but it’s cheaper to buy it separately) You can get it here.
Cost: $1999
JetBrains ReSharper
I don’t know about you, but I can’t live without ReSharper. This tool offers extremely good value for money and is a huge productivity increase. The full version is probably unnecessary, so just get the C# or VB version. Just get it.
Cost: $199 for the full version, or $149 for the C# or VB only version.
GitHub
Sooner or later something is going to blow up or break and you’re going to lose your source code. It’s essential that you have offsite source control, and GitHub is a reasonably priced solution that scales according to your needs.
Cost: $7/pm for 5 private repositories. If you want more, you pay more.
Telerik
I’m a big fan of the Telerik tools, since they have comprehensive offerings for all the relevant technologies (WPF, Winforms, ASP.NET, ASP.NET MVC, Silverlight, Windows 8, Windows Phone). The individual packages are quite pricey. If you’re targeting multiple platforms then one of the DevCraft subscriptions are probably the best value for money. DevCraft UI Edition, at $1299, is the best bang for buck. Kendo UI, in particular, is a fantastic web framework.
Mono for Android and iOS
Just a little optional extra here. If you’re interested in writing apps for Android and/or iOS and don’t feel like messing around with the native toolsets then the Xamarin Mono toolsets for Android and iOS might come in handy. They integrate with Visual Studio and allow you to use C# and .NET for development. Not cheap, but worth it for the productivity gains. You can also use it together with MonoGame, which is a cross platform open source XNA implementation, for game development.
Cost: $399 for each platform or $718 for both.
Final Word
Okay, maybe that isn’t terribly cheap ($4000+), but it covers pretty much everything you’ll need to target every platform of interest. You’ll probably also need Microsoft Office, a drawing application and various other bits and pieces, but you can get by with the open source stuff for that.
written by Paul
\\ tags: Android, CSS3, HTML5, iOS, Microsoft, Mobile, MVC, ReSharper, Silverlight, Windows 8, Windows Phone
Because they had to!
Okay, I admit that’s a bit terse, but it is the truth, in a nutshell. A little background first though. Apple released a new clock app with iOS 6 that bore more than a striking resemblance to the Swiss national rail operator SBB clock. Unfortunately for Apple, this resemblance to the famous icon didn’t go unnoticed and they had to cough up $21M for the rights to use it. Read here for a bit more detail.
You have to admit, they do look very similar.
So, why did Apple quietly pay up and not fight this? You might argue that they don’t compete with SBB or any watchmaker, and that $21M isn’t even worth going to court for, but there’s a bigger picture here. The big picture is that no matter how Apple approaches it, they lose, and they lose big. There are only two arguments here; they either copied the design or they didn’t, so let’s have a look at both defence arguments.
Yes, we copied it.
This is the simplest and least damaging approach (which is the one they took by settling, but without admitting any guilt, in public). At best this just makes Apple look like the copycats that they accuse everyone (Samsung, HTC, Google, Motorola, and Microsoft etc.) else of being. This would be deeply embarrassing for a company that trades on its “originality” and it opens them up to punitive damages. Arguing that the copying was done deliberately at a lower level (i.e. management didn’t know about it) won’t work because a company like Apple, that is involved in multiple lawsuits around the world around exactly the same design infringement issues, would be expected to perform due diligence and not allow that to slip through. The result would be the same; embarrassment, a fine and possibly punitive damages.
No, we didn’t copy it.
Now this is where it gets interesting. For this argument to hold water, Apple would need to prove that the design is obvious and any competent designer would come up with that design in a logical manner. It makes perfect sense; it’s a simple round clock with rectangular parts and no other details or adornments other than those required to function. Unfortunately for Apple, this is exactly the same logic that applies to their patented hardware designs for the iPhone and the iPad, and what won them $1B in their case against Samsung. Using this argument (and winning) would immediately invalidate their hardware patents. Clearly this would be very bad for Apple.
My Opinion.
It’s no secret that I’m not a fan of Apple (their business practices) and that I think that the vast majority of software patents are extremely detrimental to the entire software and hardware industry (and that’s without patent trolls). Although I have no real basis for my opinion, I think that Apple did knowingly copy the clock design (any designer worth their salt would know about that particular clock design), but felt that since the design is so simple it couldn’t be protected (or else they would have licensed it or used an original design). Unfortunately, this lowers my already low opinion of Apple because they vigorously defend the same rights that they refuse to recognise in others. It’s not acceptable to patent a simple black rectangle but refuse to acknowledge the copyright on a simple white circle with black rectangular markings (the clock design is actually more complicated than the external iPhone hardware appearance). Unfortunately, Apple is trying to set a precedent that really isn’t in anyone’s best interest, but hopefully they’ll tread a bit more lightly now that things are coming full circle and they’re beginning to get bitten by their own creation.
written by Paul
\\ tags: Apple, Mobile
I’ve been doodling around with the new Game Maker Studio from Yoyo Games, and after reading up a bit in the forums and various announcements that were published, I’ve come away very confused. First off, let me make it perfectly clear that this isn’t a review of Game Maker (I’ll leave that for another time). What I’m confused about (and so is YoYo Games, apparently) is who exactly Game Maker is aimed at. The “who are our customers” issue came to my attention while cruising the forums, where some indie developers were complaining about the costs of the various modules. YoYo Games have chosen to go the whole module route for different platforms (like most game tool developers) and offer the following:
- Game Maker: Studio (Win/MacOS) : $99
- HTML Module: $99
- Android Module: $199
- iOS Module: $199
Whether or not the whole thing is worth $596 isn’t the issue here (it may, it may not), the issue is the mixed message that YoYo Games is giving out. The standard response from the YoYo Games employees on the forums when people complain about the cost of the mobile modules is that Game Maker Studio is aimed at “professional” game developers. I find this quite laughable, but that’s a topic for the actual review. Here’s some choice YoYo Games responses:
Then I’d politely suggest that Studio probably isn’t for them….. We not aiming Studio at the lowest price point so everyone and their dog can buy it, we’re aiming it firmly at professional developers, and for what it does, Studio IS cheap – EVEN for developers in Poland.
We can’t reduce the price just because not all bedroom coders can afford it; it’s not aimed at them.
So, it’s pretty clear – if you’re an indie, bedroom or Polish game developer, then YoYo Games doesn’t want your business. That’s all fine, I respect that (even though I suspect that the largest market for game development tools is indie and bedroom programmers, and the volume value exceeds the “professional” market). So then why, in a quote attributed to YoYo Games CEO Sandy Duncan, do they say that “the tool is primarily intended for small companies working on a budget”? In my books these small companies working on a budget ARE the indie and bedroom coders!
Anyhow, that’s my rant for the day. I guess I’m just saying that no matter what the price, YoYo Games is shooting a bit high by aiming at “professional” developers. It wasn’t too long ago that Garage Games had such lofty ambitions and morphed into the professional middleware company formally known as TorquePowered. That didn’t work out too well, and mercifully Garage Games has gone back to its indie roots (and made huge price cuts). Want another example? How about Borland, which became the “professional” Inprise, and now is Borland again (but a shell of the former company after screwing up their developer tools division).
My point exactly? Game Maker is still Game Maker – it looks terrible (I know it can produce some decent games, in the right hands, but so can pretty much any tool). Putting “studio” in the name and aiming it at “professionals” doesn’t take the yoyo out of the company. I suspect that competition from other similar products will squeeze them enough to force the price down and make YoYo Games become indie and bedroom coder friendly again.
As a final word, remember that Corona SDK got its much needed shot in the arm from the publicity around a 14 year old producing a popular game. Think about that (and the fact that it’s cheaper)…
written by Paul
\\ tags: Corona SDK, Game Development, Game Maker, YoYo Games
I mentioned in my previous post that I thought that coverage of design patterns in game development (books) is generally lacking (some books do exist though). They’re certainly covered inadvertently (they’re hard to avoid) but there isn’t much explicit coverage. It’s actually quite difficult to define what a design pattern is, because it’s a very broad topic and can be applied to pretty much every level of software design and architecture. The definition I like is: “A design pattern is a general reusable solution to a commonly occurring problem within a given context”. I’m not going to go into great detail about what is and what isn’t a design pattern, but I do want to discuss why I think design patterns are essential to casual game development.
The first question you should be asking is why should I care about these new age design pattern things, I just want to write my game and make lots of money. Well, that’s exactly why you should care about design patterns. Look at it this way – what is the first successful casual mobile game that comes to mind? Angry Birds? Probably – it’s the first one that I thought of and I certainly wouldn’t mind the chunk of cash that it earned. But here’s the rub – it wasn’t just dumb luck that Angry Birds enjoys the success that it does. When you look at it from a technical viewpoint they did a lot of things right, and that doesn’t happen by chance; a lot of thought and design goes into producing a successful game (or any product for that matter).
So, what does that have to do with design patterns? Nothing in of itself, actually, because design patterns are derived in hindsight by analysing successful solutions to common problems and distilling a reusable solution that can be applied to similar problems. So what problem does Angry Birds solve? At the highest level, it solves the problem of producing a highly successful mobile casual game that makes huge money. The design patterns start appearing when you start looking at the knockoff similar games to Angry Birds. It’s a smart move to look at a successful game and include what you think are good design elements (without getting your pants sued off) in your own game. This has a two-fold advantage. Firstly, you’re using a tried and tested successful design (pattern) and secondly, there’s a better chance that your users are already familiar with that sort of design, so they’ll figure out your game all that more quickly.
Now that we know what a design pattern is and that successful games are potentially packed full of these juicy and useful design patterns, how do we go about finding and using them? Ideally, you could just pick up a book on “mobile casual game design patterns” and flip through them and find what you want. Unfortunately, the field is a little bit young for this and the few attempts don’t really come up to the standard that you find for general software and web development. Until casual game design patterns become commonplace, your best option is to get hold of a good set of similar games to the one you intend developing and analyse the relevant parts to find the common patterns, and then use them in your game (if appropriate). Since Angry Birds type games (also, Cannon Cat, Wolf Toss, Cut the Rope, Blast Monkeys, Froad etc.) are very popular (and I like them), I’ll analyse these games and present the meaningful design patterns. Possible things to look for when extracting design patterns are:
- Screen Navigation
- Graphics style
- Scoring
- Game Play
- Option screen design
- Touch event interpretation
- Level progression
- Level navigation
There are probably other patterns that you can pick out, and some patterns (like screen navigation) encompass smaller and more specific patterns (like level progression). The next instalment will be an analysis and presentation of screen navigation design patterns.
Mobile Game Development: Design Patterns Part 1 – Introduction
Mobile Game Development: Design Patterns Part 2 – Simple State Navigation
Mobile Game Development: Design Patterns Part 3 – Advanced State Navigation
written by Paul
\\ tags: Corona SDK, Design Patterns, Game Development, Game Maker, Games, Mobile, Monkey Mojo
Okay, okay – I’ve been very lazy and I haven’t done much (and written much). Actually, I lie. I have been playing with the tools, reading books and doing some R&D stuff. This post is just a bit of feedback and observations based on my findings. Firstly, nothing has changed – I still think that Corona SDK is the hands down best tool for Android game development, but there are some other tools that are looking better and better. Before I get to the meaty bits, let’s have a look at the improving tools.
Android casual game development tools and resources worth considering
Apart from Corona SDK, the following seem to be ready for prime time:
Monkey/Mojo
I’ve mentioned this one before, but I’m really impressed that the PS Vita has been added as a target. It’s still a little rough around the edges and doesn’t shield you from having the required sdk’s installed, but I’m beginning to like it a lot. To make things even easier, a book on Monkey Game Development has been published by Packt, so give it a read if you’re interested in Monkey.
Game Maker
This is a hard one. I’ve tried very hard to like Game Maker from Yoyo Games, but I just don’t like the workflow (it’s a personal thing – I just prefer coding to lots of point and click stuff). Anyhow, not matter what I think, they’ve published some very impressive Android games that were developed with Game Maker, so it clearly isn’t a bad tool and is certainly worth a look. It also targets Windows, MacOS, iOS and HTML5. The price is a bit of a downer though – it’s not terribly cheap anymore.
Flash/AIR for Mobile
The big news here is that AIR 3.2 for Android and iOS now supports Stage3D, so now you can create hardware accelerated games for mobile platforms using Starling.
Corona SDK Mobile Game Development: Beginner’s Guide
Sweet! A book on Corona SDK development. I’ve just started this book (I’m maybe a quarter of the way through), and while the content is good it isn’t a terribly easy read. I’ll post a full review once I’ve finished and digested it.
So, what’s next?
Good question! One thing that I’ve realized after reading a number of game development books (particularly casual games) is that not much consideration is given to design patterns around the game as a whole. There’s no quicker way to kill your game than to hack around and spoil a game with lousy navigation. A lot of airtime is given to game play, but very little consideration is given to making the whole gaming experience, from the loading screen, to level selection, settings etc. smooth and easy to understand. Games are meant to be challenging, not complicated, and the challenge should be limited to the game play, not figuring out how to actually get to play the game in the first place.
So, the next instalment will cover an analysis of the game structure of some choice casual games (of the Angry Birds type) so that we can come up with some nice design patterns to get you started with similar type games.
written by Paul
\\ tags: Android, Corona SDK, Game Development, Game Maker, iOS, Mobile, Monkey Mojo
The internets have been filled with copious amounts of mouth froth over the last few days regarding Apples new iBooks Author software. The issue is the EULA, which basically says that if you want to sell a book that you’ve created with the software that you have to sell it through Apples iBookstore and that you can’t sell it in the same binary format anywhere else. Most importantly, you are still free to use the same content in a different format and distribute it in anyway you like (pdf, Kindle, print etc). The restriction doesn’t apply if you give the book away for free. People also seem to be griping that Apple has the right to refuse to allow you to sell your book in their marketplace if they deem it unfit for any reason (sounds familiar, doesn’t it).
Anyhow, here’s the offending part of the agreement:
B. Distribution of your Work. As a condition of this License and provided you are in compliance with its terms, your Work may be distributed as follows:
(i) if your Work is provided for free (at no charge), you may distribute the Work by any available means;
(ii) if your Work is provided for a fee (including as part of any subscription-based product or service), you may only distribute the Work through Apple and such distribution is subject to the following limitations and conditions: (a) you will be required to enter into a separate written agreement with Apple (or an Apple affiliate or subsidiary) before any commercial distribution of your Work may take place; and (b) Apple may determine for any reason and in its sole discretion not to select your Work for distribution.
Apple will not be responsible for any costs, expenses, damages, losses (including
without limitation lost business opportunities or lost profits) or other liabilities you may incur as a result of your use of this Apple Software, including without limitation the fact that your Work may not be selected for distribution by Apple.
On the surface this all sounds very ominous, but when you read through the whole thing you notice that nowhere does Apple claim ownership of your work. All they state is that if you want to sell your work through their bookstore (using their custom format, which is produced by their software) that you don’t sell the same digital file outside of their bookstore. In other words, Apple doesn’t want anyone else creating an alternative book marketplace to sell the same format. Does this sound familiar? Of course it does – it’s exactly the same thing that Apple (and Microsoft, with the Windows Phone 7 Market) did with iOS apps. If you produce an app in the format for execution on iOS you can only distribute it through the AppStore and Apple has the right to reject your application. It’s the same thing! Actually, the iBookstore restrictions are actually more friendly, since you still have to distribute free iOS apps through the AppStore as well.
I do, however, have some reservations about how Apple is going to police the content of the bookstore. It’s easy enough to have automated processes to test if an app behaves properly and it’s relatively easy to verify that the content meets the marketplace requirements (ignoring the subjective nature of that). How does one go about this for a book though? I assume it means reading the entire book? I’m pretty sure that the whoever gets this job will immediately reject the book on the first violation (spelling mistake, maybe) and that there will be two classes of rejection (non publishable due to the nature of the content, and needs editing due to lousy spelling, grammar and layout). However this pans out, I’m pretty sure that Apple is going to take a lot of heat in this area and that they’re going to have to tread very carefully so as to not be accused of restricting free speech and undue censorship.
My other issue with everything is that this is an iOS only thing, but hopefully Apple will release a reader application for other platforms, much like Amazon did with the Kindle software.
written by Paul
\\ tags: Apple, iBooks, iOS
If you’re anything like me then you like to have a dedicated test device (or a few) for development that you can periodically repave when things start going a little pear-shaped. It’s kind of like having a virtual machine for testing, but unfortunately you really need a physical device for mobile development because there’s just some things that the emulators can’t do very well (like make calls, GPS, accelerometer, gyroscope, compass etc). A spare phone is okay, but they can be a bit costly if you want fairly decent performance and there’s often an issue with needing a sim card in the phone (here in South Africa all sim cards have to be registered and it’s generally just a pain in the butt). Wifi only devices are ideal for mobile game development because they don’t have all the phone crud (unless you need it for some obscure reason) and they’re a heck of a lot cheaper (and you can go for the lowest storage capacity ones because you’re not going to download every app on the planet; it’s for development testing, remember).
If you’re interested in iOS or Android game development, you have the following wifi options (not exhaustive – I’m a Samsung fan so I’m only listing the Samsung devices, but there are plenty of other ones):
Android
The Galaxy S 4.0 and 5.0 are essentially identical apart from the screen size (4” and 5”) respectively and the 5.0 has a larger battery. Both have 800×480 resolution.
- Galaxy S 4.0
- Galaxy S 5.0
- Galaxy Tab 10.1 Wifi
iOS
I’m going to look at the Galaxy S 5.0, since I prefer a slightly bigger testing device and the longer battery life is appealing.
The Galaxy S 5.0
Okay, down to business. I’m not going to cover how you go about using the device for testing – all Samsung Android devices work pretty much the same (not always such a good thing).
Pros
- Fairly cheap for what you get. $269 (R2000).
- A nice size 5” screen.
- A SD card slot.
- Full access to the Android marketplace.
- A fairly snappy 1 GHz ARM Hummingbird Cortex-A single core processor (mid-range now, but that’s good for testing).
- The usual GPS, accelerometer, gyroscope, camera etc (games often use these).
- Android 2.3 Gingerbread.
- It can double as an okay media player.
Cons
- It’s very bulky (as in heavy and very thick – 0.5”).
- The screen resolution is 480×800, which isn’t terribly clear when stretched over a 5” screen, but it’s perfectly usable. If it’s an issue then maybe the 4” model is a better choice, if you’re willing to sacrifice the 2500mAh (8h) battery for a 1200mAh (5hr) battery (and it’s a bit cheaper).
- Not the latest dual (or quad) core processor technology. It’s still perfectly good for most games, and Angry Birds works just fine, so what more do you want?
- The TFT multitouch screen isn’t quite as good as the Galaxy S phones, but it’s still very good.
- The battery can’t be removed.
Verdict
The Samsung Galaxy S 5.0 Wifi (also called the Galaxy Player 5), and the 4” variation are pretty good game development test devices. As a media player I don’t think they’ll achieve huge market penetration, simply because the similarly priced iPod Touch is just so much better as a standalone media player. This isn’t an issue if you want an Android test device though (and iPod Touch is of absolutely no use there). The physical constraints aren’t a big deal and the mid-range performance and display is a plus because you need such a device for testing. If your game runs happily on it then you can be fairly confident that you’ll get adequate performance on a wide range of newish devices (you can’t support everything, and you’ll still need additional testing on other devices).
Overall, I’m very happy with the Samsung Galaxy S 5.0 Wifi; it’s a very competent and affordable testing device.
written by Paul
\\ tags: Android, Galaxy S, Game Development, Games, iOS, iPod, Mobile, Samsung
|
