Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
11. June 2013

One man game development studios are becoming more and more common these days and plenty of them are having success.  That said, what do you do when that one man doesn't happen to be an artist?  This post looks at some of the options the Indie game developer has for creating or acquiring art for their game.

 

Pixel Art

 

Big chunky pixels that look like they jumped out of the 1980s are becoming more and more common and there is a good reason for it.  Creating Pixel art is easy, at least relative to other art styles.  Don't get me wrong, it still requires some artistic talent…  representing a complex object with a few blobs is certainly a skill.  That said, you can churn out a ton of pixel art in a very short period of time.  The downside to pixel art, if you don't like the aesthetic ( like me ), you are greatly limiting the appeal of your game.  

 

Pixel Art Example:

 

Realm of the Mad God

ROTMG Screenshot Combat

 

Realm of the Mad God is probably one of the most successful pixel art titles.  As you can see, it has a very simple aesthetic, harking back to games from the NES era… and possibly earlier.

If I am honest, far too many Indie titles are pixel art based… because it is probably the most accessible art style.  As a result, I am overwhelmingly sick of it.  It takes a hell of a lot of buzz to get me to even look at a game using this art style now.  Of course, that's just me… plenty of people still love pixel art, so you will have an audience.

 

Pixel Art Tools

At the end of the day, any image manipulation tool that supports a "fat grid" can be used.  A fat grid is a zoomed in view that shows each individual pixel extremely scaled up, as well as a view of the image at it's regular size.  This means your traditional raster graphic packages such as Photoshop, The GIMP and Paint.NET can all be used.  Of course, a great many (insane???) people just use Paint that comes with Windows!

Additionally a number of Pixel Art focused tools have been developed over the years as well.

Pyxel Edit -- in beta, written in Air

aseprite -- Allegro Sprite Editor.  In pixel art style itself

Pixelmator -- MacOS only raster graphics application.  A vastly cheaper alternative to Photoshop with pixel friendly tools

Grafx2 -- a free pixel art oriented graphic application inspired by Deluxe Paint.  Open source too if that's your thing

GraphicsGale -- available as shareware, another pixel art focused application

ProMotion -- another pixel oriented editor, this one is commercial and has been used to create several commercial games. Not sure about it's development status.

PD Pro -- commercial software.  A Photoshop alternative that is vastly cheaper than photoshop

UltimatePaint -- another Deluxe Paint derived painting app

Pixen -- another Mac only pixel editing app.  Beta is available free, otherwise its $15.

 

Frankly at the end of the day, any pixel based image editing tool will do.  Some of the above programs do make more complicated tasks like animating or lighting a great deal easier than just using Paint, so looking into a dedicated app is certainly worthwhile.  Oh, and if you are under 30, you may be wondering WTF Deluxe Paint is?  Simply put, it was THE 2D game art package for the Amiga.  I think it's safe to say that most games in the early 90s had their art drawn in Deluxe Paint!  Since those days, its become the benchmark of sorts for game art packages.

 

 

Tutorials

YouTube Video on pixel Art using GIMP

Pixel Art for games ( using Photoshop )

PixelJoint -- The sites all about pixel art and hosts a series of tutorials.

FinalBossBlues -- Another series of pixel art tutorials

 

My personal opinion… Pixel art is way overdone, I am sick of it and have to imagine many other people are as well.  That said, its the easiest art form for a non-artist to crank out.

 

Voxels

Voxels are the pixel art of the 3D world.  Voxel is an amalgamation of the worlds VOLUME + Pixel.  So, basically they are a pixel with depth, which in every day parlance is what we call a cube.  Voxel worlds are made up of thousands and thousands of cubes… like a gigantic lego set.  Minecraft wasn't the first voxel game, not by a long shot ( there was a company called Novalogic that was obsessed with Voxels ), but it was easily the most popular.

 

Voxel Example:

Minecraft

Minecraft snapshot

Comanche Maximum Overkill ( 1992! )

Comanche92or 2

 

Voxel Tools

There are a number of tools available for editing voxels, some free, some not so free.

Voxel -- create Voxels on your iPad or iPhone.  Export in OBJ/MTL format or in Minecraft's .binvox format. Free

Sproxel -- free voxel editor.  Seems to have been abandoned in 2012.  Last version was Windows only, prior version available for MacOS. Free

Q-Block -- free, online, simple Voxel editor

Paint3D -- $20.  Windows application for editing voxels.

Zoxel -- I think its free.  Available for Linux and Windows, can export in OBJ.

Voxelogic Acropora -- Much higher end product than the above, for creating ultra high resolution landscapes.  Commercial, $90, with demo available

Cubicle Constructor -- Probably the most polished looking app of the above. Prices range from free to $80.

 

Personally, and this is just me, I've always hated voxels.  These days, a voxel game is going to look like a Minecraft clone as there were SOOOOO many Minecraft clones out there.  That said, Voxels work a lot like lego, so if you can create something visually impressive in lego, you can do the same in Voxels.

 

Vector Graphics

Vector graphics are increasingly common, as you can support multiple resolutions using a single art asset.  Since files are stored as a series of vectors, the image stays sharp regardless to how large or small it is scaled.  This can be a huge boon when supporting multiple resolutions especially with mobile devices.  In many ways, constructing an image using vector graphics is similar to working with construction paper.  You essentially layer shapes on top of other shapes to make more complex objects.  Working with vector graphics is a great deal more difficult than pixel art, but isn't outrageously difficult.

 

Vector Graphics Example:

Castle Crashers

Castle crashers 20100902050138751 001

 

Vector Graphic Tools

There are less vector graphic applications and some clear favourites when it comes to game creation.

Adobe Illustrator -- This is the Photoshop of vector graphics.  It's also got a LOT of stuff in their that you don't need, as the package was originally made for doing page layout in the print world.  Still probably the most used professional tool. Expensive! Only available by subscription now.

Adobe Flash -- Increasingly Flash is becoming more and more about game creation.  Flash Professional can be used to create and animate vector graphics, and commonly is!  Also expensive. Only available by subscription now.

Inkscape -- FREE!  Great free vector graphic package.  Very commonly used by those on a budget.

Corel Draw -- another commercial vector graphic package.  Targeted at the same market as Illustrator. Also expensive ( $500 )

iDraw -- Mac/iPad only, quite cheap ( 10$ iPad, 30$ Mac ).  I personally use this program.  More intuitive than Inkscape, simpler than Flash/Illustrator.  No timeline for animation though.

 

There are a couple 2D animation systems available as well.  You can draw your character once, cut them into pieces and let the software handle the animations.  Note that these tools work with regular bitmap graphics, not just vectors

2D IK animation tools

Spine -- 2D skeletal animation

Spriter -- another 2D animation tool

 

Vector Graphic Tutorials

2dgameartforprogrammers -- Has a ton of great vector graphic tutorials.  Be sure to check out the Apache Helicopter tutorial.

Gamasutra tutorial -- Same guy as above, great series.

Inkscape Tutorials -- A series of, you guessed it!  Inkscape tutorials.  Not necessarily game related, but techniques still apply

 

3D Art

I've been a hobbyist at 3D graphics for about as long as there has been an industry and even still, I can only JUST make art good enough for a game and even then I probably take 3x longer than an actual artist, and generate much lower quality work.  Don't kid yourself, 3D is as much a profession as programming.  It will take you years to learn to the point your results don't look like crap.  Don't worry, I wouldn't mention it if there weren't options for the less… talented.  I will discuss those in a second.

 

If you are interested in pursuing 3D, you can find a list of the most commonly used 3D applications right here.  Many of these applications have a price tag in the $5000 range.  However there is the freely available Blender package which is an incredibly capable 3D program for modelling, animating and texturing.  On the other hand, it isn't an easy application to get started with.  That is why I created this five part series, Blender for Programmers.  If you are interested in 3D, it is a good place to start.

 

3D for the less talented!

There are plenty of tools available with a much lower learning curve if you want to work in 3D.  This section mentions a few of them.

Poser -- Use existing character models.  Dress them up, animate and render or exports.  You can easily create animated characters using this application, and can buy a number of pre made assets if the existing content isn't enough for you.  Poser costs between $200 and $400, although it is quite commonly on sale.

Daz Studio Pro -- This program is a lot like Poser.  However it is free but comes with a lot less assets.  I did a tutorial on creating a sprite sheet with Daz and The GIMP if you want an idea what it is like.  That said, although Daz is free, they will spam you A LOT.  I still get two or three emails a week from them and it's not trivial getting yourself removed from the mailing list!

Make Human -- Create fully boned photorealistic humans with ease.  Oh, and it's free!  Used to be a Blender plugin, but now it's free.

Bryce -- Create stunning landscapes with basically zero effort or talent.  It's rather amazing the results you can get from this guy!

Sketchup -- Previously a google application for making 3D models for use in Google Earth.  There is a gigantic repository of models available for free.  If you need to create levels or cityscapes, this is a GREAT place to start.  There was a recent article on Gamasutra on exactly this.  Be careful with licensing issues though!

 

Sculpting Applications:

These applications are like working with 3D clay.  Even with little skill, you can make some remarkably awesome results.

Sculptris -- Free!  Baby brother of ZBrush.  Try it out, it's free.

ZBrush -- THE 3D sculpting application.  $700.

3D Coat -- In between Sculptris and ZBrush.  $350.  Often on sale on Steam, keep an eye. 

Mudbox -- Autodesk's sculpting application.  Most expensive in the list, $800.

 

Use existing assets

There are a HUGE number of assets available that you can buy or simply download online.  You should be able to source a ton of your assets this way.  The maxim You Get Way You Pay For isn't always true, but it often is!  On the other hand, simply because you paid for something doesn't make it good!  Working from many of these assets is tricky because they may not be suitable for games, may not be legally licensable, etc.  

 OpenGameArt -- a huge repository of game focused 2D and 3D art assets.

Blend Swap -- 8000+ freely available Blender Blend files.

Blender-Models -- Another Blender model resource

Mixamo -- 3d character model and animation on a pay per use basis.  Much like Bryce and Daz but online.  Upload your own model for animating, or buy one of theirs.

Content Paradise -- (paid) content for Poser.

Daz3D models -- (paid) content for Daz3D

Unity Asset Store -- if you use the Unity 3D package, there is a huge asset store of ready to drop in assets and scripts

Turbo Squid -- the biggest 3D object store.  Huge variety of content, quality and prices.

CGTrader -- buy and sell 3D assets.

GameTextures -- high quality game ready texture maps for sale.

There are a number of other asset stores available, this is just a small selection of the more common resources. 

 

Programmatic Art

Of course, you always have the option of creating a game that uses strictly programmatic art.  This is, art that is generated by an algorithm instead of an artist.

 

Programmatic Art Example

Rez

Rez ingame

 

Geometry Wars

Geometry wars galaxies 20070629054423884

 

Basically if you go this route, your art is in mathematic form.  On the one hand generating your game art algorithmically has the advantage of minimizing the need for artists.  On the other hand, it requires a completely different set of skills, especially when it comes to writing shaders!  Fortunately there are a few tools out there that help you create shaders visually.

 

Hire an Artist

Of course you may also decide at the end of the day you need an artist!  Obviously adding another person to your team can have a number of downsides…  you will lose a certain amount of creative control ( and should by the way!  Why are you working with an artist if you don't trust their artistic direction? ) over your baby.  Of course there is also a loss in either ownership or a cost involved.

 

Paying an artist, how?

This part is always tricky… how much does an artist cost?  Do you get what you pay for?  Will they work for free?  Will they work for a percentage?  How much of a percentage should I give?  What should I expect from an artist?  What should an artist expect from me?

 

To answer all of those questions, it depends.  It depends on so many things you can't give a simple answer.  Some games have much higher art requirements than others.  Some people have a budget and can pay for contract work, others do not.

 

The easiest and most likely most successful option is collaborating with an artist you know in real life.  Of course, this isn't always an option and can still lead to massive friction once things become about real money.  Make sure you establish the revenue split up front, and make sure fixed costs are accounted for before you start splitting up the pie.  Also be realistic that the pie may never actually arrive!

Contracting out pieces is a bit trickier.  Probably the simplest is to pay X amount per assets.  For example, pay 25$ for a textured tree model.  Working on bid work is by far the most straight forward, but you need to be very specific in what you need from the artist.  The more detail you can give, the better your relationship with go.  Instead of saying " I need a textured tree", say "I need a textured tree, under 300 polygons, a single texture no larger than 512x512 using a power of 2 resolution".  As to determining the cost X… well that is an art form in and off itself!

There is a good chance you have no money, and are willing to offer a percentage of future profits in return for labour.  If this is the route you are going, be VERY upfront about this, and don't pester people that aren't interested in such a work example.  The further along you are in the project, the more likely you will be to acquire a good artist.  If you can hand a game to someone with programmer art stand ins that the artist needs to replace, things will go a lot smoother.  If you've got an idea only… get further along before recruiting, unless you know an artist personally.  If you got an idea only… and that's all you've got ( no programming skills ) I would generally suggest not wasting anyones time.  In this day and age, amazingly enough, the idea is the LEAST important part of the process.  Everybody has the next killer game idea!  The reality is, its generally execution that makes a game great, not the idea.  Exceptions exist, but they are exactly that, exceptions.

 

Where to recruit artists?

Real life is obviously a great place, but not always or even often, an option.  Otherwise there are a number of places you can look for artists, often depending on the type of contract you are offering.

http://www.polycount.com/forum/ -- They have a series of recruiting forums, for paid and unpaid work.

http://www.reddit.com/r/GameDevClassifieds -- Post your jobs, make sure to note paid/unpaid status.  Browse for artists looking for work

http://www.gamedev.net/classifieds -- GameDev.net job boards, contract board and hobby recruiting listings.

http://www.conceptart.org/forumdisplay.php?f=11 -- Concept artists, not game artists, but theres an amazing amount of talent here.

http://forum.deviantart.com/jobs/ -- You get a WIIIIIDDDDDEEEE gamut of talent on this forum, many without game experience, but it is certainly another place to look, if even just to figure out payment amounts.  Forums are for paid work only!

http://www.game-artist.net/forums/employment/ -- Game art focused forums, have sub forums for all kinds of hiring.

 

Summary

At the end of the day, relationships are CRITICAL.  The network of contacts you make will be one of the most valuable assets you can acquire.  Deal fairly with people, don't misrepresent yourself or your project and act professionally.  Even if you aren't paying, act professionally.  It will pay off massively in the long run.  Also keep in mind, every relationship is a two way street.  If you don't like working with an artist you contact walk away ( … if not in breach of contract! ), you will both benefit in the end.

 

Make as much clear up front as possible… revenue split, paid/unpaid, detailed specs, etc… the less ambiguity, the smoother things will go.  Oh, and never pay 100% up front, EVER!

 

This post on scratches the surface of what is out there.  As you can see, even if you don't have artistic talent, there are tons of options out there for you!  If I missed something you feel I should have included, let me know!

 

 

Art Design Programming


10. June 2013

 

The Apple World Wide Developer conference is currently going on and generally there isn’t all that much of interest to game developers.  This year is a bit of an exception as they added SpriteKit to OSX Maverick (10.9) as well as an upcoming release of iOS.  SpriteKit seems to be a combination of sprite library and physics engine.  In their own words:

Sprite Kit provides a graphics rendering and animation infrastructure that you can use to animate arbitrary textured images—sprites. Sprite Kit uses a traditional rendering loop that allows processing on the contents of each frame before it is rendered. Your game determines the contents of the scene and how those contents change in each frame. Sprite Kit does the work to render frames of animation efficiently using the graphics hardware. Sprite Kit is optimized to allow essentially arbitrary changes to each frame of animation.

Sprite Kit also provides other functionality that is useful for games, including basic sound playback support and physics simulation. In addition, Xcode provides built-in support for Sprite Kit, allowing complex special effects and texture atlases to be easily created and then used in your app. This combination of framework and tools makes Sprite Kit a good choice for games and other apps that require similar kinds of animations. For other kinds of user-interface animation, use Core Animation instead.

Followed by:

Sprite Kit is available on iOS and OS X. It uses the graphics hardware available on the hosting device to efficiently composite 2D images together at high frame rates. Sprite Kit supports many different kinds of content, including:

  • Untextured or untextured rectangles (sprites)

  • Text

  • Arbitrary CGPath-based shapes

  • Video

Sprite Kit also provides support for cropping and other special effects, allowing these effects to be applied to all or a portion of the content. All of these elements can be animated or changed in each frame. You can also attach physics bodies to these elements so that they properly support forces and collisions.

By supporting a rich rendering infrastructure and handling all of the low-level work to submit drawing commands to OpenGL, Sprite Kit allows you to focus your efforts on solving higher-level design problems and creating great gameplay.

So basically it’s a 2D game engine competing with the likes of Cocos2D.  Of course, if you use SpriteKit you will be tied to iOS/OS/X and the newest release at that.  If you are an Apple only shop, this isn’t a big deal, but if you work cross platform or are targeting older hardware, this new library is pretty much useless for now.

 

If you have an Apple ID, you can log in and read the documentation here.

News


27. May 2013

 

In this day and age almost all graphics engines are behind the curtain based on 3D.  It's just the way graphics hardware works, so we now deal with textures instead of pixels  SpriteProjectand sprites.  At the end of the day, almost every single 3D game engine get a 2D sprite engine created on top off it, and now jMonkeyEngine is no exception with the release of The Sprite Project.

 

In case you have never heard of it, jMonkeyEngine is a complete Java based 3D engine, that is quite mature ( version 3+, over a decade old! ) and completely open source.  The Sprite Project is a 2D sprite engine built over top of it.  Here is a sample application taken from the documentation(pdf link).

 

package mygame;

import com.jme3.app.SimpleApplication;


public class Main extends SimpleApplication {

static Main app;

public static void main(String[] args) {
  app = new Main();
  app.start();
}

static SpriteEngine engine = new SpriteEngine();

@Override
public void simpleInitApp() {
  Sprite sprite = new Sprite(“Textures / Sprite.png”, “Sprite 1”, assetManager,
    true, true, 9, 1, 0.15f, “Loop”, “Start”);
  SpriteLibrary.l_guiNode = guiNode;
  SpriteLibrary library = new SpriteLibrary(“Library 1”, false);
  library.addSprite(sprite);
  engine.addLibrary(library);
}

@Override
public void simpleUpdate(float tpf) {
  engine.update(tpf);
  }
}

Pretty simple looking eh?

So if you are looking for a 2D sprite library built on top of a great Java 3D engine, you need look no further.


6. February 2013

As we reported back in december, Torque2D was going open source.  Well, the day has finally arrived, Torque2D's source code is up on Github now.

Torque2D Logo

 

 

So what is Torque2D?  It is a 2D cross platform game engine, previously under a commercial license.  I will let them describe their baby:

 

 

In simple terms, Torque 2D is an extremely powerful, flexible, and fast engine dedicated to 2D game development. The following is a breakdown of the core facts about the engine:

Currently supported platforms:
* Windows
* OS X
* iOS

Support for new platforms is surely on the way. In fact, YOU get to help us decide what we should work on, be it Linux, Android, editors, or just simple bug fixing. 

Languages:
* Core: C++
* Windows: C++ and Windows API
* OS X: C++, Objective-C, and Cocoa API
* iOS: C++, Objective-C, and Cocoa touch API

Main Features:
* Box2D physics
* Simple and flexible sprite system
* Composite system capable of rendering thousands of images and animations with little performance impact
* Integrated asset system that manages all your asset loading and unloading in an optimized manner
* Flexible module system that makes rapid prototyping a snap and code reusability a simple matter
* TexturePacker Support
* TAML serialization format (like XAML and XML)
* Batched rendering
* Multiple collision shapes
* Built-in unit testing framework, cross platform
* Solid behavior system for packaging reusable game logic that can be applied to multiple sprites in different projects

In addition to the core engine languages, you can script all your game play via TorqueScript. This is a C-like syntax language that is very simple to learn and utilize for your projects. Additionally, persistent files such as particles, levels, GUIs, and more are stored as "TAML" (Torque Application Markup Language). If you have ever edited XML or XAML in the past, you should feel more than comfortable with TAML.

Blazing Speed
Blazing fast performance on Windows, OS X, and iOS. On desktop platforms, you can have thousands of sprites, particles, and physics objects running at once without ever dipping below the 60 fps mark. While more limited, iOS hardware can run the engine at a solid 60 fps, even with hundreds of objects interacting on screen.

 

Very cool move open sourcing this GarageGames, I hope it works out for you.

 

You can read the complete announcement here.


7. May 2012

 

As the title suggests, this thread is going to be about using sprite sheets with PS Studio.  For those of you unfamiliar with the term, a spritesheet is a single image with multiple sprites.  You generally group your sprites together on a single sheet as it is much more efficient for loading and generally performs better than loading one texture per sprite.

 

EDIT(5/11/2012): If you are working with an actual Vita device and using the beta SDK, there is a bug on the Vita XML that prevents this from working. Read this post for a simple workaround. Hopefully in time Sony fixes this and you no longer need to apply the bug fix. Note, the problem only occurs on an actual device.

 

Instead of showing you how to generate a spritesheet, I am going to recycle a previous post I made on creating a spritesheet using Daz3D.  Fortunately Daz Studio is still available for free if you want to follow along.  Of course you can create your spritesheet however you want, or can simply download a freely available spritesheet such as those available at opengameart.org.  Or of course you can just use my sheet which will be available later.

 

In this example, I am going to use a different program than the GIMP for assembling the spritesheet.  The end result of my Daz tutorial is a directory full of 128x96 images like these:

 

Walk_left00Walk_left01Walk_left02

 

You can download a zipped copy of the sprites I rendered right here.

 

I generated 19 frames of walking animation in each direction.  This time I am going to use the free version of the tool TexturePacker to generate my sheet.  Download and fire up TexturePacker and you will be greeted with this interface:

 

image

 

The first thing you want to do is add your sprites to the sprite palette. You can either drag and drop the folder ( using Windows Explorer ) containing your sprites to the sprite panel on the right or hit the Add Sprites button and select the sprites individually.  Add all of the sprites you just created in Daz3D ( or the folder you downloaded and unzipped ) using either method.  Dropping a folder will automatically add those sprites in a folder by that name keeping things a bit more organized.  Here is the results of me dropping my walkCycle folder on the sprites panel:

 

image

 

As you can see, it added all of the sprites under a folder named WalkCycle and automatically layed out our sprite sheet as efficiently as possible.  As this point though, we don’t really care all that much about efficiency, so we are going to make a few small changes.  In the Texture Settings panel we want to fill in a couple options.  First drop down DataFormat and change it to “Generic XML”.  Next, under Data File, pick a directory and filename to save your sprite sheet, I choose c:\temp\walk.xml.  This will automatically set the texture file to c:\temp\walk.png.  Otherwise, these are the settings I used:

 

image

 

 

You of course can use whatever settings you want, but if you want exactly the same results as me, use the above.  Now that you are ready, hit the publish button.

image

 

The end result is a PNG file and an XML document. 

 

The resulting image file:

 

walk

 

You can download the generated image file here.

 

It also generated an XML file with all of the sprite details.  The contents of that XML file look like:

 

<?xml version="1.0" encoding="UTF-8"?> <!-- Created with TexturePacker http://texturepacker.com--> <!-- $TexturePacker:SmartUpdate:a6e51795dbe6b13cd639951a1f67241c$ --> <!--Format: n => name of the sprite x => sprite x pos in texture y => sprite y pos in texture w => sprite width (may be trimmed) h => sprite height (may be trimmed) oX => sprite's x-corner offset (only available if trimmed) oY => sprite's y-corner offset (only available if trimmed) oW => sprite's original width (only available if trimmed) oH => sprite's original height (only available if trimmed) r => 'y' only set if sprite is rotated --> <TextureAtlas imagePath="walk.png" width="512" height="960"> <sprite n="Walk_left00" x="0" y="0" w="128" h="96"/> <sprite n="Walk_left01" x="128" y="0" w="128" h="96"/> <sprite n="Walk_left02" x="256" y="0" w="128" h="96"/> <sprite n="Walk_left03" x="384" y="0" w="128" h="96"/> <sprite n="Walk_left04" x="0" y="96" w="128" h="96"/> <sprite n="Walk_left05" x="128" y="96" w="128" h="96"/> <sprite n="Walk_left06" x="256" y="96" w="128" h="96"/> <sprite n="Walk_left07" x="384" y="96" w="128" h="96"/> <sprite n="Walk_left08" x="0" y="192" w="128" h="96"/> <sprite n="Walk_left09" x="128" y="192" w="128" h="96"/> <sprite n="Walk_left10" x="256" y="192" w="128" h="96"/> <sprite n="Walk_left11" x="384" y="192" w="128" h="96"/> <sprite n="Walk_left12" x="0" y="288" w="128" h="96"/> <sprite n="Walk_left13" x="128" y="288" w="128" h="96"/> <sprite n="Walk_left14" x="256" y="288" w="128" h="96"/> <sprite n="Walk_left15" x="384" y="288" w="128" h="96"/> <sprite n="Walk_left16" x="0" y="384" w="128" h="96"/> <sprite n="Walk_left17" x="128" y="384" w="128" h="96"/> <sprite n="Walk_left18" x="256" y="384" w="128" h="96"/> <sprite n="Walk_right00" x="384" y="384" w="128" h="96"/> <sprite n="Walk_right01" x="0" y="480" w="128" h="96"/> <sprite n="Walk_right02" x="128" y="480" w="128" h="96"/> <sprite n="Walk_right03" x="256" y="480" w="128" h="96"/> <sprite n="Walk_right04" x="384" y="480" w="128" h="96"/> <sprite n="Walk_right05" x="0" y="576" w="128" h="96"/> <sprite n="Walk_right06" x="128" y="576" w="128" h="96"/> <sprite n="Walk_right07" x="256" y="576" w="128" h="96"/> <sprite n="Walk_right08" x="384" y="576" w="128" h="96"/> <sprite n="Walk_right09" x="0" y="672" w="128" h="96"/> <sprite n="Walk_right10" x="128" y="672" w="128" h="96"/> <sprite n="Walk_right11" x="256" y="672" w="128" h="96"/> <sprite n="Walk_right12" x="384" y="672" w="128" h="96"/> <sprite n="Walk_right13" x="0" y="768" w="128" h="96"/> <sprite n="Walk_right14" x="128" y="768" w="128" h="96"/> <sprite n="Walk_right15" x="256" y="768" w="128" h="96"/> <sprite n="Walk_right16" x="384" y="768" w="128" h="96"/> <sprite n="Walk_right17" x="0" y="864" w="128" h="96"/> <sprite n="Walk_right18" x="128" y="864" w="128" h="96"/> </TextureAtlas>

 

You can download the xml file here. This XML file contains the details about how our original sprites are arranged within the sprite sheet and will prove useful in a moment.

 

Alright, now that we have our spritesheet and our sprite map XML file, lets fire up PSSuite and get down to some coding.  This tutorial assumes you have already gone through my earlier tutorials, at the very least the two Hello World tutorials.

 

Now create a new solution in PlayStation Studio, I called mine SpriteSheet.  We need to add a couple of references right away, add a reference to GameEngine2D, System.Xml and System.Xml.Linq. Now add your spritesheet png and xml files to the project, right click them and set their build action to content.

 

 

First we are going to create our gameloop in AppMain.cs.  I want to point something out right away… this is not the way you handle game events!  So the way things are done in this example are *NOT* the way we will do things in the future.  I went this route because you are already familiar with most of the code here.  In a (very near) future tutorial, I will show the “proper” way to handle updating game objects.

 

With that warning in place, lets take a look at AppMain.cs

 

using System; using System.Collections.Generic; using Sce.Pss.Core; using Sce.Pss.Core.Environment; using Sce.Pss.Core.Graphics; using Sce.Pss.Core.Input; using Sce.Pss.HighLevel.GameEngine2D; namespace SpriteSheet { public class AppMain { private static Walker walker; public static void Main (string[] args) { Director.Initialize(); Director.Instance.GL.Context.SetClearColor(255,255,255,0); walker = new Walker("walk.png","walk.xml"); var scene = new Scene(); scene.Camera.SetViewFromViewport(); var sprite = walker.Get("Walk_left00"); sprite.Position = scene.Camera.CalcBounds().Center; sprite.CenterSprite(); sprite.Scale = new Vector2(2,2); scene.AddChild(sprite); Director.Instance.RunWithScene(scene,true); System.Diagnostics.Stopwatch timer = new System.Diagnostics.Stopwatch(); int spriteOffset = 0; timer.Start(); bool walkLeft = true; while(true) { if(timer.ElapsedMilliseconds > 100f) { string spriteName; if(walkLeft) spriteName= "Walk_left" + spriteOffset.ToString("00"); else spriteName= "Walk_right" + spriteOffset.ToString("00"); sprite.TileIndex2D = walker.Get (spriteName).TileIndex2D; if(spriteOffset >= 18) { spriteOffset = 0; walkLeft = !walkLeft; } else spriteOffset++; timer.Reset(); timer.Start(); } Sce.Pss.HighLevel.GameEngine2D.Director.Instance.Update (); Sce.Pss.HighLevel.GameEngine2D.Director.Instance.Render(); Sce.Pss.HighLevel.GameEngine2D.Director.Instance.GL.Context.SwapBuffers(); Sce.Pss.HighLevel.GameEngine2D.Director.Instance.PostSwap(); } } } }

Click here to download AppMain.cs

 

Most of the concepts in this code we’ve seen in a previous tutorial, so I will only highlight the new details.  First thing is we declare a Walker object, this is a class we are going to create shortly that is going to handle our sprite sheet.  As you can see, the Walker constructor takes the file name of the sprite texture and xml file you created earlier as parameters. 

 

Most of the remainder of this initial code is a matter of setting up our scene and sprite objects just like we did in Hello World.  A key difference is we are getting the sprite from our walker object instead of creating it from scratch or loading it from file.  The line:

sprite.Scale = new Vector2(2,2);

Is simply to double the size of our sprite in the viewport to see it better, you can easily remove this if you wish.

 

We create a Stopwatch ( a .NET object ) and start it counting up, then enter our infinite game loop.  Lets take a look at the new logic in our game loop

 

if(timer.ElapsedMilliseconds > 100f) { string spriteName; if(walkLeft) spriteName= "Walk_left" + spriteOffset.ToString("00"); else spriteName= "Walk_right" + spriteOffset.ToString("00"); sprite.TileIndex2D = walker.Get (spriteName).TileIndex2D; if(spriteOffset >= 18) { spriteOffset = 0; walkLeft = !walkLeft; } else spriteOffset++; timer.Reset(); timer.Start(); }

 

This is basically the “guts” of our game loop.  What we are doing here is waiting for the timer to reach 1/10th of a second.  Every tenth of a second we want to move on to the next frame of animation.  However we have only 19 ( walk_left00 to walk_left18 ) frames of animation in each direction and once we hit the end of our walk cycle, we want to walk in the other direction.  So what we do here is loop through each frame of animation until we hit walk_left18 or walk_right18, at which point we flip directions by inverting the value of the walkLeft bool.  This results in changing the spriteName text prefix, otherwise we simply increment to the next frame.  Then we start our timer over again to begin the process again a tenth of a second later.  One more time, this is not the proper way to handle updates!

 

The key line in all of that was:

sprite.TileIndex2D = walker.Get (spriteName).TileIndex2D;

 

This line actually tells our sprite to refer to a different sprite within our spritesheet, causing the animation.  That will make more sense in a second when we look at the code for Walker.cs.  Speaking of which, lets create it now!

 

To create a new cs file we either click the New icon ( image) or hit CTRL + N.  In the resulting dialog select General on the left, Empty Class on the right and name it Walker.cs, like such:

 

image

 

Now open up Walker.cs and enter the following code:

 

using System; using System.Linq; using System.Xml; using System.Xml.Linq; using System.Collections.Generic; using Sce.Pss.Core.Graphics; using Sce.Pss.HighLevel.GameEngine2D; using Sce.Pss.HighLevel.GameEngine2D.Base; namespace SpriteSheet { public class Walker { private TextureInfo _textureInfo; private Texture2D _texture; private System.Collections.Generic.Dictionary<string,Sce.Pss.HighLevel.GameEngine2D.Base.Vector2i> _sprites; public Walker (string imageFilename, string imageDetailsFilename) { XDocument doc = XDocument.Load ("application/" + imageDetailsFilename); var lines = from sprite in doc.Root.Elements("sprite") select new { Name = sprite.Attribute("n").Value, X1 = (int)sprite.Attribute ("x"), Y1 = (int)sprite.Attribute ("y"), Height = (int)sprite.Attribute ("h"), Width = (int)sprite.Attribute("w") }; _sprites = new Dictionary<string,Sce.Pss.HighLevel.GameEngine2D.Base.Vector2i>(); foreach(var curLine in lines) { _sprites.Add(curLine.Name,new Vector2i((curLine.X1/curLine.Width),9-(curLine.Y1/curLine.Height))); } _texture = new Texture2D("/Application/" + imageFilename,false); _textureInfo = new TextureInfo(_texture,new Vector2i(4,10)); } ~Walker() { _texture.Dispose(); _textureInfo.Dispose (); } public Sce.Pss.HighLevel.GameEngine2D.SpriteTile Get(int x, int y) { var spriteTile = new SpriteTile(_textureInfo); spriteTile.TileIndex2D = new Vector2i(x,y); spriteTile.Quad.S = new Sce.Pss.Core.Vector2(128,96); return spriteTile; } public Sce.Pss.HighLevel.GameEngine2D.SpriteTile Get(string name) { return Get (_sprites[name].X,_sprites[name].Y); } } }

Click here to download Walker.cs

 

Our Walker class is in charge of loading and handling our spritesheet.  TextureInfo and Texture2D you have already been exposed to and in this case, nothing is different here.  Next up we declare a Dictionary of <string,Vector2i> named _sprites.  The Vector2i type is declared in GameEngine2D.Base and is simple a pair of ints. _sprites is used to store the x,y location of each individual sprite in our spritesheet, accessed by the sprites filename.

 

Let’s take a look first at the constructor.  This code is pretty straight forward if you have ever worked with Linq or XML.  We are simply opening our XML file, the filename of which we passed in from AppMain.  Note that we added “application/” to our paths, all your files on Vita are located under this subdirectory.  Next we read the XML file and extract each <sprite> entry into a new anonymous type composed of Name, X1, Y1, Height and Width.  Name represents the file name of the source image, X1 and Y1 represent the pixel coordinates within the generated spritesheet, while Height and Width are the dimensions of the sprite within the sprite sheet.  Given that all of our sprites are the same size, these values are of little importance.

 

Now that we’ve parsed out our XML file, we populate our _sprites dictionary using these values ( minus height and width which we don’t need past this point ).  However, we don’t actually want the x and y pixel coordinates of our image, but instead the offset within the spritesheet texture.  We can determine this value by dividing the X and Y values by the sprite Width and Height respectively.  Keep in mind, this works because all our sprites are the same size ( 128x96 ) and would require different logic if you had sprites of differing sizes in your sprite sheet.  You may notice I subtract 9 from the height value… this is because GameEngine2D SpriteTile’s locations start from the bottom left instead of the top left!  I prefer top right and this is how I generated the sheet, so invert the values.  If you design your sprite sheets to start at the bottom left ( so the first frame is at the bottom left corner ), you wont need to perform this calculation.  Now you may be wondering… why 9?  Well that’s the number of sprites we have in each row on the sprite sheet (10, counting from 0 equals 9).

 

Finally we load our texture using the filename we passed in to the constructor.  Again we prepend “Application/” to our filename.  The last thing of note here is the second value in our TextureInfo constructor.  This Vector2i informs the TextureInfo the dimensions of our sprite sheet, telling it at there are 4 columns of 10 rows of sprites.  It doesn’t matter that the last row isn’t full of sprites ( there are only 2 in the spritesheets bottom row ), if you try to access them you will simply get an empty space or whatever the background colour of your spritesheet is.

 

Our destructor is nothing special, just cleans up like a good little citizen should.  Remember it’s your responsibility to dispose of any objects you own and are no longer using.  C# is garbage collected, but its still easy to run out of memory in a hurry if you don’t keep things tidy.

 

Finally we have a pair of Get() methods.  The one takes a sprite name, looks it up in our _sprite dictionary, retrieves the X and Y offset of the sprite within the texture, then passes those values into the other Get() method.  This Get() method then creates a new SpriteTile assigning it our already created _textureInfo.  Next it sets the tiles index within the texture using the passed in coordinates to represent our currently selected sprite, sets the tiles dimensions to 128x96 (pixels) and returns our sprite.  Please notice there is absolutely no error checking or handling here in order to keep things short.  You really should have a wee bit more error checking in your own code! Winking smile

 

The end result of all this activity:

 

walkcycle

 

 

Click here to download the entire project source. In addition to the full project source, the zip also includes all the image files used in this tutorial.

Programming


GFS On YouTube

See More Tutorials on DevGa.me!

Month List