These are some useful bits and pieces I've found while sifting the web for game dev info. Especially mobile game dev info.

Response times

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially importantif the response time is likely to be highly variable, since users will then not know what to expect.

What not to do for casual games

   1. Make it really hard.
   2. Have a dozen mediocre game modes instead of one good one.
   3. Make it a 600 MB download that requires two next generation video cards and 4GB RAM.
   4. Price your game at $35 or $3.50 and sell only from your myspace homepage.
   5. Use the right mouse button.
   6. Give it a terrible name or theme.
   7. Award low scores.
   8. Expect users to read.
   9. Make it challenging and cerebral.
  10. Ignore what everyone else says about your game.

Things not to do in mobile UI

http://www.littlespringsdesign.com/blog/2006/07/11/how-to-reduce-use-of-your-mobile-application/
    * Have an unnecessarily large application footprint. That way, the application will take a long time to load, so the cost of restarting the app is high.
    * Phone home with every launch. This technique lengthens the time until the user can start using the application again, prohibits her from using it without c
overage, and can run up her data charges. You wouldn't want to set a time stamp for end of license and only phone home when the license has expired - no, that wo
uld let people back into the application too quickly!
    * Don't save user data. If the user has to re-enter data, she is less likely to use the application again. If she gets interrupted in the middle of searching
 for an airplane ticket, by all means erase all the search parameters.
    * If you have to save user data, save it for a long time. Our fearless user will definitely want to search for a ticket for August 12 the next time she uses
the application - on August 15.
    * Be oblivious about user context. You know that your user is on that trip to Tokyo . offer her information about events happening in New York! Especially if
 she lives in London.
    * Destroy user state. A more advanced version of "don't save user data", this will require users to start at the home page or main screen every time she star
ts the application. You wouldn't want to return her to the news item or video clip she was viewing two hours ago - make her find it again!
    * Force a single user interface onto all devices. Especially fun is requiring touch screen users to use virtual hardware buttons, but using one of the softke
ys as "Back" on a device that has its own Back button is particularly popular. Couple this with making the hardware back button inert! After all, the user knows
how to use her own device's user interface paradigm: you wouldn't want to support that.
    * Use a tiny font and subtle colors. This technique increases users' eye strain.
    * Don't remember the user. Requiring the user to type a user name and password each time adds to the experience. Advanced: require mixed case, numbers, and s
ymbols in your passwords.
    * Expire passwords and sessions after a couple minutes. Those of you in the financial sector know all about this one, but some of the rest of you haven't tri
ed this trick yet. Because somebody might walk away from a computer and expose secure data to prying eyes, keep the session timeout for a mobile device very shor
t, because people walk away from their phones all the time, letting strangers use their connection and services.

Universal fallacies of distributed applications

http://today.java.net/jag/Fallacies.html

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause
 big trouble and painful learning experiences.
1.      The network is reliable
2.      Latency is zero
3.      Bandwidth is infinite
4.      The network is secure
5.      Topology doesn't change
6.      There is one administrator
7.      Transport cost is zero
8.      The network is homogeneous

Micro-ISV checklist

   1.  Register Domain
   2. Reliable hosting
   3. Website design
   4. BasicWebsite content
   5. Install traffic monitoring on your site
   6. Create forums, encouragefeedback
   7. Maintain a FAQ
   8. Get the best screenshots you can
   9. Configure email for domain
  10. Get payment account
  11. Allow payment from your website
  12. Create a PAD file -- portable application description
  13. Register at download sites
  14. Strategy: separate "free" from "professional" products
  15. Get a suitable end user license agreement (EULA) -- infact get two!
  16. Auto update strategy
  17. License activation webservice/website
  18. Get a license management database
  19. Build a proper installer
  20. Obfuscate your assemblies
  21. Automate your build+release strategy
  22. Free up enough time/resources for dealing with support/feedback
  23. Shiny, Usable, Helpful
  24. Plan and enact your promotional strategy
  25. Do it all again

Future of networked games

http://www.raphkoster.com/2006/02/10/are-single-player-games-doomed/#comment-2384

What is going to happen, and what I am specifically referencing, is that games of ALL sorts will be delivered via services.
The services will have persistent identities.
The services will have persistent high score tables.
The services will maintain profiles for you.
The services will publicly display those profiles.
The services will matchmake you.
The services will datamine your activity.

The services will market to you based on your activity. The services will even likely look like games themselves, and might even BE games themselves. They will a
lso be places of commerce. They will download everything to you; you will not buy at retail. And you will feel that all this is more convenient, that your achiev
ements are cool to have, that your profile is who you are, that your high score is the one to beat. You'll still dig single-player gaming, but you'll be playing
the game of the service even if you think you'll be playing the single-player game.

More future of games

From http://www.gamasutra.com/austingdc2007/index.php?id=15374

- the system is the game, not the interface, not the presentation.
- any button will do.
- long phases take your time Ā– response time is rough.
- be done fast, once you’ve made a decision.
- do it side by side. Has to be massively parallel.
- extended accumulated state – save your profile.
- no roles – classless – teams are deterministic.
- representation agnostic – draw it however.
- open data – change it however.

Things that don’t work:

- twitch games.
- Inputs that are locked to commands – dance mats, styluses.
- Models that rely on specific representations (ie 3D).
- Models reliant on prior art – if you haven’t played every RTS you’re screwed.
- Narrative lock – if you tamper with our story, it won’t be good!

Parallel models:

- Badges (achievements)
- Ratings (skill or social)
- Rankings (high scores)
- Reviews (and tagging)
- Gifting
- Networks
- Leagues (segmentation)

A checklist of the major problems facing independent mobile development

From http://www.littlespringsdesign.com/blog/2008/03/06/challenges-in-the-off-deck-mobile-content-market/

   1.  Discovery - the user has to find the content
   2. Distribution - the content has to get onto the handset
   3. Usefulness - the content has to provide actual value to users, to delight users
   4. Usability - it has to be easy to use
   5. Contextuality - the right function and the right content at the right time, while mobile
   6. Monetization - content owners have to have a business model

Some excellent writing and thoughts on mobile game dev

http://patterns.littlespringsdesign.com/index.php/Game_Design

Gartner's projected technologies that will change the world over the next four years:

   1. Multicore and hybrid processors
   2. Virtualization and fabric computing
   3. Social networks and social software
   4. Cloud computing and cloud/Web platforms
   5. Web mashups
   6. User Interface
   7. Ubiquitous computing
   8. Contextual computing
   9. Augmented reality
  10. Semantics

http://businessofit.blogspot.com/2008/05/gartner-reveals-top-10-technologies.html

Dev