NoshBar's Dumping Ground

Just a terrible tiny video update showing the latest features added to C.R.A.P:

  • Different car handling types
  • Portals to different levels/areas
  • Buildings and meshes now go transparent when you're behind them
  • Jumping out of moving/flying cars
  • Pedestrian(s) following A* paths
  • Abusing aforementioned pedestrians so they are no longer capable of following their destiny

[ view entry ] permalink print article

Go home A*, you're drunk.

The figure on the right is what A* looks like when it's working properly.
The figure on the left is what A* looks like when it's been bludgeoned over the head with a dead racoon whilst intoxicated.

As shown by the different colours in the level editor shot (right), parts of tiles are marked as either:

  • unwalkable (red)
  • walkable (yellow)
  • preferred (green)

This means that while a pedestrian CAN walk across a road, they shouldn't always use roads to walk on when there's a (theoretically) safer place to do so: the pavement/sidewalk all y'all.
In order to get this right I simply make unwalkable surfaces an obstacle as usual, but allocate a heigher weighting-scale to the walkable areas than the weight-scale of a preferred tile area.
When I say "weight-scale", I mean that the weight a tile is normally assigned (say 10 for horizontal/vertical movement, 14 for diagonal movement) is multiplied by the scale assigned to the tile area.
open tile.H = distance from end * movement weight * tile area scale

Of course, if you mess that up a little bit ("obstacles? oh, you mean *10000 scale factor right? overflows? no, not heard of them, why?"), you get the image on the left. I don't claim to know why it ended up doing what it was doing, but it found its way eventually, and might come in handy for drunk pedestrians.
Not that they'd ever make it that far without being hit by a car, muh har har!

Oh, the square texture on the level shows the granularity of the path-finding.
It also turns out that it makes it easier to get a sense of perspective with it on, so I may keep it.

Navigation Meshes.

Recast is a lovely looking tool. It takes 3D geometry and calculates walkable areas depending on a large, large variety of factors.
Recast does not have awesome documentation.
Recast only comes with one demo code sample, an incredibly scary looking project with many complicated GUI things that -as someone just looking for how it works- I don't care about.
Where is my "hello world, walk over me" example? Eeee!

So instead of, you know, having patience and doing things "the right way" and figuring it all out, I simply implemented OBJ export in my level editor.
10 minutes later and I had this lovely test up and running using a build of the aforementioned scary-looking-project:

It all looked peachier than James and his giant produce, until I started looking closer.
No matter what settings I used, I could not get the mesh to produce a walkway between two buildings that are far enough apart for a tiny block to walk through.

Not only that though, I don't know how I would differentiate between "walkable" and "preferred" areas. It just generates one large polygon for the pavements and street, which is not really what I want.

That all said, this is by no means a fault of Recast. This is all just me being stupid.
I went back to the scary GUI project and found a single file that you can basically see how everything works, and it's not toooo bad.
But for right now, I'm just too keen to prototype to mess around with this too much.

[ view entry ] permalink print article

It all started with a level editor...

Well, that's a lie, it started through experimenting with the A* Path Finding algorithm in the hope of eventually making a car driven by an intelligent entity.

2 weeks ago I decided to restart work on this project, and it went something a little like this...

Step 1 - Edit, Edd and Eddy.

"Hmm, I like the idea of tiles, and Tiled is great, I wonder how I could automagically convert the 2D into 3D... wait a minute, I'll make my own!"

*sigh*, why does it seem like a good idea every, single, time?

Level editors, they're visual things.
People like me, they're impatient things.
Quickest possible way to get something visual up and running that I know of? Delphi. *sigh*. I guess I have a weak spot for the special.

Seeing as I stopped producing gold eggs a long time ago, I downloaded the latest version of Lazarus and within an hour I had something usable.

As you can (hopefully) see above, the map is made entirely out of 3D tiles. Each tile is made out of an arbitrary amount of blocks, each one building on top of the previous one, height-wise.
While the "user interface" is a bit rubbish (having to manually enter values), changes are visible throughout the map as you make them.
Placing them on the map is as simple as using the arrow keys to move around the map and hitting space to place the current tile (page up/down cycles between the available tiles).

For non-block shapes, you can import OBJ files and litter the landscape with instances of them. What's nice is that they automatically snap to the height of the tallest block in the currently highlighted tile, making placement really easy.
You can, of course, adjust them on a per-pixel basis.

It's around this time that I start thinking about integrating Lua into the editor, so that you can make plugins for loading/saving and tools... but instead decide to test whether everything works on Linux unchanged.

Huzzah! It does! Nice work FreePascal/Lazarus people!

Step 2 - Level Viewer

I knew that the only way I would ever see something from my work would be to throw my "good programmer" hat out the window into busy traffic during a heavy-agriculture-machinery trade show day.

With the joy of a thousand rabbid skunks I hacked away at some code and had a "level viewer" in no time at all and I had finally found an excuse to investigate and use SDL2.

Seeing as I had a map you could move around and view from any angle, I thought it would be a pity if I just left it there...

Step 3 - Physics

... so I took the opportunity to investigate the Bullet physics engine.
The first thing I learnt about it was how horribly overcrowded the supplied examples are, and how sparse the online documentation is.

That aside, I did manage to get things up and running quickly enough to have the tiles in the level converted to static physical bodies that my new little blocky player character could run and jump on.

Adding a car was a bit tricky, the settings are a bovine to get right, and they still need some serious tweaking, but -hey-, I didn't have to code the physics engine, so I can't really complain, can I?

There's also a patch I have to make for vertex index array collision shapes, so hooray, I get to contribute!

Step 4 - Lowest of the low

I always try aim for possibly the most underpowered device still around in wide-circulation: the last thing I want is to make something that no one can use.

So I stuck to fixed-pipeline OpenGL. Despite being slower on modern devices and not really supported on mobile devices, the GLES1 on Android seems to be okay with what I've done:

While it's still my most favourite achievement to date, it really does look pretty damn awful, and I think it could really do with some shadows...

Time to learn about shaders and friends.

[ view entry ] permalink print article

LÏKE is like LÖVE 0.8, but watered-down and less awesome.
LÏKE is an implementation of a subset of LÖVE features.
LÏKE does have some extensions though, such as live-reloading of assets and scripts and a touch API for touchscreens.
LÏKE is a minimal framework you can use to make 2D games in Lua.
LÏKE works on Windows, Mac OS X, Linux, Android, iOS, QNX (PlayBook) and WebOS.
LÏKE is a self-contained single executable less than 500Kb in size, written in C from scratch using OpenGL, Lua 5.2, PortAudio and the Chipmunk Physics engine.

I made my first game, jmp:err, using LÖVE. The experience of learning Lua and a new framework in a day was great.
Some things about LÖVE annoyed me though, the lack of proper ports to other platforms, the font API and I had disagreements, etc.

So, as things always go, I thought I'd make my own version the next weekend as a challenge, using the API in a "black-box" type approach.
After two days of crazily bad coding, I got my game running in my own version of the engine, exciting!

The main goal was just to get my game running on Android, but with the groundwork basically done, I figured I would keep on working on it.
I decided to port my bridge tutorial to Lua in an effort to learn "classes" in Lua and get a grips with the physics engine.
One thing lead to another and BAM, LÏKE was born.

See what's currently implemented by visiting the LÏKE page via the link on the sidebar.
Downloads for all platforms to be put up once I get my PC at home running again.

[ view entry ] permalink print article


I touched my first computer at age 16. I almost made a game immediately.
I almost made a game every month of every year for the next 16 years.
There's only so much self-respect you can lose until you just have to prove that you're capable of finishing something.

The time had come where I asked my life for 8 hours of uninterrupted codery goodness, and this is how it went...

(DOWNLOADS are at the bottom)

The game idea:

Something simple that can be finished in 8 hours.
Something that has few actions performable by the player.
Something that can easily have randomly generated levels.
Those infinite jumping games are popular, they only have tilt left and right, they also use the only physics/maths I understand, velocity.
I hate infinite running/jumping games, no sense of accomplishment.
Make a jumping game with a defined set of levels and each level must have a finishing point/goal.
For some reason, people like competing, so make the levels timed.

The engine:

I've looked at many frameworks in the past few years, I've also ALMOST finished quite a few myself.
The LÖVE framework seemed to have a simple enough API to get a grips with, and even though I'm not that familiar with Lua, it didn't seem like it would take long to learn.
10 minutes of messing around with the engine and its examples and I was sold. For prototyping, it was gold.
And if worse came to worst, I could always write my own lightweight framework for all the platforms, and oh hey, I just recently put the Lua engine into Tweenimator to see if I could, I wonder if... NO, FOCUS!

The editor:

Sublime Text setup with a LÖVE "build" command.
Tools->Build System->New Build System
"selector": "main.lua",
"cmd": ["F:/apps/LOVE/love", "$file_path"]

I also used the Lick addition for LÖVE so that every time I saved changes to my code, the game would restart automatically.

The prototype:

107 lines.
The orange rectangle at the bottom is the permanent floor.
The orange square is the player.
The blue tiles are all platforms you can pass through upwards but rebound off when falling.

Bah, this is dull, if you had a level with platforms stacked in a neat center row, everyone would always have the same time, it's impossible to be quicker.
Make it so that the player can SLAM DOWN to hit a platform quicker and thus improve their time.
Hmm, better, but not great.
AHA, make it so that platforms are in two states that the player can switch between, making them only collidable with their current colour!
Muuuch better.
For some reason the dual colours make me think of Tron (and Transformers, and Jumper (hey!) and...)
That's it, I'm going full Tron on this one... while being respectful of IP and copyright and what-not...

The graphics:

No matter what I make, it'll suck.
But I'm also against just leaving things as plain squares.
Well, seeing as I'm Tronning this lot up, may as well make everything glow like a sonofafemaledog. JJ Abrams would be proud.

Open Paint.NET.
Draw something on one layer (text, block, whatever)
Duplicate layer, shift it down and right one.
Change the colour to blue or orange.
Apply Photo->Glow effect to both layers, SHAZAM!

I need something for the background, to parallax scroll, because no game is complete without it.
Think "jumping" as the theme.
That's it, I'm going Tron, may as well print some source code with some "jmp" instructions in.
Open the Tweenimator binary in OllyDbg to see some assembly, holy balls, look at all those jumps at the entry-point, jackpot!
Also, this game shall be called "jmp:err", or "jmperr"

The audio:

No matter what I make, it'll suck.
Go through some chiptunes for ambient music, they all sound too "busy".
Search for randomly generated music.
The Trance Music Generator sounds promising.
Download 3 different MID files from it, find one that might work.
Convert the MID to OGG using VLC with the jRhodes3 soundfont (audio codec) I'm so fond of.
The resulting file is 5MB and a bit busy in the middle... sod it, open it in Audacity and strip it all down to one tiny 10 second looping sample... no one sane is going to keep the music on any way.

Sound effects.
I don't need anything complicated, just a few blips and bloops for jumping, boosting and... menu sounds.
Make some samples using an online sound effects generator.

The menus:

Every game needs menus to be "complete". Damn.
I need text for this. It must look Tronny.
Hello Tr2n.ttf!
Find some menu code examples on the LÖVE forums (can't remember where exactly, sorry source!).
Modify it so that every menu item has a data item associated with it that is displays next to the menu text. This is useful for displaying times next to levels and...
Make options menu for adjusting volumes, modify menu so that it can take left/right as input and call appropriate callbacks.

The persistence:

Time to save/load scores and configuration options.
Hmm, Lua must have some simple function to do this, right?
It does, it's called the Lua Community, huzzah!

The result:

911 lines of slightly mutated ill-tempered spaghetti code.

The game works. There are some features/patterns left to the player to find out, kind of like the first few times you play Mario Brothers.

It's nice to have finally finished a game.
Well. Almost.
It's like this...

The splash screen is vile...
The graphics and audio are terrible...
Showing the code to any living organism would result in it bleeding out of the spaces between its cells.
The gameplay is good enough, but there are so many things I could do to improve it...
There still isn't any real sense of "winning"... you make it to level 10, it shows a different "win" message, then lets you go on forever...

... or at least that's the theory.
Every level is assigned a random seed.
Every level is randomly generated according to this seed, each platform is placed within vertical reach of the previous one.
There is no check to see if the horizontal + vertical distance is reachable... but all of the first 10 levels are completable... either by magic, or by the magic numbers I came up with for platform heights and widths.

I don't know how the game works really.
But I felt myself playing it quite a lot while developing it... something I never expected to do.

Most importantly, I finally came closer to finishing something...

The summary:

Sublime Text with LÖVE build system

LÖVE with helper libraries
- Lick
- Menu.lua
- table saving stuff

- Tr2n.ttf
- OllyDbg for generating some ASM code for my background
- MWSnap (my keyboard doesn't have a print-screen button on it, required for capturing assembly output in OllyDbg)
- Paint.NET

- Sound Effect Generator
- Random Music Generator
- VLC using the jRhodes3 soundfont
- Audacity

The download:

Windows Executable
OSX Executable
Generic .LOVE file for existing LÖVE 0.8+ installations

[ view entry ] permalink print article

<<First <Newer | Older> Last>>