Posts Tagged ‘3d unity’

I’m in

Posted by
Saturday, April 22nd, 2017 4:23 am

It my first Ludum Dare experience

wish me luck!

Running solo for the 48 hours creating all the art, audio and code myself.

I am a full time 3D Graphic Artist for a games studio in Australia but recently in the last two months I have picked up teaching myself C# and Java for Unity.

The lead up for the game Jam has given me a goal to learn code fast in my spare hours , just in time for Ludum Dare 38

Art Software available:


3Ds Max


Substance Painter

Substance Designer

Photoshop CC

Procreate (Ipad Pro)

Game Engine: Unity 5

Language: C#

Editor: Visual Studio 2015

Music: GarageBand


Give me some tips to improve my modelling, rigging, and animation time. It took me 3-4 hours to make this character and only with walk animation. The hardest part is the rigging and animation it took me about an hour or two. Would you give me tips or hints on how to make 3d models faster and better.


Also, in the future I would like to make 3d models like in Street fighter or tekken in which they have animations for grabbing or attacking the other 3d models. Any beginner or intermediate tutorials you can give me?

Streaming Game Dev for Beyond Infinity!

Posted by
Monday, January 2nd, 2017 12:18 am

Hey guys i’m streaming development for the game i’m working on Beyond Infinity. If anyone’s up for some David Bowie and Unity dev  you can watch here:


Stream Link


FUNRiDE! Play With Your Friends!

Sunday, December 25th, 2016 7:43 am


They’re all tough,
They’re all determined,
But there’s only –one room– in this arena (which is also one room ;D)
Animals from all over the world have gathered together to decide
which animal is the ultimate ride and the best survivor?

Pick your animal, choose the way you control it and start the entertaining fight!
You can play against bots, or your friends (on the same keyboard)!


Round1-optimized by HealTheIll

Set Characters:

Charactersgif by HealTheIll

Pick the animal you believe the most (there are 17 so far!)

*all models were designed in MagicaVoxel and it was our first time using it, it’s a great software! you should check it out!

you can also pick a name, choose whether a bot plays it or a human and how you want to control it.


After everything is set, you’re ready to go!

gather as much speed as you can and push your foes away!

the fastest animal will push farther,

*hint : you can also use the fence to bounce yourself and gather even more speed!


1) Boot with wings – speed up
2) Cake – shrinks your character
3) Blue Potion – grows your character
4) Red/Blue Capsule – let you pass through objects

Have fun! and don’t forget, there’s only one room in this arena! and it better be yours!



>Tom – Unity programmer
>Rom – Character Designer
>Artur – General Designer
>Assaf – Music

We must say, that we really had too many unpredictable occurrences,
therefore we couldn’t work full time on the game
yet, we’re pretty satisfied with the final result,
especially because it’s our first time trying Unity and going 3D
(All our previous games were developed in Gamer Maker engine)

Hopefully you’ll like what we came up with :)

Oh and, it’s very recommended to play with your friends since the bots aren’t that smart atm ^-^”

Plans for the future:

Better Graphics – particles, lots of effects, better GUI

More POWERUPS – we already have some in mind, but if you feel creative and have an awesome powerup let us know and we might add it +credit to you

Better AI – Tom is researching machine learning (using generation Neat algorithm) and it’s going pretty well, in worse case, we’ll try to program better one ourselves

Maybe More Arenas – we already thought about some other unique arenas such as an arena made of trampolines but we’ll see

Network Game – play against your friends online!

Mobile Version – we might think about a mobile version, but there’s still time until we get to that…

if you have any other ideas that you think will improve the game please let us know and have a big credit if we accept them!


Non Euclidean Room – Postmortem

Posted by
Friday, December 23rd, 2016 1:33 pm

For Ludum dare 37, I worked on a game about wandering around a strangely connected room. The idea obviously come from the works of Escher on “impossible” geometries. The connection with the theme is to have only one big room, but using portals to make it interesting to visit.
You can play and rate the game here :

At first I wanted to have puzzles, like pointing lasers to open doors. You would use portals to change gravity and walk on the ceiling. I also wanted to have markers for the player to place around and help you navigate the room. In the end, I only had time for portals and a simple room, with a couple of interesting visual tricks. The scope is smaller, but by focusing on smooth portal transition, level design and polishing, the game ended up pretty well.
Here is timelapse recorded during the creation of “Non Euclidean Room” :

Portals :
Making portal feel simple but a lot of things can go wrong. At first I simply wanted to plug a copy of the room at each door and teleport everything around. That can work but it limit what you can do a lot. You cant have two doors close to each other. Basically you can only have doors on the external faces of the room.
Then the next technique is to use a render texture to produce a view from the portal exit with a second camera. An object will use that texture to display it on the main camera.
Here is the code (in Unity C#) I use to place the portal camera according to the main camera and transforms from Enter and Exit portals :

Quaternion Rot180 = Quaternion.Euler(0, 180.0f, 0);
Vector3 LocalPos = EnterPortal.transform.InverseTransformPoint( MainCamera.transform.position);
Vector3 RotatedPos = Rot180 * LocalPos;
PortalCamera.transform.position = ExitPortal.transform.TransformPoint( RotatedPos);
PortalCamera.transform.rotation = ExitPortal.transform.rotation * Rot180 * Quaternion.Inverse(EnterPortal .transform.rotation) * MainCamera.transform.rotation;

You use the main camera location in the local space of the entering portal, you pretend it’s a local position in the exiting portal and get it’s world location to place the portal camera. The rotation by 180 degrees is there because the exiting portal face opposite to the entering portal. You do the same on the rotation of the camera.

Portal camera location

This technique can certainly work, but will need a render texture per door. So I tried something else.
I used only two cameras, and the stencil buffer. The idea is to first mark (in stencil buffer) the portal pixels on the screen by drawing them from the main camera point of view. Then draw the scene through the portal, by placing the camera at the correct position, and using the stencil as a mask. Then rendering the usual camera above that, without overriding the portal door.
For the player motion himself, I just teleport the player when he pass the middle point of a portal to the relative location in the second portal.

Portal Anatomie

A second trick that I needed is to use a clip plane along the portal door. You want only objects from beyond the portal to be visible. For that, you can use an oblique projection matrix. This technique create a near clip plane in an arbitrary orientation by distorting the camera projection matrix. There is some downside though, as some visual glitch can appear when the camera is near the clip plane. If you stop in the middle of a portal, you can sometimes see the screen edge disappear. Another idea, that I didn’t have time to test, is to send the clip plane to the shader, and use the instruction “clip” to discard pixels that are on the wrong side. That way, no need for a custom projection matrix.

Oblique projection matrix

After having that first version working, there was only one visual glitch when going through a portal. You could not see a portal trough another portal. That was very obvious when walking through a portal : every other portal will pop into existence. To fix that, I needed to display portal through portal, at least for the nearest portal from the camera.
The idea is to use the stencil bit masks to read and write two separate portal indexes. That way I could tag a door, and a door inside a door. This did limit the portal count to only 15, as there is only 4 bits left in the stencil buffer for each index. But this was enough for the small game I had in mind for Ludum Dare. I could also take the nearest 15 portals from the camera, but it was already time to start the level design so I limited myself to 15 total. You may notice that there is 16 doors in the game. In fact the final door that let you leave is not a portal, it’s a regular door. The portal transition is smooth enough that you don’t notice. Since the LD, I improved the tech quite a bit in a post-compo version.

Visual style :
I decided quite early on the visual style I wanted for the game. The reference to Escher’s work is obvious : black and white with thick lines and a shading made by changing line density. I choose a style a bit more sketchy and, of course, animated. The strokes are placed on the screen and move with the camera. The animation is there to hide that fact. I blend 3 layers of strokes, and 3 times per second, each one have a chance to pan and rotate. This give an unpredictable animation. Some people found the effect a bit too disturbing after a while. I want to revisit it later.

The second part of the visual effect is the edge lines. The issue with portals, is that I render everything in “forward” so I don’t have a “normal buffer” to run my edge detection on. I don’t have a proper “depth buffer” either because of the way I render portals. So, I needed to use only the color buffer to make my edge detection. To detect normals, I simply render the absolute value of the pixel normal in the color buffer, modulated by the lighting intensity. So to have the luminosity of a pixel, I can use the value of the color (average of red, green and blue). And I can use offsets in hue to detect edges by sampling a pixel to the right and a pixel to the bottom of the current pixel.
I also wanted to detect depth discontinuities, so I had the idea to modulate the pixel color by the depth, making some sort of fog. Surfaces with the same normal but at different distances will then have a slightly different colors, and could be detected by the edge filter. The fog gave a moody atmosphere to the scene but I liked it. To complete the look, I added a Gaussian bloom filter, to give some gradient to the flat blue interactive objects.

Scenes from the game :
– Penrose infinite stairs

– Twin scenes through portals

– Falling through an empty space

Future post-compo version :
As much as I like the game as it is, a simple exploration game where you make your own path, I wanted to do more. In the beginning, I wanted to change orientation when you go through portals, letting walk on walls and ceiling. But I used the Unity Controller. And that controller cannot be rotated around freely. The collision capsule is fixed on the Z axis. So I did with that constraint. But now I started to extend the game in a Post-Compo version. The idea is to make a second room and exploiting everything I couldn’t in the base game.
– Infinite recursive portals :

– Proper puzzle with blocks (and laser later) + walking on walls :

I hope to complete that second room in early January 2017, with interesting puzzles and a longer playtime.

FDP corp present “Piece of meat”

Saturday, December 10th, 2016 7:13 pm

Hello everybody ! We are proud to be here one more time ! We are also proud to show you our work !


LD37 One Room :

FDP corp present “Piece of Meat” our second project under the ludum dare banner. We try to plan a puzzle tactical game around the industry theme with a lot of humour and fun. The game exploit a satiric view of our future.
Likes the first time we will try to finish it for the deadline.


Our team :


Jalibter as Main Dev

Dannou as Main Graphist

Bob as Graphist
JeanTapas as Compositor
MonsieurDuc as something usefull like a BOSS


Our consultant and helpers

Plexus as Dev and logic
Gribouille as Marketing and Event
Holyengine as Graphist


You can check our works there :


We working with :

We working on those software

Unity 5.4
adobe suite
fruity loops

Feel free to ask your questions on our stream.



Piece of Meat the story :


In 2099 the growth of the human race became uncontrollable.
Overpopulation has become the biggest threat.
Humanity under the enlightened guidance of the FDP corp, has surrendered.
You play as a young factory manager, with one dream, change the world.

Your first mission will be to make a cheap and useful production system.


Some tease :


Story tease :





All the staff hope you enjoy it ! leave a comment if you want we will answer !
Streams are ONLINE ! you could check our work in progress.


First updates! (Mouse in da house)

Saturday, December 10th, 2016 5:03 pm

Hi everyone! We are Ethereal Psyche Games from Spain and it’s our first jam here as a team.

We were working all day (we still have all night long here) and this is our progress with our main character. Hope you liket it!


(As soon as we have polished the levels we will show you the gameplay along the night).



One Room and no game yet!

Posted by
Friday, December 9th, 2016 11:50 pm


OK I have a room built furnished and in Unity but no game so far!

Nice poster thought!

Friday, August 5th, 2016 10:50 am

Hey, Ludum Dare!


We create game-ready Art. Over one thousand #developers use our assets now!

We organize specially discounts for LD36 on Cubebrush. All products have a discount of 60%
Check out store on Cubebrush (.unitypackage + source files)

Discount code: Ludum-dare-august

Also, check our Unity AssetStore (Only .unitypackage)

Box scr_01Boxscr_03

ShiftyBalls Postmortem

Posted by (twitter: @aaghgames)
Saturday, April 30th, 2016 9:01 pm

Here is our ShiftyBalls postmortem. It’s a little on the long side, but we hope that you enjoy it. If you want to try our game, ShiftyBalls, you can do so right here. Thank you, by the way, to everyone who has rated ShiftyBalls and provided feedback!

Day One:

When the theme was announced at 9 PM Friday night, Floata (our musician/level designer) immediately suggested an exploration/treasure hunting game where the player had to shift elemental form to survive hazards. Sounded straight forward enough, so off we went. I (Budaniel) do the programming and art, and shortly after we got the movement in, I moved on to try and create a humanoid avatar. The issue is that I’m primarily a 2D artist, and our game was going to be 3D. The resulting 3D model wasn’t bad. The rigging and animation, on the other hand, became the stuff of nightmares.


So, with that horror set aside, I made what was intended to be a temporary avatar – a smiling red ball. We liked it enough, though, to keep it and build the rest of the game around it. We added ice-, fire- and rock-based forms and tied them into the game play: ice freezes water, fire is fast but dies in water, and rock can survive trips through lava. At this point I forwarded Floata the game and he built our first level.


The level, once completed worked well as a tutorial to introduce the basic mechanics to the player. The hardest part, surprisingly, was getting the block to rise out of the lava. For whatever reason, we fought that one piece for almost an hour. We could have worked around it, we could have removed it, we could have come back later, but nope – we had to finish it right now, darn it. We did eventually finish it so we could move on with a clear conscience.

We eventually finished up laying out level one and half of level two before day one drew to a close Saturday night. Our vision was coming together, and we still had 48 hours before the deadline.


Day Two:

I began day two by working on key graphics. Specifically, I made the key for unlocking the gate in the levels. For all my desire to learn 3D graphics, I’m still not really there, so thankfully a key isn’t too hard to make.


Once that was completed we moved to complete the design on level one (we’d left the end point unfinished earlier). Floata wanted the level to finish on a sailing ship, but I failed at making a serviceable sailing ship, so that ship sailed and we went a simpler route. It was about this time that I noticed a bug in our player movement.

Apparently I had set the player to detect as being on the ground if their vertical velocity was less than zero. What that meant was that as long as the player was falling they could jump again, resulting in the ability to bounce through the air. How on earth we got this far without noticing that is beyond me, but it was quickly fixed – fun as it was, it kind of ruined any challenge the game had.


Taking a break from level design, work began on the title screen, which meant we needed a name for the game. After some deliberation we settled on ShiftyBalls. It may be kind of juvenile, but we’re ok with that. While I was posting a progress post on the Ludum Dare site, the tagline of the game came to me like an epiphany.


With that out of the way we went to work on level three. Working as a team over Skype went well and the level came together in no time. We had originally intended for this to be a large, multi-path level but we pared it back down after a discussion as to its relationship in scale to the rest of the game.

We had been discussing up this point adding indicators for the various forms and a timer of sorts, so when better than now to add them? I toyed with various styles and settled on an seriously boring “colored circle with a number in it” look after failing at multiple flashier variations. Looking back, I wish I’d used pics of the ball in its various forms for the buttons, but I am not a very smart person sometimes.

The timer turned out to be the biggest headache so far, as tying it to the forms and their transformations turns out to be a little harder than I’d expected. The problem was as simple as me misunderstanding how to use a single line of code (InvokeRepeating, to be exact), but it delayed progress for over an hour. That led into the evening, and the end of day two.

Day Three:

Most everything we’d aimed for was in the game now. We had three levels (more is always better, but we liked the three we had) so day three was bug-fixing and graphics-polishing day. The first order of business was doing away with the gray boxes that had stood in for textures throughout the game. Originally intended to look like tiled flooring, the way it got stretched all over the place gave it a really chintzy, low-res look. We opted to go for a simple two-piece approach, with a darker body of the surfaces with a shiny, lighter top surface. While this meant I basically had to go back and double up every single surface in the game, the results (combined with a starfield skybox) were a positive step.


We tested the hell out of it in the morning, but one issue stuck out: the ice kept blinking back to water for a half second while you were freezing it. This began a small odyssey that nearly derailed the entire project.

I told Floata I would fix the issue, and then sat down on my own to do just that. I figured it would take 30 minutes, tops, but in trying to isolate the problem, I broke the freezing mechanic entirely. We were only about 6 hours until deadline and I had just destroyed a core part of our game. I tried to put it back together, but in doing so, it didn’t work anymore. Panic and stress began to set in, knowing that I had to find and fix the problem right now. Here’s a small rundown of the events as it went all wrong.

  1. The water stopped freezing on contact
  2. The water froze on contact, but then immediately unfroze
  3. The water started as ice and became water instead of vice versa
  4. The water froze as soon as I turned to ice, even if I wasn’t touching it
  5. The water froze but never unfroze
  6. The water turned to ice but didn’t become solid
  7. The water rapidly blinked frozen/unfrozen

None of these were ideal. It took me probably two hours or so, but not only did I get it working again (the issued turned out to be three different, conflicting scripts all trying to do the same thing), I also fixed the original issue in the process. Hooray for success! I’m glad that I fixed it and I didn’t have to be guilty of ruining our game at the last minute.

With deadline rapidly approaching, we ran the game through its paces a few more times and finally posted it, and now its fate is in the hands of you fine people for judgement.

ShiftyBalls Wrapup

Posted by (twitter: @aaghgames)
Friday, April 22nd, 2016 3:05 pm

I’m Budaniel from AAGH Games, and I wanted to post a quick look at ShiftyBalls and what went well, plus what didn’t. I have written a long postmortem for some other time, so for right now let’s just focus on the positives and negatives from our experience in Ludum Dare 35.

What went well:

  • The controls turned out better than planned. We originally had tank-style controls, which (as you’d imagine) did not feel intuitive and were unnecessarily difficult.
  • The way the elements interact came off pretty much as intended, with each having their usefulness.
  • We did pretty well on time. We were wrapped up on mechanics (for the most part) by Saturday afternoon and by Monday it was just bug-fixing.

What went not-so-well:

  • The art could have been so much better. I’m still learning as a 3D artist and my attempts to make a decent animated, humanoid main character fell flat, leading to the ball we have now.
  • We could have explained the elements a little better instead of just dropping the player into a level with all three at once. For example, we’ve heard that the Fire element should survive lava like the rock does, but in this case you’re not a fireball – you’re on fire, and that’s why you’re running faster (because it hurts).
  • We could have used more  sound effects. We often struggle to nail this element in a Ludum Dare, but this time I felt their absence to more than usual.
  • The new web version seems to be giving some people issues, which I don’t think we can fix at this time.
  • I nearly broke everything on Monday afternoon. I was trying to fix one small bug with the ice and broke that mechanic completely, resulting in a few hours of trying to fix the game.

That’s all for now. Thanks to everyone who’s tried ShiftyBalls, and to those that haven’t, give it a shot and leave us a comment – we love feedback!


Done…..Monster Of All Trades

Posted by (twitter: @cynicalmonkey)
Sunday, August 23rd, 2015 4:12 pm

Compo Entry finished, kept it simple (2 kids and a Game Jam do not make light work) but it as my own work (if without sound) Its a 1 player card game where you play through a story deck of cards and use your own deck to overcome different encounters using the 3 tools at any monsters disposal, being scary, being spooky or being cuddly. Didn’t get to blog much about the progress so added some art below.  In the end weren’t we all monsters……


Soccer Cow: our #LDJAM Submission

Posted by (twitter: @jenninexus)
Tuesday, April 21st, 2015 11:01 pm

Hi friends!  After an intense game jam weekend packed with excitement, we were able to submit Soccer Cows just in time!

MartianGames did all the programming and we collaborated with my 3D-cow-modeling skills to make this Unconventional Weapon-themed experience.  I’m glad we teamed up because he’s teaching me to code & I’m still a novice :-) but I’m loving the opportunity to expand my skills and learn from an experienced developer.  The community has been really fun to meet & explore and I’ve appreciated the creative encouragement!  Looking forward to future jams & getting better all the time.

Shadow aka | GameJolt | Twitch

Jenni: Twitch | GameJolt | Facebook


That’s not our first entry yet we made the beginners’ mistake. We planned too many features. So many we can’t budge them anymore. We’re not sure if we should publish the game as it is, so that’s what we have now.


+ clients can connect

+ players can move
+ client can pick a weapon
+ client positions are synchronized
+ client animations are synchronized

+ Player
+ 3 Weapon models
+ 2 Ammo models
+ ~20 C# Scripts
+ ~10 Textures
+ ~15 Models
+ 1 Arena + 2 Development scenes
+ 14 sounds
+ 60 git commits

– client can shoot but it not synced on server
– rigidbodies are weird
– no UI in game
– only 1 weapon implemented
– poor position sync algorithm, clients lags
– no gameplay at all
– …

Something we learned:

1. It’s a bad idea to make a multiplayer shooter based on ropes interaction in three days. Pretty obvious
2. It’s not a simple task to sync objects while changing scenes in Unity
3. Syncing 3D physics in Unity is just too hard to understand for a human being
4. Listening to a new team member (who wants to make a 3D and then just gives up) is not a good idea either

So that’s it. We couldn’t finish it, but would be pretty happy to hear your opinion. Do you want us to publish the game as it is?

Work keeps being interrupted

Posted by
Sunday, April 19th, 2015 4:07 pm

Hey! We just want to keep working but this little guy just wanted to bite visit us lol don’t be scared he’s a friend <333



I’m in

Posted by
Thursday, April 9th, 2015 11:51 am

Im in for my 5th time


Engine: Unity 5

Ide: notepad++

2d art: gimp 2.8 and

3d art: blender 3d or maya

Motivation: Spotify

[cache: storing page]