View Profile Bcadren
Lucien Fatima @Bcadren

29, Male

Indie Developer

Joined on 12/19/13

Exp Points:
446 / 550
Exp Rank:
Vote Power:
4.89 votes
Global Rank:
B/P Bonus:

Recent Game Medals

20,760 Points

Free Will is Dead 10 Points

Give up the ability to think for yourself by naming yourself "ICRAVEFLESH".

Worse than Death 25 Points

Get the Bad Ending.

008 5 Points

Complete level 8

007 5 Points

Complete level 7

006 5 Points

Complete level 6

005 5 Points

Complete level 5

004 5 Points

Complete level 4

003 5 Points

Complete level 3

002 5 Points

Complete level 2

001 5 Points

Complete level 1

Latest News


So I started Ludum Dare last weekend worked the first day of it then gave up on getting done on time. I suppose I could have finished something VERY SHORT repetitive and arcady with the amount I had finished; but all I had was roughly 9 seconds of gameplay and the amount of time it took made me feel very disheartened about the idea of finishing it in the time frame.

I'm now looking at what I had done on the project and the full project idea and considering if it's worthwhile to finish or not.

First; what there is: Video. Preview

Basically the player will hit a half-pipe about 3 seconds after starting; have half a second in the air to pull a 180 [+/- 10 degrees] and land it (or else they wipe out); that's about it. 

What went wrong to cause that to take so much time?:

Though I'm trained in 3DS Max, I never really made the transition to Blender after I lost my 3DS Software License. I was trying to code 3D models and animations by hand. It works and I understand the math behind it well enough to do it; it's just slow and difficult compared to using the software. For example; that skateboard is this lovely piece of code: http://pastebin.com/wHhwVQwE

Writing the Triangles is particularly annoying; that long array of numbers is crucial to how the level is actually drawn. Notice also that the model doesn't really have any normals. I just called "mesh.RecalculateNormals();" to not give it complete crap; but default normals like that doesn't light anywhere near as well as good normals would. Since Unity uses normals by vert instead of normals by triangle trying to get the right angles would both be time consuming and require lots of vertex duplication; which I didn't have time to go through.

Anyways; though I could do that; making the skateboard animate correctly to not clip through the half-pipe [Which is literally defined with the equation y=0.5x^2 for a period of y=0 to y=1] was proving pretty impossible (especially since the position of the skateboard was controlled by one script and the rotation by another [out of necessity, unfortunately]). With fresh eyes it occurs to me that if I rendered the objects on seperate layers I could have more easily gotten 'close enough' and ran with that.

In short I wasn't really using the right tools and the method I'd rigged together was rather inefficient.

The rest of the game was more complicated physics and though it seemed simpler (except animations, perhaps) after all the issues I'd had up to that point I didn't feel like continuing to slog through it.

On the positive side:

  1. I think I've proven that I understand how to manually right a mesh well enough that I could feasibly write some fair procedural mesh generation for situations where it's more necessary (voxel systems; making Unity look like an old Sector shooter).
  2. The candy-stripping on the boxes was a bit of a happy accident. I couldn't make straight lines like the game the look was inspired by without duplicating vertices; which I didn't want to do. 
  3. The level reader works pretty well and was a pretty cool idea. LevelData is saved as an image (Red = Direction, Green = Tile type, Blue = Height, Alpha = Unused, probably enemies IF they needed to be seperate from Tile type [unlikely]) and reads into a 'tile' class for easy parsing. In retrospect the tile class is only for coder ease and unnecessary; could just as easily have only parsed through color data live without the middleman eating memory. It draws the first test level from this; but for a longer game I'd probably have to make an actual level editor; because manipulating that much data in GIMP is both inefficient and confusing.

So what's the actual idea:

In Short: Tile-based isometric platformer based around skateboarding.

  • Double-tap left/right to jump left/right by one lane.
  • Press and hold to turn the board left/right.
  • Up/Down to speed up/slow down; but no stopping.
  • Space causes jumps one arbitrary unit into the air.
  • Space again while in the air bounces on the board and hit anything below you (unconventional weapon).
  • Space over a grind rail to follow it.
  • Nativigate a deadly skatepark and dispatch all enemies that attack you.
  • Features include up/down slopes and twists. Swinging axes; firing turrets, which must be tricked into shooting themselves; crumbling platforms, etc.
  • You must dispatch all enemies to finish each level.
  • Up to 100 units of height variety. 
  • Multiple cameras. (Possibly; if the one camera view restricts level design too much.
  • Speed control necessary to get proper jump length.


Here are the notebook entries from this if anyone cares. It's mostly just the math and mesh notes I had to write down wile handcoding the meshes. 

Opinions on if I should finish this or not?

Latest Playlists

Bcadren doesn't have any playlists, and should go check out some amazing content on the site and start adding some!