Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

5. October 2012

I am about to embark on a bit of a sidetrack here on GameFromScratch.com, hopefully a few of you find it interesting.

 

Basically I am going to start looking at developing game tools using HTML5.  Tooling is a massive part of the game development process and traditionally i've used RAD client only tools like C# + WinForms in this capacity, but HTML5 is becoming increasingly appealing.  I have done a great deal of traditional web development, but nothing really like this.

 

My first project is going to be a dry run on a level editing tool.  I have NO intentions of actually using the end result in a production environment, it is as much a learning experience for me as anything else.  This unshackles me from spending time on stuff like… design, as I intend to throw away everything anyways ( famous last words? ).  Besides, until you have a solid grasp of what you are doing and what problems you are going to face, it's pretty hard to create much of a design anyways.  Now, if I enjoy the experience and the results, I will put a great deal of thought into the design of the finished product.  But when just trying things out, design mostly just gets in the way.

 

This is not the first time I have gone down this road, I've started a number of times and run in to the same problem over and over.  Too much choice, not enough knowledge to make the decision.  I always end up looking at frameworks, design patterns, libraries, toolkits etc, and always end up getting nowhere.  Even picking a client side JS library can consume weeks of your life, throw in a persistence framework, MVC or MVVM framework and months of your life are gone.

 

In the past I went down this road, I looked in to technologies ( such as YUI, Kendo, jQuery, Backbone, Moustache, Dojo, etc… ) and found strengths and faults with all of them.  What I didn't find is success…  This is an area that is anathema to me.  I like to research things, know my options going in and make a decision from a position of some knowledge.  Problem is, there are just too damned many frameworks and options.

 

So I am doing something I never do.  I am picking the technologies up front, and come hell or high water, I am sticking with them until the end.  Therefore for my upcoming project I am going to work with:

- YUI 3 for UI, controls, data, program flow, etc...

- EaselJS for graphics.

 

 

Why YUI 3?  Well because it is pretty much an all encompassing framework, it does about everything, taking decisions away from me.  I don't need to pick a client side technology like jQuery, nor a mobile suite like jQueryMobile, nor a back end like Backbone or ember, package system like require, etc…  YUI pretty much has it all out of the box.

 

Why EaselJS instead of a plethora of game/animation HTML5 libraries?  God knows there are enough of them!  Well, because I haven't used it and I intended to look in to it.

 

So, I am not saying either of these technologies are better than their alternatives, I simply don't have the experience yet to make such a judgement.  I am going with them because, well, they are there.

 

Hope you find the process interesting.

Design, General, Programming

4. October 2012

 

Earlier this morning, this news article came across my desk and caught my interest for a number of reasons.  Basically as the title states, Appcelerator - the makers of the popular Titanium mobile development suite have funded a game development technology startup Lanica.

 

Lanica Logo

So, why should you care?

 

Well first off, Appcelerator Titianium is a very nice development environment.  For a few different reasons I chose not to develop with Titanium, the inability to debug on Android devices being the biggest hindrance ( and mostly Google's fault for making such a terrible emulator ), however this fault may have been removed!  ( I will be looking into this very shortly ).

 

Next, while working in HTML5 on mobile is nice, the question still remains if it is feasible for high performance games.  PhoneGap brings HTML5 to mobile devices in native app form, but it doesn't bring the performance.  There are a number of other technologies working on this problem, but one more is always a nice thing.

 

Finally Lanica does have some pedigree.  One of the two founders is Carlos Icaza, who among other things, was the founder and first CEO of Ansca mobile, the people that make the popular Lua based Corona SDK.  ( Recently featured in this comparison of Lua game engines ).

 

So, they have funding, they have experience and they are creating a game engine using a technology I am interested in.  You can certainly colour me intrigued.

 

A little bit ( so far as I can gather ) about the engine itself, Platino:

Platino allows Titanium users to build casual to high-end games in JavaScript using a carefully optimized, C++ native-built, cross-platform game engine.

But wait, there’s more:

  • OpenGL ES 2.0:  We’re bringing you the industry standard in hardware-accelerated, cross-platform API for 2D and 3D graphics.  The OpenGL engine is a flexible and powerful low-level interface between software and graphics acceleration, so you get the best performance with the most efficient (i.e. lowest possible) use of resources.
  • Isometric Tile Engine:  We have developed our own internal isometric engine, written entirely in C++.  The best part? It features direct hardware rendering and occlusion detection for your maps to be rendered at full hardware speed, giving them near real-time interactivity.
  • Sprite Sheets:  We also have developed our own internal sprite sheet engine, which also is optimized for performance and rendering.
  • Box2D:  The same physics engine that drives Angry Birds and some of the most popular mobile games on the market is embedded in the Platino game engine.
  • Particles:  We know you’re too creative for a “one size fits all” approach. So, using our Particle Designer plug-in, you can now create stunning visual effects at hardware speeds by customizing every aspect of your particle emitters.
  • Shaders:  Our game engine leverages OpenGL’s shading language to calculate rendering effects on images, vertices, and pixels – giving you a high degree of flexibility and rendering capabilities for your games.
  • 2.5D Support:  Built natively (yet again!) to give your game that extra “depth” needed to create pseudo-3D effects.
  • Native Interface Access:  Full access to your creations, so you can tinker with the native UI, mouse events, accelerometer, and more through Titanium’s powerful JavaScript methods and classes.


So if you like to work in JavaScript, want to create a game targeting iOS and Android but with native performance, Lanica/Platino/Titanium are certainly worth keeping an eye on!

 

As of right now, they appear to be in the pre-beta stage, although there is a sign up page here.  Hopefully I am able to get more access to Platino shortly, so I can bring you a bit more information. Neither pricing nor a release date have been announced yet.

News , , ,

3. October 2012

After a release candidate, followed by another release candidate, Blender 2.64 is finally here.

 

For game developers, the big release was actually the last one, this release is more focused of VFX, but there is still plenty to get excited about.  Here are details of the release in the Blender Foundation’s own words:

 

The focus was on creating a full VFX pipeline, with improved motion tracking using a planar tracker, easier green screen keying, and a new mask editor. A new tile based compositing system was added, along with more advanced color management. Cycles rendering got dozens of smaller features and improvements resulting from its use in production.

Sculpting now supports masks, and a skin modifier was added to quickly create a model from skeletons. The game engine got improved shadows and physics options, and Collada export now has more options to tune for exporting to other game engines.

 

The key changes, from a game developer’s perspective, are probably:

Mesh Tools

Bevel and inset now are modal operator with mouse control, a wire frame tool was added to turn edges into wireframe tubes, and vertex/edge/face sorting tools were improved.

Collada

The Collada exporter has been improved for better support of export to game engines, with more fine grained options to control which data is exported.

Sculpting

Sculpting has received some major improvements such has masking to control which areas of the mesh are influenced by sculpting, new brush map modes to control how textures are projected onto the model, and an input stroke averaging option to make brush strokes smoother.

Skin Modifier

The Skin modifier takes a skeleton made up of vertices and edges as input and generates a polygon skin as output, consisting mostly of quads aligned along the edges. The output is mostly quads, although some triangles will appear around intersections.

Game Engine

Lamps and shadows were improved with support for variance shadow maps, shadow color, sun lamp shadows and lamp textures. Non-power of two textures and compressed textures will now load faster and use less memory. A new Character physics type was added, designed for player controlled characters.

 

Of course there were also a ton of bug fixes.

 

Good job on the release Blender team!

 

You can go download the newest release right here.  Of course, expect a bit of a wait as their servers get pummelled.

News , ,

3. October 2012

 

Not to make any assumptions about your mother’s computing abilities of course!  My mother is flummoxed by powering a computer on and its all down hill from there, so perhaps not quite easy enough *my* mother could do it.  But it is easy, really easy.  Really.  Easy.  This is just one of those areas Moai really shines.

 

If you are unfamiliar with the concept, a tilemap is pretty straight forward.  You have an image or series of images that hold the art for your game.  In this example, we are going to use a regular top down ( not isometric ) perspective and our image map is composed of tiles 32x32 pixels in size.  Your game map is then made up of a grid that says “at this location, draw this tile”.

 

First, the topic of the image itself.  That one, in the spirit of open source, I am ripping off someone else’s work! Smile  You may remember a while back Mozilla released a completely free HTML5 based MMO, BrowserQuest.  Well, we are going to make use of one of the tilesheets from that project.  This is the file right here (it is big).  This is massive overkill, but I like massive overkill.  Here is a shrunk down version of the image we are going to be working with:

image

 

The image is composed of 20 columns of 32x32 images and 98 rows of them, for a grand total of 1,960 tile images or cells, in a single image.  So, that covers our image, let’s take a look at the code:

screenWidth = MOAIEnvironment.screenWidth
screenHeight = MOAIEnvironment.screenHeight
if screenWidth == nil then screenWidth =1280 end
if screenHeight == nil then screenHeight = 800 end

MOAISim.openWindow("Window",screenWidth,screenHeight)

local viewport = MOAIViewport.new()
viewport:setSize(screenWidth,screenHeight)
viewport:setScale(480,320)

local layer = MOAILayer2D.new()
layer:setViewport(viewport)
MOAIRenderMgr.pushRenderPass(layer)

local map = MOAIGrid.new()
map:initRectGrid(15,10,32,32)
map:setRow(10,0x0b,0x0c,0x0d,0x0b,0x0c,0x0b,0xc7,0xc7,0xc7,0xc7,0x0d,0x0b,0x0c,0x0d,0xc7)
map:setRow(9,0x2e,0x2f,0x30,0x31,0x32,0x0b,0x0c,0x0d,0xc7,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(8,0x41,0x42,0x43,0x44,0x45,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(7,0x55,0x56,0x57,0x58,0x59,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(6,0x69,0x6a,0x6b,0x6c,0x6d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(5,0x7d,0x7e,0x7f,0x80,0x81,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(4,0x91,0x92,0x93,0x94,0x95,0x0b,0x0c,0x0d,0xc7,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(3,0xa5,0xa6,0xa7,0xa8,0xa9,0x0b,0x0c,0xc7,0xc7,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(2,0xb9,0xba,0xbb,0xbc,0xbd,0xc7,0xc7,0xc7,0xc7,0xc7,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(1,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2)


local mapTiles = MOAITileDeck2D.new()
mapTiles:setTexture("tilesheet.png")
mapTiles:setSize(20,98)

local prop = MOAIProp2D.new()
prop:setDeck(mapTiles)
prop:setGrid(map)
prop:setLoc(-480/2,-320/2)
-- functionally the same as above
-- prop:setPiv(480/2,320/2)

layer:insertProp(prop)

And if we run this code, we see:

 

image

 

Ok, that’s a pretty cool amount of stuff on screen, for not so much code!  Let’s take a look at exactly what we did here.  Once again from the top ( one of these examples I am going to do from the bottom! ).  Once again, we are only going to look at the new bits, so if I fail to cover something, check out the prior tutorials, chances are I covered it then.

 

local viewport = MOAIViewport.new()
viewport:setSize(screenWidth,screenHeight)
viewport:setScale(480,320)

We’ve seen this many times before, but always in the past I’ve set setSize and setScale to the same value, this time I didn’t… why?  Well the biggest reason is, I defined the grid of map values by hand, which was a gigantic pain in the butt for a screen made up of a 15x10 array of tiles ( 480/32==15, 320/32==10 ), let alone a 1280x800 screen!  By setting the viewport to the actual resolution of your device, but setting the scale to your target resolution ( in this case, the iPhone 3g’s native resolution ), MOAI automatically handles the scaling for you.  This is a nice easy way to support a number of different screen resolutions without having to code each one by hand.

 

Speaking of the map values:

local map = MOAIGrid.new()
map:initRectGrid(15,10,32,32)
map:setRow(10,0x0b,0x0c,0x0d,0x0b,0x0c,0x0b,0xc7,0xc7,0xc7,0xc7,0x0d,0x0b,0x0c,0x0d,0xc7)
map:setRow(9,0x2e,0x2f,0x30,0x31,0x32,0x0b,0x0c,0x0d,0xc7,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(8,0x41,0x42,0x43,0x44,0x45,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(7,0x55,0x56,0x57,0x58,0x59,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(6,0x69,0x6a,0x6b,0x6c,0x6d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(5,0x7d,0x7e,0x7f,0x80,0x81,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(4,0x91,0x92,0x93,0x94,0x95,0x0b,0x0c,0x0d,0xc7,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(3,0xa5,0xa6,0xa7,0xa8,0xa9,0x0b,0x0c,0xc7,0xc7,0x0c,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(2,0xb9,0xba,0xbb,0xbc,0xbd,0xc7,0xc7,0xc7,0xc7,0xc7,0x0d,0x0b,0x0c,0x0d,0x0b)
map:setRow(1,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2,0xc2)

In the immortal words of Douglas Adams DON’T PANIC!  This looks a lot scarier than it actually is.  We are creating our map, which is a variable of type MOAIGrid.  Think of a grid as a 2d array of sorts that holds references to the tiles at each location.  Really that’s about what it does.  So we start of by initializing with a call to initRectGrid() passing in the number of tiles ( 15x10 ) and the width and height of each tile ( 32,32 ).  The next 10 lines are simply populating the grid with calls to setRow(), the first value is the row index, then what follows is a list of 32bit indexes in hexidecimal.  This is where the scary comes in.

 

Basically the top left tile in our image map is at 1 ( 0x01 ) and there are 20 tiles per row in the image we used, so the first image in the second row is therefore at 21 ( row count * row width + offset == 1 * 20 + 1 == 21 ), which is then translated in to hex, which is 0x15. 

 

So, basically we “draw” our map using image locations ( as a 1d index using the formula above, converted to hex ).  The MOAIGrid itself, row 1 is the bottom most row, which is why our grid counts down from 10.  Now let’s take a look at how we created our source image:

 

local mapTiles = MOAITileDeck2D.new()
mapTiles:setTexture("tilesheet.png")
mapTiles:setSize(20,98)

Pretty simple over all.  We create a MOAITileDeck2D.  Remember, a Deck is parlance for an image source, and in this case our source is a single image composed of dozens of tiles.  We set the actual image with a call to setTexture() and pass in our filename tilesheet.png.  We then set it’s size, letting it know it is made up of 20 columns and 98 rows of tiles.

 

local prop = MOAIProp2D.new()
prop:setDeck(mapTiles)
prop:setGrid(map)
prop:setLoc(-480/2,-320/2)
-- functionally the same as above
-- prop:setPiv(480/2,320/2)

Neither MOAITileDeck2D or MOAIGrid are display items, for the we need to create a MOAIProp2D.  We set it’s deck ( or source ) to our newly created MOAITileDeck2D mapTiles and it’s grid to our MOAIGrid map.  Finally we set it’s position with a call to setLoc.  This is an area of some possible confusion ( and why I showed the commented setPiv() as well ), because by default our prop will be at (0,0), which is the dead center of the screen.  However, the pivot point of our prop in the case is actually the bottom left corner of our map.  Therefore, we either need to move the pivot point to the center ( what the commented out code does ), or we position the prop offset from the center of the screen by half the width and height of the viewport.

 

You can actually accomplish a heck of a lot with just a bit of code.  Obviously in your case, you want want to use a tool to generate the MOAIGrid indices, doing it by hand is a PITA ( trust me! ).  Really though, the visual rendering of a top down RPG game just boiled down to a dozen or so lines of code!  Perhaps most impressively, this just scratched the surface of what MOAIGrid can do.

 

Coming Soon

General, Programming , ,

2. October 2012

In this prior post I covered the process of configuring JetBrains' IntelliJ to work with Moai.  As part of the process, I configured a pair of External Tool menu items to launch your code in Moai.  This setup works well enough, but I am a keyboard guy and mousing up to the Tools->Moai->Run Moai… well, it's a pain in the ass.

 

So today I finally did something about it and configured a hotkey.  The process is relatively easy.

 

Open the IntelliJ Settings screen from the file menu, or Preferences if running on Mac.

On the left hand side, scroll down and locate Keymap.  Expand External tools, Moai ( or whatever you named it ), then double click the tool you want to hotkey.

External tools keymap

 

Select Add Keyboard Shortcut:

Now select First Stroke and hit the hotkey combo you want.  Warning, it will pass through system commands, so APPLE+SHIFT+W or ALT+F4 will try to close the window for example.  Keep trying unit you find a combo that isn't conflicting.  The below combo is APPLE+Control+R.

Setting the hotkey

 

Click OK, then Apply, then OK again, and your hotkey will be set.

 

Now in IntelliJ hit CTRL+Win/APPLE key + R and your Moai app should run.

General

Month List

Popular Comments

Toonz Now Open Source as OpenToonz
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


26. March 2016

 

Toonz is a 2D animation package which has now been open sourced under the New BSD license as OpenToonz.  Toonz has a long history in 2D animation for inking, painting andimage digital composition and has been used extensively by Studio Ghibli on such projects as Princess Mononoke and others.  Toonz dates back to the early 90s in SGI machines.

 

From the OpenToonz site:

  • This is software for producing a 2D animation.

    It is based on the software "Toonz", which was developed by Digital Video S.p.A. in Italy, customized by Studio Ghibli, and has been used for creating its works for many years. Dwango launches this OpenToonz project, in cooperation with Digital Video and Studio Ghibli.

  • This software can be used by anyone free of charge, no matter whether the purpose of use is commercial or not.
  • This is available as an open source, so that users can modify its source code freely.
  • We aim to develop a new platform for connecting the academic research into frontline animation production.

Studio Ghibli also contributed GTS, a scanning tool as part of OpenToonz:

  • Sequence number scanning can be conducted efficiently according to in-between animation numbers.
  • Compatible with 4 types of scanning.
    (black-and-white, colored, with or without binarization)
  • The settings for scanning can be saved. Processes can be reproduced when some cuts are rescanned.
  • Compatible with the TWAIN standards

The source code for OpenToonz is available on Github.  You can download binaries and documentation for OpenToonz here.

GameDev News ,

blog comments powered by Disqus

Month List

Popular Comments