nav2

Showing posts with label 2d. Show all posts
Showing posts with label 2d. Show all posts

Thursday, January 25, 2018

Godot 2.1 - 1$ gesture recognition plugin

Some time ago I encountered a little charming google doodle game that uses the player's scribbles for input:


You can play it here:
http://www.google.com/doodles/halloween-2016

That mechanic inspired me so much that I decided to try and implement it in Godot. Luckily I didnt have to start from scratch. The basic 1$ algorithm was ported to gdscript, but its bare bones implementation was not ready for gamedev. It was only a function that can be crashed. I added some commits to it. Fixed some game crashing bugs in common corner cases and added a bunch of cool features.

After porting it into a plugin, I added the ability to teach it new gestures and record them in a json file.
Added some extra optional features:
 The developer can set limited ink - to limit the size of shapes that can be drawn Upon recognizing a shape, it also emits a signal of what shape it is and how much ink was left when it was completed If the ink left is > 0, it will create a collision shape from the drawing, that can be used to interact with other parts of the game You can limit how many collision shapes can be drawn optionally.
Optional particle effect and ability to set line thickness and color Ability to set the allowed drawing area and change the mouse cursor to a pencil then it is over it

Here is a demo video:

It can recognize the following shapes out of the box (in the json file):
  • carret
  • v
  • pigtail
  • lineH
  • lineV
  • heart
  • circle
If you like the plugin, feel free to get a copy from itch.io (maybe even leave a tip in the jar ;) ):
https://blurymind.itch.io/1-gesture-recognition-addon-for-godot

Github page here:https://github.com/blurymind/1dollar_gesture_recogniser/tree/master/addons/1dollar

If there is enough interest in it, I will port it over to Godot 3..
Might make a little game with it when I get the time :)

Sunday, August 28, 2016

Job applications - happy villager

I had a call from an agency a couple of months ago. They forwarded my portfolio to a studio in London. The studio was looking for an animator/rigger with experience in Unity3d and mobile games. My previous experience was close to what they were looking for and that got me to the interview stage. They interviewed me via Skype and explained that the final stage would be a test for which I have 4 hours to complete and send.
The test was on the following week. When I got the project file the clock started ticking. I didn't know what to expect prior to getting it. What I got was just body parts in black and white , and a reference image (on the right). The goal was to rig the character and animate a happy emotion that is up to 4 seconds long.
Rigging the character took about an hour. I arranged some elements into their own subfolders. The hierarchy of elements was key to getting the animation polished quicker. For example I put all face controls under a facedir node - that would allow me to turn her head with less keyframes to manage.
The minimalist character design was a good thing in this case - even with the imposed limitations -such as for example the lack of joints in the legs. I worked with what I had.

All and all they never did give me a call. Instead the agency told me that I have passed their test and they really liked my work. However the CEO has decided to hire somebody that they already know from previous projects instead.

Normally I wouldn't share work done for others, but given how I did not get paid in this case, how they didn't give me personal feedback and also that there was no NDA signed, I feel absolutely free to share this here :)

The animation has a drop in frames, because it is captured from Unity with capture software. When running, it is as smooth as butter 60fps. Thus why all I could get out of the whole experience is now the gif file you see above and the unity project.

If you are looking for an animator with rigging experience - who can do the rigging and the entire animation in Unity alone - I can send you this test file to review it yourself.


Friday, May 13, 2016

Feature proposal - vector eraser that erases strokes up to intersections


Very often when cleaning an ink drawing, the artist will need to clean up line overshoots. A good example of this is hair, but it applies to many places in a drawing.
In vector software, we tend to favor line overshoots, because that way we know for sure that our shapes will be closed off and ready for the bucket tool.
The first time I see this idea applied in an open source project is in  OpenToonz - the 'Remove Vector Overflow' command. This is where this command is supposed to come in and save the day.

It however hardly works. Very often it does noting at all.In fact almost 80% of the time when you select two overshooting individual lines, nothing happens, or it erases parts of the lines you want to keep.
My suggestion here is to add two new modes to the eraser tool - when you are using it on a vector level. These two modes can already be found in other software such as toonboom, clip paint studio and last but not least - inkscape:

A. Erase up to intersection - This can be found in both Toonboom and clip paint studio. What it does is it erases the lines up to the intersection point - where they intersect with another line. Clip paint studio has it as an eraser tool mode and it works excellently.
Toonboom has two strategies to deal with this. One is the one clip paint uses. But as a second strategy - there is an option in the brush tool - to always create a new node where the stroke you drew overlapped another stroke. From there on it is easy to erase all the nodes exactly to that point and you dont need to move nodes around to get them to overlap. Another strategy with the brush tool is to automatically snap the beginning and end of a line to a closeby node of another line or the line itself (toonboom). Inkscape allows you to continue previously drawn lines - but unfortunately works at the end points of lines and is very limited.

B. Object mode eraser- very often the artist would require to erase entire strokes of a drawing - every stroke is a vector object. Right now in OT you have to go to the select tool, select the strokes and hit delete, then go back to the eraser tool to continue working. In inkscape the eraser tool can also erase entire strokes like this:
The implementation in OT almost never works in practice. It works when you draw a simple square, but when you draw a character and start trying it out - the one in clip paint does the job , while vector overflow in open toonz fails
I wonder how clip paint does it. It's the best one I've seen so far. Strokes there dont create nodes at intersections - so they must be somehow figuring out where the intersecting points are:
Here is my theory
--when the stylus starts a stroke in vector eraser mode:
1. Vector erase stroke collects a list of lines (like inkscape does in example B.) that you touched during the stroke.
--On release the following happens:
2. Instead of deleting the entire lines (which is an option also), it splits them all up at intersections points (cache result)
3. Using the result from step 2 , It marks the parts of the lines that your stroke has touched and deletes them
4. The lines that were split up (in step 2) are connected again
5. All the lines in the list of lines from step one are deleted and in their place are created the lines created by this operation.
To the user it looks like lines were deleted up to the intersection - just like it happens in the gif of example A .
Anyways, if i knew c++ i would have tried to figure out a way to make this. Hopefully a more experienced programmer will be interested.
So in order to implement a vector eraser mode that deletes lines up to intersections, you will first need to implement a mode in which it can collect a list of all the lines that it has touched.
You get two awesome vector erase modes in one!

Inkscape developers are much closer at achieving this tool, as they posses the main elements.
The default eraser tool mode already collects a list of lines that the stroke has touched.
The 'Cut Path' command can split a line where another overlapped it, it however deletes the line that overlapped it - which is something we do not want in this case!

Krita Developers - Are actually currently trying to collect funding via kickstarter to improve the vector tools in it. There is no statement made in the campaign that they are planning on adding such a mode to the vector eraser. It is not a stretch goal either. But in any case, I found out that some of them are quite aware of this tool in Clip Paint Studio. Whether we see it in Krita or not - only time will tell. It currently needs an entire rewrite of the vector system, but for that to happen they need your help:

If you haven't seen krita yet, feel free to give it a try. Downloads to the latest version are available at the kickstarter campaign page.

OpenToonz - The development of opentoonz is active as I write this, we will see if in the future they improve this feature. In any case, I filed it here #287 in their bug tracker.

Tuesday, February 16, 2016

Spiter Render Kit - for Blender 3d

Here is something that I made for myself - primarily for game jams. I used it on a bunch of personal projects too. After a while I decided to pick it up, give it some polish and share it with the rest of the world.

What is Sprite Render Kit?

Sprite Render Kit is a sprite rendering system for Blender - specifically designed for rendering animated and static sprites for 2d games.
Its benefits become most obvious when you need to create a sprite with 4 or 8 directions of animation. It's main goal is to save you time!

In one click you render an animated character from 4 different angles and the files are properly named!

The Kit contains:


- A Scene Setup - Created to allow Blender to render an animated model from 4 different angles simultaneously.
- It is made out of one main scene (where you set your settings) and 3 more scenes for the remaining camera angles!
- The work Layout is created in a way that allows the user to conveniently view the model from all the 4 target rendering angles on one screen.


- An extensive Python Script, created specifically to allow the user to sync all scenes to the main one. Set it up in the main scene, the rest get synced to it in just a single click:
- It syncs all of your Render settings (BI and cycles)
- It syncs all of your Freestyle line sets from the main scene to the other scenes in the file (useful for sprite sheets with lineart)

- A Camera Rig, capable of simultaneously controlling all 4 cameras:
- Designed for Rendering an animated model from 4 different directions
- In ortographic or perspective mode (Ortographic is recommended)
- Tweak the center and angle of rendering with easy to use controlers
- Control zoom level
- Control render angle (45 degrees = isometric)
- Control the height angle of all cameras or on a per camera basis
- Control an offset on the left and right cameras - easier to center the model

- A node output setup - capable of rendering all sprites to a dedicated directory -set with proper naming conventions

Great! Now, how do I use it?

Here is a How To video:
The process is fairly straightforward!
  1. Open the blend file included in the zip
  2. Go to the first layer and Append your animated model in it.
  3. Play the animation, set the animation range to the proper value - the one you used in the appended file. Keep it playing while you configure your cameras.
  4. Select the model's armature in object mode and scale it up/down if needed, position it in Z and Y so it is centered in all 4 views.
  5. Go to the layer of the camera controls and use the "y offset" controller to position in center your character on the bottom two views.camera controls layer
  6. Use the "heightCtrl" to set the Z angle of rendering (height) you want to see your character in.
  7. Use the "spriteRenderCams-globalCtr" properties (N-panel) To configure these optionally:
    1. Isometric angle - Rotates the camera rig on Z - this allows for isometric angle. Set to 45 to get diagonals.
    2. Ort scale - This can be used to zoom in/out the 4 cameras (orthographic)
    3. Persp/ortho - If set to 0, the cameras switch to perspective mode. It's recommended to keep at 1 (ortho)
    4. Persp focal lenght - This can be used to set the focal length of the 4 cameras (when in Perspective mode)
  8. Set your Rendering settings (Make sure you are at the a-Main scene if you aren't)
  9.  You can enable Freestyle optionally and set your linesets
  10.  Run the script that I have provided in the blend file ("syncScenesRender.py") - always run it before rendering. It syncs the 4 scenes. Syncs your render settings, your freestyle linesets, makes sure everything on layer one is in all 4 scenes.runScript
  11.  Render single frame. A new folder called "output" will be created in the same directory where your spriteRenderKit.blend file is. Inside that folder you will find a single image from all 4 angles. See if you are happy with how it looks. See if the naming is correct. The sprite pointing to the left is named "left**.png" and the one pointing up is "up**.png" - whatever makes sense to you.
  12.  If they are not correctly named, you can rename them by selecting the appropriate output node and in it's n-panel change the "File Subpath" to the appropriate name. Keep the ##.renameSrk
  13.  Run the Sync script again and this time Render it as animation sequence. You will discover that the output folder is now populated will the frames. The script works with Blender Internal, Cycles and Freestyle.
  14. From here on you can use a tool such as shoebox to put all the frames in a single spritesheet. Alternatively you can use them as an image sequence - it all depends on the game engine you are using.

Where can I get this?

I am glad you asked. :)

Blender market (buy from here to also support blender!):
https://cgcookiemarkets.com/all-products/sprite-render-kit/

itch.io:
   
By getting it you also get my support in using it, any ideas you might have in improving it too.


Monday, February 16, 2015

Some hired work from the 2011 - graphics and mockups for tablet games

Back in 2011, I had the pleasure of signing up for a part time job with Cogworks studios  -as artist/animator . I made graphics and mockups for a bunch of iOS games/Apps. There was an opportunity to go full time, however I was in the middle of my second year at the University of Bradford - there were a lot of assignments stopping me from doing that. Also UK students are not allowed to work for more than 20 hours per week.


We used toggl to track my time each month. Sadly university took a lot of it and as you can see from one of my reports- I wasnt able to spend too much on concepts.

There was of course a non disclosure agreement with the job. Those type of agreements usually have a period of time - in this case 3 years - in which I am not allowed to release any information or show any of my work publicly. Well since 4 years passed I said to myself - What the heck, Let's do it. I am going to share with you some of the more fun ones. :)

Please note that some of these were quickly made sprites - used to put together a prototype for a few games. They were in no shape or form the final product. The names I am giving the games are not the final product names.

One of the projects was to do a game in a frame concept for Team 17. The deadline was very tight, so it's not very polished. I am not going to go into detail about the game ideas or design, since none of that was my work.

There was another ongoing project for a Jenga-like game where you stock blocks ontop of each other. I made a title screen, two backgrounds and animated sprites for the blocks. Each block had a face with a different character. Doing the backgrounds was really fun, since they were vertically very tall. We had a level where you stack blocks all the way into space, another one which started deep underwater and kept going until reaching the surface and so on. I had to use illustrator on that one, since it had better export tools.


There was a Bird in a factory game project where I made a number of bird concepts for. Then when we picked one of them - I made a fully playable animated sprite for the bird- run, idle, death, etc.
Some of the background elements also had to be animated - smoke, saw, travolator, etc etc. Those were simple enough to just do in Inkskape. I had set up for myself a script in linux that exports the svg layers as an image sequence. And another one which makes a gif file from the image sequence  (for presentation purposes). That saved a lot of time.

 I made an entire spritesheet in inkscape. There was no premade concept art, but the guys at Cogworks gave me some direction as to what animations they are going to need and some of the specific gameplay event items. I had some creative freedom in coming up with various hazards for the little bird though.

Overall these were fun projects for me and working with Cogworks was a real pleasure!
I do hope that they get to complete/release some of these games some day. Looking at my work from 4 years ago, I can't say that I am completely pleased with it. Surely it can do with a lot more polish! If these games ever get on production schedule, I would be more than happy to work on them full time.

Tuesday, January 27, 2015

Gamejam 2015 - Ignite the Knight

I participated in this year's global game jam event - in Plovdiv. We were a 5 people team and we made a 2d html5 game. Gamejam offers only 48 hours to create a game. A big part of this time is taken by  other activities connected to the event.

My job in the team was to make nearly all the graphics in the game- all the environment art and player sprites!
You can see the GameJam entry here --  globalgamejam.org/2015/games/ignite-knight 

Play the game here online!

And a video Demo here:
 

Game Mechanics

The topic of this year's GameJam event was " What do we do now?".
We had a number of ideas for the game. Starting with a point and click game where the pilot has passed out drunk and you are one of the passengers trying to land the plane by guessing which button to press. We came up with variations of this idea with a boat and a bomb. But it all led to a game where guessing was the main mechanic and the player was not in control of the situation at all.

Next on we thought of a top down game, where the player is forced to navigate his/her way through a maze. In order to enforce the theme of gj2015, we made the floor collapse - forcing the player to constantly move.
I asked further to make the player continuously run in a direction - so it is impossible to stop moving.
The programmers were against it at first, but then after some talk on how it will help compliment the topic of the event and how to implement it, they caved in.

Part of the reason I wanted the continuous run mechanic was also the character design that I had in mind at the very start.


Animating the player Sprite:


I started with a rough animation test in Pencil2d - which I gave to one of the programmers as a placeholder, so he had something to work with early
on. I made three placeholder sprites - side, front and back - of the run cycle! It is a bit messed up in the gif file here, so apologies.
The placeholder sprite is required to figure out how big the character will be on the screen and to implement the code for triggering the animation. This later on would drive some of the character design decisions- such as the thickness of the line, the size and amount of details, how tall he is and so on.



Modelling the Knight

Since the perspective in the game is top-down, the player sprite would require at least three versions for each animation it has. This led me to the idea of using Blender3d to make the sprite.
The idea behind the character is all aimed to compliment the continuous run gameplay mechanic. The knight has no shoes on and the floor is really really hot - running in his underwear, he is trying to get to the end. In this case the top half of his heavy armor is not helping the situation one bit. As you can see from the sketch, the character design is really really simple. It is taking into consideration how small the sprite would be on the screen. I modeled him out of really simple shapes - as quickly as possible. Then his colors were added via Vertext Painting - to skip the Uv unwrapping step altogether.  Since the final sprite would be 128x128 and the extreme limitation of our deadline, I couldnt afford to give him fingers.
I used rigify for the armature, but removed the bones in the hands and added extra bones for the helmet- to create a humorous secondary action later on.

Animating the Knight in blender

The knight has 5 actions in total:
Run, Idle (jumping on one place), Jump (over lava), Win, Die.
While working on the animations, I stumbled on some of the pet peeves that I have with blender's animation system and gui design. For example the lack of autoframe mode for f-curves and some other niceties that I missed from maya. I voiced my opinion at the forum.

The biggest problem came when blender wiped all of my animation data when closing the file- Without a warning! It nearly killed the project. Thankfully I already had my sprites rendered. However, It robbed me of the opportunity to further polish the animations and add a red ribbon on top of his helmet- for more secondary action.

The automatic purge of animation clips , which by default have no user assigned to them is a decisgn decision in blender that has plagued a lot of users before me.  Blender deletes animation clips by default when you close your file and it doesnt warn you. One must click on a small "F" button in order to tell blender not to delete the animation.
Since this terrible design has caused too many examples of data loss, I filed a bug report on the issue with the hope that developers will address it accordingly! For example Blender could warn you that it will delete a clip by color coding it and appending a "(wipe data)" message to its name or an asterisk symbol. I made a few mockups!
https://developer.blender.org/T43430#288111
While being at it, I also made a rant at blender artist about it and  suggested the Auto frame feature. One of the developers responded by making an implementation - to which I gave my feedback.


Rendering the sprite pipeline:


This project was a great way for me to test the latest version of my ADVANCED NPR SHADER -ver4 in a real production environment with a deadline. The shader gave the knight model a nice hand drawn style, which fits with the overall art direction of the game.
The cartoon line was achieved with the solidify modifier and another special outline shader.

Next on I had to set up the camera rig and the scenes. There are 3 scenes, which share a camera rig with 3 cameras- it was the only way to get blender to render a target from three different angles and give a conveniently rendered animation sequence for each action from three sides.




Painting the Tiling sprites for the Environment:



For the environment it was no brainer to use Krita. It has a feature that gives it a HUGE advantage over Photoshop - The wraparound (w) viewing mode  makes it very nice for painting tiling textures! Also the ability to clone layers, the numerous different brush engines and awesome interface. Krita is just wonderful.





Conclusions:

For this year's Game Jam event - I managed to meet most of my goals:
- The game we made was more ambitious and had much more graphics than the one from previous year!
- I used open source software for the entire pipeline! In the process I discovered bugs and design flaws, which were clearly voiced to the community and the developers of that software. I contributed back this way.
- I tested the Advanced NPR Shader -v4 in a real production environment with a sharp deadline. This shader will be made available some time in the future- along with a learning video course. It's one of my ongoing personal projects :)

In Other News: 
Gmic developers added a very useful feature that I suggested! This is exactly why I love open source software. Very often when you have an idea, the developer actually looks into it and if he likes it- BAM! It's right there a day after it was suggested:



The colorize filter is a great alternative to the traditional bucket fill tool. Give it a try. It's available in both Krita and Gimp.
-----------------------
Omake - some music I made with renoise in my free time:

Sunday, May 18, 2014

Advanced NPR Cell Shader ver 3 - and some thoughts on NPR lighting, and wishes for the BEER project


Ever since I released the Cell shader style material for Blender, there has been a rising number of people requesting from me to update it and continue developing it. I took some of your feedback and requests and managed to incorporate them in it. Admittedly there was also a huge break in which I kind of forgot about it as a whole, but some of you kept reminding me about it and I also kept remembering that I actually need to improve this material and add some features to it in order to continue production on SODA TRIP where the watercolory style is a must have.

So here it is! You can now download the cell shader - version 3 material from HERE:
Advanced Cell shader material version 3

Instructions how to use, some notes on new features and a wishlist to blender devs included in the video:

Advanced NPR Cell Shader 3 from todor imreorov on Vimeo.
The video contains some observations and ideas for b3d's npr renderer project- BEER.

New features:
- Watercolor effect!
- 2d screentones
- 2d gradients
- Receive shadows from external objects

- Textured mode and cells only mode
- Cell shading colorization
- Texture patches with multiply
- Spec bump pattern

-a much more modular and efficient node set up - under the hood.
The cell shader in completely modular - from version 2 and above! What's even better- it is much tidier. The matcap generator has become much tidier, easier to debug and extend. It is a part of the cell shader tools pipeline! This required a full redoing of node set ups from scratch.
Utility nodes (node groups) can be easily debugged, re-stacked and reused in different combinations and other shaders. These nodes are sort of like non destructive modifiers or effects.

Working on this cell shader allowed me to shape a number of concepts in my had as to how a potential NPR rendering engine would ideally work and what is currently missing in blender. You will hear some of these musings in the video anyway, but if you are too lazy to watch it- here is a summary:

Blender NPR BEER renderer ideas:
My wish for an ideal NPR shader is one that would allow me to use this sort of NPR effect modifiers on a per color-cell basis.
If freestyle has linesets, each of which has modifiers. A cell shader would have CELL sets, each of which would have cell shape/alpha modifiers (such as a watercolor effect, screentone effect and so on) and also cell color modifiers (such as 2d gradient, color patches, etc). 

Utility Nodes in version 3

Ideally a user would be able to set a cell set to receive shadows from isolated parts of itself and/or other objects. These geometry parts would be specifiable via a vertex group. So the user will be able to for example select only the nose to have a drop shadow, or only the chin to drop a shadow onto the neck. This is important for stylized shading. Just as important is also the ability to specify where you never want shadow to fall (example - the eyes) and where you never want  light to fall (example- inside the mouth). 
From there on it is kind of like the pipeline of my NPR cell shader material. Each cell goes through a number of modifiers that give the cell a specific style and flavor.
Once we get a greyscale render of all the cell sets, that information is then fed to the next stage of the process- THE COLOR STAGE.
In that stage we specify a texture or a vertex color layer as a base color. Then we can colorize the shading of each cell with a 2d gradient or a flat color- these things would ideally be keyframeable - so as to change them when the background is changed.
Additionally it would be nice to have the ability to have vertex based color patches that can also be keyframed, and also (tiling) texture patches. The option to operate on a cartoony character that is not UV unwrapped should be easily accessible.  

Then after all that is the Finessing stage.
In that stage you can add a rim light or a spec light- both of which can be made textury around the borders.

One of the design goals of this shader was to be flexible and to allow the artist to individually operate on elements. So it was important for me to separate cast shadows and normal based shadows - to be able to isolate and affect them with light and shadow masks; to be able to overlay color and texture patches, to affect the hue and saturation of cells; to be able to use 2d gradients and 2d screentones...

There are some other things on my wishlist, but these were and still are the big ones. There is more to be done to improve this shader, but there are also some annoying glsl bugs currently that trully discourage me from pushing it further to work on blender. 

Bugs encountered in blender:
However there are a couple of things in it that would break the glsl preview due to existing viewport limitations/bugs (as of 2.69)!

1. buffer shadows with "only shadow" option are pitch black in the glsl viewport. I filed a bug report for any developer interested in looking into it:
http://developer.blender.org/T37582

posted more about the limitation here:
http://blenderartists.org/forum/showthread.php?303682-Limitations-in-existing-Blender-features-you-would-like-to-see-resolved&p=2520945&viewfull=1#post2520945

2. For some reason using the screentones module (node group) or a 2d gradient (view/orco based vector) adds a white overlay on top of the material in glsl, but still works just fine as expected when rendering. It seems to be affecting the specular and rim light modules somehow.

3. Wishlist for Node groups in blender:
- A boolean switch (tick box) for 0/1 so we can have small switches instead of sliders when we want to enable/disable something.
- ability to expose drop down lists in the node group node- to select existing textures, vertex colors and other types of data. This would allow for a cleaner node material setup.

Wednesday, April 2, 2014

Image scripts - useful batch operations - image utilities - unpack gifs, mass resize images with a single click and other useful operations

I have been a linux user for more than 10 years now. There is a rant about it from a while ago.
Over the years, I had to use the terminal, had to edit config files, compile and package software. It was one of the "joys" of the platform.
So while I can't call myself an experienced programmer, I had to learn a little bit about scripting and debugging. Today if you are a Ubuntu user, you absolutely dont need to know anything about linux in order to use it happily. But Ubuntu and debian are such a drag. They might have all the packages and resources in the world, but they are no fun any more. I am a manjaro user myself, but these tricks should work for you on any distro that has the required utilities.

So without further adieu, in this nifty trick, I am going to show you how to configure the "Thunar" file manager to acquire basic image conversion and editing capabilities. If you are not a thunar user, there are alternatives to do this.

Unpack Gif action
What does it do: It lets you extract all the frames in an animated gif file and make a png image sequence out of them.


1. Open thunar. and then Edit-configure custom actions
2. In the dialog , click on the plus (+) icon to create a new one.
3. Call it "unpack gif" or whatever you like.
In the command box type this:

If you are wondering how it works, the convert operator is a part of "imagemagick" - an image processing library that most linux distros have. If you dont have it, jut install it. -coalesce is an option specific for gif animated files. %n  is explained in the custom actions editing window

4. In the "appearance conditions" tab, specify the conditions:

Dont forget to tick the "images" box only.
This will tell the "unpack gif" menu entry to appear in the right click menu only when a gif file has been selected.

5. Now save it and test it. Right click on an animated gif file and select "unpack gif" :)

We can now unpack animated gif files from the web!! If you are a programmer and you need some placeholder graphics for your game, this script is already very useful to you!
Most game engines do not accept gif files, and take png image sequences instead. You might of course also need a sprite sheet packer.

Now lets say that you are not happy with the size of the image sequence. You would like to shrink all of the selected png files by 50% or 100%. How do we do that without wasting 10 minutes of our lives?

Pack a Gif action
The drill is the same, only the command is slightly different:

This will create a looping animated gif out of all the png images in a directory where you execute the command. It will name the animated gif with the name of the frame you selected.

Resize PNG images action
This one is just like the previous, but it has a number of extra steps before adding the custom action. This time we are first going to create our own bash script to use as an operator.
0. Create an empty bash script file somewhere. Call it
"resizeImagesScript.sh"
Don't forget to make it an executable. And finally open it with your favorite text editor.
Then paste this:

Save it.

1. Open thunar. and then Edit-configure custom actions
2. In the dialog , click on the plus (+) icon to create a new one.
3. Call it "resize overwrite /2"
In the command box type this:

4. In the "appearance conditions" tab, specify the conditions:

Dont forget to tick the "images" box only.
This will tell the "resize overwrite /2" menu entry to appear in the right click menu only when an image file has been selected.

5. Now save it and test it. Right click on multiple image files and select "resize overwrite /2" :)

it should make all of the selected images 2 times smaller than their original size.

6.If you would like to alter this script or create more custom actions in thunar's right click menu, you absolutely can.
-The "50" in our example from step 3 is the new size in %. It is telling the script to shrink the images to 50% of their original size. If you would like to shrink images by smaller increments, you can try with 75 instead. This will make it 1.5x smaller instead of 2x.

-Alternatively you can make selected images bigger! If you use 150 in the command box, it will multiply the size by 1.5. If you use 200, it will make it double the original size.

-Also if you dont like that the script is overwriting the images, you can check out the last commented line in it.
Copy

and paste it in the place of

in the sixth line of code.

Now you can unpack any animated gif file into an image sequence. Then shrink or grow the size of the image sequence sprite. The beauty of this solution is that you dont have to open any software, then open files and waste time importing and exporting. All you do is right click on the file(s).

Finally if you are wondering, where do I find animated gif files to use as placeholder sprites in my game?
Let me give you a few hints. :P

Some more cheat codes:

Extract Alpha channel mask from PNG (useful for 3d artists)


Extract layers from SVG

and in the script:



Trim images by their alpha channel:

Via imagemagick. This is useful when you want to batch auto crop a lot of body part images for a 2d character rig that needs to be animated as a cutout animation in some game engine.

Create a picture Atlas from all the png images in the directory:

Useful when you want to pack all of your images into a single image file.

Note that all of these commands work on windows and mac as well - with some alteration in some cases.

Tuesday, January 28, 2014

Winning Game Jam plovdiv

This year we participated in the first global game jam event in my home town- Plovdiv.
"Team Chameleon" was formed out of 5 people: 2 programmers, one graphics guy (me) ,a musician, and a level designer.

You can play the game HERE in your browser.

And THIS is it's entry page- on the global game jam website.
Howto play the Demo:
Please note that the game doesnt have a loading screen yet, so you will need to wait a bit for the graphics to load from the web. 
The astronaut can see in one of the 4 different color spectrums. Hit spacebar to switch between them and make their platforms visible. Also note that seeing in a color spectrum also makes you SEEN by the monsters that exist in that spectrum. The goal is to get to the bunker! :) 



The game won us the industry game jam award- given to us by gameloft!
------------------------
Organisation

During the first day of the event, when the topic was revealed:
"We don't see what we see, we see what we are" (or something like that)
All I did was wonder around and try to get to know people in the room - find out what their take on the theme was and also to see if I can find some programmers. 

The initial idea of the game is that we, as human beings have a limited perceiving of the world - for our eyes can not see the complete spectrum of light. This idea came to be after a chat with a color blind guy, whom I met at the event (what are the odds).
After finding 2 excellent programmers, or more like them finding me- we got together at the table and had to come up with a game pitch in less than 30 minutes!

For this part the best thing for me to do was to allow for everyone to shoot ideas and on my part-write them all down on a piece of paper and compile the pitch. 

Some of the ideas were:
- Colored vs black and white
- Perceiving things in a wrong way (in different colors)
- Seeing only things in certain colors.
- Forcing the player to memorize where platforms are
- Point and click items in a room in a sequence - in order to proceed to the next room (puzzle)
- Platforming (voted on this - it's a popular genre that people understand)
- At the end of the brainstorming session I enforced on the team the need for antagonism. Memorizing platforms is not enough to keep the players on their toes. Thus enemies need to be hidden in every color spectrum.  

After the pitch was done, I got everyone on the team sit down together and flesh out the idea.  We were 4 people in the room -  having us all vote wouldn't have worked, so my involvement in this part was not to vote on ideas. Instead I sat outside the idea pool and acted as a mediator. I outlined our production plan on the white board -going through everything we need, see if everyone is on the same page and if not- let voting do the work. People brought up valid issues in the design and they voted on the best solutions - fleshing out the design. Would invincible platforms still act as platforms or not? Would invincible enemies continue to chase you while you don't see them? Is the outlined plan realistic for the 48 hours? What are our priorities- which features can be labeled as "extras"? What do the programmers need from me- the artist and from the rest of the team. What resolution would the game run in. How big is the sprite. And so on.

While one of the event organizers told me that we are wasting time with this planning, I still believe that one hour wasted on planning saved us from several hours wasted in arguing and headaches. I have been through this with other teams in the past and I knew what a recipe for little disasters looks like. It's when problems are brought up really late during production!
---------------------------------------
Workflow
First of all, game jam is an event in which a team has to make a game in 48 hours. Since I was the only graphics person in the entire team, I had to choose my battles wisely.


It started with an animation pencil test (done in pencil2d) - so i can give something to the programmers early on- for them to test with and also for me to get an idea about sprite size. This would later determine the line thickness of the final sprite and also the detail design.

Next on I looked for inspiration from "The forbidden Planet" and other b-movie posters from the silver screen era of awesomely cheesy 3d movies.
And thus drew the initial background- as tall as the game resolution and as wide as I my heart desired (then cropped it).   

Using Artrage- for it's natural media tools. Those helped me get closer to the poster vibe. Back in those days artists had no computers. I even faked some scratches on the paper and extra paper grain.

Having a BG tile lets me establish the overall color palette of the game - something that is a reference point when choosing colors for the player,platforms and enemy sprites - those need to stand out.

For the final sprite animations I used Toonboom studio. This allowed me to tweak colors and crispy line thickness. Finally- exporting to any size that my heart desires (or more like the programmers desire)- one of the greatest advantages of vectors.

Both the enemy and the player sprites are animated inside the same file- to save time and to have an easy way to compare them. The enemy design and coloring is inspired by a stylistic effect some pulp posters use - depicting it as a dark shadow with a detail defining neon rim light(s).
I managed to plan enough time for doing some 3 tone cell shading on the player sprite. The programmer required me to export both the player sprite and the enemy sprite in 4 different color mode versions. 




I know I could have done this as a cut out animation rather than inking all the frames. I chose to do it the proper way because setting up a cut out rig alone would have wasted that time anyway- the sprite animations are short so it wasn't worth it compromising their quality. If they were longer or the programmers needed it cut out for some procedural things- like armor swapping- then I would have had used "Spriter" instead of toonboom studio.

All this and much more was done in less than 48 hours!!!
Even managed to speedpaint a picture for the title screen during the last thirty minutes.

The title picture reuses the Planet graphic. There is the obvious mistake of having a different number of fingers. That index finger sure is crazy. But this is what generally happens after some sleep deprivation. :)

What didn't make the cut:
Our level designer kept insisting on having different backgrounds (suns) for each color mode. I resisted  because it complicates the core "hook" of perceiving colors and it is also creating more work for me.
He also insisted on having cut scene drawings to tell a comedic narrative. While this was welcome by me since his ideas on those are really entertaining- I decided not to do it because things with more priority were not finished. 
If we had more time I would have had the programmers change the font at the title screen, fixed the issues with my own half baked graphics, had insisted that platforms in the game are jump through type rather than solid, had insisted to place a different background for each level and a different music too (the musician made more than one tracks for the level) and many other things.
But this game is finished now and it's time to move on to better things. :)