Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

2. December 2014

 

Starting life as niche technology, costing millions of dollars and used only on high end films, 3D graphics have now become nearly ubiquitous these days.  Still used in movies ( nearly all movies these days ), 3D graphics are used heavily in games, TV, marketing, conceptualization, engineering and much much more.

 

In this particular guide we are going to look at the more popular options out there, with an obvious bias towards gaming.  If you are just starting out and trying to get an idea of what’s available, this should be the perfect page for you!

 

This entire discussion ( and much more I think ) is available as a 56 minute talk in 1080p on YouTube as well as embedded at the bottom of this post.

 

A Quick History Lesson

 

Actually, the big two would probably be more accurate, as Autodesk recently put a bullet in one of these apps.  These are probably the three most used commercial 3D graphics applications, and to really understand them probably requires a bit of a history lesson.  Don’t worry, I’ll keep it brief.

 

Way back in the stone age of computer graphics, there were a handful of really successful 3D applications, but at the forefront were a pair of applications.  One was a product called Power Animator created by a company called Alias ( who became Alias/Wavefront ) which eventually morphed into a project called Maya.  Power Animator was used in such early and high profile 3D movies like Terminator 2 and The Abyss and on early 3D video games like Super Mario 64.  The other major player of the day was a product called Softimage ( the one that just took a bullet actually… ) which was used to make Jurassic Park and the Virtua Fighter series of games.  By no means were they the only players, many others existed such as Nichimen nWorlds, Lightwave and more, but these two were the big players used in big budget movies.

 

A few things started to happen however…  In these early days, the computers capable of running these 3D applications were dedicated workstations like those from Silicon Graphics Inc (SGI) and Digital (DEC).  These machines ran from $10K to $50K and much much more.  3D graphics applications certainly weren’t and neither were the machines that ran them. 

 

There was a movement towards running 3D applications on “mere mortal” machines.  The earlier mentioned Lightwave ran on Amiga’s for example, as did a popular-at-the-time application called Imagine.  But three major things happened to bring 3D graphics to the unwashed masses

 

  1. home computers became less crappy.  OpenGL arrived, 3D cards arrived, processors got faster and memory increased
  2. Autodesk created a program called 3D Studio that ran on DOS.  It was a very small player in the industry (outside of CAD that is), but opened 3D up to a world of people that never had access.
  3. Microsoft released Windows NT and wanted to move into the 3D market, so they did what they did and bought it.  That is, they bought Softimage and ported it to Windows.  Coupled with companies like Intergraph releasing workstation class PCs and the rise of the video card, they succeed.

 

Fast forward a few years and many amazing things happened.  Kinetics became Autodesk ( of AutoCAD fame ) and 3D Studio became 3D Studio Max, moving from DOS to Windows.  In fact, Windows is now the new home of 3D.  SGI is fast becoming a fading memory and all the major applications have been ported to Windows.  Then a wonderful thing happens… prices all start to fall!  A version of Maya and Softimage are available for under $1,000 and free game focused versions are available of Softimage ( Mod Tool ) and 3D Studio ( GMax ).  3D had truly started coming to the masses.

 

Enter Autodesk.  There was a LOT of consolidation in the industry…  Alias and Wavefront merged to form Alias/Wavefront, Microsoft purchased Softimage and eventually sold it to Avid.  In the end, Autodesk purchased both Avid and Alias resulting in all three major 3D applications being owned by a single company.  Almost over night the price wars predictably enough ended, and the prices went up.  That said, it hasn’t all been bad.  These days, for students and educators anyways, the entire Autodesk suite is available for free.  There is also a game focused version of Maya available, which we will discuss shortly.  So in some ways, 3D has become a great deal more expensive and a great deal cheaper all at once.

 

So, that brings us to today.

 

The Big Three… Er… Two

 

In commercial studios, be it for games, TV or movies, the same three products are the ones most encountered:

3D Studio MAX

Maya

Softimage Xsi

 

As I mentioned earlier, after a very long and successful run, Softimage is being put out to pasture.  Softimage 2015 was the most recent, and final, release ever.  Obviously if you are just starting out today and need to pick a package, Softimage is no longer a good choice.

 

That leaves Maya and Max to choose from.  Traditionally 3D Studio Max was strongest in games, with many game developer friendly features ( excellent plugin system, ability to build your renderer into Max, great low polygon tools, good texturing tools, etc ), while Maya was known more for Film and TV, with animation certainly being it’s strong suit.  That all said, it’s become more and more common to see Max used for film work and Maya used for game work, so the old stereotypes don’t really hold.

 

Actually, being under the same rough has leads to a convergence of sorts.  Over time the feature list of the two products is quickly becoming virtually identical.  As have the keyboard shortcuts, even the file formats are standardizing ( FBX, read more about it here if interested ).  With each new release, each product is starting to feel more alike than different.

 

Of the two, I personally prefer Maya, although the mouse heavy UI drives me nuts.  3D Studio MAX is just getting so long in the tooth that it’s massively in need for a major overhaul.  I first used Max when it was initially released and frankly the Max of today is very very very similar.  Same UI, even a lot of the same tools, tools that have long since been obsoleted.  This is just cluttering things up and making the learning curve higher.  Maya was the result of a complete re-write on the other hand, so the code base is much newer with less years of cruft.  The menus though, those mouse heavy radial menus…  ugh.  Of course, this is all personal opinion.

 

At the end of the day, Max and Maya are your two safe choices if you want a job in the industry.  Max probably has an edge for getting you into a game studio, while Maya probably has an edge getting you into a film studio.  At the end of the day though, they are owned by the same company, speak the same language and are often both used.

 

Neither however is cheap.  3D Studio MAX is $3,675.  Interesting fact, it’s always been that price… even during the 3D application price wars, Autodesk never dropped their price.  The big difference is you can now lease monthly or annually, for $185 / month or $1470 / year.  Maya is now the exact same price as Max ( see how they are becoming more and more similar… ) down from a pricetag of about $5K last year.  Softimage was around the same price.  I’m not sure if you can even buy it anymore, if you can, Autodesk sure don’t make it easy.

 

Oh yeah, Max is Windows only, while Maya is available on Windows and Mac.  If you are a Mac user, that’s a pretty important tidbit of info, no?

 

Maya for Indie Developers

 

Last year, Autodesk took a step towards courting the indie game developer market with the release of Maya LT.  This is a stripped down version of Maya that targets indie game developers specifically.  It is priced at $30 a month, or $795 to purchase a perpetual license (with, I believe, one year of support).

 

So, the obvious question is, what’s stripped out?  Initially the limitations really sucked…  polygon caps, no scripting support, it was pretty much crippled.  Over time though they revisited things and made up for some of the glaring mistakes.  The big areas that are cut are Visual FX stuff and most of the renderers.  This means, if for example, you wanted to create a pre-rendered cutscene, you couldn’t.  The animation features have also been stripped back, leaving mostly the stuff you would use for real-time games.

 

At the end of the day Maya is really only suitable for modeling and rigging game assets or possibly level creation/design.  That said, for a great many game developers, that’s all you actually use it for.  For a full breakdown of Maya vs Maya LT features, you can check here.

 

 

The 900lb Open Source Gorilla in the Room

 

If you are sitting here thinking 4 grand?!?!?!??! OUCH!

 

Well, meet Blender.

 

Blender started life as an in-house 3D tool for a company called NeoGeo… yeah, not the NeoGeo game console, but instead it was the Netherlands largest 3D house… or is that haus?  Eventually a company named NaN was formed to “productize” Blender.  NaN died in 2002 and a project was launched to open source the Blender code… in many ways this was one of the first highly successful KickStarter campaigns!  Blender was eventually open sources, the community took it and ran with it and Blender is thriving today.

 

Blender is entirely free and open source.  It’s nowhere near as commonly used commercially as Max or Maya, but it is certainly used, such as for pre-viz work on Spiderman 2.  I would lie though…  the vast majority of commercial games *aren’t* created using Blender.  If you are looking for something to stick on your resume, Max and Maya certainly carry more weight.

 

HOWEVER, and this is where we drop heavily into opinion land for a bit…

 

If you are working on a 3D game and need to create textured, animated, 3D models, Blender is just as capable as 3D Studio Max or Maya, even without factoring in the price tag.  For many years, Blender had a reputation for being chosen solely because it’s free.  Those days are starting to pass however.   Put into the simplest terms, for the last several years I would say with each new release, Blender is the application that is improving by far the most of the three.  Now, you will find all three apps are quite capable, with Maya/Max and Blender all being strong and weak in different categories.

 

Blender used to ( ok… still does ) have a reputation for being hard to use with an unwieldy interface and in many ways, this was quite fair.  Blender followed it’s own idioms and was a VERY keyboard heavy workflow which takes some time to get.  Also, rather bluntly, Blender 2.4’s interface was pretty much terrible.  Blender 2.5 however was a massive rewrite and rework and it really bore fruit.  Then the 2.6 releases improved the rough edges, while 2.7 has a heavy focus on usability, and it’s make a huge difference.  If you haven’t checked out Blender since the 2.4 days you really owe it to yourself to try it again.

 

The single biggest flaw with Blender IMHO, at least as far as game development is concerned, is the file support.  Autodesk owns the FBX format and the COLLADA file format is a bloody mess of complication to the point that nobody really does it all that well.  This means getting assets into and out of Blender can certainly be more of a challenge than using Autodesk products.  This is an area Blender have recently focused their efforts on and the Unreal Engine folks have kicked in some cash toward the effort so hopefully this improves.

 

So, my summary on Blender… it’s honestly an equal to the two Autodesk products, with as I said, it’s strengths and weaknesses.  I also personally think it’s improving at a much greater rate than either of those products.  Of course, it’s also a hell of a lot cheaper.  That said, once you start paying actual salaries, the cost of software licenses quickly become peanuts.  Can you use Blender for your own game project?  Certainly.  Should you?  That depends on you really, but you should certainly try it out.  The functionality is certainly there, with the biggest flaw easily being the content pipeline.  However, if you are a student looking for a job, Max and Maya will certainly look better on a resume.  A great artist will be able to make great art in any three of those tools, and a good studio will hire an artist will a great reel, regardless to the tool it was created in.  That said, at the end of the day, human resources will be looking for Max or Maya on your CV… they will not be looking for Blender.  Which is actually kind of sad.

 

My much shorter summary…  Blender is free and very good, you should certainly give it a look.  Oh, being Open Source… it’s available on basic everything… possibly even your Toaster… although oddly enough, not been ported to iPad.  Seriously, someone really should port Blender to the iPad!

 

 

Sculpting… the new hotness

 

Another major development in the world of 3D is 3D sculpting.  Sculpting is like working in digital clay for quickly creating hyper detailed, very organic meshes.  In in the world of real-time games, this is still quite useful, as high resolution versions of game models are often used to create something called a normal map.  This allows you to use texture maps to fake super high levels of detail.  Another common operation is to sculpt hyper high resolution models, then basically “trace” a lower detailed version over top.  This is a process called retopology.  Now the good news… all three of the above solutions have sculpting built and retopology tools built in.  That said, compared to the tools we are about to discuss, they simply sucks at it.  So it’s becoming increasingly common to see these kinds of applications pop up in studios.  That said, these are more like initial tools in your toolbox, and certainly not where you should start!

 

zBrush

Pixologic’s zBrush is where the whole sculpting movement started and it’s by far the biggest player in the space.  It’s also $800 by the way.  It’s not an end to end solution, it’s designed to do what it does, then passes the results off to a different program ( Max… Maya… Blender… ) for animation, rendering, etc.  For sculpting though, it’s hard to beat zBrush.  You should at least be aware of it’s existence.

 

Sculptris

$800 a little rich for you?  How does free sound?  Sculptris is an interesting project… it actually started life as a fan’s attempt to replicate zBrush.  Said Fan did a pretty damned good job of it, to the point the Pixologic bought the rights and make it available for free.  So go, download it now… even if you don’t ever do anything with it, it’s an amazing amount of fun.

 

Mudbox

Of course you couldn’t be a 3D application without having an Autodesk product, could you?  Mudbox is Autodesk’s offering in the 3D sculpting space.  It started life as a tool used by Weta on King Kong and Lord of the Rings.  Eventually Autodesk bought them and now it’s available for $500 or $10 a month.  In all honesty, that’s the end of my knowledge, I’ve never used Mudbox, nor have I ever talked to an artist that chose it over zBrush.  There is however a trial available, so I really should check it out one of these days…

 

3D Coat

3D Coat is another interesting product out there that focuses on 3D tasks…  Sculpting, 3D Painting and Retopology.  3D Coat is about $400 at full retail.  It is however available on Steam so keep an eye out for amazing discounts.  Be warned, you need the commercial version if you are using 3D Coat for a commercial product.  3D Coat does have a trial available.

 

 

Hey What About _________!

 

 

In all honesty, we just ticked off the major boxes… but of course that was by no means comprehensive.  There are a few other packages you should certainly be aware of, so let’s discuss them now.  These aren’t rated lower for functionality, but simply for popularity.

 

Modo

Modo started life somewhat recently ( by 3D application standards ) as a dedicated 3D modeler.  The company itself was formed by a number of former Lightwave developers and this application has a huge following.  Over time it’s evolved to become much more than a modeler, although it’s still not quite a full 3D suite like Max, Maya or Blender, it’s getting very close.  As the functionality has grown, so to has the price tag.  Currently its 1000Euro.  Animation is a somewhat recent addition to Modo, so the functionality is a bit limited compared to more mature packages.  That all said, Modo has grown in functionality at an amazing rate and is getting quite popular.  There is also a trial available.

 

Lightwave

As I just stated, Modo was formed by a bunch of ex-Lightwave developers.  Lightwave is a once great package that has seemingly lost it’s way and as a result, a great deal of it’s user base.  Lightwave still exists today, there was a new release in 2014, but it seems to be developing at a snails pace and the community around it seems to have mostly disappeared.  Lightwave has been used in a staggering number of TV and Film projects, as you can see here, but the number of recent projects seems to have dried up.  Lightwave costs $1000USD and there is a free trial available.

 

Sketchup

This application is actually used a surprising amount.  It was purchased by Google and used to create 3D models for Google Earth.  Eventually however Google sold it off and it’s a stand alone product again.  Sketchup is available in both a free and commercial version.  At the end of the day, for commercial game dev you will probably need the pro version, which has a $600 price tag.  Sketchup is a 3D modeller only, but damn is it an easy to use one!  For an introduction to 3D modeling, the free version may be the perfect place to start.  You can read more about Sketchup’s use in game design here.

 

Silo

This program is most similar to Modo in functionality and I was a huge fan when it came out.  It’s mostly a modeler that’s gained more features over time, it has a nice low price tag of $109, is cross platform and great to use.  So why the negativity?  Well, the developers basically abandoned it for many years, only recently started working on it again.  I have no idea how much support there is behind this application.  It’s such a shame too, as this product could have been truly great.  There is a trial available and it’s worth checking out, but I wouldn’t rely on too many new features or bugs being fixed going forward.

 

Wings

Wings is an awesome 3D modeler, based heavily on Nichimen Nendo, an awesome 3D modeler that came before it.  It is free and open source and uses a completely different technology called Winged Edge meshes.  Unfortunately it’s also written in a programming language about 4 people on earth use, so when the primary developer stopped supporting it, it effectively died.  It’s still available, and still very cool, but in the last few years it’s stayed still while the world around it got a whole lot better.

 

Cinema4D

This package has quietly existed for years, gaining more and more features and a rabidly loyal user base.  To be honest, I’ve never really got it, especially with a $3,700 price tag.  That said, there must be advantages, as it wouldn’t still exist otherwise.  There is a trial available if you want to check it out for yourself.

 

Houdini

This one has also been around for a very long time and was traditionally used quite heavily for 3D effects in movies.  In all honesty, this is the single most confusing piece of software I have ever tried to use! ;)  It takes a procedural approach to 3D and frankly, I don’t really understand how it works, so I’m not even going to try to explain it.  There is a trial available and Houdini is available for $2000.  They do however have an Indie friendly version available for $200, that is tied to company revenue.  Remember that somewhat famous Dead Island trailer that took the web by storm?  That was created in Houdini.  Again though, this program is very very very weird. 

 

Animation Master

Here is another application that’s quietly been around forever, 1987.  It’s a low cost modeling and animation tool that is based around splines and patches ( most modern modelers are polygonal / subD surfaces ).  Organic models are easy to create, the animation tools are surprisingly comprehensive and the price tag starts at $80.  It’s an interesting package and there is a trial available, but it’s a bit of a pain to get it running. 

 

Shade3D

To be honest, I know almost nothing about this application, even though it’s been around forever.  It’s a full suite 3D package like Max or Maya and they recently released a Unity version.  I tried Shade shortly after that release ( a trial is available ), and the documentation was extremely lacking at the time, so I got pretty much nowhere.

 

Hexagon

A free 3D modeling package made available by Daz.  Reviewed it quite a while back, not a fan.  An advance warning, Daz will spam the ever loving hell out of you if you give them an email address!

 

 

TL;DR

 

So, you got to this point and now you are probably asking… now what?  That’s a lot of options, what should I do???

 

The answer really depends on you and what your goals are.  If you are a student (secondary or post-secondary) and looking to get into AAA 3D for games or film, the answer is pretty much a no-brainer.  Get in the free student program from Autodesk and start learning either Max or Maya.  If it’s games you are most interested in, Max is probably the route to go between the two.

 

If you aren’t a student, or aren’t trying to work on your CV, the answer gets much trickier.  The choice between Maya, Max and Blender on strictly technical merits comes down mostly to the persons opinion and work-style.  If you are working with a large team, or on a free product, Blender quickly becomes a no brainer solution as well.  If you’ve got no budget at all, Blender simply wins by default.  Otherwise I would recommend taking advantage of the free trial, trying out all three and seeing which one has a workflow that fits you.  Just be warned, it’s going to take some time to come to terms with each package.

 

For all others, I saw this.  At least download Blender and Sculptris.  Both are completely free, both are very good and both are excellent places to start.  The skills you learn transfer very well to other packages.

 

The Video Version

 

Art ,

23. November 2014

 

Today I was contacted by a developer from the jMonkeyEngine team who was interested in spreading the word about the OPENGEX format among indie developers, and I agree completely with the goal.

 

Before I even get in to OpenGEX, it’s helpful to first look at the alternatives available for 3D import/export.  Moving 3D assets between software packages and into game engines has long been a challenge and there have been a number of popular formats as a result.  Let’s take a quick look at the more popular choices.

 

COLLADA

 

Site Link

 

COLLADA is probably the monster in the segment now, standing for COLLAborative Design Activity, ranking up there amongst the most contrived acronyms I’ve ever encountered.  COLLADA started life at Sony and was later submitted to Khronos, the party responsible for OpenGL, for standardization.  Several major players in the industry signed on to support COLLADA, pretty much everybody actually, but most importantly, all the big boys signed on,  including Alias ( Maya ), Avid ( Softimage, at the time anyway… ) and Autodesk ( 3D Studio Max ).

COLLADA was designed primarily as an interchange format between tools, allowing you to for example use Max and Softimage in your art pipeline rather seamlessly.  For the most part it worked too, the industry came together and interchange was probably better than it’s ever been.

Obviously there is a but, or I wouldn’t be writing this, I would just say “hey, we should all use COLLADA!” and be done with it.  So, time for the but… and what a big but it is. ( sorry… )  First off, COLLADA is a huge, some could say bloated format, that is ill suited for games.  Again, it was designed for communication between authoring tools, ease of use and performance certainly weren’t priorities.  Being controlled by the Khronos board certainly couldn’t help either, and it didn’t.  The format became convoluted over time.

The next major problem is a change in the industry… you see, Autodesk bought everything.  So suddenly most of the software this open standard was designed to work with are owned by a single company.  Now with each new version released, things are broken, often needlessly.  For a large company like Unreal or Unity, supporting a complicated and constantly moving target isn’t a big deal, they can frankly just throw money at it.  For smaller, indie or open source game engines, this isn’t a solution.

 

FBX

 

Site Link

 

The FBX format started life in a product called Filmbox, made by a company known as Kaydara.  Filmbox started life as a motion capture suite and obviously needed to support various software packages, so they created the FBX file format.  In the early days, well before the rise of COLLADA, it was supported by pretty much all of the common 3D packages of the day ( 3D Studio Max, Lightwave, Softimage, Power Animator ( Maya’s precursor ), Cinema3D, etc ).  Well, Filmbox was eventually renamed MotionBuilder, a product that exists to this day and it was acquired by Alias, the makers of Maya and PowerAnimator before it.  Remember how in the COLLADA write up I said Autodesk bought everything?  Well, that wasn’t really an exaggeration… in 2006, Autodesk purchased Alias and with it gained control of MotionBuilder and the FBX file format.

So, fast forward to today and Autodesk controls Softimage, 3D Studio Max, Motion Builder, Softimage and more.  FBX is the format they use internally to communicate between their own tools.  So at the end of the day, if you are working entirely in the Autodesk ecosystem it’s the easiest and safest route to go.

For game developers though, it’s a bit of a different story.  Once again, the large guys can easily support FBX, just like COLLADA.  Perhaps most importantly, Autodesk make available an SDK for working with FBX.  Some game engines make use of this SDK such as LibGDX’s fbx-conv tool.  There are limitations on this license however on of the biggest is that it is incompatible with GPL, meaning Blender and similar tools can’t use the SDK.  ( although I would put this on the awfulness of GPL instead of Autodesk’s license, but that’s splitting hairs ).  This means Blender uses a “clean room” implementation of FBX and this means that the FBX support in Blender is, well, pretty crappy.

 

FBX however is not a game friendly format either, once again, it’s designed for communication between game tools, not for fast and efficient storage.  So even in the case of tools like LibGDX that support it, they ultimately just use it as a source and convert it to their own internal format.  This means each time you change your asset in your modeling tool, you have to convert it again and again.

 

OBJ, 3DS, MD2, DXF, etc

 

 

This is a catch all category, but it’s worth noting the above.  Open Source game engines commonly support some of the older simpler formats, one of the most common being OBJ.  These were the file export formats from popular 3D applications from years ago ( OBJ = Alias, 3DS = 3D Studio, DXF = AutoCAD, MD2 = Quake Engine ).  The reason they are supported is the formats tend to be fairly simple with a large body of code already available.

 

On the other hand, they are also ancient and incredibly limited, especially when it comes to animation data.  If you have simple requirements, a simple format should do the trick and frankly you will often see OBJ format supported when animation data isn’t needed ( such as by Mixamo Fuse or Poser, for model data ), but once you start adding complexity, these formats start to show their age.

 

I am mostly mentioning them for completeness only.

 

 

So, a TL;DR summary of the negatives of each format:

 

COLLADA

  • bloated and complicated format
  • run by Khronos group ( this is a good and bad thing )
  • fragile between versions, breaks easily
  • not game engine friendly

 

FBX

  • proprietary file format
  • controlled by Autodesk
  • not open source friendly license
  • not game engine friendly

 

The Others

  • ancient
  • poor animation support
  • limited functionality

Enter OpenGEX

 

Site Link

 

This brings us at last to OpenGEX ( Open Game Exchange ), an open 3D file format targeted specifically at game developers for use in game engines.  It was created by Eric Lengyel originally for the C4 Game Engine and was funded by a successful IndieGoGo campaign.  Essentially you can think of OpenGEX as a stripped down, game engine focused version of COLLADA.  Instead of being XML based, it uses OpenDDL (Link).

(Edit to fix JSON error)

The easiest way to understand the value of OpenGEX is to compare the format to COLLADA.  Fortunately the OpenGEX site provides just such an example.  Looking at the OpenGEX format, it’s quite clean, very reminiscent of OBJ, but with support for modern features.  The purpose behind OpenGEX’s creation is nicely captured in this comment:

 

The OpenGEX format was created because Collada, the open standard that we all hoped would provide a well-supported asset exchange format, has proven to be an unreliable mess. The most common source of problems has been the poor quality of the Collada export plugins available for software such as 3D Studio Max and Maya, and we attribute this to Collada’s over-engineered design and its mutating under-specified format.

 

Now of course, a format is of little use if no tools support it, and this is where OpenGEX shines.  There are already exporters for Max, Maya and Blender.  Additionally there is an Import template available for implementing OpenGEX in your game or engine.  It’s basically a Visual Studio 2013 project with the code used by the C4 Engine to load OpenGEX files.

 

If you are interested in learning more, you can read the PDF spec here.

 

So…. what?

 

So what’s the value in all of this to you as an indie game developer?

 

Well, if you are working with Unity or Unreal Engine, very little actually.  They have the resources to support the COLLADA, with all of it’s quirks, breaks and other warts.  If however you are working with a open source or smaller game engine, moving to a much more sane format can make everyones life easier.

 

As is the nature of any format, the more it’s used, generally the better it becomes ( unless of course committee bloat sets in ).  Basically, the less time smaller developers have to spend on content pipeline tools, the more time they have to work on improving their engine.  Additionally, the less headaches the game developer suffers getting assets in their game, again, the more time they have to work on the game.

 

There has been some recent movement in regards to supporting OpenGEX.

 

First off, the developer who contacted me from the jMonkeyEngine has recently made a Java library on Github available for handling OpenGEX files.  This could potentially enable other popular Java based game engines *cough*LibGDX*cough* to support OpenGEX.

 

It was recently announced too that Ogre3D is working to support the OpenGEX format as well.  Again, the developers words perfectly capture why this is important:

Partly to address that I'm planning on adding support for the OpenGEX format.
Because of two reasons:

  1. The format is actually really good, easy; and contains everything we need. It's basically our XML mesh and skeleton format, but in JSON.
  2. Joint effort. There are already plugins. Open Source plugins. Which are being used for the C4 engine. If Ogre adopts the same format, we can share the burden of maintaining 3D asset exporters. Those are hard to maintain given Autodesk always releases a new version every year with partically no difference but breaking many plugins on the way. It should also empower more adoption of the OpenGEX format, and hopefully get others in. Unlike Collada, OpenGEX is good.

 

That second reason sums it up perfectly.  If a number of indie game engines all adopt the same format, the burden of maintenance is spread across a number of developers instead of each developing their own proprietary format and all the support that entails.  It also makes creating game tools that work across game engines a much easier task.  Finally, it helps break Autodesk’s chokehold on the industry!

 

So mostly it’s a matter of trying to spread the word and gain support.  One critical component would certainly be getting support into the Assimp ( Open Asset Import Library ), an open source model importing library that is the underpinning for many game engines importers today.  There is already an open feature request, so if you feel an open game friendly COLLADA option would be useful, that would certainly be a good place to start.

General, Programming ,

22. November 2014

logo

 

The Urho3D C++ cross platform game engine just released version 1.32.  The following is the change log from this release:

 

 

  • Finalized Urho2D functionality, including 2D physics using Box2D, sprite animation and tile maps
  • Threaded background resource loading. Must be manually triggered via ResourceCache or by loading a scene asynchronously
  • Attribute and material shader parameter animation system
  • Customizable onscreen joystick for mobile platforms. Used in examples
  • Touch camera control in examples on mobile platforms
  • Touch emulation by mouse
  • Multi-touch UI drag support
  • Consistent touch ID’s across platforms
  • Absolute, relative and wrap modes for the operating system mouse cursor
  • Support for connecting & removing joysticks during runtime
  • Negative light & light brightness multiplier support
  • Transform spaces for Node’s translate, rotate & lookat functions
  • Scrollable console
  • Selectable console command interpreter (AngelScript, Lua, FileSystem)
  • Touch scroll in ScrollView & ListView
  • UI layout flex scale mode
  • Custom sound streams from C++
  • LogicComponent C++ base class with virtual update functions similar to ScriptObject
  • Signed distance field font support
  • JSON data support
  • Matrix types in Variant & XML data
  • Intermediate rendertarget refactoring: use viewport size to allow consistent UV addressing
  • ParticleEmitter refactoring: use ParticleEffect resource for consistency with ParticleEmitter2D and more optimal net replication
  • Expose LZ4 compression functions
  • Support various cube map layouts contained in a single image file
  • Configurable Bullet physics stepping behavior. Can use elapsed time limiting, or a variable timestep to use less CPU
  • Default construct math objects to zero / identity
  • Mandatory registration for remote events. Check allowed event only when receiving
  • Teapot & torus builtin objects
  • FXAA 3.11 shader
  • Triangle rendering in DebugRenderer (more efficient than 3 lines)
  • Material/texture quality and anisotropy as command line options and engine startup parameters
  • Spline math class, which the SplinePath component uses
  • Console auto-show on error
  • DrawableProxy2D system for optimizing 2D sprite drawing
  • Possibility to decouple BorderImage border UV’s from element size
  • Editor & NinjaSnowWar resources split into subdirectories
  • UI hover start & end events
  • UI drag cancel by pressing ESC
  • Allowed screen orientations can be controlled. Effective only on iOS
  • Rendering sceneless renderpaths
  • Define individual material passes as SM3-only
  • Support for copying ListView text to system clipboard
  • Async system command execution
  • Generic attribute access for Lua script objects
  • Use Lua functions directly as event subscribers
  • Touch gesture recording and load/save
  • AssetImporter option to allow multiple import of identical meshes
  • Automatically create a physics world component to scene when necessary
  • GetSubimage function in the Image class
  • Possibility to clone existing components from another scene node
  • Improve terrain rendering on mobile devices
  • Refactoring of camera facing modes in BillboardSet & Text3D
  • Additive alpha techniques for particle rendering
  • Possibility to use CustomGeometry component for physics triangle mesh collision
  • Access to 2D node coordinates for convenience when using 2D graphics features
  • Save embedded textures in AssetImporter
  • Use best matching fullscreen resolution if no exact match
  • Use SDL_iPhoneSetAnimationCallback instead of blocking main loop
  • Allow fast partial terrain updates by modifying the heightmap image
  • API for setting image pixels by integer colors
  • Refactor to remove the separate ShortStringHash class
  • Deep clone functionality in Model resource
  • Zone can define a texture which is available to shaders. Not used by default
  • Allow logging from outside the main thread
  • Log warnings for improper attempts to use events from outside main thread
  • Improved CustomGeometry dynamic updates
  • ConvexCast function in PhysicsWorld
  • Screen to world space conversion functions in Viewport class
  • Allow sending client rotation to server in addition to position
  • Allow accessing and modifying the engine’s next timestep
  • DeepEnabled mechanism for disabling node or UI element hierarchies and then restoring their own enabled state
  • Allow to prevent closing a modal window with ESC
  • Per-viewport control of whether debug geometry should render
  • Optional interception of resource requests
  • Readded optional slow & robust mode to AreaAllocator
  • Optionally disable RigidBody mass update to allow fast adding of several CollisionShape components to the same node
  • Runtime synchronization of resource packages from server to client
  • Disable multisample antialiasing momentarily during rendering. Used by default for UI & quad rendering
  • Glyph offset support in Font class
  • Font class internal refactoring
  • Allow to create AngelScript script objects by specifying the interface it implements
  • Window position startup parameters
  • Functions to get time since epoch & modify file’s last modified time
  • Optionally auto-disable child elements of a scroll view when touch scrolling
  • Allocate views permanently per viewport to allow querying for drawables, lights etc. reliably
  • Allow to specify material techniques/passes that should not be used on mobile devices
  • Reduced default shadow mapping issues on mobile devices
  • Minor rendering optimizations
  • Build system: possibility to build Urho3D without networking or 2D graphics functionality
  • Build system: improved generated scripting documentation
  • Build system: improved support for IDE’s in CMake scripts
  • Build system: support up to Android NDK r10c and 64-bit ABIs
  • Build system: numerous other improvements
  • Editor: resource browser
  • Editor: spawn window for random-generating objects
  • Editor: allow either zoom or move from mouse wheel
  • Editor: locate object by doubleclicking node in hierarchy
  • Editor: take screenshots with F11, camera panning
  • Editor: button in value edit fields that allows editing by mouse drag
  • Updated SDL to 2.0.3.
  • Updated AngelScript to 2.29.1
  • Updated assimp
  • Updated Recast/Detour
  • Fix MinGW build issues
  • Fix techniques referring to wrong shaders
  • Fix Node::LookAt() misbehaving in certain situations
  • Fix resize event not reporting correct window size if window is maximized at start
  • Fix PhysicsWorld::GetRigidBodies() not using collision mask
  • Fix zone misassignment issues
  • Fix Lua not returning correctly typed object for UIElement::GetChild() & UIElement::GetParent()
  • Fix uninitialized variables in 2D physics components
  • Fix quad rendering not updating elapsed time uniform
  • Fix forward rendering normal mapping issues by switching calculations back to world space
  • Fix wrong logging level on Android
  • Fix multiple subscribes to same event on Lua
  • Fix missing Octree update in headless mode
  • Fix crash when using FreeType to access font kerning tables
  • Fix ReadString() endless loop if the string does not end
  • Fix shadow mapping on OS X systems with Intel GPU
  • Fix manually positioned bones being serialized properly
  • Fix file checksum calculation on Android
  • Fix accelerometer input on Android when device is flipped 180 degrees
  • Fix missing or misbehaving Lua bindings
  • Fix crashes in physics collision handling when objects are removed during it
  • Fix shader live reload if previous compile resulted in error
  • Fix named manual textures not recreating their GPU resource after device loss
  • Fix skeleton-only model not importing in AssetImporter
  • Fix terrain raycast returning incorrect position/normal
  • Fix animation keyframe timing in AssetImporter if start time is not 0
  • Fix storing Image resources to memory unnecessarily during cube/3D texture loading
  • Fix to node transform dirtying mechanism and the TransformChanged() script function
  • Fix returned documents directory not being writable on iOS
  • Fix click to emptiness not closing a menu
  • Fix FileWatcher notifying when file was still being saved. By default delay notification 1 second
  • Fix .txml import in the editor
  • Fix erroneous raycast to triangles behind the ray
  • Fix crash when multiple AnimatedModels exist in a node and the master model is destroyed
  • Fix missing Matrix4 * Matrix3x4 operator in script
  • Fix various compile warnings that leak to applications using Urho3D
  • Fix DebugHud update possibly being late one frame
  • Fix various macros not being usable outside Urho3D namespace
  • Fix erroneous layout with wordwrap text elements
  • Fix debug geometry rendering on flipped OpenGL viewports
  • Fix kNet debug mode assert with zero sized messages
  • Fix not being able to stop and restart kNet server
  • Fix AreaAllocator operation
  • Fix possible crash with parented rigidbodies
  • Fix missing network delta update if only user variables in a Node have been modified
  • Fix to only search for June 2010 DirectX SDK, as earlier SDK’s will fail
  • Fix wrong search order of added resource paths
  • Fix global anisotropic filtering on OpenGL
  • Fix animation triggers not working if trigger is at animation end
  • Fix CopyFramebuffer shader name not being used correctly on case-sensitive systems
  • Fix UI elements not receiving input when the window containing them is partially outside the screen to the left
  • Fix occlusion rendering not working with counterclockwise triangles
  • Fix material shader parameter animations going out of sync with other animations when the object using the material is not in view
  • Fix CPU count functions on Android

 

You can download the library here.

 

The project homepage is available here.

Programming , ,

13. November 2014

 

Welcome to the first ever Steam Powered Game Dev review, a look at game development tools available on Steam.  This post looks at FUSE character creator by Mixamo.  In addition to this text review, you can watch the entire thing in video form by clicking right here, or using the embedded player at the bottom.

 

title

Product

Fuse Character Creator

Product Type

3D Graphics Application

Steam Store Page

Website Link

Current MSRP

$99 USD

Steam Discount at Time

75% off

Product Website

Website Link

Available On

Windows, Mac




First let’s start with what Fuse is.   It’s a character creation package, for generating fully textured 3D character models.  If you’ve ever used Smith Micro’s Poser or Daz Studio, you should have a basic idea what to expect.  However, Fuse varies from those packages in some very significant ways.

 

  • It is entirely about character creation, there is absolutely no animation built in.  Don’t worry, this isn’t a big deal as we shall see shortly.
  • It is by far the easiest to use of the three.  Quite literally anyone could use Fuse successfully.
  • It makes for extremely customizable characters, both in regards to model and textures.
  • It has some of the most confusing pricing you will ever see!  ( Actually, Daz is worse! )
  •  

    Character Creation

     

    Let’s jump right in and you can see what I mean.  On it’s surface Fuse is remarkably simple.  You start of by selecting various body parts, like so:

    image

     

    Basically you go through 4 stages.  The first is to build your character model out of body parts.  The above screen shot shows an assembly with a Zombie head selected and torsos being chosen.  Currently for example, there are 34 different torso shapes to be chosen from, ranging from teen cartoon to adult skinny zombie. 

     

    Here is a fully assemble teen female character for example:

    image

     

    You can mix and match body parts however you’d like.  You may be asking at this point… what about creating your own body parts, can you do that?  Yes, you can, I will cover that shortly!

     

    Character Customization

     

    Now that you’ve assembled a basic character by setting the head, arms, torso and legs to use, it’s time to customize.  Simply click the Customize tab and continue, like so:

    image

     

    If you’ve ever played a video game that gave you an incredible amount of control over your character’s creation, you should have some idea of how the process works.  This however goes into a staggering level of detail, with control over pretty much every single facet of your character.  You’ve also always got the Randomize button, which you can simply keep spamming until it spits out something your like.

     

    In addition to using sliders, you can also use the mouse to interactively sculpt the features you want to change, like here with the nose selected:

    image

     

    Clothing your Character

     

    Next it’s time to cloth your character.  One again you simply click the clothing tab.  By the way, you can go back to any of the previous stages at any time if you require.  Clothing works pretty much the same way as character creation:

    image

     

    For each various body part you can choose from a number of different outfits or styles.  If you are wondering, yes, you can give women beards or dress men in thongs if that’s what floats your boat.  There is a decent selection of models available to get started but no doubt you want to know if you can import your own?  Once again, the answer is yes, and once again, we will get to that shortly.

     

    Texturing Your Character

     

    Now that we’ve got a fully dressed 3d modeled character, it’s time to customize the texturing.  This is an area where Fuse absolutely shines!  They have partnered with Allegorithmics to package in their Substance technology for texturing and it’s powerful stuff.  For example, when setting the characters skin texture, here is how it works:

    image

     

    So you can set a basic base skin color, then rapidly modify it using intuitive sliders like “age”, “eye shadow color”, “lipstick” etc.  Plus you have control over the end texture resolution, a critical requirement for games.  You can generate a texture anywhere from 64x64 to 2048x2048.

     

    It’s the sheer volume of controls available for substances that is most impressive, this is just for the skin component:

     

    Video_2014-11-13_145755

     

    You can configure each and every part of your character, using premades like “jean” and sliders like “dirt level” and “age”.  It makes texturing incredibly simple, although there is no option for placing decals or multi texturing right now.  You do however get a fair bit of control over shader performance:

    image

     

    So, essentially that is the process of creating and texturing a full 3D character.

     

    Now it comes to animation, and this is where things get a bit confusing…  but first…

     

    Getting Your Own Content In

     

    As I mentioned earlier, yes, you can import your own body parts and clothing into Fuse, as well as Substances.  However there is a bit of a gotcha, there always is.

    The process is actually quite simple.  You model and UV map in your favorite 3D application, then export in OBJ format, an ancient and simple 3D file format that pretty much every 3D application supports.  However, you do have to follow strict guidelines available here.

     

    Animating Your Character

     

    Although Fuse doesn’t do animation, it’s exactly what the company that make it, Mixamo, does.  Mixamo offers a cloud based animation service and Fuse can hook directly into it.  Basically to get started, you simply click the Animate button when your character is prepared:

    image

     

    Your character will then by automatically uploaded to Mixamo’s servers.  Advanced warning YOU NEED TO HAVE THE UNITY 3D PLAYER ALREADY INSTALLED!

    Otherwise your file will upload then you will get an error.  Pretty stupid that Fuse doesn’t check for it automatically, but c’est la vie.

     

    I’m going to go fairly light on my coverage of Mixamo, as it’s basically a completely different site and service.  You can see a bit more of it in action in the video if you wish.

     

    The basic process goes like this… when you hit Animate in Fuse, your character is uploaded to Mixamo and automatically rigged.  You can then apply different premade animations to your character ( or none at all if you wish ), then download your character.

     

    Here is Mixamo in action creating an animation sequence:

    image

     

    There are hundreds of animations available, some completely free, some for a fee.  We will discuss money in a moment.  Here again you have decent control over your character and you can sequence multiple animations into a single file.

     

    Next you download your file from Mixamo’s server.  Any file your created will be available, so you can re-download to your hearts content.  You simply go to your My Characters” page and select the character to download:

    image

     

    On the download page, you can select in what format you want the file to be downloaded:

    image

     

    You can come back at any time and select a different format, or use different settings.  Now let’s look at the finished project imported into Blender:

    image

     

    The character texture, with bones showing in x-ray mode.  There we have it… a fully rigged, textured character with a walk cycle.  All told it took me about 5 minutes to create this character.

     

    Oh, and you might be wondering, what if I don’t need animation, can I still use Fuse?  Yes, yes you can.  There is an option to export as OBJ format, which again, is available in pretty much every 3D application available.  Of course, the results wont be rigged.  You have a bit of control over the results, but not a ton.  Sadly I couldn’t locate a place to set a polygon budget for example.

    image

     

    I believe it is the simplest way to get a game usable rigged character into a 3D modeling application.  There are other options, Autodesk has their own Character Generator, there’s Make Human and of course Poser and Daz that I mentioned earlier.  Fuse however just hits that sweet spot between ease of use and power that I appreciate so much.  With the exception of the missing Unity Web Player, I encountered no technical issues at all.

     

    There is however the cost…

     

    The Cost

     

    Cost is an interesting subject and can be a bit confusing when dealing with Fuse.  First off, there are two versions of Fuse available on Steam, Fuse Basic and Fuse.

     

    Fuse Basic is a stripped down version, far less body parts, far less character pieces to work with, less textures, etc.  You can however download it completely free, and I encourage you to do so, if only to see if Fuse performs well on your PC.

     

    However, Fuse has one HUGE advantage over Fuse Basic, and something that makes it an incredible bargain.  If you buy Fuse on Steam, you get two free auto rigs a week.  This means that you can have Fuse rig two characters you send to Mixamos server each week.  Now we are about to see the value of Fuse when we look at Mixamo’s pricing.

     

    The are the “bundle plans” on an annual basis:

    image

     

    And here are the “À la carte” prices:

    image

     

    Suddenly those 2 free auto-rigs a week start becoming a hell of a good deal.  The $100 purchase of Fuse on Steam pays for itself after 2 characters are rigged!

     

    What tier you need ultimately comes back to your individual requirements.  Myself, I move at a snails pace, so I highly doubt I will be working on more than two different character riggings per week, plus I am capable of making my own animations if required.  If you are absolutely spitting out characters or use tons of animations however, one of the bundles may be the way to go.  The economics of Fuse Basic though are always bad, especially if you can find Fuse on sale like I did. 

     

    The Video Version

     

     

    Summary

     

    If you need 3D animated characters, Fuse is certainly worth looking at.  With the ability to import any body parts or props into Fuse, you can make pretty much any character you require, assuming you have the ability.  If you have no 3D modeling skill, the breadth of props available in Fuse probably aren’t enough to do everything you need.  If on the other hand you are a great modeler, but terrible animator, Fuse is absolutely perfect for you.

     

    There are a few things I wish that were different.  I wish you had more control over mesh generation and polygon counts specifically.  All told though, I have never encountered a package that enabled me to create animated and actually game usable models anywhere nearly as easy as Fuse does.  I certainly do not regret my purchase.

    Art , ,

    8. November 2014

     

    Amber have just open sourced Copperlicht, a WebGL 3D JavaScript engine.  Copperlich was previously available for 99 Euro per year.

    Logo

     

    Here is an overview of Copperlicht’s functionality:

    • 3D World editor: CopperLicht comes with a full 3D world editor named CopperCube.
    • Many supported 3D file formats: 3ds, obj, x, lwo, b3d, csm, dae, dmf, oct, irrmesh, ms3d, my3D, mesh, lmts, bsp, md2, stl, ase, ply, dxf, cob, scn and more
    • Built-in Collision detection: Throw a polygon soup into the engine and walk around the 3D world.
    • Lots of 3D graphics features, see below.
    • Incredibly fast: CopperLicht is highly optimized and able to render and animate even huge 3d scenes.
    • Character/Skeletal animation: supports playing back animated meshes with an unlimited amount of joints and an unlimted amount of weights
    • Simple to use: easily understandable SceneGraph API with lots of tutorials and examples in the documentation
    • Binary compilation: Unlike other WebGL 3D Engines, CopperLicht compiles your 3D meshes into a small, binary file which downloads quickly, reducing bandwith usage for your users. Simply import your 3D files into the CopperCube editor and publish it as CopperLicht scene.
    • Totally free: CopperLicht is free to use. And open source. Just download and go!

     

    You may notice the strike through that Copperlicht includes a 3D world editor; this isn’t entirely true with the open sourced version.  There is a commercial editor available named CopperCube, however it is a commercial product

     

    I have to say, I like this move.  You can create a full game using Copperlicht without the editor, while the editor is available on a 14 day trial.  This means people can contribute to a Copperlicht project without paying money, but there is a value add sell that means the developer can eat!  I hope this will result in an increase in popularity for Copperlicht that in turn increases sales for Coppercube, which would be win/win.  I personally would like to see the demo extended to 30 days, or preferably be 14 actual days, not 14 calendar days.

     

    This announcement is quite timely, as I just recently had this conversation on Twitter:

     

    TwitterDiscussion

     

    I feel almost prescient!

     

    This is a slightly different business model, but one I firmly support.  On the whole I think this is a great change.  I have used Irrlicht in the past and was impressed by the engine.  Now I am going to look closer at Copperlight and possibly due a tutorial series on it in the future.  Now that Copperlicht and Coppercube are a bit less intwined, I wonder if Coppercube could move to being more agnostic and be of use to say… Three.js or Turbulenz.

     

    Are you at all interested in hearing more about the Copperlicht engine here on GameFromScratch?

    News , ,

    Month List

    Popular Comments

    Creating an HTML5 RPG level editor: The tools required
    Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


    Home > Design >

    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 , ,

    blog comments powered by Disqus

    Month List

    Popular Comments