Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

26. November 2015

 

Quickly after the open sourcing of Goo engine,  Goo have announced a new version of their Goo Create tool.  They also launched a new developer forum.

From the announcement:

New Features/Improvements

UI Overview inside of Create

New users get presented with a general UI overview of the Dashboard and Create. Hopefully this will help people get started and contribute to the creation of a larger and more dynamic community that everyone can benefit from.

Uniform (and proportional) Scaling

create-uniform-scale

There is a new checkbox in the Transform Component panel that lets you enable uniform scaling. When this setting is enabled, changing one of the scale values will also change the other values to ensure that they keep the proportions between them. For example, if the scale is set to (1, 1, 1), changing the scale along the X axis to 2 will result in a scale of (2, 2, 2).

Correct script names in the Chrome DevTools

Scripts will now show their correct name in the Chrome DevTools. This makes it a lot easier to debug your scripts.

Other Improvements
  • Numerical (spinner) inputs we improved to ensure that text selection works properly and that dragging up or down to change the value works in a smooth way (not stopping to change will dragging over the “threshold” area).
  • Texture positioning inputs now use steps of 0.01 for a more precise control.
  • Added touch support for the button script.

GameDev News ,

26. November 2015

 

Construct2, the popular visual HTML5 game engine, just released version R218 beta.  Construct2Logo

From the release notes:

New this release: support for NW.js 0.13.0-alpha6 with a few bug fixes, experimental support for recording a video of the canvas with Firefox, and pressure and size information for touches, particularly relevant for the iPhone 6S with its 3D touch support.

NW.js 0.13.0-alpha6

Hot on the heels of the alpha5 update, alpha6 is now out with more feature support and some important bug fixes including allowing NW.js features to work in preview mode. This C2 release also fixes a bug that was causing a blank screen after export. Be sure to head to scirra.com/nwjs to download the latest alpha6 release of NW.js, which is out now.

Canvas video recording

Firefox 43 adds a new feature that enables recording a video of canvas elements. Note Firefox 43 is due for stable release in December, but you can try it now using Firefox Beta, Dev or Nightly. The User Media object has been extended to allow recording the canvas, and Construct 2 has a new "canvas recording" example that demonstrates how to use it. Previously recording a video of your game would involve using separate video recording software, so it could be handy to instead record it directly from the browser.

This is a pre-release feature, so there may be some bugs or quirks. I noticed for example Firefox only appears to encode video at 30 FPS with the VP8 codec in a WebM container. If you need video in another format, you may need to transcode it afterwards. It also does not currently include sound, although it may be possible to add that later on.

 

Changelog

Add User Media: experimental support for recording a video of the canvas [currently Firefox 43+ only].

Add Touch: experimental WidthForID, HeightForID and PressureForID expressions, to get a given touch's area and pressure. This should also report the pressure of touches on the iPhone 6S (although we do not have a device to test this on yet).

Bug Fix NW.js plugin: caused blank screen in NW.js 0.13

Bug Fix IAP: could have failed to restore purchases on Android

Bug Fix Using savegames could crash if the browser had blocked access to storage

Bug Fix Preview & debugger could crash in Firefox if cookies had been disabled in Privacy settings

GameDev News ,

19. November 2015

 

I remember using Allegro wayyyyyy back in the day in the early 1990s.  It was one of few graphics libraries available for DOS based machines (even though it started life as an Atari library) and certainly one of the only free game libraries available.  Amazingly enough Allegro is still under active development.  Anyways enough reminiscing…  today Allegro.js was released, an HTML5 library inspired by Allegro.  For a brand new library there is already an impressive amount of documentation and reference material available.  One of the hallmarks of the Allegro library was it was brutally simple to use and Allegro.js seems to have carried on that tradition.  Here is an example Allegro app:

 

// bitmap oobjects
var logo,ball;

// sample object
var bounce;

// size and speed of the ball
var size=64,speed=5;

// positon of the ball
var cx=100,cy=100;

// velocity of the ball
var vx=speed,vy=speed;

// drawing function
function draw()
{
   // draw allegro logo background
   stretch_blit(logo,canvas,0,0,logo.w,logo.h,0,0,SCREEN_W,SCREEN_H);
   
   // draws the ball resized to size*size, centered
   // stretch it a bit vertically according to velocity
   stretch_sprite(canvas,ball,cx-size/2,cy-size/2,size,size+abs(vy));
}

// update game logic
function update()
{
   // did the ball bounce off the wall this turn?
   var bounced=false;

   
   // if the ball is going to collide with screen bounds
   // after applying velocity, if so, reverse velocity
   // and remember that it bonced
   if (cx+vx>SCREEN_W-size/2) {vx=-speed;bounced=true;}
   if (cy+vy>SCREEN_H-size/2) {vy=-speed*3;bounced=true;}
   if (cx+vx<size/2) {vx=speed;bounced=true;}
   if (cy+vy<size/2) {vy=speed;bounced=true;}
      
   // move the ball
   cx+=vx;
   cy+=vy;
   
   // if it bounced, play a sound
   if (bounced) play_sample(bounce);
   
   // add gravity
   vy+=.3;
}

// entry point of our example
function main()
{
   // enable debugging to console element
   enable_debug("debug");
   
   // init all subsystems, put allegro in canvas with id="canvas_id"
   // make the dimesnions 640x480
   allegro_init_all("canvas_id", 640, 480);
   
   // load ball image
   ball = load_bmp("data/planet.png");
   
   // load background image
   logo = load_bmp("data/allegro.png");
   
   // load the bounce sound
   bounce = load_sample("data/bounce.mp3");

   // make sure everything has loaded
   ready(function(){
      
      // repeat this game loop
      loop(function(){
         
         // clear screen
         clear_to_color(canvas, makecol(255, 255, 255));

         // update game logic
         update();

         // render everything
         draw();
   
      // all this happens 60 times per second
      }, BPS_TO_TIMER(60));
   });
   
   // the end
   return 0;
}
// make sure that main() gets called as soon as the wesbite has loaded
END_OF_MAIN();

 

If this looks interesting to you be sure to check out Allegro.js.  It looks like a cool library, based on another cool library, just waiting for a community to form around it.

GameDev News, Programming ,

22. June 2015

 

Export to web has been a popular bullet point on most game engine feature lists as of late.  Both Unreal Engine and Unity recently offered native HTML5 export (Unity has had a plugin option for years, but plugins have gone the way of the Dodo).  LibGDX has offered a HTML5 target for ages, Haxe based game engines can all cross compile to HTML or Flash.  GameMaker, Construct, Stencyl and more have HTML5 exporters.   Of course, there are a number of HTML5 native engines (I suppose Construct should be on that list actually…), but they aren’t really what this conversation is about.

 

At the end of the day though… is anyone actually doing it?  Is there a “shipped” title from any of these engines that people are playing in any quantity?  It is my understanding that the vast majority of commercial web and Facebook games are still Flash based, with HTML5 representing perhaps 10-20% of titles.  More importantly, most of these titles are relatively simple, nothing harnessing a fraction of the power of an Unreal or Unity type engine.

 

It leads me to question, is HTML5 a feature everybody wants but nobody uses?

 

What inspired this thought was this interesting article on Godot’s efforts to target the web.  I have been actively monitoring the game development world during the entire timespan Juan described and I witnessed all of these “next big thing” technologies that came and went.  Summarized from the article, they were:

  • Native Plugins
  • Google Native Client
  • Flash
  • ASM.js
  • WebAssembly

 

This is by no means a comprehensive list, LibGDX compiles from Java to JavaScript using Google’s GWT for example, and some of these technologies were certainly successful for a time such as Flash.  Of course too, games written and targeted for HTML5 exist.  It’s this whole HTML5 as an additional target approach that I am beginning to think is just a gimmick.  The funny part is, I love the idea too… I evaluate a lot of game engines and I always see “HTML5 export” and think “ooooh, that’s good”.

 

Games in the browser certainly seemed to have a brilliant future at one point.  The Unity web plugin really did bring Unity to the web.  I used a couple of Unity powered 3D tools, such as Mixamo, and it was very near to native in experience (they have since ported to HTML5 since the Unity plugin was end of life-d).  Google’s Native Client (NaCL) had some promise, with shipped titles such as AirMech leading the way, but a single browser solution was never going to fly.  Ultimately Flash, especially with it’s promising (at the time) 3D API had the most promise, but a combination of Apple’s malevolence and Adobe’s incompetence brought that to an inglorious end.

 

Perhaps it’s just ignorance on my end.  Can anyone out there point me at an HTML5 game (not a tech demo, an actual game) created in either Unity or Unreal Engine?  I realize both are fairly new, so I would also settle for examples that are under development but show promise.  Keep in mind here, I’m not talking about HTML5 game engines, there certainly is a future in HTML5 games and of course they can be wrapped and deployed to a variety of platforms.  No, it’s “HTML5 as an additional target platform” support that seems to be pure gimmick at this point.

Totally Off Topic

29. March 2015

 

The popular HTML5 library Phaser have just released 2.3.  It’s not a huge new functionality release, but it’s got some major architecture changes that will affect you greatly if you are a Phaser user.  First off, they went down a more modular approach leading to fewer god classes.  This is aPhaser 2.3.0 good thing™.  Then thanks to this redesign, they also made the Phaser build process different, allow you to disuse unneeded portions.

 

From the release notes:

 

Significant Updates

 

GAME OBJECTS AND COMPONENTS

All of the core Game Objects have received an important internal restructuring. We have moved all of the common functions to a new set of Component classes. They cover functionality such as 'Crop', 'Physics Body', 'InCamera' and more. You can find the source code to each component in the src/gameobjects/components folder of the repo.

All of the Game Object classes have been restructured to use the new component approach. This puts an end to the "God classes" structure we had before and removes literally hundreds of lines of duplicate code. It also allowed us to add features to Game Objects; for example Bitmap Text objects are now full-class citizens with regard to physics capabilities.

Although this was a big internal shift from an API point of view not much changed - you still access the same methods and properties in the same way as before. Phaser is just a lot leaner under the hood now.

It's worth mentioning that from a JavaScript perspective components are mixins applied to the core game objects when Phaser is instantiated. They are not added at run-time or are dynamic (they never get removed from an object once added for example). Please understand that this is by design.

You can create your own custom Phaser classes, with your own set of active components by copying any of the pre-existing Game Objects and modifying them.

 

CUSTOM BUILDS

As a result of the shift to components we went through the entire source base and optimised everything we could. Redundant paths were removed, debug flags removed and new stub classes and hooks were created. What this means is that it's now easier than ever to "disable" parts of Phaser and build your own custom version.

We have always included a couple of extra custom builds with Phaser. For example a build without P2 Physics included. But now you can strip out lots of additional features you may not require, saving hundreds of KB from your build file in the process. Don't use any Sound in your game? Then you can now exclude the entire sound system. Don't need Keyboard support? That can be stripped out too.

As a result of this work the minimum build size of Phaser is now just 83KB (minified and gzipped).

Please see this tutorial on how to create custom builds.

 

ARCADE PHYSICS

We've updated the core of Arcade Physics in a number of significant ways.

First we've dropped lots of internal private vars and moved to using non-cached local vars. Array lengths are no longer cached and we've implemented physicsType properties on Game Objects to speed-up the core World collideHandler. All of these small changes have lead to a nice improvement in speed as a result, and also allows us to now offer things like physics enabled BitmapText objects.

More importantly we're now using a spacial pre-sort for all Sprite vs. Group and Group vs. Group collisions. You can define the direction the sort will prioritize via the new sortDirection property. By default it is set to Phaser.Physics.Arcade.LEFT_RIGHT. For example if you are making a horizontally scrolling game, where the player starts on the left of the world and moves to the right, then this sort order will allow the physics system to quickly eliminate any objects to the right of the player bounds. This cuts down on the sheer volume of actual collision checks needing to be made. In a densely populated level it can improve the fps rate dramatically.

There are 3 other directions available (RIGHT_LEFT, TOP_BOTTOM and BOTTOM_TOP) and which one you need will depend on your game type. If you were making a vertically scrolling shoot-em-up then you'd pick BOTTOM_TOP so it sorts all objects above and can bail out quickly. There is also SORT_NONE if you would like to pre-sort the Groups yourself or disable this feature.

Another handy feature is that you can switch the sortDirection at run-time with no loss of performance. Just make sure you do it before running any collision checks. So if you had a large 8-way scrolling world you could set the sortDirection to match the direction the player was moving in and adjust it in real-time, getting the benefits as you go. My thanks to Aaron Lahman for inspiring this update.

 

PHASER.LOADER

The Phaser.Loader has been updated to support parallel downloads which is now enabled by default (you can toggle it via the Loader.enableParallel flag) as well as adding future extensibility points with a pack/file unified filelist and an inflight queue.

There are no known incompatibilities with the previous Loader. Be aware that with parallel downloading enabled the order of the Loader events may vary (as can be seen in the "Load Events" example).

The parallel file concurrency limit is available in Loader.maxParallelDownloads and is set to 4 by default. Under simulated slower network connections parallel loading was a good bit faster than sequential loading. Even under a direct localhost connection parallel loading was never slower, but benefited most when loading many small assets (large assets are more limited by bandwidth); both results are fairly expected.

The Loader now supports synchronization points. An asset marked as a synchronization point must be loaded (or fail to load) before any subsequent assets can be loaded. This is enabled by using the withSyncPoint and addSyncPoint methods. Packs ('packfile' files) and Scripts ('script' files) are treated as synchronization points by default. This allows parallel downloads in general while allowing synchronization of select resources if required (packs, and potentially other assets in the future, can load-around synchronization points if they are written to delay final 'loading').

Additional error handling / guards have been added, and the reported error message has been made more consistent. Invalid XML (when loading) no longer throws an exception but fails the particular file/asset that was being loaded.

Some public methods/properties have been marked as protected, but no (except in case of a should-have-been-private-method) public-facing interfaces have been removed. Some private methods have been renamed and/or removed.

A new XHR object is created for each relevant asset (as there must be a different XHR for each asset loaded in parallel). Online searches indicated that there was no relevant benefit of XHR (as a particular use-case) re-use; and time will be dominated with the resource fetch. With the new flight queue an XHR cache could be re-added, at the cost of some complexity.

The URL is always transformed through transformUrl, which can make adding some one-off special cases like #1355 easier to deal with.

This also incorporates the fast-cache path for Images tags that can greatly speed up the responsiveness of image loading.

Loader.resetLocked is a boolean that allows you to control what happens when the loader is reset, which happens automatically on a State change. If you set resetLocked to true it allows you to populate the loader queue in one State, then swap to another State without having the queue erased, and start the load going from there. After the load has completed you could then disable the lock again as needed.

Thanks to @pnstickne for vast majority of this update.

 

PIXI V2

We are now using our own custom build of Pixi v2. The Pixi project has moved all development resources over to Pixi v3, but it wasn't ready in time for the release of Phaser 2.3 so we've started applying our own fixes to the version of Pixi that Phaser uses.

As a result we have removed all files from the src/pixi folder that Phaser doesn't use, in order to make this distinction clearer. This includes EventTarget, so if you were relying on that in your game you'll need to add it back in to your local build.

We've also removed functions and properties from Pixi classes that Phaser doesn't require: such as the Interaction Manager, Stage.dirty, etc. This has helped us cut down the source code size and make the docs less confusing, as they no longer show properties for things that weren't even enabled.

We've rolled our own fixes into our version of Pixi, ensuring we keep it as bug-free as possible.


You can read the entire release notes here.

Programming, News ,

Month List

Popular Comments