00:00
00:00
Bcadren
Lucien Fatima @Bcadren

Age 32, Male

Indie Developer

Joined on 12/19/13

Level:
8
Exp Points:
654 / 710
Exp Rank:
99,103
Vote Power:
5.04 votes
Rank:
Civilian
Global Rank:
> 100,000
Blams:
0
Saves:
6
B/P Bonus:
0%
Whistle:
Normal
Medals:
1,649

Altering these settings may filter what you see.

Latest Art

Latest Audio

Subscribe to RSS Feed

Recent Game Medals

29,800 Points

Frig Off! 50 Points

Launch a frigate ship

All Guns Blazing 100 Points

Launch a cruiser ship

Wow! 8 Billion Is A Lot! 100 Points

Complete the game

Mouse Breaker 100 Points

Click 10,000 times

Bomb's Away! 25 Points

Launch a bomber ship

The Gang's All Here 100 Points

Have 15 ships of each class at launched at once

Let's Get Ready To Rumble! 10 Points

Launch a fighter ship

Scouter Launched! 5 Points

Launch a scout ship

Dungeoneer 100 Points

Achieve the goal steps for each level.

Picnic Time 50 Points

Clear the dungeon and retrieve your sandwich.

Latest News

More

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.
Longer: 

  • 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.

Notebooks:

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?