Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

22. June 2012

 

In this tutorial we are now going to implement a web app end to end using YUI and hosted in Node.  It isn’t actually going to do anything much, but it will illustrate everything you need to create a client and server in JavaScript using YUI App and Node.  Over time we will add more bells and whistles, but there is actually everything you need here to create a full functioning web application.

 

After looking in to it a little closer, YUI is incredibly well documented, but actually implementing YUI App Framework in a real world environment there are gaps of information missing.  Generally all you are going to find is samples with a gigantic HTML files where all of the script is located in a single file, which obviously isn’t good form nor very maintainable.  Unfortunately, when you actually set about splitting your YUI App into separate files and templates, you are completely on your own!  In fact, this tutorial may in fact be the first one on the subject on the internet, I certainly couldn’t find one. 

 

That said, there are still some great resources I referred to over and over well figuring this stuff out.  First and foremost, was the App Framework link I posted earlier.  It effectively illustrates using models and views, just not how to organize them across files in a complex project.  The GitHub contributor app was another great sample, but it again, was effectively one giant HTML file.  Finally there is the photosnear.me application’s source code up on GitHub.  It is a full YUI App/NodeJS sample and is certainly worth reading, but as an example for people learning it is frankly a bit too clever.  Plus it renders templates out using Node, something I wanted to avoid.

 

Alright, lets do a quick overview of how program flow works, don’t worry, it’s actually a lot less complicated than it looks. It is initially over-engineered for what it ends up accomplishing.  However, in the end you basically have the bones of everything you need to create a larger more complex application and a code structure that will scale with your complexity.

 

image

This ( in the image to the left ) is the file hierarchy that we are about to create.  In our root directory are two files, server.js which is our primary NodeJS application, while index.html is the heart of our web application, and where the YUI object is created.

 

Additionally, in a folder named scripts we create a pair of directories models and views.  Models are essentially your applications data, while Views are used to display your data.  Finally within the views folder we have another folder templates which is where our handlebar templates reside.  If you have done any PHP or ASP coding, templates are probably familiar to you already.  Essentially they are used to dynamically insert data into HTML, it will make more sense shortly.

 

We are going to implement one model, person.js, which stores simple information about a Person, and one view person.View.js which is responsible for displaying the Person’s information in the browser, and does so using the person.Template.

 

Now lets actually take a look at how it all works, in the order it is executed.

 

First we need our Node based server, that is going to serve the HTML to the browser ( and do much much more in the future ).  Create a new file named server.js

var express = require('express'), server = express.createServer(); server.use('/scripts', express.static(__dirname + '/scripts')); server.get('/', function (req, res) { res.sendfile('index.html'); }); server.get('*', function (req, res) { res.redirect('/#' + req.url, 302); }); server.listen(process.env.PORT || 3000);

 

Essentially we are creating an express powered server.  The server.use() call enables our server to serve static ( non-dynamic ) files that are located in the /scripts folder and below.  This is where we serve all of our javascript and template files from, if we didn’t add this call, we would either need to manually map each file or you will get a 404 when you attempt to access one of these files on server.  Next set our server up to handle two particular requests.  If you request the root of the website ( / ), we return our index.html file, otherwise we redirect back all other requests back to the root with the url appended after a hash tag.  For more details, read this, although truth is we wont really make much use of it.  Finally we start our server to listen on port 3000 ( or process.env.PORT if hosted ). Amazingly enough, these 9 lines of code provide a full functioning if somewhat basic web server.  At this point, you can open a browser and browse to http://localhost:3000, well, that is, once you start your server.

 

Starting the server is as simple as running node server.js from your command line.  This assumes you have installed NodeJS and added it’s directory to your PATH environment variable, something I highly recommend you do.  Now that we have our working server, lets go about creating our root webpage index.html.

<!DOCTYPE html> <html> <head> <title>GameFromScratch example YUI Framework/NodeJS application</title> </head> <body> <script src="http://yui.yahooapis.com/3.5.1/build/yui/yui-min.js"></script> <script src="/scripts/models/person.js"></script> <script src="/scripts/views/person.View.js"></script> <script> YUI().use('app','personModel','personView', function (Y) { var app = new Y.App({ views: { personView: {type: 'PersonView'} } }); app.route('/', function () { var person = new Y.Person(); this.showView('personView',{model:person}); }); app.render().dispatch(); }); </script> </body> </html>

 

The most important line here is the yui seed call, where we pulling in the yui-min.js, at this point we have access to the YUI libraries.  Next we link in our model and view, we will see shortly.  Ideally you would move these to a separate config file at some point in the future as you add more and more scripts.  These three lines cause all of our javascripts to be included in the project.

 

The YUI().use call is the unique way YUI works, you pass in what parts of YUI library you want to access, and it creates an object with *JUST* that stuff included, in the for of the Y object.  In this case, we want the YUI App class ( and only it! ) from the YUI framework, as well as our two classes personModel and personView, which we will see in a bit more detail shortly.  If you use additional YUI functionality, you need to add them in the use() call.

 

We create our app and configure it to have a single view named personView of type PersonView.  Then we set up our first ( and only route ), for dealing with the URL /.  As you add more functionality you will add more routes.  In the event a user requests the web root, we create a person model.  Next we show the personView and pass it the person model we just created.  This is how you connect data and views together using the YUI app framework.  We then render our app and call dispatch(), which causes our app url to be routed ( which ultimately causes our person model and view to be created. If you aren’t used to Javascript and are used to programming languages that run top down, this might seem a bit alien to you at first.  Don’t worry, you get used to it eventually… mostly).

 

Now lets take a look at our model person.js

YUI.add('personModel',function(Y){ Y.Person = Y.Base.create('person', Y.Model, [],{ getName:function(){ return this.get('name'); } },{ ATTRS:{ name: { value: 'Mike' }, height: { value: 6 }, age: { value:35 } } } ); }, '0.0.1', { requires: ['model']});

 

Remember in index.html in the YUI.use() call where we specified personModel and personView, this is how we made those classes accessible.  By calling YUI.add() we add our class into the YUI namespace, so you can use YUI.use() to included them when needed, like we did in index.html.

 

Next we create our new class, by deriving from Y.Model using Y.Base.create(),  you can find more details here.  We declare a single function getName(), then a series of three attributes, name, height and age.  We set our version level to ‘0.0.1’ chosen completely at random.  When inside a YUI.add() call, we specify our YUI libraries as a array named requires instead of in the YUI.use call.  Otherwise, it works the same as a .use() call, creating a customized Y object consisting of just the classes you need.

 

Now lets take a look at the view, person.View.js

 

YUI.add('personView',function(Y){ Y.PersonView = Y.Base.create('personView', Y.View, [], { initializer:function(){ var that=this, request = Y.io('/scripts/views/templates/person.Template',{ on:{ complete:function(id,response){ var template = Y.Handlebars.compile(response.responseText); that.get('container').setHTML(template(that.get('model').getAttrs(['name','age','height']))); } } }); }, render:function(){ return this; } }); }, '0.0.1', { requires: ['view','io-base','personModel','handlebars']});

 

Like person.js, we use YUI.add() to add personView to YUI for availability elsewhere.  Again we used Y.Base.create(), this time to extend a Y.View.  The rest that follows is all pretty horrifically hacky, but sadly I couldn’t find a better way to do things that way I want. The first horrible hack is that:this, which is simply taking a copy of PersonView’s this pointer, as later during the callback, this will actually represent something completely different.  The next hack was dealing with including Handlebar templates, something no sites that I could findon the web illustrate, because they are using a single HTML file (which makes the task of including a template trivial).

 

The problem is, I wanted to load in a Handlebars template( we will see it in a moment ) in the client  and there are a few existing options, none of which I wanted to deal with.  One option is to create your template programmatically using JavaScript, which seemed even more hacky ( and IMHO, beats the entire point of templating in the first place! ).  You can also precompile your templates, which I will probably do later, but during development this just seemed like an annoyance. The photosnear.me site includes them on the server side using Node, something I wanted to avoid ( it’s a more complex process over all, and doesn’t lend itself well to a tutorial ).  So in the end, I loaded them using Y.io. Y.io allows you to make asynchronous networking requests, which we use to read in our template file person.Template.   Y.io provides a series of callbacks, of which we implement the complete function, read the results as our template, “compile” it using Y.Handlebars, we then “run” the template using template(), passing it the data it will populate itself with.  In our case, our name, age and height attributes from our personModel.  template() after executing contains our fully populated html, which we set to our views container using the setHTML() method.

 

Finally, lets take a look at person.Template, our simple Handlebars template:

<div align=right> <img src="http://www.gamefromscratch.com/image.axd?picture=HTML-5-RPG_thumb_1.png" alt="GameFromScratch HTML5 RPG logo" /> </div> <p><hr /></p> <div> <h2>About {{name}}:</h2> <ul> <li>{{name}} is {{height}} feet tall and {{age}} years of age.</li> </ul> </div>

 

As you can see, Handlebar templates are pretty much just straight HTML files, with small variations to support templating.  As you can see, the values {{name}}, {{height}} and {{age}} are the values that are populated with data.  They will look at the data passed in during the template() call and attempt to find matching values.  This is a very basic example of what Handlebars can do, you can find more details here.

 

Now, if you haven’t done so, run your server using the command node server.js, if you have set node in your PATH.

 

Then, open a web browser and navigate to http://localhost:3000, and if all went well you should see:

 

image

 

 

Granted, not very exciting application, but what you are seeing here is a fully working client/server application with a model, view and templating .  There is one thing that I should point out at this point… in the traditional sense, this isn’t really an MVC application, there is no C(ontroller), or to a certain extent, you could look at the template as the view, and the view as the controller!  But don’t do that, it’s really quite confusing! Smile  Just know, we have accomplished the same goals, our data layer is reusable and testable, our view is disconnected from the logic and data.  Don’t worry, the benefits of all of this work will become clear as we progress, and certainly, once we start adding more complexity.

 

In the near future, we will turn it into a bit more of an application.

 

 

You can download the project source code here.

Programming , , , , ,

22. June 2012

 

Social games company Wooga have just open sourced their HTML5 game Pocket Island.  Youwooga-with-hosts can read the full Pocket Islands / Magic Land ( which used to be a Facebook App ) story right here.

 

If we are honest, after reading that I think they are putting too much blame at the feet of HTML and not enough at the feet of Facebook and themselves.  Additionally, in the few minutes I played, I saw a remarkably polished, pretty, *boring* game.  That said, I find that with most social games, so perhaps I am not the proper critic…

 

PI

 

Anyways, the end result is a good one for the rest of us.  The source is now up on Github. I don’t know about you, but I always jump at seeing commercial source code when the opportunity presents itself.

 

The tool chain required does seem a bit… complicated though.  brew, ruby, gem, rake, markdown, gcc, node, lessc, jslint, spritoia and pngcrush.  That said, ive never done an ounce of Ruby programming, so perhaps this is par for the course in ruby development.

 

Good on Wooga for sharing.  Perhaps nicest of all, the art assets have all been included as well ( under the Creative Commons non-Commercial license ).

News

21. June 2012

 

A few weeks ago, I mentioned that I might put together an HTML5 Roleplaying game tutorial and inquired how much interest there was in the subject.  There was sufficient interest, so I dove into the subject a little bit closer and came to a bit of a conclusion.  It’s ultimately theHTML-5-RPG tools that make the game in this case.  So, in addition to a game, I would have to create an editor, which is actually where most of the guts would reside.

 

This presented an interesting problem for me, as I’ve done a lot of web development, I mostly worked server side in a traditional language like C# or Java.  For this project, I wanted it to be JavaScript end to end.  I have a few key requirements:

 

  • single language, end to end
  • server based editor, that can be run locally on the client
  • code reuse between game and editor
  • MVC/MVP or MVVM based.  ( if you don’t know these acronyms, don’t worry )
  • event driven
  • rich UI
  • run on a tablet’s browser
  • database and local/remote filesystem support
  • json-based level output, which can be used by clients in any language
  • game entity scripting, probably again, in JavaScript

 

Part of these requirements are driven by personal interest, I have always wanted to try making an MVC based game editor.  MVC means, model-view-controller ( MVP == model view presenter and MVVM == model view viewmodel ) and it is a manner of design for decoupling your data ( your game’s/editor’s objects ) from your view ( your application or webpage ).  There are a number of great advantages to implementing things this way, including testability, maintainability, reuse and perhaps most importantly, it imposes a clean separation of responsibilities between systems.

 

The single language end to end is an easy one.  JavaScript.  While JavaScript is by no means the best designed language in the world, it is a extremely well supported one with a very bright future.  It is increasingly becoming a language that every developer is going to need to know, so why fight the future?  Of course, I could use a slightly higher level implementation like Coffeescript, Closure or Dart, they all ultimately compile down to JavaScript in the end.  That said, one of the biggest reasons I want to use a single language from end to end, is so the most people can follow along without having to know or learn multiple programming languages, so I will probably go with plain Jane JavaScript.

 

Now the whole running on a server and locally, that presented a bit of a trick.  I want people to be able to follow along, and run it from their own computer for their own projects, so offline is a must.  However, I also wanted an editor available for people who are only interested in game side of the equation, which is why I want to host one on my server.  That said, I also don’t want to bog my own servers down too badly.  This presented a bit of a problem, but it was solved soon enough when I started looking into….

 

Database and local/remote file system support.  Behind the scenes, a lot of tools are actually built around a database, whether they realize it or not.  In the end, many tools end up creating their own crude database server around their own file format, or often XML.  In my view, this is awfully close to re-inventing the wheel.  If you are using database like functionality in your tool, use a database!  Fortunately when it comes to JavaScript, there are an absolute ton of options!  From redis, a simple to learn key/value based database and JSON based CouchDB to more traditional databases like MySQL and SQL Server.

 

HTML5 has some options when it comes to local storage, such as well… webStorage.  There are some pretty heavily limitations here, one of the biggies is the lack of support.  Size limits are also rather severe size limitations, in the area of 2.5-5MB, a limit that you will run into extremely quickly.  The alternative to persist these files on the server isn’t really appealing to me, when I am the one paying the server bills! Smile

 

This is where Node comes in.  Node nicely solves just about all of these problems.  Essentially I am going to develop the editor as a node based client/server, where the user has the option of installing the client and server locally, and running it just like any other application.  This gives me access to the local file system and whatever other libraries I need.  However, it also allows me to use the exact same code to provide a hosted version of the editor other users can simply run in their browser.  Essentially Node will act as the host for the DB, as a web server and as the interface between the local machine and the view.

 

Speaking of which, this leaves the view…

 

Again, as I said earlier, the majority of client/server programming I did was built over Java or C#, so the HTML5 / JavaScript approach was new to me, so I had to take a closer look at what options exist.  In short, there are an absolute ton of options… too many in fact.  However, my rather well defined needs narrows things down quite a bit.  In fact, I am down to a pair of options, and would love your opinion on them.

 

 

Option 1

 

jQuery for the UIjquery-logo1

jQueryMobiel for the mobile UI

Node for the backend

CouchDB or redis for the database layer

Express for the server bits

Backbone.js for the um, backbone ( this is where MVC comes in )

Moustache and icanhazjs for the templates

underscore, well, just to make things work

 

 

Option 2

 

YUI for the front end (desktop and mobile), routing, MVC and server bitsyuilib

Node for the backend

CouchDB or redis for the database.

Handlerbars for the templating.

 

 

 

Both have benefits and detriments, especially from the perspective of a tutorial.

 

jQuery is easily the most popular UI library out there, and there is a gigantic amount of support available ( and dozens of books ), with a gigantic community.  Backbone and Moustache are less used, but still well supported.  Unfortunately, this also means introducing a half dozen pieces of tech, a very confusing prospect.  Development on all of these products moves extremely fast, which is a double edges sword.  Finally, and this is highly personal, I hate the look of jquery and underscore code, it feels so… hackey.

 

YUI on the other hand, is from a single vendor, with much less supporting material but very good documentation and a very clean modular design.  More to the point, it is an end to end system so it is very consistent.  However, if something goes wrong the community is much smaller and the supporting materials aren’t as readily available.  Perhaps the biggest downside with YUI is the newness of it.  YUI3 is still in transition away from YUI2, and YUI App ( the YUI equivalent to Backbone ) is young and at times it shows.  From an engineering perspective though, YUI just feels more solid and less like a clever hack.

 

Right now, ease of explanation is winning out, and I am leaning towards using YUI.  Going with on all encompassing library is much easier to configure and explain to readers, so that is a big plus.

 

Any thoughts or opinions on the subject? 

 

Oh, and if this is all sounding extremely confusing, don’t worry, it really isn’t that bad.  The end product should still be a single archive you download and execute with a simple click. 

 

So, over the next few weeks ( or more ), we are going to be going off on a slightly odd tangent here at game from scratch, and crossing over into the world of web app development, I hope many of you find it interesting.  For those that don’t, don’t worry, I will still be publishing game development specific contents and tutorials too!

Design , ,

20. June 2012

 

This tutorial is going to cover creating transition effects between your GameEngine2D scenes.  It is actually going to be rather short and mostly code, as the subject is actually quite simple and consistent between different effects.

 

All right, lets just right in.  First of all, when need our main application.  This is going to perhaps be the simplest one we have created to date, and all of the code should be familiar to you by now.  Create a new file named AppMain.cs as follows:

 

using System; using System.Collections.Generic; using Sce.Pss.Core; using Sce.Pss.Core.Environment; using Sce.Pss.Core.Graphics; using Sce.Pss.Core.Input; using Sce.Pss.HighLevel.GameEngine2D; using Sce.Pss.HighLevel.GameEngine2D.Base; namespace SceneTransitions { public class AppMain { public static void Main (string[] args) { Director.Initialize(); Scene1 scene1 = new Scene1(); Director.Instance.RunWithScene(scene1); } } }

 

All we are doing is Initializing the Director object, creating our custom scene of type Scene1 and telling it to run.  This literally is about the shortest PlayStation Mobile application you can create.

 

Now lets take a look at Scene1.cs

using System; using Sce.Pss.Core.Graphics; using Sce.Pss.HighLevel.GameEngine2D; using Sce.Pss.HighLevel.GameEngine2D.Base; namespace SceneTransitions { public class Scene1 : Scene { Texture2D texture; TextureInfo ti; public Scene1 () { this.Camera.SetViewFromViewport(); texture = new Texture2D("/Application/pic1.png",false); ti = new TextureInfo(texture); SpriteUV sprite = new SpriteUV(ti); sprite.Quad.S = ti.TextureSizef; sprite.Position = new Sce.Pss.Core.Vector2(0,0); this.AddChild(sprite); this.ScheduleUpdate(1); this.RegisterDisposeOnExitRecursive(); } ~Scene1 () { ti.Dispose(); texture.Dispose(); } public override void Update (float dt) { if((Sce.Pss.Core.Input.GamePad.GetData(0).ButtonsDown & Sce.Pss.Core.Input.GamePadButtons.Cross) == Sce.Pss.Core.Input.GamePadButtons.Cross) { if(Director.Instance.CurrentScene.IsRunning) Director.Instance.ReplaceScene(new Scene2()); } } } }

 

We are declaring a new class Scene1, which is derived from GameEngine2D.Scene. In this scene, in the constructor we are setting the camera to be sized to the viewport, creating a texture from our image pic1.png ( oh yeah, you need to add 3 images to your project, I picked three PS Vita wallpapers I downloaded off the net, you can use whatever files you want, but I assume you name them pic1.png pic2.png and pic3.png ) then create a sprite out of it.  This is all stuff we have done in prior tutorials.  We now add the sprite to our scene, and schedule this scene to receive updates.  Finally we call this.RegisterDisposeOnExitRecursive().  This function call is key, as it tells the Director to dispose of this scene when it is replaced.  If you do not call this, we will quickly run out of memory.

 

Next up is our destructor.  TextureInfo and Texture are both classes that you are expected to manage destruction of yourself ( they implement IDisposable ).  So in the destructor, which is called when our scene is replaced, we need to dispose of both of these items.  ( Actually I believe TextureInfo will take care of Texture2D, but don’t quote me on that ).

 

Next up is our Update() method.  As we have seen in the past, this method is called once every frame and is where your scene’s logic should be located.  In this case, we are waiting on the user hitting the Cross button ( or S key if using the simulator ), in which case we tell the Director to Replace the scene with a new created Scene2, which we will now create.

 

Create a file named Scene2.cs with the following code ( which is going to look extremely familiar… )

 

using System; using Sce.Pss.Core.Graphics; using Sce.Pss.HighLevel.GameEngine2D; using Sce.Pss.HighLevel.GameEngine2D.Base; namespace SceneTransitions { public class Scene2 : Scene { Texture2D texture; TextureInfo ti; public Scene2 () { this.Camera.SetViewFromViewport(); texture = new Texture2D("/Application/pic2.png",false); ti = new TextureInfo(texture); SpriteUV sprite = new SpriteUV(ti); sprite.Quad.S = ti.TextureSizef; sprite.Position = new Sce.Pss.Core.Vector2(0,0); this.AddChild(sprite); this.ScheduleUpdate(1); this.RegisterDisposeOnExitRecursive(); } ~Scene2() { ti.Dispose(); texture.Dispose(); } public override void Update (float dt) { if((Sce.Pss.Core.Input.GamePad.GetData(0).ButtonsDown & Sce.Pss.Core.Input.GamePadButtons.Cross) == Sce.Pss.Core.Input.GamePadButtons.Cross) { if(Director.Instance.CurrentScene.IsRunning) { Director.Instance.ReplaceScene( new TransitionCrossFade( new Scene3() ) { Duration = 4.0f, Tween = (x) => Sce.Pss.HighLevel.GameEngine2D.Base.Math.PowEaseOut( x, 3.0f )} ); } } } } }

 

So, basically it’s a cut and paste job of Scene1, just with a different texture file, and a different looking replace scene call.  I will look closer at that in a second.  Notice too that here we are creating a Scene3 in our Update() call, lets go ahead and create it next.

 

Create Scene3.cs

 

using System; using Sce.Pss.Core.Graphics; using Sce.Pss.HighLevel.GameEngine2D; using Sce.Pss.HighLevel.GameEngine2D.Base; namespace SceneTransitions { public class Scene3 : Scene { Texture2D texture; TextureInfo ti; public Scene3 () { this.Camera.SetViewFromViewport(); texture = new Texture2D("/Application/pic3.png",false); ti = new TextureInfo(texture); SpriteUV sprite = new SpriteUV(ti); sprite.Quad.S = ti.TextureSizef; sprite.Position = new Sce.Pss.Core.Vector2(0,0); this.AddChild(sprite); this.ScheduleUpdate(1); this.RegisterDisposeOnExitRecursive(); } ~Scene3() { ti.Dispose(); texture.Dispose(); } public override void Update (float dt) { if((Sce.Pss.Core.Input.GamePad.GetData(0).ButtonsDown & Sce.Pss.Core.Input.GamePadButtons.Cross) == Sce.Pss.Core.Input.GamePadButtons.Cross) { if(Director.Instance.CurrentScene.IsRunning) { Director.Instance.ReplaceScene( new TransitionSolidFade( new Scene1() ) { Duration = 1.0f, Tween = (x) => Sce.Pss.HighLevel.GameEngine2D.Base.Math.PowEaseOut( x, 3.0f )} ); } } } } }

Again, another cut and paste job, with just the texture file name changed, and a different ReplaceScene() call, this time creating a Scene1, basically creating an infinite application that shows Scene1, then button press, shows Scene2, button press, shows Scene3, button press, shows Scene1, repeat over an over.

 

Now lets look at the key differences between how the transitions work:

 

Scene1:

Director.Instance.ReplaceScene(new Scene2());

Scene2:

Director.Instance.ReplaceScene( new TransitionCrossFade( new Scene3() ) { Duration = 4.0f, Tween = (x) => Sce.Pss.HighLevel.GameEngine2D.Base.Math.PowEaseOut( x, 3.0f )} );

Scene3:

Director.Instance.ReplaceScene( new TransitionSolidFade( new Scene1() ) { Duration = 1.0f, Tween = (x) => Sce.Pss.HighLevel.GameEngine2D.Base.Math.PowEaseOut( x, 3.0f )} );

 

The transition from the first screen, does nothing, it simply transition to the next scene with no visual effect.  Your first image will simply be replaced with your second image.

 

Scene2 however, transitions by creating a new temporary scene, a TransitionCrossFade, which is essential a short lived scene that goes between Scene2 and Scene3 and causes a cross fade effect.  As you can see, we provide a Tween method which controls the rate at which the fade will occur.  A tween are not simply the people responsible for the bizarre success of the Twilight franchise, its actually short had for inbetween, which is essentially just a function that is going to be called over and over during a transition until it is completed.  Tweens are quite common in the animation world. 

 

Scene3 works almost identically to Scene2, but instead of a cross fade, it’s a solid fade.  You can see the difference in the video of this application in action.  There is one very important thing to be aware of here… these temporary scenes, TransitionCrossFade and TransitionSolidFade, if you try to replace them before they have completed running, your application will crash!  Truth is, in real life you won’t be switching scenes this quickly, so it should be a non-issue, but it is something you should be aware of.  If you want to witness this first hand, load this code up in the simulator and just repeatedly hit S, you will crash soon enough.

 

Now, let’s take a look at our code in action:

 

Transition between scenes on the PlayStation Vita Simulator

 

As always, you can download the full sources here.

Programming , , ,

19. June 2012

 

A couple months back took a long look at Appcelerator and initially I loved what I saw.  For those of you unaware, Appcelerator allows you to develop “native” applications for Android and iOS in JavaScript that execute in a special version of the V8 JavaScript Engine. I started developing a prototype app of a simple Android game for my daughter and got surprisingly good results quickly.  It was a very encouraging start, but then the wheels fell off.  I notice a number of people end up on this site from search engines looking for an Appcelerator review ( for some reason? ) so I thought I would share my experiences.

 

For whatever reason, I got distracted and put it down for a while, I came back to it recently and intended to finish off that prototype.  Here is the kicker, the exact same code from a couple months ago, unchanged, no longer works on my Transformer tablet.

 

I will say, this is frustrating to say the least.  Now, since the code didn’t change it was obviously an update to Android that broke things, I can’t exactly blame that on Appcelerator Titanium ( oh the joys of Android device compatibility… ) but I can blame them for what came next…

 

You can’t debug on device.  At all.  With the exception of printing comments to logcat, you are basically blind.  This obviously leads to a problem, as here is what happens when I run the app.  ( Which by the way, still runs perfectly fine on my Galaxy Note running Android 2.3.x, its just on my Asus Transformer that it breaks ):

 

appcell

 

Since I can’t debug on device, this is the results I get from connecting with the Delvik Debug Monitor:

 

06-19 09:56:51.090: I/TiApplication(1823): (main) [0,0] checkpoint, app created.
06-19 09:56:51.130: I/TiApplication(1823): (main) [46,46] Titanium 2.0.2 (2012/05/30 10:21 2ff31a3)
06-19 09:56:51.170: D/dalvikvm(1823): GC_CONCURRENT freed 268K, 5% free 6703K/7047K, paused 2ms+2ms
06-19 09:56:51.380: D/dalvikvm(1823): GC_CONCURRENT freed 314K, 6% free 6898K/7303K, paused 2ms+2ms
06-19 09:56:51.450: E/TiApplication(1823): (KrollRuntimeThread) [318,364] APP PROXY: ti.modules.titanium.app.AppModule@4112e910

 

 

And, that is it.  Since I can’t debug on the device, I am pretty much DOA here.  The forums answer nothing ( although I did find other people having similar problems ).  I of course could debug in the emulator with two exceptions.  a) the error only occurs on the actual device b) the debugging experience on Android is still awful.

 

This is another area with Appcelerator Titanium I always found infuriating… the emulator.  Getting it to actually run with your running emulator was a nightmare, you had to match up the Android build version and run configuration exactly with the version of the running emulator, then it was still a 50/50 chance that it would actually use your emulator, or start a new one.  If you’ve worked with Android before, you know how fun waiting for the emulator is!  There is light and the end of the tunnel with the recently release Intel emulator running a heck of a lot quicker, but unfortunately the JavaScript V8 virtual machine Appcelerator relies on doesn’t work with it.

 

It’s a shame to be tripped up on such a thing, but actually being able to debug on your device is an absolute requirement, as is demonstrated by this situation.  There are other annoyances with using Appcelerator certainly…  the binaries it generates are “large” to be extremely kind, performance can be a bit spotty at times and you virtually have to write two applications if you want to support iOS and Android, but none of these was enough to make me give up. 

 

Not being able to debug on device, coupled with some remarkably meh support.. that is.  Combined with the fact my application was broken by an Android update… if I can’t get my code working with my three devices reliably, what happens when I release to the masses with their millions of different devices?

 

Which is disappointing, as I really liked working with Appcelerator.  I even liked Appcelerator Titanium as an IDE, which is shocking as I hate Eclipse, which it is based on. 

 

There is potentially light at the end of the tunnel, as there is an open ticket for debugging on device.  Unfortunately, its been assigned medium priority and has already been open for almost a year.

 

Appcelerator Titanium is an interesting and encouraging product, but for the above reasons, I just can’t commit to using it.  Add native debugging support, and I will certainly reconsider.

General , , ,

Month List

Popular Comments

GameFromScratch.com’s List Of Newsworthy GameDev Topics
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


17. November 2015

 

I have noticed that there isn’t one good single source for game development news.  When a new game engine is announced or a new version of a critical tool, library or engine is released, there is no easy way to hear about it.  I hope to step in and fix this with GameFromScratch.  I am to become a single hub for indie and professional game development release news.  Basically I am going to scour the web for information so you don’t have to.

The following is the list of projects that I intend to monitor for news worthy activity. This is of course a work in progress, so if there is an engine, tool or project you want me to follow, let me know in comments or email me at news@gamefromscratch.com. Once finalized I will make this list permanently available so it will be easy to tell which projects are being tracked.  As news occurs it will be announced here under the category GameDev News.  Don’t worry, this isn’t GameFromScratch turning into a news only site, things will remain much as they are… just with a lot more news thrown in!

If you are the author of a tool, engine or project that is not on this list, be certain to email me. Of course, if you’ve got news to announce, sending it to me directly will result in a much higher chance of me noticing and thus reporting on it.  Ideally include a link to your RSS feed if one exists.  Otherwise I am setting up an elaborate network of RSS feeds, scripts and manual site checks to keep track of what is going on in the world of game development. 

This is of course a work in progress, so give me some time to get things all sorted and working properly.  Your feedback is as always appreciated!

 

So without further ado, the initial list of technologies I am monitoring.  The “Other” category is for the topics I am considering covering or that I feel are news worthy but don’t have a single source.


Engine Tools/Libs Other
  • LibGDX
  • Unity
  • Unreal
  • Blender Game Engine
  • Paradox3D
  • Duality
  • Urho3D
  • Gameplay3D
  • Gideros Mobile
  • Cocos2D-x
  • Marmalade
  • Monogame
  • Love2D
  • jMonkeyEngine
  • Babylon
  • Godot Engine
  • GameGuru
  • Construct2
  • GameMaker
  • RPGMaker
  • Torque2D/3D
  • Wave Engine
  • CopperLicht
  • Leadwerks
  • Atomic Game Engine
  • Polycode
  • Phaser
  • Corona
  • Shiva 
  • Neoaxis
  • Esenthel
  • Spring RTS
  • Goo Create
  • Oxygine
  • PlayN
  • ChilliSource
  • PlayCanvas
  • AGK
  • Dark Basic
  • ClickFusion
  • Isogenic
  • GDevelop
  • Citrus Engine
  • Stencyl
  • Blender
  • Tiled
  • Box2D
  • SFML
  • SDL
  • Ogre3D
  • Allegro
  • LWJGL
  • Pixi.js
  • CraftyJS
  • CreateJS
  • Bullet
  • Autodesk’s Suite (Max/Maya/Mudbox)
  • Adobe’s Suite ( Photoshop, Mixamo, Flash )
  • ZBrush
  • 3D Coat
  • Modo
  • Sketchup
  • Overlap2D
  • Texture Packer
  • Physics Editor
  • bgfx
  • Substance Painter/Designer
  • Quixel Suite
  • CopperCube
  • CocoonJS
  • GLFW
  • Flixel/HaxeFlixel
  • Flash/HaxePunk
  • Luxe/Snowkit
  • Inkscape
  • Krita
  • Xamarin
  • RoboVM
  • GIMP
  • Starling
  • Articy Draft
  • Game Jams
  • Free Art Releases
  • New GD Book Releases
  • Game Jams
  • Kickstarter GameDev

 

If you are wondering, the first column is mostly composed of complete game engines while the second contains mostly game libraries and tools.  The distinction is completely arbitrary so don’t mind which column I sorted a given technology by, it has no real meaning.  I may move libraries to a completely different column in the future.

I know that by no means this list is complete, it’s just the libraries I could come up with off the top of my head that are news worthy ( mature, have a user base and aren’t abandoned ).  So if you have additional suggests, please email them or leave them in the comments below.  As new suggestions are added I will update this list accordingly until I consider it “ready”, at which point I will move it to a permanent location.

News, GameDev News

blog comments powered by Disqus

Month List

Popular Comments