Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

8. August 2013

 

In the previous post, we looked at creating a simple design concept for our game jet sprite.  Now we are going to start modelling our jet using Blender.

 

Of course, I cannot teach Blender in a single post.  Fortunately I have already covered modelling in Blender in a prior tutorial series.

 

Programmer Art: Blender for Programmers

 

If you already have experience with Blender, EXCELLENT!  Jump right in.  If however you haven’t much/any experience with Blender, I will assume you have gone through all of the above tutorials.  So instead of saying "Press X to delete the faces” I will simple say “delete the face”.  Dont worry, just keep the Quick Reference open in another tab and you should be OK.  If a concept is new or not covered in the above tutorials, I will go into a bit more detail.

 

In the design area, we created a top and side profile of our image, now if trimmed them down to two separate images, side and top.

 

Side.png

Side

 

Top.png

top

 

We are going to use these as modelling aids in Blender.

 

Setting up a background image in Blender.

 

Load up Blender, delete the default cube, then switch to Top view in 3D View.  Make sure you are in Orthographic view mode ( 5 on the number pad ).

Bring up the properties window ( N ) then locate Background Images and enable it:

image

 

Then click Add Image.  The dialog will expand with more options.

Click the Axis pulldown and select Z Axis Top, like so:

image

 

Click the Open button and find your top reference image.

image

 

Your Blender should now look something like this:

image

 

In the Properties window, near the bottom of the Background Image panel, you should see a manipulator for X and Y. 

image

 

Move the image along the X axis so it’s aligned with the Y axis in your top view, like so:

image

 

Now repeat the same process for side image.  It is exactly the same process.  Click Add Image, and another image will be available in the panel.  This time select axis as X Left and obviously use the side reference image instead.  If you have done it successfully, your Left view (Ctrl + 3 on numpad ) should look like this:

 

image

 

Now we want to make sure the two views are somewhat the same size in both the left and top views.  The way I do this is to simply create a cube the length of the reference image in the side view ( Add cube, S)cale + Y ), like so:

image

 

Then switch into Top View:

image

 

Hmmmm… this isn’t right… our top reference image is far too big ( or I suppose, the side image is far too small… ).

 

It’s a simple enough fix.  In the properties window, where we adjusted the X position earlier, there is also a setting for size.

image

 

Adjust the size and position of the background image until it matches the dimensions of your cube.  Be sure to use the proper dimensions, as there will be a set of controls for each the top and side background images.  IF you need to see through the CUBE texture while adjusting, hit the Z key to enable XRay mode.  When you are done, your top view should look like:

image

 

Perfect.  We now have two perfectly calibrated background images to work with.  Now delete the rectangle, we no longer need it.

 

OK, that section got a bit picture heavy, so I will end this part here so page load times don’t become insane.


Click here for the Next Part


Art , ,

7. August 2013

 

This isn’t an area I spend a ton of time on, as I haven’t got much talent for drawing.  That said, if I just fire up Blender and start modelling I tend to be a lot slower then if I nail down the basics of my concept, at least the proportions and overall shape, before even beginning to model.

 

In this case my concept was pretty simple… I want to make a jet that is a throwback to classic planes of old like the twin tailed Lockheed P38 Lightning or the DeHavilland Vampire, except with wing mounted engines like the Me-262.  However, I want it to appear near-future modern, like a contemporary of the F22 Raptor or F35 Lightning II.

 

For non plane buffs, I basically want:

 

This (P38):

p38

 

Or This (Vampire):

Vamp

 

With engines like these (Me-262):

me262

 

But more modern/futuristic, like this ( F22 ):

f22

 

 

Got it?  So basically I want a retro style twin tailed jet that looks futuristic.

 

So, time for some doodling!  I have a tendency to start with something really quick, break it down into individual pieces and go from there.  This way I get mostly the correct perspective, but I can work on smaller details instead of big picture… I can also quickly decide what works and what doesn’t.

 

For this, I worked entirely on my iPad Mini using a 5 dollar stylus and the application iDraw, which is a vector based graphic suite for iOS and MacOS.  Obviously any sketching app would work, as would paper if you have access to a scanner or digital camera.

 

Here is my first brain dump of the concept, side and top view:

1

 

I'm relatively happy with the top view, but hate the under-wing engine and am not a fan at all of the side profile.  I am thinking wingmounted engines don't work too well with the look I am shooting for here.

 

Instead I am going to switch to a single jet engine, like the Vampire pictured above.  Let’s clean up the tail section a bit and move to a single centrally mounted engine, again top and side view:

2

 

OK, I'm pretty happy with that look over all, now I’m going to look at the top and wing layout.  I start with:

3

 

Not really a fan.  Doesn’t make a ton of sense for the wing to extend out in front of the air intake.  Instead I decide to extend the air intake forward quite a bit, like so:

4

 

I like the overall shape better, it’s starting to look more modern, but I am still not a fan of the cockpit, nor have I nailed down the side profile yet.

 

On to the side profile.  I start with a quick sketch of the side, now using the forward wing, air intake and single engine. 

5

 

I did a quick sketch in black and it’s too fat and not very modern.  Drew over it in red more to my liking.

 

Now it’s a matter of figuring out the cockpit I am still not happy with, as well as the front view.

6

 

Started with a 3/4 view of the cockpit area, a rough front sketch, then a slightly cleaner one.  Over all, I’m pretty happy with the front profile.

 

So, I’ve got my basic design down, now the most important part, as a modelling aid and so I get the proportions generally right, I trace over the side and top view of my design using the line tool and end up with this:

7

 

The basic outline for the side and top profile of our jet.  I am certainly going to win no awards for artistic talent, but it should be sufficient for my needs and over all, I’m fairly pleased with the design concept.

 

You will see how we use it in the next part when we fire up Blender.

Art, Design

7. August 2013

 

I am about to create a game sprite for my own use and I figured I would document the process.  I am going to make an animated jet sprite and ultimately output a multi-frame single sprite sheet ready for use in a game.

 

Through the process I (may) cover:

  • Concept design ( as far as I do it anyway… )
  • Modeling it in Blender ( probably over multiple parts )
  • Texture painting in Blender
  • Texture finishing in GIMP or another image manipulation program
  • Animation ( maybe, might be overkill ) in Blender
  • Rendering in Blender
  • Making a sprite sheet, probably using TexturePacker
  • Using the sprite sheet in code (maybe ), probably using Haxe/OpenFL/Some Haxe Library, but subject to change.

 

Basically if I need to do it, I will document the process.

 

Keep in mind… I am a programmer who dabbles in art, and it shows!  We are just one step up from programmer art here, but the process is pretty much the same, you just need to add a bit more talent and patience. I am certainly not recommending anyone follow my work process, but it may give you some ideas.  Worst case scenario, it may just give you a good laugh!

 

Hope you enjoy.

News, Art , ,

3. June 2013

 

As I am just starting out on a new game these days, I am in the most wishy-washy stage of development, design.  Over the years, the way I went about designing an application has changed greatly as technology, my team size and frankly, me, have changed.  Now that I work mostly alone I find I am a lot less formal than I used to be.

 

In the ancient days, I ignored design completely, or used a spiral bound binder and a pencil.  On my last large scale project I worked mostly in Visio for object design and program flow modelling.  For idea capture and design documents, OneNote was my loyal ally.  If you find yourself working using a paper and pencil most often, you should check out OneNote, it is probably the greatest application Microsoft make and I say that without hyperbole.  It is an under-exposed and under-appreciated application.  Whenever I see websites comparing Evernote or Google Keep I laugh and laugh and laugh.  Those two programs aren't in the same league as OneNote.  That said, the OneNote mobile offerings, at least on iOS and Android are pretty terrible and the web version is only ok.  The application version though, its just great. 

 

That said, this combination of applications has definite limits.  These days I am working more commonly across platforms, splitting my time about 50/50 between MacOS and Windows.  Unfortunately Mac Office doesn't include OneNote and Visio isn't available either.  Also, I am no longer part of MSDN and Visio is stupidly expensive.  The other major change is the rise of tablets.  I find myself on mobile much more often now, either the iPad or my Galaxy Note ( which you can pry from my cold dead hands! ).  So, if I am out and about and an idea comes to me, its nice to just whip out my phone or tablet, which are on instantly, jot the idea down and move on.  Additionally, I find touch a much nicer interface when working on a fluid design.

 

One of the flaws of working with code modelling software is it is often too advanced for me.  I don't need it to validate my class design, I am not working in a team or with contractors, so I don't need it to create formal design documents or strictly defined interfaces.  At the end of the day I generally just like to enter a class name and description, then model relationships between other classes.  That or create flow charts that illustrate user or application flow.  Visio can do this, but it is massive overkill.  Enter the mind map.

 

In my life, I always had a bit of a mental block towards this kind of software…  I don't really know why, but I never really looked into it closer and I regret that, as mind mapping is basically what I've needed all along.  Essentially mind mapping is just a diagramming software that models relationships.  That's about it and exactly what I am looking for.  There are reams of mind mapping applications out there, from downloadable applications to web services, from free to very expensive.  If you want to try one out free, you can try FreeMind or XMind to get started.  If you haven't tried one yet, you really should.

 

Myself, I am using a combination of applications for program design.  My design documents and "raw text dump" application of choice is still OneNote.  I vastly prefer authoring in the full application in Windows, but the web application and mobile apps work in a pinch, at least for reading.  On iPad I use iThoughtsHD, which you can see in action below:

IThoughtsHD

I haven't found a mind map application that works well on my Note, but I've also barely looked.  I like iThoughtsHD because it's quick, intuitive and supports the functionality I need. On top, it is compatible with most other Mindmap applications including FreeMind and Xmind that I mentioned earlier.  So I can design on the go, then open on my desktop on any platform.  Truth is though, I vastly prefer working on the tablet, it is just such an intuitive format for this kind of work.

 

If there is any interest, I will go into a bit more detail on Mind mapping and iThoughtsHD for game design.  I know this is a topic that isn't generally discussed very often, although that could be because people find it boring! ;)

 

So, that's what I use these days to design my applications ( and other projects ).  What do you use?

Design

14. May 2013

I just recently took a look at available Haxe game engines and decided to take a closer look at two of them, HaxeFlixel and Awe6.  I started with Awe6, as frankly it's the most non-traditional of the two options and as a result, the most interesting to me.

 

Awe6 is a very design pattern heavy framework, built around the concepts of Inversion of Control and Dependency Injection, but reality is, just about every single design pattern that isn't the Singleton make an appearance.  As a direct result though, groking it all can be a bit confusing… my current understand of things took a great deal of digging through code and documentation to arrive at.  That is one immediate problem with Awe6…  the number of examples available can at best be called lacking.

 

I actually prefer going through working code than I do documentation, so this part is a rather large disappointment.  Then again, if I document awe6 usage, I suppose I will have more people interested in the material, double edged sword I suppose.  Anyways, so far as existing code to work from, there is the incredibly simple Hello World example, the demo in github and finally this example, probably the best of the bunch.

 

 

Ok, enough about what other people have done, now lets take a look at what I've discovered.  One of the ongoing trends of Haxe development holds true for Awe6.  If you are developing on Windows using FlashDevelop, the process is amazingly smooth.  If you aren't… it isn't.  I've given in and just work under FlashDevelop, at least when creating my projects.  I deploy to Dropbox then can reboot and test in Mac if needed.  The following instructions apply to Windows/Flashdevelop only.  You can get it working on other OSes, but its a pain.

 

Getting started is brutally simple.  If you haven't already, install Haxe and NME.

Open a command prompt and type haxelib install awe6

Then run the command haxelib run awe6 install

 

That's it.  Assuming you have FlashDevelop installed, you can now create a new awe6 Project via the project menu, otherwise refer to their site for details of working from command line.  It will create a fully fleshed out folder structure for you, but truth is, when just starting out this is a bit daunting.  That said, the Hello World example is a bit too trivial, so I set about writing something that is middle ground… a more advanced Hello World, or less advanced example project, depending on your perspective.

 

This awe6 sample simply loads an image and allows you to manipulate it using the left and right arrows.  The code:

 

 

import awe6.Types;
import nme.display.Bitmap;
import nme.display.BitmapData;
import nme.display.Sprite;
import nme.Assets;
import nme.Lib;

/**
 * ...
 * @author Mike
 */

class Main
{
	static function main()
	{
		var l_factory = new Factory( Lib.current, '<?xml version="1.0" encoding="utf-8"?><data></data>' );
	}
	
	public function new()
	{
		// needed for Jeash
	}
}

class MyImage extends Entity  {
	private var _sprite:Sprite;
	
	public function new( p_kernel:IKernel )
	{
		_sprite = new Sprite();
		super(p_kernel, _sprite);
	}
	
	public override function _init(): Void {
		super._init();
		_sprite.addChild(new Bitmap(Assets.getBitmapData("assets/img/mechwarriorFrameScaled.png")));
	}
	
	override private function _updater(?p_deltaTime:Int = 0): Void
	{
		super._updater(p_deltaTime);
		if (_kernel.inputs.keyboard.getIsKeyDown(EKey.RIGHT))
			_sprite.x += 10;
		if (_kernel.inputs.keyboard.getIsKeyDown(EKey.LEFT))
			_sprite.x -= 10;
	}
}

class Factory extends AFactory {
	public override function createScene( type : EScene) : IScene
	{
		var scene = new Scene(this._kernel, type);
		scene.addEntity(new MyImage(this._kernel),true);
		return scene;
	}
}

 

 

 

Below is the Flash target if you want to play around with it (click it first to give keyboard focus, then price left or right arrow):

 

If you created a Awe6 project, you will notice the one above is a great deal simpler, but all the same basics are there.  Some of the terminology may certainly seem alien to you… Factory? Entity?  But don't worry, its not actually that difficult in the end.

 

Let's start with the Factory…  this is basically the "guts" of your game…  guts actually is probably the wrong analogy… brains would be a more accurate description or perhaps backbone.  Essentially you extend the Factory class to implement specific behaviour to your game by overriding a series of methods.  In our simple example above, we override the createScene method, but there are dozens of other methods and members that you can set.  The full documentation is right here.  Essentially the factory configures/defines your game, handles special actions ( such as the back key ), allows you to provide your own implementation of the Sessions, Preloader, Overlay, etc…  

 

So, if Factory is the brains or backbone of your application, Scenes are the meat of it.  This is how you organize your game into manageable pieces.  You could create a Scene for say… the title screen, one for when the game is playing, one for displaying the high scores, one for credits, one for settings, etc.  On top of this, literally, you have the Overlay, which is basically a top level UI or HUD if you like.  Your Factory class can create one, but I believe you can also create one at the Scene level as well.

 

After Scene, we have entities… simply put, these are "things" in your game, visible or not.  This could be… your main player, an enemy or a simple proximity trigger.  Entities can in turn contain other entities.  A Scene can contain numerous entities which themselves can contain many more.  Each entity will receive an update() call per tick for updating itself.  That's the bare basics of the hierarchy of objects and that just scratches the surface… it doesn't touch on other aspects such as Agendas ( state machines ), Session ( game state ), Preloader ( asset loading/caching ), or many other aspects of the framework.  We also don't touch on the kernel yet, which is a very important concept that we will talk about in a moment.

 

Now, lets take a quick look at how our code works, in order of execution.  When our program's main() is called, we simply create an instance of Factory, a class we define that inherits from AFactory.  We pass in the context as well as a simple empty configuration in this case.  As part of the process ( we will look a bit deeper in a second ) our Factory classes createScene method is called.  In createScene, we create a simple scene and add a MyImage entity to it. MyImage is a simple Entity that contains a Sprite class holding our mech image.  In the updater method ( called each tick when the entity needs to update ), we check the kernel for input, and move our position accordingly.

 

Now, understanding exactly what is going on behind the scenes is probably the trickiest part, so lets take a closer look at the process.

 

As we mentioned earlier, the Factory class is critical to your game, forming it's backbone, setting major configuration settings and perhaps most importantly controlling scene creation.  This is where execution begins.  You inherit from AFactory, but awe6 remaps it to an appropriate version depending on your platform ( you can see this logic in action right here, the same trick is performed for a number of classes ), all of the platform specific implementations simply provide platform specific functionality, but ultimately inherit from this guy, AFactory.hx.  It's kinda confusing at first, but you only really need to involve yourself in the details if you are trying to grok the source code.  The most important part of of AFactory to understand at this point is this call:

 

inline private function _init():Void
{
#if haxe3
config = new Map<String,Dynamic>();
#else
config = new Hash<Dynamic>();
#end
_configure( true );
_driverInit();
}

 

The call _driverInit() is of critical importance.  This is where the kernel is created.  What is the kernel, other than the object we keep passing around?  Well if Factory is the backbone of your game, Kernal is the backbone of awe6.  Essentially, kernel IS the game engine, and ultimately it is created by your Factory class ( or more specifically, the class your factory inherits from ).  So, obviously kernel is important, let's take a look at it's Init() method, it will make a great deal of things clear:

 

override private function _init():Void

{

super._init();

_view = new View( this, _context, 0, this );

_processes = new List<IProcess>();

_helperFramerate = new _HelperFramerate( factory.targetFramerate );

_isPreloaded = false;

 

// Perform driver specific initializations.

isDebug = factory.isDebug;

isLocal = _driverGetIsLocal();

_driverInit();

 

// Initialize managers.

assets = _assetManagerProcess = new AAssetManager( _kernel );

audio =_audioManager = new AudioManager( _kernel );

inputs = _inputManager = new InputManager( _kernel );

scenes = _sceneManager = new SceneManager( _kernel );

messenger = _messageManager = new MessageManager( _kernel );

_view.addChild( _sceneManager.view, 1 );

_addProcess( _assetManagerProcess );

_addProcess( _inputManager );

_addProcess( _sceneManager );

_addProcess( _messageManager );

_addProcess( _audioManager );

 

// Set defaults for visual switches.

isEyeCandy = true;

isFullScreen = false;

 

// Signal completion to the factory and initialize factory-dependent components.

factory.onInitComplete( this );

 

session = factory.createSession();

session.reset();

_preloader = factory.createPreloader();

_addProcess( _preloader );

_view.addChild( _preloader.view, 2 );

}

 

This is where the various subsystems are created ( assetManager, audio, input, etc… ) and started running ( via addProcess call ).  Then you will notice the code calls back into the Factory, calling the onInitiComplete method.  At this point, the Factory now has a copy of the kernel and the kernel has a pointer to the factory.  One other very important call for program execution is 

_view.addChild( _sceneManager.view, 1 );

View is something drawn on screen, in this case the main window.  In sceneManager, this is where we go full circle, with the call:

scene = _kernel.factory.createScene( p_type );


This in turn is what calls our derived Factory class's createScene method, causing the Scene to be created, our entity to be added to the scene, etc...

 

The bright side is, you don't really need to know ANY of this to make use of Awe6.  I just personally hate using a framework if I don't understand process flow.  It's a clever architecture, decoupling key systems and allowing for you to organize your own code in a clean manner, while still enabling communication between various systems.

,

Month List

Popular Comments