Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
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


15. August 2011

 

This began life as a post here but it became long enough and IMHO important enough, I am going to clean up the spelling a bit and repost it here.  It was in response to a fairly new developer with a question about class design.

 

 

This is one of those things that is nearly impossible to explain in a post, or hell, short of a small book.


But generally ( and yes, there are exceptions, thousands and thousands of exceptions ) you want to decouple your objects from each other as greatly as possible. You also want to keep code as self contained as possible, again, with thousands of exceptions.

 


A lot of the time when you are designing your classes ask yourself "If I changed this class, how many other aspects would need to be changed as well?" Then go about breaking those dependencies where possible. If two classes don't really need to know about each other, break that dependency. If two classes share 90% of their functionality, derive from a common base class.

 


On the other hand, you have to let common sense be a factor. One really common reason to abstract away your classes into engines and various components is so you can make switches later. For example, if you are using SDL, but want to be able to switch over to SFML at a later date, it's common to make a Renderer class, and an intermediary class over all the various objects like Bitmaps and Sprites, that both SDL and SFML provide so you can transparently change Renderers without making a code change. Reality is though, for 90+% of projects, this is just an added layer of complication and work that will never ever be used. This is where common sense has to come into play. Yes, from a purely object-oriented perspective, it is a very "pure" design that implementation details are abstracted away. From a practical and getting shit done sense, it's just a stupid waste of time.

 


This is where we get to the next sticking point and another area where new developers ( and experienced developers! ) get it really wrong most of the time. Global variables. See, when a new developer learns about global variables they seem like a godsend, as then you frankly don't have to design classes at all, just make everything globally available! This in a very short while makes extremely unreadable and maintainable code. Other new ( and experienced developers ) have heard about this and had it drilled into their heads that GLOBALS ARE BAD!!!! and react accordingly. Ironically enough, 9 times out of 10 this seems to always result in the same discovery... the Singleton. If you haven't yet, some day you will discover the singleton pattern and you will think it is the answer to your prayers. It's not a global, it's an object!!! Actually no, it really is just a global with a pretty layer of object oriented goop wrapped around it(**). Then you will encounter another group of people that will yell from the mountains SINGLETONS ARE BAD!!!! Which in the end leads you to engineering half a hundred "Manager" or "Adapter" classes to eliminate your dependencies on global variable and singletons. All the while, no work is getting done on your game.

 


Now it's time to let you in on a dirty little secret. Globals aren't bad, they are actually pretty frigging useful and important. The most important thing is, DO NOT ABUSE THEM. That is it. Chances are, you are going to have some form of global object, like perhaps a Game, App or World class, this is completely reasonable. On top of that you are going to run into code that needs to be globally accessed, such as your Audio class or Event class, which is also quite reasonable. It simply does not make sense to pass in an Audio class to say, a GameEvent, because that game event might on occasion need to play a sound. There are quite literally only a handful of things that should be made globally available but if it makes sense to be globally available, make it globally available.

 


But here is where the design gets tricky again, if you are making something globally available, do not make the relationship two-way, or at least not unless the two-way relationship is completely generic or via an interface. For example, if you have a game engine ( globally available ), and that game engine has a (globally available ) event queue, that at some point a game object needs to add events to, make sure that the event queue has the most absolutely minimal requirement to know anything about the game object and that the game engine itself needs to know absolutely NOTHING about the game object, as this is where your design can start to fall on it's face.

 


One last general rule of thumb when dealing with globally available classes, make them static whenever possible, it will lead to less potential hazards. Additionally, when make global objects provide access to other global object ( for example Game::SoundManager ), use accessor methods and const whenever possible. Keep all allocation and de-allocation specifically in the realm of the containing object.

 

 

 

 

 

 

 

 

 

 


(**) There are actually more to singletons than just object oriented globals. Yes, Singletons are global in scope but they have a couple very important properties. First of which is deferred allocation, meaning the Singleton isn't using memory until the first time it is used, unlike a traditional static variable. Additionally, a Singleton can be sub-classed as a mechanism of providing a single interface to potential disparate code bases, so for example you could have a Renderer::GetInstance(), which is sub-classed as OpenGLRenderer or DirectXRenderer, which will provide your code with a single global runtime determined instance. If you don't understand this paragraph, that’s completely fine, I'm just throwing it out there as a caveat so my over simplification of a Singleton isn't misleading... they do have their uses.

Programming Design


1. May 2011

 

Hmmmm, really need to settle on a name for the bipedal robotic characters that isn't Mech/Mecha soon just to ease these conversations! Not my most creative day so I’ll just go with GPR now.

 

Anyways, the GPR is very much fundamental to the game.  One of my favorite things about Autoduel and Mechwarrior Mercs was the sense of acquisition.  Start with a lowly machine and work your way up the ranks.  One of my favorite factors of Chromehounds was the customization aspect.  I intend to incorporate both into our game.

 

The very first Mech, er GPR the character starts with is power_loadervery primitive, like the Powerloader from Aliens that Ripley used.  Very simple bipedal machine with a single weapon forward firing weapon mount.  As the player wins matches, they will have the option of swapping that weapon out for better weapons and eventually with be able to buy better GPR frames.  In the end though, it will entirely be about trade offs.

 

Each frame will have a certain number of slots available, of different sizes to accommodate different sized weapons.  Additionally frames will be able to have different power plants, that will be a factor in speed, battery life, weapon power and charges.  So you could mount a big heavy laser, that really sucks the juice or mount smaller engine which would be lighter and faster but couldn’t power the weapons as well.

 

It is all about trade offs, so you could create a fast lightly armed frame, or a heavily armed slow machine or simply an average all around machine.  You could also use munitions based weapons like rocket launchers or machine guns that don’t use energy from the engine, but once they run out of ammunition are as good as useless. 

 

cci_40All frames start with a certain amount of energy, tied to the type of power plant installed.  Things like the weight of the frame ( from weapons and armor ), firing of energy weapons, running at high speeds, taking damage from certain types of weapons, etc.  If energy goes to zero, you stop dead and can’t fire.  Engines will recharge slowly on their own, so you need to balance speed and weapon use to keep your power levels healthy.  Or, go with a power plant that has a rapid recharge rating.  In my head now, statistically a power plant is rated by:  size ( amount of space needed by frame to install ), weight, power available, recharge rate and frame class(es) ( what size of frames the engine can be install into ) and finally cost.

 

Frames work on a very similar manner, with various weight classes, like featherweight, light, medium, etc…  In addition they have variant number of weapon mounts of different types ( forward facing, 360, back facing, 360 degrees auto tracking, pod based, etc ), maximum weight for all add-ons ( engines, weapons, armour, etc ), maximum internal space for engines.

 

So, in the beginning, machines would be only a few meters tall, with a single weapon and underpowered engines and minimal armor.  By the end though, the player could be piloting a literal titan, several meters tall and bristling with weapons and armor.  Of course then, so will their enemies. 

 

From a developers perspective, this means I need to figure out how to make weapons44784_md-Guard, Imperial, Sentinel, Tank, Walker, Warhammer 40,000 modular.  In the end I imagine this comes down to dynamic parenting of bones, but it is something I need to look into from a technical point of view before continuing too far ahead.  I had been tempted to make frames even more customizable, so different legs, torsos, cockpits, arms and weapons, but truth is I think the level of work is too high to handle right now, especially when it comes to creating the animations.  If the modular weapons end up being not too difficult, I may revisit this concept.

 

You know, the name Frames is starting to grow on me.  BattleFrames?  Battle Frame Formats?  Yeah, that’s the perfect name, BFF!  Oh, wait….  *groan*  Back to the drawing board.

 

For those looking at the various inspirational images in this post, they are from the top Ripley in a Power Loader in Aliens, the Walker from Avatar and finally the Imperial Guard Walker, which is probably the closest in my minds eye to the kind of vehicle the player will start in.  Think of it like the go-cart of Frames.

Design


25. April 2011

 

So, in its relatively short lifespan Android has seen a 1.0, 1.5, 1.6, 2.0/2.1, 2.2, 2.3 and most recently 3.0 release.  As a developer, you need to decided which of these to target and which of these to ignore.  In many ways, if you are using Unity or another engine it makes the decision easier, as they set a minimum level and abstract away the details in their own code.  For the record, the minimum Android version supported by Unity is 2.0.

 

One of the most obvious factors in deciding what version to support is market penetration.  Luckily, Google provides such information.  This chart shows the OS version of devices that have connected to the market in the past 14 days.

 

Hmmm, pretty simple really when you look at it.  Support Android 2.1 and higher and you are good to go.

 

From a developer perspective this is pretty true too.  There were vast numbers of changes between 1.5 and 1.6, things you would think would be a no brainer like multi resolution support, but due to such small market numbers in the first place, I think we can simply ignore 1.5 and earlier.  Trust me, they aren’t worth developing for.

Android 2.0/2.1

From a game developer perspective Android 2.0 really isn’t all that different from Android 1.6 but there are a few giant gotchas, not to mention the various “undocumented” features.

First off, due to a move towards virtual buttons, HOME, MENU, BACK and SEARCH buttons now execute on key up, instead of down.  These little changes cause all kinds of nightmares moving between platform versions.

Perhaps of the most importance to game developers, MotionEvent can now report multiple simultaneous touches ( aka, multitouch ).  Also, if you are using the NDK ( C native code ), OpenGL ES 2.0 is now supported.

Really, that’s about it.  There are other changes of course, support for bluetooth 2.1 profiles, better thumbnail generation, etc… but to a game programmer, not much else of consequence changed between 1.6 and 2.0.

 

Android 2.2

This was the big daddy of all updates.  First of all, they enabled JIT in the Dalvik VM, resulting in 2x-5x performance increase CPUwise over Android 2.1.  Personally, I never experienced anywhere near that level of increase, but the improvement in speed is extremely noticeable.  So first and foremost, your code is going to be faster running on Android 2.2.  If CPU bound, in some cases then, your code is going to be MUCH faster on Android 2.2.

Besides enabling JIT there were a number of other changes of note to a game developer.  One exceedingly big one is the ability for Apps to install to SD card instead of into the devices memory.

Perhaps biggest of all is that OpenGL ES 2.0 support is now available to Java based apps.  The media framework also gained a few new abilities that are quite useful, like the ability to detect the completion of a sound loading in a SoundPool.

That’s about it, but then again… a massive increase in speed, the ability to load to an SD card and OpenGL 2.0 ES support…  that’s a pretty substantial upgrade.

 

Android 2.3

Android 2.3 is one of the first versions that actually looked at gaming as a priority.  They improved the garbage collector to minimize pauses, which are killer to immersion.  Nothing like having a 30fps shooter slow to a crawl because the garbage collector kicked in.  They also increased the performance of touch and keyboard events and used a 3rd party OpenGL ES video driver to increase 3D performance.

In the feature perhaps most called for, they implemented OpenSL ES for native audio support.  Up until 2.3, audio support has been at best weak on Android.  Now expect to see a lot of audio applications from the iPhone show up on Android because frankly until now, they were impossible to implement.

For the very few games that require it, if you want to use a front facing camera, Android 2.3 is where support was added.  Also added support for a slew of new sensors to enable Wii-esque actions, if of course the device has said sensors installed.

Really, in the end, the audio changes are the main event in the 2.3 release.

Unless of course you are doing Native Development using the NDK.  If that’s the case, this release was huge.  Until 2.3, you basically used the NDK to develop libraries that you called from a Java code.  All your UI and event management code had to be done in Java.  With 2.3, they added the NativeActivity class which pretty much allows you to work 100% in NDK/C++ code and kiss java goodbye. 

This should result in a performance improvement and make porting to Android easier.  My question is, will it fragment the market even more?

 

Android 3.0

And this brings us to the most current release as of writing, 3.0.  3.0 was mostly about adding tablet and tablet UI support to Android, but from a developers perspective there were a few new additions that are handy.  Lets go with the biggy first, Android 3.0 is the first OS release to support multicore processors.  So I suppose you want to target that shiny new Tegra2, 3.0 is where you are going.

They also added new animation support, but that’s not really animation support in a way that a game developer would care, that’s more for flying bouncing windows and other annoying and overly abused eye candy.

They did however add hardware acceleration for 3D graphics.  I am kind of surprised it took this long, but is definitely a welcome feature.

They also added something called Renderscript, which due to my ignorance may or may not be of use to game developers.  I really need to look into it further, but for now I will let Tim Bray @ Google explain it.

Renderscript is a new API targeted at high-performance 3D rendering and compute operations. The goal of Renderscript is to bring a lower level, higher performance API to Android developers. The target audience is the set of developers looking to maximize the performance of their applications and are comfortable working closer to the metal to achieve this. It provides the developer three primary tools: A simple 3D rendering API on top of hardware acceleration, a developer friendly compute API similar to CUDA, and a familiar language in C99.

Renderscript has been used in the creation of the new visually-rich YouTube and Books apps. It is the API used in the live wallpapers shipping with the first Honeycomb tablets.

The performance gain comes from executing native code on the device. However, unlike the existing NDK, this solution is cross-platform. The development language for Renderscript is C99 with extensions, which is compiled to a device-agnostic intermediate format during the development process and placed into the application package. When the app is run, the scripts are compiled to machine code and optimized on the device. This eliminates the problem of needing to target a specific machine architecture during the development process.

Renderscript is not intended to replace the existing high-level rendering APIs or languages on the platform. The target use is for performance-critical code segments where the needs exceed the abilities of the existing APIs.

When I get the chance I will look into this Renderscript a bit closer, but it does sound interesting.  3.0 is such a niche of installed devices however that it really isn’t a feasible minimum level to target at this point.

 

 

So in summary, 1.5 and earlier are so ancient and decrepit you are just as well as ignoring them.  1.6 is pretty much the “core” of the current API, but a large portion of the 1.6 install base will be running on old hardware where the resolutions simply may not be worth supporting ( like 320x480 ) in a game, so this generation may be skippable on that merit alone.  Multi-touch and ES2.0 native support are the big draw to 2.0/2.1, while 2.2 offered a fair number of advantages.  Simply put, 2.3 and 3.0 currently don’t have a big enough install base to bother supporting as your minimum target.

Therefore, and this is purely opinion, if I were starting a game today… which I suppose I am, I would look at 2.0 as my baseline target unless I really needed one of the new features or the performance gains that 2.2 offers.  Luckily in my case, the developers at Unity already came to the same conclusion I have.

One last word of warning.  In my brief time working with Android, I found version bugs to be a major pain in the ass, especially in code dealing with media.  I had code that wouldn’t work in the emulator, that would only work in the emulator, that would work in 1.6, and 2.2 but not in 2.1.  Put simply, Google have done a pretty terrible job at times in the forward/backward support category.  With your code, make sure you test on as many devices and as many OS versions as you can.  This single handedly is the reason I am not developing directly for Android any more.  I spent more time, by a large magnitude, dealing with crap like this than I actually did developing.  Of course, your mileage may vary!

Design


24. April 2011

I suppose now is as good a time as any to actually talk about “the game” we are in fact going to create from scratch.  There are a few very key things to keep in mind when going through the game design process…  imagination is cheap and easy for most people, but you always have to keep in mind, at the end of the day you need to implement all these zany thoughts you have had.  So, in a nutshell, when designing a game, keep in mind your capacity and timeframe and ask yourself “can I actually do this?”.  In a nutshell I’m just saying don’t bite off more than you can chew.  So very often you hear people talking about how they want to make their first game, then go about describing some epic MMO that EA would have a hard time budgeting!

At the same time though “Pong from scratch” really isn’t all that exciting, although in all honesty it is a very good place to start.  I have created many “simple” games in the past and one of the quickest things you learn is, that simple it isn’t!  Ok… game time.

auto_duel_01Way back in the land of 80s computer gaming, there was a title called Autoduelcreated by Origin of Ultima and Wing Commander fame.  It was based off the Steve Jackson Games, um, game Car Warswhich in a nutshell was essentially MadMax the roleplaying game.  It’s the future, the world has gone to hell and we put guns on our cars… go!  Pretty much that was Autoduel.  Thing is, outside of creating my character, acquiring more money and sporting up my car, the game was actually rather lame, but the first few hours…. pure epic awesome.  Especially the time spent in the Arena and then using your winnings to design your first car! This bit of character building, customization and arena combat has always been buzzing around in the back of my head as the core of a very good game.

Now also may be a good time to point out that referring to yourself as “Lord British” is not really all that indicative of sanity.  This is to say nothing of poor “Chuckles” who you know had to have been talked into this whole thing.  Now Richard “Lord British” Garriott created many of the defining games of my childhood, so I am going to give him a pass on this one, but to you budding game designers, I don’t recommend it at all!

Anyways, back to the whole game design.  In a nutshell the big things I took away from Autoduel were the character development, arena combat and vehicle customization and of course the arcade like controls when you are actually duking it out.  The kernel of a very fun game is in those simple points.

Then in 2002, what is perhaps my favorite game of all time was released, Mechwarrior 4: 300px-MwmercsboxMercenaries. In this game you control a giant Battlemech, which is essentially a giant piloted robot killing machine.  What made this game truly great, especially compared to earlier versions, was the ability to purchase and customize your mech.  A perfect blend of strategy in the mech creation aspects, then thrust you into the action just like Autoduel did years earlier.  Even more uncanny, their was a portion of the game where you character competed in arena games, and again like years earlier with Autoduel, this was hands down my favorite part of the game.  Now, as I understand it, I need to be very very very careful in my use of terms here.  Mech, Mecha, Battlemech, etc… are all trademarked terms and will summon a hoard of avenging lawyers faster than you can say “lawsuit”.  This is why over the years we have been introducted to Chromehounds, Gears, Hercs and hundreds of other words that aren’t Mechs.  So let me say it loudly and now, this is not in any way going to be a game about Mechs!  This is going to be a game about giant mechanical human piloted robots!

So, before I get into more detail later on, essentially I am looking to create a game that combines Autoduel and Mechwarrior, with an arena focus.  Let me say this as loudly and plainly as I possibly can… our giant robots are not, in any ways Mechs!  So please don’t sue me.

Design


GFS On YouTube

See More Tutorials on DevGa.me!

Month List