Following up on the Tweener for games tutorials, this time we will see how to update amounts gradually using Tweener to make them look nice & smooth.
As an example we can see my game GAIA - Guess Who? where the score is updated gradually instead of in one step (immediately) adding more to the user's experience and making the game more playable and enjoyable. Trust me, these little details can make a difference ;)
Update amounts gradually using Tweener: What I've got on stage is a dynamic textfield with instance name "txtScore". To give it a value, we declare a variable called myScore:
var myScore : Number = 100; txtScore.text = myScore;
If you run the movie, your txtScore shows 100. Nothing exiting I know... :P
Because we need to update this amount when a certain event happens, then we add a button, we will call it mcAddBonus. Now let's use tweener to update the score adding a 50 points bonus:
import caurina.transitions.Tweener;
var myScore : Number = 100; txtScore.text = myScore;
Testing the movie, whenever we press our button after a second myScore updates by 50. Still nothing special :( but, how about if we use the tweener onUpdate parameter instead of onComplete? the onComplete only updates our score when the tween has finished but as we saw on the previous example, onUpdate updates the value gradually before the tween finishes. Let's change the code:
import caurina.transitions.Tweener;
var myScore : Number = 100; txtScore.text = myScore;
To be honest I was a bit too positive about this one and I was expecting to get one of the first 3 prizes, however, there were 200+ games and many of them were really good, so 5th place is not bad at all ;)
Actually there were two categories: - Rock Star Winners - Gaia Audience Prizes and my game Gaia - Guess Who? won the 5th place of the Gaia Audience Prizes category.
Using Adobe Flex as front end and Ruby on Rails as backend technology, here it comes Timetoast, a new web 2.0 site that you should keep an eye on. From their press room:
LONDON, England - April 22, 2008 - Timetoast, the new web-based timeline creation application, launches it’s service to the public today. Timetoast.com is a web application that allows people to create interactive timelines, which they can share anywhere on the web. Anyone can join and start creating and sharing their own timelines, all they need is a valid email address. It's also completely free. Timetoast.com was built on top of powerful open-source frameworks and technologies such as Ruby on Rails, MySQL and Adobe Flex
You don't even need to sign-up if in case you want to check the public timelines. However, you would need to fill in a small form (only 4 fields) to become a member and start creating your own time-lines. By default your timelines will be saved as "drafts" that later on you can change this status into "public" allowing the world to see them. One of the cool features is that there's RSS feeds everywhere! even each timeline has its own feed; this is great if in case you want to create a mash-up application or let's say widgets showing these data...
So, if in case you want to track a project, share the story of your life, your dog, your relationship... or tell others what you know about your favourite artist using a timeline, go and sign-up.
Last week I came back from holidays, I was back in my home country after almost 6 years since I left, that's why I couldn't update the blog... Anyway, as mentioned before, I'll be writing some tutorials on how to use Tweener for games development, however, take into account that the code can be used on other applications as well... The first "tutorial" is Creating a countdown using Tweener From my point of view, adding a countdown to a game helps to improve the playability as the user feels more challenged to finish certain task. After reading Arthur Debert's Tweener Tips, I got the idea on developing further his "Poor's man timer":
First we declare a variable called "timeleft" and set it to 30, so we will count down from 30 seconds to 0. The function tweenDown() traces the updated "timeleft", decreases the timeleft value by one and using tweener it calls itself every second thanks to the onComplete parameter.
If we tide up a bit, we can add another function to trace the updated value of timeleft, then we have something like:
var timeleft : Number = 30;
function showTimeleft() : Void { trace(timeleft); }
The function showTimeLeft() will trace the updated value of timeleft thanks to the parameter onUpdate and this allow us to do something else instead of only tracing; we can add a textfield (with instance name txtTime) to show us the updated timeleft value and the updated script would be:
var timeleft : Number = 30;
function showTimeleft() : Number { return txtTime.text = timeleft; }
Now, the problem is that when the countdown reaches 0, it doesn't stop! so we can add another function to check if there's any "timeleft" and if there isn't, then do something else. The final script for a simple countdown is:
import caurina.transitions.Tweener;
var timeleft : Number = 30;
function showTimeleft() : Number { return txtTime.text = timeleft; }
function tweenDown() : Void { Tweener.addTween(this, {time:1, onUpdate:showTimeleft, onComplete:countDown}); }
On my previous post I said I would avoid using "best practices" when developing my own stuff; trust me that this thing of people stealing code really annoys me but I've decided to change my tactic.
The thing is, you never know when you are going to work again on a project as for example, I want to update the Flash Date Calendar Widget I built long time ago, and even though the file "is not that bad" still is a bit messy and makes my work a bit harder; now imagine, if I completely avoid doing the things in "the right" way, any update in the future will be a nightmare!
To avoid feeling bad about the "code thieves", what I will do is to keep on writing tutorials and to show how easy is to use my secret weapon: TWEENER. These days I'll put together a series of tutorials on how I use tweener to do certain tasks like updating score, shooting, updating life, etcetera.
Generally speaking, best practices are good. But what are best practices? from the Wikipedia:
...Best practices can also be defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people.
Right, so in theory we want to accomplish a task in the most efficient way and I absolutely agree with that not only applied on programming but in other things we do in life. Now, if we are talking about programming and more specifically, programming ActionScript for Games, then the thing changes a bit and mostly will depend on one factor: are you developing as part of a team? if the answer is no, and you are definitely the only one working on certain game (or any application in general), then my advice is: "AVOID BEST PRACTICES".
and no, I'm not mad (well, not that much...) but I've opted for not using best practices because:
- The number of flash developers is growing (this is great!) - The number of people learning actionscript is growing (is fantastic!)
ok, both are actually good things, but...
- the more people learning actionscript, the more people use the ever growing number of evil tools to decompile your applications.
And that's the thing, I've been working long hours on a specific script, using my knowledge, my brain, studying, experimenting, testing, debugging... and all that just for a bandit that will come and steal all the hard work to monetize with it? NO THANKS!
the problem is, these days is very easy to monetize with your games, both using MochiAds and getting sponsors so there's a whole lot of thieves out there waiting for you to release a game just to steal some pieces of your code (if not all of it...)
Anyway, at the end of the day, they will manage to do it but I want to make their work not that easy, so from now on, I'll start using something like alphanumeric properties and methods so a code thieve will find only var s48758wikk49 : String = "alajsktha" that in fact it should be something like var score : Number = 567; and forget about best practices... :D will be fun!
and of course, I'm seriously thinking about buying SWF Encript from Amayeta, I think any serious flash developer should have a copy of it.
First of all, I still haven't got internet at home. Why? well, whenever my girlfriend allows me to turn on the computer, I don't want to spend my time checking my email, forums, blogs, etcetera; I prefer to work! :) These days I've been working on my games, updating old games and creating new ones and to promote them, I have updated my old website Overload Studios. Last time I updated the site was back in 2003! almost 5 years ago, so definitely I had to do something about it and do it fast so that's what I did:
Homepage: - Took a component from AFComponents. - Followed a tutorial in Spanish from Infected-FX (Gracias wey!) - Added some of my widgets - Added google ads, analytics, etc. and voila!
Games Pages: - Games and other swf files embedded using swfobject - Added some of my widgets - Added google ads, analytics, etc. and bingo!
my site has many more visits now; definitely a clean, clear and fresh design helps you to get more visits :) Of course I would love to have something more complex, having a rating system, allowing users to leave comments (that I can use as feedback to improve my games...) etcetera but at least the first step is done ;)
As I mentioned before, I had the idea of working on a game-widget or a widget-game or whatever you want to call it... And there it is, a widget called Piranha Loca, available at this moment only from Widgipedia as a web widget but I'm planning to add it to different widget distributors and have it available as a desktop widget as well. Again I've added MochiAds to the game so I can get some revenue out of the long hours that took me creating it :)
Inspired by Salvador Dalí's "The Persistence of Memory" where melting clocks mix with other elements including a group of ants, there it is yet another analogue clock for my collection...
Persistence of a Genius
The time is first taken from the computer system then shown as an analogue clock; the ants react to the mouse pointer. I've taken some elements from different widgets I built before as some of the elements used by Dalí were used in more than one of his masterpieces... When I was developing it, I was listening to "Salvador Dalí" by the Spanish band Mecano about 3 or 4 times in a row... I love that song! :)
If you like the Persistence of a Genius, you can get it from this link.
If you want to monetize from a game you have developed, apart from adding MochiAds and submitting your game to MindJolt as I did with La Cucaracha, you can look for a sponsorship. There are many games portals out there that, if your game is good, would be happy to pay you some money if you change/add this or that to your game, however, the best deal I have found so far is the Hallpass Developer Top Score Special. The idea is to make your game compatible with their top-score system and you do that adding just one line of code. I added this line of code to my game Slippery Pong and submitted it to Hallpass, when my game was accepted and added to the portal, I've got an email from Hallpass letting me know the $50 had been paid to my paypal account :)
Bill, from Hallpass says:
...I have been a full time web master (for games portals) for almost 10 years now. The reason why I have been able to stick around this long is because I "work with" developers. Not simply sponsor games which I think will get the most hits back to hallpass. As you can see many of our games get passed up by other portals, on hallpass I try and work with up-and-coming developers in the hopes they remember us after they make their first big hit and allow us to work with them on it. I dont get the max value of every game I sponsor but when you add up all the developers together hallpass offers a great package, and helps promote unknown talent.
Hallpass allows your game to have MochiAds so you get money from both your adds and from their sponsorship. I think is a great deal!
The idea of having a widget to do marketing for a game didn't work much; after joining MochiAds to get some revenue from my games, the thing was going a bit slow... I still haven't lost my hopes on using widgets to do some marketing though but definitely the way to go is to distribute your applications EVERYWHERE. For the last year I've been building widgets and uploading them into different distributors, trying not to upload the same widget to more than one distributor; however I don't think it was the best option. The more distributors show your widget, the more users... Now, going back to the game "La Cucaracha", I decided to send it to some game distributors, including NewGrounds, where the game did so so and I had some views that generated some small profit (around $1 :D )... A couple of days ago, I got and email from MindJolt telling me that they had accepted my game and after a small amend should go live; I did the changes and the game went live yesterday and... HURRAY!!!! I had almost 50K views in one day only! the reason? MindJolt has a really cool Facebook application where people are encouraged to play games and compete with their friends to see who has the highest score...
GREAT! that encourages me to keep on developing games, although I shouldn't leave widgets on a side, so the next one will be a game widget! :D
Roaches is a widget I built some time ago and put it on yourminis but didn't think it will be successful at all, however seems like its a bit popular as so far has more than 1200 installs.
I've made some minor updates as the cockroaches were a bit slow but the biggest reason for the update (and for this post) is because this widget has now a new purpose: Marketing. I've added a small "play game" button as a "call to action" to any person watching at the widget; the widget itself has some sort of interactivity as the cockroaches react to the mouse pointer, but I'm promoting the update of La Cucaracha, a game I made long time ago and these days I've been working on it (but haven't managed to upload the latest update as I cannot connect to my server... :( ) Anyway, here it is:
Might be a bit naughty from me adding something to a widget that has been in the wild for a while but at the end of the day, as soon as my widget doesn't have any sponsor, I'm its owner and I can do the changes I want (changes that won't change much the nature of the widget though). erm... this of sponsors sounds more like in the gaming industry as when you build a game, you can go to online companies that can buy it from you or sponsor it in any way; I think we are missing this in the widget industry.
Anyway, yes, I'm back to the gaming industry as from last month I started a new job as a Flash Developer for an Online Games company in Central London. As well I moved houses and I haven't got internet at home yet, that's why this blog has been a bit quit these weeks...
The event is on Thursday December 6th in the sunny and trendy city of Brighton and if I managed to convince my new managers (I'm changing jobs next month), I'll be there for sure.
Taking part in the Blog Action Day I will talk about this subject that is related to Digital Media and to the environment as well: Screensavers. Screens. Many people tend to confuse the terms and end up calling "screens" to their monitors (the hardware); screen is part of the monitor, only where the software is projected or displayed and this one shows data as pixels for us, human, to understand.
What pixels show is actually light. This is basic Digital Media colours theory where each pixel shows a combination of Reds, Greens and Blues (RGB) and when their value riches 256 (100% for humans) then is white light.
When there's absence of colours, there's absence of light; this will led us to believe that: the less light, the less power your monitor spends.*(wrong statement!)
A screensaver is a computer program designed to prevent a "Phosphor burn-in" on a CRT and plasma computer monitors by blanking the screen or filling it with moving images or patterns when the computer was not in use.
If you check the screensavers that that come by default in your windows (I haven't checked the Mac ones...), you will notice that all of them have a black background.
screensaver = saves your screen *(again, wrong statement!)
Now, what should we take into account when building screensavers? - Something important from the Wikipedia's Screensaver definition is that they mentioned CRT monitors and these work in a different way as the TFT-LCD monitors that most of us use nowadays. * Wikipedia:
Monitors running screensavers consume the same amount of power as when running normally, which can be anywhere from a few watts for small LCD monitors to several hundred for large plasma displays. Most modern computers can be set to switch the monitor into a lower power mode, blanking the screen altogether. A power saving mode for monitors is usually part of the power management options supported in most modern operating systems, though it must also be supported by the computer hardware and monitor itself.
Additionally, using a screensaver with a flat panel or LCD screen instead of powering down the screen can actually reduce the lifetime of the display, since the fluorescent backlight remains lit and ages faster than it would if the screen was turned off completely. As fluorescent tubes age they grow progressively dimmer, and they can be expensive or difficult to replace. A typical LCD screen loses about 50% of its brightness during a normal product lifetime, if left on continuously. (In most cases, the tube is an integral part of the LCD and the entire assembly needs to be replaced.)
Thus the term "screen saver" is, in most cases, a misnomer--the best way to save the screen (and also save electricity) would simply be to have the computer turn off the monitor
. So, I would recommend: - Check who your target is and depending on that, consider (or not) designing a clean and clear screensaver, avoiding a black background. Remember, those screensavers made by Microsoft for its Operative System, where made some years ago, when most of the people had CRT monitors. - Be careful with the animations, definitely use them but don't abuse them. It's not good to have all the elements in the screensaver jumping from side to side as that can become annoying. - Avoid using sound. - Don't worry much about the file size as you would for a web application. - Use vector graphics as you don't know the screen resolution of the final user if in case you would allow the graphics to be scaled (up or down) or if you want to use a fixed size for your animations, then consider a plain background colour as there might be people using really high resolutions that will want to use the screensaver. If in case you have chosen to have a fixed size, then you can use bitmaps as they wont get pixelated and consider optimize the graphics for 800x600 pixels resolution as in the latest web browser statistics, there's a still big 14% of users with this screen resolution.
If you think of anything else that should be taken into account, please add it in the comments. And remember, the best way to save energy is turning off the monitor, so if you leave your desk for more than 5 minutes, just press that button ;)
more info: http://en.wikipedia.org/wiki/Screensaver
The way I'm learning things, specially about building widgets, is from trial and error. This is not the best way to learn as it's better to prevent than to cure but as I don't have enough time to read and study about the subject and because this is just a hobby for me, I just do the things as I think they will work but after finding the "errors" I realize there are many things that can be done in a better way.
It's not that I'm new on the subject (building widgets) but it's my nature, I love experimenting, I love finding out how to do things in a different way and I love using my creativity when doing stuff.
So, the series I wrote about "Building flash web widgets" are WRONG! not because the script doesn't work nor because other technical issues but because of some basic aspects I didn't take into account when I built the widgets.
This is a review of those posts about building widgets and the final product:
Web Widgets vs Desktop Widgets - Subject It might sound obvious but web and desktop are two very different worlds and even though there are many people out there trying to merge both worlds, bringing the web to the desktop and vice versa, web and desktop are still very different from each other, desktop is personal, web is open to the world. Desktop widgets interact more with your system and with the data that comes from it, being this a CPU usage, space left in the hard drive, etcetera, things no-one else cares about but only you. Web widgets interact more with web users showing visitors statistics, countdowns for different events, music you like, and other things you definitely want to share with other people. How about building a clock as I did for the tutorials on building widgets? It works for both web and desktop, it's a common subject but the concept should be treated in a different way: keep it simple for the web and for the desktop, it can be simple or it can be interesting & complex as well.
- Usability When we are on-line we want the information to be displayed now, we want to understand what it's going on ASAP, therefore, showing an experimental clock where the user has to think to understand what the time is just DOESN'T WORK.
How do I know that? Well, just check out the pathetic statistics; after more than a month out there, the clock has not even 30 subscriptions. On the other hand, we are used to admire the desktop and its applications, we can open any widget and take our time to check it out, we love playing with it, dragging it, changing colours checking the different options, and if we don't like it just drag it to the recycle bin and that's it... More than 500 downloads in less than a month tells me that. - Dimensions Even though your web widget can be displayed in many different environments, most of them and in most of the cases, they will be displayed in the sidebar of a blog; remember that nowadays not only my aunt but hers cat has a blog and even if it's not the rule, your widget will end up in a sidebar's blog. As mentioned in this post, the "Pie Clock" is 200 by 200 pixels and that is TOO BIG for any sidebar. I would recommend any size from 100 to 180 pixels width and depending on the concept/design, from 50 to 300 pixels height. I would say, 180x300 pixels is just the perfect size, however, this depends on the subject-concept-design. Take into account that Google adds some extra pixels to the sides of your widget (b*stards! :D ) as you can see on this breakout-mini widget that just looks AWFUL. - Size Not the dimensions but the size of the application itself, known as well as weight, in bytes. Might seem to be obvious but as we are used to develop things for the web, we tend to optimize all the graphics for the web. In fact, when building web widgets, we SHOULD optimize for the web all the graphics and our widget should not be bigger than 50kb (that is already BIG!), however, that again depends on the concept. Remember that people will have more than one widget and we should think about the loading time of a website and how important it is for users (when a site takes to long to load, people tend to close it and visit the next one...) When building for the desktop, the graphics should look really good, we don't need to optimize them and we can add all the necessary stuff using the best possible quality as users don't care about how big a downloadable file is; of course, we don't have to abuse, I would say from 2 to 3MB file size would be fine. - Shape I know I want to be as creative as possible, I want to break the usual square and my widget should have crazy shapes everywhere. Well, if we are using Google Gadgets to distribute our web widgets, that won't be the case, Google adds an ugly box around the widget with an opaque background so our web widgets will look like in a prison that doesn't let them "breathe" (graphically speaking). Did I called them b*stards before? :D For desktop widgets its different, we can have nice shapes, of course, we shouldn't abuse nor we should have transparent octopus shapes everywhere, keep it simple but break the square box.
- Final touches Adding nice animations and transitions is essential for an eye catching widget, of course being careful not to reach the limit from nice to cheesy. The advantage for web widgets is that the whole widget can have an animation, it can move from side to side, change shape, etcetera, but desktop widgets, specially with exotic shapes, request a lot from the processor when moving on the stage. Another thing to add is an extra menu using the right button of the mouse, read this post for web widgets and this post for desktop widgets. Something I'm considering is adding a "read me" .txt file attached to the desktop widgets where I can explain how to use the widget and other documentation.
- Extra options When adding customization options to the web widgets, the options are usually available only when first selecting and installing the widget. Could be great if the web widgets would have a better way to update this customization options when already installed. I'm not quite sure but Clearspring allows you to update this options when the widget is already in use, I remember having read something about it when adding one of their widgets on my blog. Desktop widgets usually have the option to change settings at any time, that's a great thing and a big advantage from desktop widgets over web widgets.
This is the "widget version" of the Breakout game I did some time ago. I submitted it to Google Gadgets and I must said, it was again a big pain! I really thought that it will be easy this time but no way, finding the right page to do all the things its a nightmare, creating the elements and editing the xml file is another big headache... Anyway, here it is:
The widget shows the latest visitors statistics from your blog or website, collecting the data from Clicky and showing the top 7 of a respective category. The available options to show are:
- visitors top cities - incoming links - search engines - downloads - operative systems - visitors top countries - entrance pages - web browsers - search keywords - exit pages - pages - searches - languages - screen resolutions - incoming link domains - outgoing links
So far, no one has yet set the rules in this crazy widgets world and now we are suffering the consequences. Different distributors use different options, tools, scripts, approaches, etcetera and none of them seem to be compatible with each other.
Even though from November last year the World Wide Web Consortium already listed a document about widgets, there's still something wrong about the web widgets ecosystem.
Alex Iskold has a very interesting post on the subject (How javascript is slowing down the internet...) and after reading it, I got rid of some widgets as an attempt to speed up the loading time of this blog but it is still slow.
Today I was reading a post from Derek Anderson and his frustration on the matter (Fricken widgets keep disappearing) and I absolutely agree on what he says. Lawrence Coburn at Sexy widget wrote something related and how he realized it after one of his readers comment.
Definitely we need to do something about it. Now, that us (widget developers) need to monetize to have decent servers, it's definitely true! My stuff is hosted in a very dodgy server and I've asked for help to some widget distributors without any positive answer. At the end of the day, I don't get anything from my widgets but they do and they should help us out.
There are some distributors that host the widgets themselves and that's fine as I don't need to worry about my dodgy server, however, sometimes their server is slow as hell so I have got rid of 5 cool widgets hosted in their server as you never know when their server will go slow again (affecting my site).
Now let's see how the process works: - As an internet user I visit your page and this one starts loading. The speed depends on my machine, my internet connection and YOUR SERVER (where your site is hosted). - If you have widgets, the first request goes to THE WIDGET DISTRIBUTOR'S SERVER - as soon as the distributors javascript file has loaded, this pulls the widget and it comes the third request: WIDGET DEVELOPER'S SERVER. - how about if the widget triggers some info from a web service? and if it's a mash-up? more servers involved... - It's very likely you will have more than one widget (specially if you blog about widgets) and the more widgets distributors involved, the more requests to different servers, the longer your page will take to load... kaput!
There are far too many steps, requests, etcetera and what happens is, your page is taking ages to load and I don't want to wait so I leave your site...
Solution: get rid of all other widgets but mine! :D ok ok, that's not a solution... I think the problem is very complex, distributors and developers need to find a solution together, the developers need more support from the distributors, otherwise this crazy widgets world will collapse soon.
I have already written something about the distribution of web widgets but if we are talking about distributing desktop widgets, the approach should be a bit different.
If you have built a Mac Dashboard widget, definitely you would need to submit it to Apple Dashboard, however, you shouldn't leave the things there and should submit it to a different distributor as well, in this case I would recommend you Widgipedia. In fact, Widgipedia is the only distributor that accepts any sort of widgets, from web widgets to Mobile widgets and of course desktop widgets so if you have followed my tutorials on Building desktop widgets with Zinc and right click on desktop widgets, the following step is the distribution.
Something I like the most about submitting widgets at Widgipedia is that your widgets don't need to be accepted and approved by any person so as soon as you have finished filling in the form and click "submit" your widget will be available for distribution. Great! and to make the things even easier, the form to submit a widget to Widgipedia is unbelievable simple.
The steps to follow are: - Sign up if not already a user
- click on the Submit a Widget button
- Fill in the form
- Choose the platform and browse for your widget (in this case is a standalone widget for windows)
- Click submit and you should see the message "Your widget was successfully updated." and that's it, your widget should be the first one in the gallery and the distribution will start...
Check out the "pie clock" desktop edition that I just uploaded.
So now you know, for desktop widget distribution, Widgipedia is the way to go.
