• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

GAF Indie Game Development Thread 2: High Res Work for Low Res Pay

Status
Not open for further replies.

LordRaptor

Member
Thanks for advice you guys, I'm not too familiar with modelling and texturing, so I wasn't entirely sure of the terms to search for - looking for doing "decals" in blender and unity were returning very different results for what I wanted to do

However, using a custom shader you can overlay a texture over another without duplicating the mesh. You just designate both textures to use separate UV layers.

Maybe this will help, it came up when I googled "unity lerp material"
http://docs.unity3d.com/ScriptReference/Material.Lerp.html

Hmm, I hadn't considered that... I assume that's the technique used for things like making objects be affected by weather, by slowly increasing a snow or rain texture over an environment texture - I've used material.lerp before, but on an emissive to do a beacon 'ping'.

If its an 'old school' technique thats valid, I'm fine with staying old school - just means tried and tested in my book XD

Two separate textures mean two materials, which mean two draw calls, and there's no getting out of that AFAIK if you want to do things that way.

Basically, I think you've got to choose between more materials and draw calls or increased texture space, and I'd suggest that you go for wholesale texture swaps since the way you're handling your face "decal" means you'd be using a transparent shader, and those are pretty expensive (on mobile, at the very least), on top of resulting in all sorts of sorting errors if you don't handle things just right with your materials and shaders.

I haven't played with the new Unity 5.4 beta yet, but I was under the impression that the newly added GPU mesh instancing allows multiple versions of the same mesh + same material for 'free' as one draw call per material, in which case I might be better off future proofing a small hit now for a big gain down the line....?

I'm thinking I might prefer to use a single reference material shared between instantiated objects and modified by script, than to have multiple pre-baked textures / prefabs and managing those.
 
Hmm, I hadn't considered that... I assume that's the technique used for things like making objects be affected by weather, by slowly increasing a snow or rain texture over an environment texture - I've used material.lerp before, but on an emissive to do a beacon 'ping'.
Yup, lerp is often used to animate the blending of two different textures, by using time or a sine wave as the alpha input. But you don't actually have to animate the lerp. If you make the "alpha" value static/constant, it will mix two textures together permanently instead. :)

If its an 'old school' technique thats valid, I'm fine with staying old school - just means tried and tested in my book XD
I agree. My game actually uses the technique extensively. Most of the characters with eyes or mouths use a slightly offset plane floating above their skin.

I do use the Lerp method for some environmental things in the game (like animating skyboxes - it can be used to create a night/day transition, among other things), but for characters I find it's cheaper/faster to just use the floating mesh with transparency, instead of creating a custom shader to blend them all together.

Although transparency materials are technically more expensive than opaque ones, I think that only becomes an issue if you have tons of models doing it at a time, or if you're on mobile. My game is for PC and doesn't have a lot of characters on screen at a time - the most you'll see is 2 or 3 at a time. It's a non-issue in my case.
 
Would anyone here befit from using Spriter? I realized I had a spare steam code (I backed the kickstarter and realize I don't need the extra code) and would love to give it to anyone who would put it to use.

No lurkers or anything, just regular posters in this thread.

EDIT: Gone!

hope it helps
 
New gameplay video from Light Fairytale showcasing the first battles.

Please check it out and tell me what do you think about it!

youtube.com/watch?v=htn8U_765yQ

That's looking adorable. You're colour palette and graphics style reminds me a bit of Dreamcast-era games (somehow I thought it looked like a visually better successor of the Evolution games). It has that nostalgic charm, also with the soft focus and the soundtrack. It's WIP so I do not know how much you plan to change - personally, I feel the zoomed-in view works better for the battles (zoomed out, the spiders are difficult to identify for example), but the overview look could be something optional to get a better understanding of enemy placement in potential more complex battles?
 
New gameplay video from Light Fairytale showcasing the first battles.

Please check it out and tell me what do you think about it!

youtube.com/watch?v=htn8U_765yQ

Really good start.

I'd look at considering where the eye has to move during battles. Specifically, the name of the attacker and attack being at the top of the screen, whereas the damage numbers are in the middle, over the character being attacked. It's sort of tiring to follow.

I think it would be worth considering making the name of the move appear above the attacking character as opposed to the top of the screen (and without the fancy box). This would keep the players eyes focused on the characters themselves and not having to read the attacker and move at the top and then dart down to the characters to see damage before it disappears.

Also, I'd not show any text at all unless it was a special attack or magical spell. When it's the basic/default attack, it just seems to be an unnecessary distraction.

Lastly, consider putting a border around the damage numbers (a white stroke, for instance) to help them pop out. It was occasionally difficult to see the numbers clearly because it was a muted red on a muted brown background/character.

All of that said, it looks really cool :D
 

Lautaro

Member
I finally have my first mech for one of my dream projects. It has a humanoid rig which makes easy to find animations but sadly most of them are too.. "human-like" for a mech, too much breathing and moving. Also the shoulder bones are messing with the mech shoulder armor as you can see in this gif:

pzWvHR9.gif


This one is a heavily modified (by me) version of a mech made by a freelancer, I was planning to hire him to make more but I think I have enough Blender skills to try at using it as a base. I know basic modelling and unwrapping so maybe I can be like Noogy and deal with art and code at the same time. I just hope I can avoid animating too, that seems like a PITA.
 
I finally have my first mech for one of my dream projects. It has a humanoid rig which makes easy to find animations but sadly most of them are too.. "human-like" for a mech, too much breathing and moving. Also the shoulder bones are messing with the mech shoulder armor as you can see in this gif:

pzWvHR9.gif


This one is a heavily modified (by me) version of a mech made by a freelancer, I was planning to hire him to make more but I think I have enough Blender skills to try at using it as a base. I know basic modelling and unwrapping so maybe I can be like Noogy and deal with art and code at the same time. I just hope I can avoid animating too, that seems like a PITA.

Nice.
 

neko.works

Member
That's looking adorable. You're colour palette and graphics style reminds me a bit of Dreamcast-era games (somehow I thought it looked like a visually better successor of the Evolution games). It has that nostalgic charm, also with the soft focus and the soundtrack. It's WIP so I do not know how much you plan to change - personally, I feel the zoomed-in view works better for the battles (zoomed out, the spiders are difficult to identify for example), but the overview look could be something optional to get a better understanding of enemy placement in potential more complex battles?

Thanks!

The zoomed-out view is not used when the player enter his commands, so I don't think visibility is a major problem here.

Really good start.

I'd look at considering where the eye has to move during battles. Specifically, the name of the attacker and attack being at the top of the screen, whereas the damage numbers are in the middle, over the character being attacked. It's sort of tiring to follow.

I think it would be worth considering making the name of the move appear above the attacking character as opposed to the top of the screen (and without the fancy box). This would keep the players eyes focused on the characters themselves and not having to read the attacker and move at the top and then dart down to the characters to see damage before it disappears.

Also, I'd not show any text at all unless it was a special attack or magical spell. When it's the basic/default attack, it just seems to be an unnecessary distraction.

Lastly, consider putting a border around the damage numbers (a white stroke, for instance) to help them pop out. It was occasionally difficult to see the numbers clearly because it was a muted red on a muted brown background/character.

All of that said, it looks really cool :D

Thanks for these ideas! I'll see what I can do.
 

Minamu

Member
Is Unity clever enough to understand that if I code music and sound volumes to have certain pitches and audio level mixes so they fit well, would a music volume meter from 0-100 take my mixes into account? I'm about to embark on a coding journey and make an options menu with Canvas for basic stuff like audio volume (and on/off), etc.

For example, let's say I hard code my background music to be at 80% volume, but if I then change the volume setting in options to 100%, would that mean 100% or 80%, you know? :)
 
Is Unity clever enough to understand that if I code music and sound volumes to have certain pitches and audio level mixes so they fit well, would a music volume meter from 0-100 take my mixes into account?

If you set your mixer channels properly and assign audio sources to the correct channels, yeah it works like you'd expect. Master volume affects everything and individual channels can be used to tweak the proportions. Snapshots are handy for muting.
 

Minamu

Member
If you set your mixer channels properly and assign audio sources to the correct channels, yeah it works like you'd expect. Master volume affects everything and individual channels can be used to tweak the proportions. Snapshots are handy for muting.
Great, then I'll look for some tutorials tomorrow :D
 
I just want to clarify that this is awesome! Cool stuff all the way down, man!

Thanks :) Much appreciated!

Since I really like game manuals and feel they should get some more love, I've decided to create a fake-manual for the Gunkatana demo. Also, this will serve as a nice printout for game pub nights and similiar events as well as a neat short overview about some bullet points of the game. It's still a bit WIP, I might change some details or finetune some stuff/correct typos (there will always be typos, that's an unbroken rule for everything where you have to hit a "publish" button even after several typo hunting sessions), add more pages when we grow in content and game modes...



edit.: Ahh this is a bit big.. I made it smaller for the forum. Sorry for inconveniences! For full resolution sharp and readable version click here!
 

JulianImp

Member
I haven't played with the new Unity 5.4 beta yet, but I was under the impression that the newly added GPU mesh instancing allows multiple versions of the same mesh + same material for 'free' as one draw call per material, in which case I might be better off future proofing a small hit now for a big gain down the line....?

I'm thinking I might prefer to use a single reference material shared between instantiated objects and modified by script, than to have multiple pre-baked textures / prefabs and managing those.

I wouldn't rely on 5.4 features though, because Unity's notorious for breaking lots of things with their latest updates. I'd recommend sticking to their stable releases and only upgrading for testing purposes.

I've thought up an algorithm you could try and see if it works:
  • Single model (no face "decal" mesh required)
  • Shader takes two textures: face features (with transparency) and everything else
  • Both textures use the same UV maps, and the face "decal" is mapped exactly the same way as the face
  • Shader draws the body texture first, and then blends the face texture on top of it
  • To animate the face, you'd swap the secondary texture
Of course all this means the face texture would have lots of empty space and that'd add up over time, but doing things this way would solve two big issues. First, you won't have to use transparent materials (the bane of mobile and the zbuffer) since the body will always be opaque and the shader will merely overlay the face on top of it; and second, you won't even need a separate mesh for the face, saving some triangles/vertexes. As a bonus, you'll have standalone face textures, but still only one per texture. I think you might be able to do a face atlas and change the face UVs programmatically, but then again I haven't been writing shaders all that much so I don't know how you'd be able to manage a single set of UV coordinates with two textures that'd actually require different UVs.
 
Bleh, took all day today (Monday) but animated all my frames for the player character. I'll probably add a few more attacks, but all his basic animations are done (there's way more than what's in the gif as well). Pretty proud of myself to be honest :D

oaDqxI5.gif
 
I've finally realised how stupid I am with my graphics.

Three years ago when I started development as a dinky demo my game looked like this.


Today it looks like this.


I haven't changed a single thing about the graphics. They were so mathematically simple that I considered it impossible to improve. When I received negative feedback I blamed it on the art style; not my implementation of it. I debated many times about switching art styles but eventually decided against it. Instead I programmed optional visuals into the game just like how in Halo Anniversary players can toggle between original and remake graphics. It's a cool feature to have in the game, but all this time I've missed the obvious "just improve the art style itself!"



Not sure what triggered it, but the other day I finally understood this. So now I'm re-imagining VizionEck's graphics. Currently I'm thinking of trying something like this.


Still needs some work on the colored lines themselves to make them more physical feeling. The real time reflections will be a pain but with my low polycount it should at least be doable.
 

correojon

Member
^^ It looks very cool, reminds me of the emergency lights of the Metro of Madrid:
Alumbrado-de-emergencia-2.jpg

(This second one isn´t from there, but it popped up in Google and I think it´s pretty cool):
alumbrado-salida-emergencia-sumidelec.jpg


Maybe these images can give you some ideas.
 

anteevy

Member
Not sure what triggered it, but the other day I finally understood this. So now I'm re-imagining VizionEck's graphics. Currently I'm thinking of trying something like this.



Still needs some work on the colored lines themselves to make them more physical feeling. The real time reflections will be a pain but with my low polycount it should at least be doable.
Looks way better with the reflections. Maybe you could play around with the colors and make them easier to view, i.e. not as extreme as they are now.
 
I'm using a new game design document template and I'm not sure what the part about abstract classes and components is asking. Is it referring to how objects react to each other in the environment? The derived classes part also has me confused. I'm writing for a JRPG and I feel like I need to change these parts to fit, because I don't see how they're relevant to my game.
 

JeffG

Member
I'm using a new game design document template and I'm not sure what the part about abstract classes and components is asking. Is it referring to how objects react to each other in the environment? The derived classes part also has me confused. I'm writing for a JRPG and I feel like I need to change these parts to fit, because I don't see how they're relevant to my game.

Its purely the technological implementation of the software. Its the section of the document that describes how the software is structured. Do some reading on Object orientated programming if you want more gory details.

If you are unsure about it...skip it for now. When you start writing code it might make more sense


Example

Abstract class

Generic Item,

It has weight, Value and can be consumed.

Derived Class based on Items. Could be Potions, Scrolls....etc

When potions get consumed...health goes up.
When scrolls get consumed...a spell is used. (or maybe a skill level goes up)


That kind of thing
 

Minamu

Member
I'm using a new game design document template and I'm not sure what the part about abstract classes and components is asking. Is it referring to how objects react to each other in the environment? The derived classes part also has me confused. I'm writing for a JRPG and I feel like I need to change these parts to fit, because I don't see how they're relevant to my game.
I haven't checked the link but it sounds like it wants your coding structure, maybe in uml/xml diagram form.
 

RollingTorque

Neo Member
http://tracingcolors.com/

Tracing Colors Trailer on Youtube

Tracing Colors is puzzle jump and run game in development for mobile.
There is a prototyp Version to download from the website.

The Target Platform is Mobile.
The Windows Version is more for testing convenience.

Like i said, this is an prototyp Build to get some opinions, to see if people like it.
So if you should test it, please tell me what you think of it.

If someone is testing it on an android device.
First off, thank you. and second, could you tell me your fps.
There is and button in the pause menu to show it.

tracing_colors_trailer_01.jpg


tracing_colors_trailer_02.jpg


tracing_colors_trailer_03.jpg
 
^^ It looks very cool, reminds me of the emergency lights of the Metro of Madrid:
Alumbrado-de-emergencia-2.jpg

(This second one isn´t from there, but it popped up in Google and I think it´s pretty cool):
alumbrado-salida-emergencia-sumidelec.jpg


Maybe these images can give you some ideas.

Thanks!

Looks way better with the reflections. Maybe you could play around with the colors and make them easier to view, i.e. not as extreme as they are now.

It's important to keep the colors strong for gameplay purposes, but they do need something. I'll try sinking them slightly into the surfaces and give a glow.
 

Jumplion

Member
I've finally realised how stupid I am with my graphics.

Three years ago when I started development as a dinky demo my game looked like this.



Today it looks like this.



I haven't changed a single thing about the graphics. They were so mathematically simple that I considered it impossible to improve. When I received negative feedback I blamed it on the art style; not my implementation of it. I debated many times about switching art styles but eventually decided against it. Instead I programmed optional visuals into the game just like how in Halo Anniversary players can toggle between original and remake graphics. It's a cool feature to have in the game, but all this time I've missed the obvious "just improve the art style itself!"



Not sure what triggered it, but the other day I finally understood this. So now I'm re-imagining VizionEck's graphics. Currently I'm thinking of trying something like this.



Still needs some work on the colored lines themselves to make them more physical feeling. The real time reflections will be a pain but with my low polycount it should at least be doable.

Love that reflective style. Kind of makes me want to go back to my mobile game and utilize some of those reflective techniques, it really makes the rest of the scene pop.
 
Its purely the technological implementation of the software. Its the section of the document that describes how the software is structured. Do some reading on Object orientated programming if you want more gory details.

If you are unsure about it...skip it for now. When you start writing code it might make more sense


Example

Abstract class

Generic Item,

It has weight, Value and can be consumed.

Derived Class based on Items. Could be Potions, Scrolls....etc

When potions get consumed...health goes up.
When scrolls get consumed...a spell is used. (or maybe a skill level goes up)


That kind of thing

I haven't checked the link but it sounds like it wants your coding structure, maybe in uml/xml diagram form.
I might have to omit it. I never got coding down beyond a very basic level over the years. I think I might be able to write something for Derived Class if it's just describing what items and spells do. Would I need to do each individual item or spell? Or is that too much information and I just need a few examples to show to others?
 

DNAbro

Member
I might have to omit it. I never got coding down beyond a very basic level over the years. I think I might be able to write something for Derived Class if it's just describing what items and spells do. Would I need to do each individual item or spell? Or is that too much information and I just need a few examples to show to others?

Depending on how you derive something, you might need a class for each individual item. For example you can have a class called HealingPotion that takes in a number and depending on that number, it heals you by that amount. Or you could have multiple classes like SuperPotion, HyperPotion that each have a set number of how much you can heal.

It can be debated on which is better, I say if it has different functionalities such as healing HP versus Mana, make it it's own class.

I hope this is what you are asking and I didn't make it confusing.
 

JeffG

Member
I might have to omit it. I never got coding down beyond a very basic level over the years. I think I might be able to write something for Derived Class if it's just describing what items and spells do. Would I need to do each individual item or spell? Or is that too much information and I just need a few examples to show to others?

If you are not writing the code, then documenting the "things" and their actions/consequences is a good start.

I wouldn't go into details about items/spells until other stuff is done. (Mind you...if you have already decided, then fine, document it.) But I wouldn't get boiled down in details if big gaping holes exist in other parts.

But it really depends on how you work to create the game. I am coding/designing at the same time. Every once in a while I end up having to refactor a whole bunch of code. (Code tends to reflect the clarity of vision of the solution. If you are unsure how or what you want done, the code tends to be kinda crappy. lol)
 

Noogy

Member
Man, after wrapping up a difficult update for iOS and an IndieBox announcement I am SO ready to jump back into Unity and fiddle with actual game development.
 
Ugh, I'm trying to do something that feels like it's trickier than it should be and it's driving me nuts. Doing procedural mesh stuff in the Unity editor and managing it is pretty annoying.
 

missile

Member
Man, after wrapping up a difficult update for iOS and an IndieBox announcement I am SO ready to jump back into Unity and fiddle with actual game development.
Cool. I'm eagerly awaiting new art stuff of yours!


On the another news;
I made some further progress towards my wave-propagator I told about recently,
yet I still don't know if it will ever work as expected. xD I also made some
further progress towards my hardcore 3d retro graphics expedition. I'm currently
working on a small experimental retrolyzed rasterizer for not being restricted
too much by standard rasterizing schemes, initially, such that I can test my
ideas all out, because it seems that the rasterizer and the wave-propagator can
profit from each other when combined in special ways. Will see.

Considering 3d retro graphics, in the past days I've cracked down the RGB color
cube multiple times and applied some dithering techniques. I can now assign
arbitrary bit-resolution to the RGB cube with any dithering techniques filling
in the gaps. Next to the standard dithering techniques, I'm trying to compute
some blue noise dither patterns (not by using Floyd Steinberger (don't like
it)) and see how they perform regarding retro 3d graphics. Another dithering
techniques I'm currently working on is a (stationary) random dither technique
where the image is fully random dithered but only the moving parts in the scene
get random dithered anew -- in such a way that their new random pattern won't
produce any visible pattern with the stationary pattern right next to it. I
can't remember having seen such a technique in the past for realtime 3d
graphics despite random dithering was used alot esp. on still images or static
3d graphics. Problem is, for realtime 3d graphics/animations random dithering
produces heavy flickering on the screen which certainly was the reason why it
wasn't used for realtime 3d graphics back in the days (Bayer and some specifics
NTSC/PAL-aware patterns (with the dots a little more dispersed) where used
almost always).

Anyhow, cracking down the RGB cube is nice, because you can, after some setup,
simply cast your 24-bit color into an, for example, 8-bit color table, doing
realtime color quantization on-the-fly, which is nice, but it won't produce
this specific old-school 3d retro look. One more step is necessary. Even if you
quantize down like crazy and dither the hell out of it, the image won't look
good. The best thing you will get is CGA-EGA-VGA 3d graphics rendered out of an
RGB color cube, which looks ok if you have at least three shades per channel
producing 27 colors. But two shades, i.e. 8 colors, won't really work any
longer. An artist will draw/render a much better pictures given these 8 or 16
colors, even considering 3d graphics. Hence, the solution is hand-picking the
colors and shades (hence, no RGB cube) and dither with those, which should
give better results than using a low-bit RGB color cube. However, there is a
disadvantage. By fixing the palette this way you'll fix the light's color,
which isn't the case for the RGB cube, but which is ok if you just want to have
one color for light. But I can imagine a techniques to relight the scene with a
different color composed out of the very same palette building a pseudo-RGB
cube. Some further studies are necessary. So why using the RGB cube at all
then? Well, it's nice to have and you can perform all your computations in
24-bit/float color format under the hood. Hence, your standard RGB renderer
doesn't need to change in this case.

Hopefully at the end of the week I will have some derezzed madness ready for
your spoiled eyes. xD


Edit:
Another issue is anti-aliasing. Doing it in RGB is nice, but if you quantize
down afterwards, then all these fines shades were computed for nothing. Seems
that anti-aliasing needs to be done in palette mode as well using only the
existing shades which either remain after quantization or are part of the fixed
palette to begin with, if possible at all given the colors and shades
distribution. Hmmm ... an interesting topic to look into.
 
We've made some improvements to our Crewman character for Bomber Crew. Trying to bring back the charm & immediateness of our earlier prototypes, but in 3D:
tumblr_o6mkdkj4rP1vok9lho1_400.gif


at the day job right now, so not able to take a screenshot with them in the context of the game- but I will later!
 

Minamu

Member
I might have to omit it. I never got coding down beyond a very basic level over the years. I think I might be able to write something for Derived Class if it's just describing what items and spells do. Would I need to do each individual item or spell? Or is that too much information and I just need a few examples to show to others?
Who are you doing the document for? At first I thought it was just a fun experiment to try for you, but maybe I misunderstood?

If you have a team you're writing for, and you have very little programming experience, I don't think anything beyond a basic description of how all parts of the game works together is needed. It's probably better to let the programmers decide how they want to structure their C++ files and inheritance levels etc. Write what you know for sure and maybe write what you think they want and then just show it to them and see if they understand or have any input on what to change, and let them modify it to suit their purpose better :) Chances are that they have a ton of ideas right off the bat when you explain the game idea on how to structure their classes, and in my experience it's better to trust them to do their job properly.
 
Sweet! Hopefully you guys will even surpass the 2d version! :+
When will there be a demo or something?

Not sure yet- maybe in a month or two? We both have full time (also game development) jobs, and we're just doing Bomber Crew some weekends & evenings- so it's fairly slow going sometimes!
 

KOCMOHABT

Member
Didn't post here for a while, so here it goes

Finally went ahead and implemented muzzle flashes for the guns. Tobias, the artist, suggested trying geometry and I think it looks good :) (note that the muzzfleflashes are scaled 2x for the gif)
qRDR4Wa.gif


kwuLeGe.png


Apart from that we have some new models as well. A drone/quadcopter and the first import of high quality terrain meshes with normal maps and sorts. I think it looks good :)

It will be an alternate armament for a car - instead of having a basic rifle, a gattling gun, rocket/torpedo launcher etc. the car will have a drone operator and some drones to deploy.

The idea is to have some "Area of Effect" modifier for a set time, very much like a mage.

With different drones you can buff certain areas, for example:

  • a smaller / different version could help make repairs on the cars mid-fight.
  • they could give better vision and help make more precise shots.
  • a smaller / different version could help make repairs on the cars mid-fight.
  • they are equipped with some light firearms to lay down some fire.
  • they can shoot enemy rockets/torpedos/other projectiles

Now I don't want to go too far into "wait this is just an classic mage/knight/goblin/elf rpg with cars!", but I thought, since the game is supposed to be played a bit like a mix of RPG and RTS, I needed some more interesting abilities that would make sense in an AOE context.

If you can think of other stuff that could work, please share!
 

LordRaptor

Member
I wouldn't rely on 5.4 features though, because Unity's notorious for breaking lots of things with their latest updates. I'd recommend sticking to their stable releases and only upgrading for testing purposes.

GPU mesh instancing has been on the cards for a loooooong time, so I'm not worried about using it immediately, but I'd like to be able to when they roll it into their stable releases

For your other suggestions, I'll do some experimenting and see whether Im happy soaking performance hits or not, thanks

Apart from that we have some new models as well. A drone/quadcopter and the first import of high quality terrain meshes with normal maps and sorts. I think it looks good :)

With meshes like that, I think the rpeeating sand texture you use for the floor works much better with your current aesthetic than the faux-low poly squares one did, although given your screens don't use that anymore I guess you came to the same conclusion
 

Razlo

Member
We've made some improvements to our Crewman character for Bomber Crew. Trying to bring back the charm & immediateness of our earlier prototypes, but in 3D:
tumblr_o6mkdkj4rP1vok9lho1_400.gif


at the day job right now, so not able to take a screenshot with them in the context of the game- but I will later!

Like the combination of polygons and pixels there. Unique style!
 
Status
Not open for further replies.
Top Bottom