Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1302332 Posts in 58047 Topics- by 49121 Members - Latest Member: tettsure

June 28, 2017, 02:30:08 pm

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsFeedbackDevLogsIRKALLA
Pages: 1 ... 20 21 [22] 23 24 ... 36
Print
Author Topic: IRKALLA  (Read 223306 times)
Sjonsson
Level 0
***


Multi-hatter. Level design get's the love.


View Profile WWW Email
« Reply #420 on: September 08, 2014, 07:01:25 am »

Just discovered this project, must say I love the environment I've seen so far!
Logged

Unity-chan is that ex that you'll never get over but on the same time will always regret.
Skydsgaard
Level 1
*



View Profile
« Reply #421 on: September 09, 2014, 06:13:50 am »

@Belimoth
@airman4
@Skippi
@keo


Thank youuu!!

@shpen Hi! Yep, it’s done manually. The workflow that I use is pretty similar to Glauber's in the video, but way more chaotic and disorganized. Also, you can see how clear he has the animation in his mind, barely changing one pixel after it has been placed.
For me, it’s more a kind of test-error workflow. And this insecurity makes me save a crazy amount of different files just in case that I end up in a place where there is no way out, and I have to go back and restart.
So at the end of the day, I have like 50 files named:
 
“mech_hit_01.psd”
“mech_hit_02.psd”
“mech_hit_03.psd”
“mech_hit_03_arm_01.psd”
“mech_hit_03_arm_02_ok.psd”
“mech_hit_03_arm_02_ok_foot_01.psd”
“mech_hit_03_arm_02_ok_foot_02.psd”
“mech_hit_03_arm_02_ok_foot_03_ok.psd”
“mech_hit_04_chest_01.psd”
“mech_hit_04_chest_02.psd”

and then I realize, fuck, the arm is wrong! And I go back to the “mech_hit_03.psd”. So, I keep pushing myself until I get it right. -You are crazy -Who says that?

Aniway, let me try to put all these frames in one single video, so you can more or less see the progress, I will try to do it this week. Just for you Smiley

@barneycumming <3 Smiley

@Scifa you will know Wink

@HyperDuckChris wow! Thanks a lot man, I'm also a big fan of your work for a long time :D welcome to the thread Smiley

@Jad @Reilly yeeeeeah, that is a super cool idea, we will make it. Maybe by code. And I was thinking about adding some dust trail to complete it. Thanks a lot dudes Smiley

@Sjonsson Thanks!
Logged

CasePortman
Level 1
*



View Profile Email
« Reply #422 on: September 09, 2014, 08:13:08 am »

Wow, those animations are glorious! I absolutely love the look of this game and somehow only just discovered this thread.
Fantastic stuff!!
Logged
shpen
Level 0
**


merp


View Profile WWW
« Reply #423 on: September 11, 2014, 11:19:04 am »

Aniway, let me try to put all these frames in one single video, so you can more or less see the progress, I will try to do it this week. Just for you Smiley

You're a saint.  Grin
Logged

Skydsgaard
Level 1
*



View Profile
« Reply #424 on: September 12, 2014, 11:56:50 am »

@CasePortman Thanks!!

You're a saint.  Grin

xD here you go Smiley
« Last Edit: September 12, 2014, 12:19:13 pm by Skydsgaard » Logged

shpen
Level 0
**


merp


View Profile WWW
« Reply #425 on: September 12, 2014, 12:35:56 pm »

@CasePortman Thanks!!

You're a saint.  Grin

xD here you go Smiley

Wow, seeing the progression and how many iterations you've done makes it even more impressive considering how seamless and fluid the end result is. How long would you say that took you to make?
Logged

Skydsgaard
Level 1
*



View Profile
« Reply #426 on: September 16, 2014, 11:27:12 am »

@shpen Thanks dude. It's difficult to say, I usually have several animations going on, and I work on this project mostly at night, after regular work and home duties, (so not my most productives hours) but I supoooose..10-15 hours? I dont know ^__^U
Logged

dhontecillas
Level 0
***


View Profile
« Reply #427 on: September 16, 2014, 04:30:45 pm »

Hey guys!

We think that perhaps you are interested to know how we put those guys from Photoshop into the game.

Skydsgaard uses the Animation Timeline in photoshop to draw every frame in a separate layer, he sets the times and builds the animation for that movement ( hey, being explained by a programmer it sounds  like it takes a few seconds to do that, uh ?  ).




At the beginning, he was exporting every frame to a .png, then loading it in the editor (I will probably write something about it another day), and once there he sett the frame times again for every frame. Doing that for lots of animation is a pretty boring and painful process,  so we've tried to improve that.

Looking for some plugin to do that stuff I've landed into this Retro Affect blog post: http://retroaffect.com/blog/132/Photoshop_Animation_to_Sprite_Sheet/#b . They have an script that exports every frame to .png. That seems to solve part of our problems but we have two handicaps:

1. losing the timing information for each frame
2. exporting only one image per frame

So after digging into the PS scripting documentation ( http://www.adobe.com/devnet/photoshop/scripting.html ) I didn't find any way to read the times from the timeline ( I could actually write them from the script but not read from them ). So the solution was finally to export to a .gif instead, and then use a Python script to read the gif, with its times, and export every frame to a .png ( that is what is actually using our 'editor' to handle the animations ).

At this point we are not needing any PS script, but we have to take into account that we have to "export for web" and set the appropiate settings in order to not get dithering into the final gif ( If you use the "simple" functions from the PS scripting language you will get dithering, but if you record the "export for the web" action using the tools provided by adobe, and then use that generated code for exporting the gif you will get clean images ).

But we still have a problem. We are not going to use only one image for each frame in all the animations. For some FX we are going to need different layers ( for example, when shooting, the main character  is going to get some parts lighted ). But we don't want to have to mantain two different PSD files for each layer. So we came with a naming convention for the layers, so we could use a script to export them all:

- Layers starting with: bg__
        Those are layers that Skydsgaard can use to test different backgrounds for the animation, and that won't be exported to any image
- Layers starting with:  ly1_, ly2_ ...
        Those are extra layers that will go to separate images for each frame
- The other layers:
        Those are the layers that would be interpreted as the 'main layer'

So, this way we ended with two scripts :
     - The PS script that exports to a .gif and a collection of .png with a different naming for each layer
     - The Python "importer" script , that reads the .gif to obtain the times, and reads the different .png that following a name convention we can know to what layer corresponds.

And now, for those who have read to this point... the code:
PS Script :
https://gist.github.com/dhontecillas/e3a4e943c49f2d9dd22d

Python snippet:
https://gist.github.com/dhontecillas/668f5bd103ba1e3fc6a4

Of course, anyone, feel free of doing whatever you want with the code, modify it, adapt it to your needs, whatever ... If you use it, and you feel grateful, you can always buy our game once its finished! Smiley

Well, a final couple of comments. From the python snippet you can infer the format used by the editor for the sprites. And the PS Script, if you use the format : [spritename]__[componentname]__[movementname], the python interpreter will use it to build the structure of the json file ( this is how we separate the sprite information in our tools ).


Hope you like it ! Tongue
Logged
maxl
Level 2
**



View Profile WWW Email
« Reply #428 on: September 16, 2014, 04:38:13 pm »

Good read! Smiley

I cannot stress enough how important it is to have a good workflow going for the graphical assets (and any other assets as well). Being able to iterate fast and going from changing something in the source (PSD in this case) to seeing its results in-game quickly is soooooo important. Glad you've found a workflow that works for you! Smiley
Logged

Currently:


Released games: Nubs' Adventure | Rico
Reilly
Level 2
**


14/f/tx


View Profile WWW Email
« Reply #429 on: September 17, 2014, 06:38:54 am »

You guys might want to look into PS Layer Comps, could be a little closer to what you're looking for?
Logged

dhontecillas
Level 0
***


View Profile
« Reply #430 on: September 18, 2014, 12:23:41 pm »

@maxi Thanks! We would like to get a good "improvements/effort" ratio with the tools. And that was a pretty boring/time consuming process.

@Reilly I had a look at PS Layer Comps, but I don't know how to improve the process using them (take into account that I'm not a PS power user).

For now, we removed an acceptable amount of pain when exporting the frame layers, but I would love to hear any suggestions to improve it. ( Although I won't be able to implement them at the moment, because I moved to programming other stuff ).
Logged
cvasquez
Level 0
**


View Profile WWW Email
« Reply #431 on: September 18, 2014, 12:44:29 pm »

Someone might have asked this already, but why are you using a 3D version of the mech? Are you using that as a reference to animate the pixel version?
Logged

Twitter: @3xchris
Howard Day
Level 1
*


Huge fan of spaceships and exposions.


View Profile WWW Email
« Reply #432 on: September 18, 2014, 01:09:26 pm »

cvasquez: They aren't. That was *only* fan art by me. Sorry for the confusion!
Logged

Main Art guy on Wings of St Nazaire, here's our Devlog, and my Personal Website. SPACESHIP!
cvasquez
Level 0
**


View Profile WWW Email
« Reply #433 on: September 19, 2014, 10:52:16 pm »

No need to apologize, seriously awesome stuff you had going there!
Logged

Twitter: @3xchris
DuckfaceNinja
Level 0
*


Ninja


View Profile
« Reply #434 on: September 20, 2014, 07:16:12 am »

What an admiring animation stuff you have there...  Cool
Would love to see those mecha in serious action  Well, hello there!
Logged
dhontecillas
Level 0
***


View Profile
« Reply #435 on: October 05, 2014, 08:47:14 am »

Hi again!

Today I will tell you about...
Our Pixel Rules
 
This topic is more related to the visual art style, or art direction, and probably you would expect to hear about this from Skydsgaard. But, before I start,.. the disclaimer :

The rules or constraints we are going to state are art decisions took for Irkalla, and this doesn't mean that we think that all pixel art games should follow them, nor that not following them gives worse results, or that there should be any kind of dogma when working with pixel art. (And, actually, we reserve our right to change our mind in the future about any of them! XD ).

One of the good parts working with Skydsgaard is that he has a very clear idea of what he wants ( that is also a curse, when I have something that is not exactly how he wants, or something is off by one pixel Smiley.

So, from the very begining he gave some rules for the game:
     - No pixel rotation: no sprite would be rotated, yielding "square pixels" that are not "axis aligned". (From the programming point of view, that is like making the code simpler, so .. yay! I am very happy  with this rule Smiley
     - Ability to have fx ( post process, and posibly other procedural stuff ): Well, that is going to be more work. But, at the end, I enjoy programming .. so, welcome rule ! ).
     - No pixel blurred at edges: This means perfect scaling (every pixel must fit into the bounds of screen pixel). So, although this appears to be a simple rule, there are some things to take into account.

So, we expect to release our game on PC / Mac / Linux and PSVita. That means, that although nowadays most people have HD monitors 1920x1080 ( 16:9 ), we can not rely on that for our game. ( Actually I do not have such a screen res, I have a 1280 x 800, and a 1680 x 1050, both of them of 8:5 ratio ).  This image is a cool reference of screen resolutions : http://en.wikipedia.org/wiki/Display_resolution#mediaviewer/File:Vector_Video_Standards8.svg

Also, we have to take into account that we want to play it on TV, so we must take into account the "overscan" ( http://en.wikipedia.org/wiki/Overscan ) when choosing a "base resolution" to work with.

So, lets find the "optimal" screen resolution ( http://en.wikipedia.org/wiki/Overscan#Overscan_amounts ), using arount 85% of a 1920x1080 , what yields a 1632 x 918, and we want the pixels to be 3x at that resolution, sooooo .. we end up with a "base resolution" of  544x306 pixels !!

So, here are our "ideal" resolutions : 544x306 at x1, 1088x612 at x2, 1632x918 at x3, ... but, a decision remains : What happens when we the screen are bigger than that one of those resolutions ?

(for the following images, all coloured parts are the level beeing displayed, and the dark blue is the part corresponding to the 'base resolution')

First option: have that part of the screen, in black. Not cool. Not at all .. imagine my 1280x800 screen, would fit the x2 scaled version: 1088x612 , that means 192 lines of black pixels vertically, and 188 horizontal.
This is how it would look in a 1920x1080 screen :



Second option: select the scale based on the base resolution, but fill the entire screen with the level.
Then, in our reference HD screen this would look like this :


 This is an option, but that would mean that somebody could get more information on one level only because it has a bigger screen .. Imagine a screen with a resolution of 1080x1920 (weird? well, think about putting an hd screen in vertical ! )

 
That resolution would select the 544x306 pixels resolution, because the 1088x612 doesn't fit by width. So, imagine, the player using this configuration would see a "6 times the base resolution high, and almost 2 times the base resolution width".


If we expect the level to be equally fair for all players, this is not an option.

If we go back to the first option, that would look like this :



Third option: The mix! have a "Level Design Resolution". That means allowing the camera to display a constant multiplier of the base resolution. This would limit the advantage a player can have by having a different screen resolution. But it still yields a challenge when designing levels, as we will have a "base resolution" and a "level design resolution".

We'll need to take into a account that differences between these two resolutions must not led to any advantage. So, the narrower that difference is , the easier will be to have the level balanced ( or beeing fair to all players ).

So, we ended up with the third option with a x1.5 ratio... that means :
- 544x306 up to 816x549 at x1 scale
- 1088x612 up to 1632x918 at x2 scale
- 1632x918 up to 2448x1377 at x3 scale and so one..

And in the vertical orientation it would look something like:


I think this is a good compromise. I could code some kind of script to calculate the size of "black bars" that can result on the most common screen resolutions.

As always, if someone has any suggestions to improve the amount of used screen space without penalizing the "balance", I would be very keen to know about them.

Logged
SunWuKong
Level 3
***


Help me, help you.


View Profile WWW
« Reply #436 on: October 05, 2014, 11:18:57 am »

So, from the very begining he gave some rules for the game:
     - No pixel rotation: no sprite would be rotated, yielding "square pixels" that are not "axis aligned". (From the programming point of view, that is like making the code simpler, so .. yay! I am very happy  with this rule Smiley
     - Ability to have fx ( post process, and posibly other procedural stuff ): Well, that is going to be more work. But, at the end, I enjoy programming .. so, welcome rule ! ).
     - No pixel blurred at edges: This means perfect scaling (every pixel must fit into the bounds of screen pixel). So, although this appears to be a simple rule, there are some things to take into account.

Very interesting stuff!

Your screen resolution answers sounds similar to what we are doing.

We took into account the game resolution and the fact we wanted square pixels. Since we also wanted perfect scaling we allow only even multipliers of the base game resolution. Any extra space is filled with black bars and/or the game screen itself is scaled to fill up the monitor or TV space. It was (for us) the best solution short of having this extra large game space that would be cut and cropped according to the users settings and resolution.

Great post and Best,

-Tim
Logged

dhontecillas
Level 0
***


View Profile
« Reply #437 on: October 07, 2014, 01:22:51 am »

From the programming point of view, it wouldn't be too difficult to have a switch in the options menu saying: "use full screen although the artist would be sad for edges beeing blurred" , only in cases we don't cover all the screen  XD . Perhaps is too long. I guess that at the end we could about it.. but first I would make the calcs for the most common resolutions to see where we would end with screen not beeing completely used.

I will try to find some kind of statistics about screen resolutions. Does anyone know where I could get that ?
Logged
Netsu
Level 10
*****


proficient at just chillin'


View Profile WWW
« Reply #438 on: October 07, 2014, 02:01:32 am »

I usually look here: http://www.w3schools.com/browsers/browsers_display.asp
You can also click on the 'other high' link to see a further breakdown: http://www.w3schools.com/browsers/browsers_resolution_higher.asp
Logged

dhontecillas
Level 0
***


View Profile
« Reply #439 on: October 07, 2014, 10:20:36 am »

@Netsu Thanks for the links! I was using them, when someone point me to this Steam hardware survey : http://store.steampowered.com/hwsurvey
And by clicking on the "Primary Screen Resolution" I could see what Steam users have. However, those stats are probably "hardcore gamers"-biased (lots of HD screens!). And taking into account web users is more "real".

Anyway, having those stats is pretty cool Smiley
Logged
Pages: 1 ... 20 21 [22] 23 24 ... 36
Print
Jump to:  

Theme orange-lt created by panic