That's really nice!!

Thanks!

Looking forward to the blog post to how you did this..

I posted a link to it in the Tutorials sub-forum, as Marching Squares.  I'm glad to answer any questions there if the explanation doesn't cover it.

This tutorial explains how to go from basic and blocky to smooth and seamless by using Marching Squares to automatically stitch together tiles.

Starting from the simplest 1:1 tiling system we cook up a few automatic placement strategies and boil down the bits to extract the very essence of the marching squares algorithm.

I've created a simple HTML5 tile placement demo using the algorithm as described, so you can see the Marching Squares in action and peek under the hood at the metadata itself.

This tutorial is targeted at entry level game devs. As such it covers info that many skilled folks are already familiar with, but even experts might pick up a trick or two.  For instance:  Did you know it's possible to implement marching squares without a single conditional ('if / then') statement or lookup table?  Ever thought about using the 'saddle point' solution beyond its problem space to add a bit of variety to all of the tiles?

Being born from TIGS' own Placeholder Graphics thread, the tileset template is free to use in your own implementations.

If algorithms were tools, Marching Squares would be a Swiss Army Knife.  Swedish soldiers shouldn't have all the fun...

I extended some of the 12x12 placeholder tiles to create a placeholder tileset that's compatible with my HTML5 implementation of Marching-Squares.





The template pattern is included so folks can extend the tile gradient.  There's a transparent border to help with placement; Sometimes the similar tiles blend into one another.

I'm writing a blog post that explains the tile layout / tile selection logic.

Experimenting with dynamic shadows in HTML5 Canvas.

Adding some editing modes to my HTML5 engine's in-game editor.

I'm wondering if the reason few games like this exist is because there is no real demand for them, or if its just an unexplored market on the PC (or my research has been terrible!). I figured with Big Picture there is a definite way in for a game like this and people still nostalgically and fondly reflect on time spent playing the games I gave as examples.

Ugh. Make the game you want to play.  Screw "the market", and your terrible "research".  Trust that there are others like you in the world who will enjoy what you do, and make something that you will REALLY enjoy.  Proof of like mindedness: Other games that are in the same genre.

If you're making games to fill some niche instead of because you're passionate about them, then I have nothing more to say other than: Good Day To You, Sir!

Also, there is a feedback forum for getting game feedback.  It will help if you give some feedback first, however.

As a Kickstarter I wouldn't drop one red cent.  Not until you have a prototype of SOMETHING playable.  It's so easy to get a few coloured squares moving around that it's silly to ask for funding without at least that.

So, you're on the right track either learning to do a bit of coding / or finding someone who can right away.  I mean, it's the gameplay that counts so how else can you even tell if the game ideas are even going to be fun without a prototype?

You might also enjoy this: No one Cares About Your Cool Game Idea

Ideas are worthless. The only currency that holds any weight is the ability and drive to execute. That awesome game idea you have, the one that’s going to “change everything”, the one that you’re going to sell for a million dollars, the one that no one has come up with yet… frankly, no one gives a shit. Harsh, but then, the truth is not pleasant; it is just that, the truth.

Note that bit about executing.

Usually, I do both.

First, I do the fastest and dirtiest code possible to get a particular feature working.  This typically involves a degree of trial and error anyway, no need to waste time beautifying code that'll get deleted.

After discovering a design that actually works well, I rewrite the feature as elegantly, cleanly, and modularly as possible with detailed comments for every function and parameter in the interfaces and some comments in the sticky bits of implementation code.

Even though this seems like it would take longer than just noodling over a problem, designing a solution, then implementing it cleanly, It's actually several times faster (for me anyway).  Nothing sucks more than having to throw away a swath of beautiful code you just spent tons of time creating when you discover your design doesn't work as well as you'd like during implementation.  That's the time sink to avoid, IMO.

Even for things I'm sure will work I do the quick and dirty first, then clean it up.  It takes discipline to go back and re-write working (dirty) code, but often times it ends up even faster / better during the 2nd time around.

To keep from rewriting everything forever: Once I've done the clean version (esp. if it has unit tests), I won't touch it unless I absolutely have to; I'll create a work-around instead.  Save those cool improvements for a v2.0 overhaul, but get v1.0 done first.

Thus, I take advantage of both coding in the quickest and dirtiest fashion, and having a beautiful, well-documented, clean, and working code-base that I'm not ashamed to show off.  The biggest benefit is that I have little or no desire to scrap the project and start over from scratch half way through due to poor design or ugly code -- I typically have neither due to this bottom-up approach.

Now working on the streaming tile renderer and multi-level coordinate system.


This shot shows the debug "engine coordinates" output of each 16x16 block of tiles.  Each different color 16x16 area is a section of cached tiles.  If a section of tiles has been rendered recently it's not re-drawn or recomputed: The cache is used as the screen scrolls seemlessly.  The effect is that loading time for user created patches is diminished to be unnoticeable (pre-fetching), and rendering speed is increased.

Also, tiles wrap at the edge of the world and we can scroll at sub-tile resolution, ie, don't have to scroll a full tile at a time.

The caching and coordinate systems affect gameplay indirectly: The limits of the tile coordinates, and bandwidth costs will determine how big we can make the game world.

Some more experimenting must be done, but currently I plan on supporting a game world with up to enough tiles to cover the surface of the Earth, to scale.  Eg: If each tile is 1m (~3ft) in width and height, then we'll need to support about 40 million x 40 million tiles to contain a to-scale tile based version of Earth.  A copy of Earth in tile form wouldn't be very procedural -- well, I could use OpenCV to search among the 4 billion over-world seeds to find a close match to Earth, I suppose, but that would defeat the purpose, eh?.

I'm not sure what max world size would be best from a gameplay perspective.  We may need to do a much smaller planet instead.  Scrolling 40 mil tiles at 20 screens every minute (3sec per 40 tile wide (640px) screen) would take 3.8 years to go all the way around the planet once (that's 7.2kph or 4.5 mph), and you'd need to do that over a million times to see the whole planet -- Or, it would take over a million people playing non stop for 3.8 years to explore the whole thing.  Though the engine could theoretically support a much larger world, this seems a large enough, so that'll be the upper limit I'd say.


Next I'll begin merging the tile placement code with the infiniscroller code. That means we should have something to play with soon -- After that we'll be fleshing out the details of the procedural tile placement systems.

IMO, sounds like you're describing a Roguelike to me.  Perhaps have a look into some rougelike games? 

There are many RLs with the tile based detailed interaction simulations, even down to hunger -- or tiredness, not to mention standard things like weapon speed, movement costs, etc.

Bonus: Many roguelikes are open source, so just snag one and add 2D or 3D graphics, away you go.

Checkout RogueBasin.

Just an update to let you know we're still kicking.



I got music and sound effects working, as well as rudimentary tile placement in the online version. It's not quite ready for public consumption yet, but I'm making steady progress on the code.

I'm experimenting with using marching squares to automatically stitch tiles together to speed up manual tile placement.

These metallic hole tiles are WIP, and actually not for this project -- Just using them here to see if the diagonal stitching is working.  Also the upper left corner configuration indicates we may want at least two different layers of tiles:  A base layer for the ground stuff, and another to place walls on (so we don't have to make a million base tiles each time we want one partial tile atop a background tile).

We may not end up using any diagonals for this project, but my engine will support it.

A fellow gamedev was asking about Sega Mega Drive / Genesis color palettes.  I've worked with Genesis limitations before, but a few searches didn't turn up much in the way of nicely laid out palettes, even less for the shadow and highlight modes the machine was capable of.  Maybe my Google-Fu is just weak.

So, today I created a program to output the full color palette of the MD, and sort the colors by hue going left & right.  The fully saturated colors are sorted by value going up towards black, and the less saturated are sorted by saturation going down.  It's a dumb little program, but it's moderately better than picking from the RGB cube slices, IMO.



Also included are the same colors in RGB cube slices.

Note: I didn't group all the shadow and highlight colors into the the main color sort because these separate palettes typically can't be used together -- Scanline interrupts could change palettes, but it was too slow for real-time to do a full screen with lots of switching.

Note also that PNG images may have gamma correction applied depending on your editor, which can skew colors needlessly.  Thus, if you want to pick colors, here's a TGA version.

[Three winners will be selected randomly by random.org through Rafflecopter]

This post is off topic.  That is, unless you consider entering a raffle to be a "competition".

Competition Rules

Open worldwide

Entrants must be 13 years of age or older to enter

Competition start date – 12:00 am GMT 23rd March 2013

Competition end date – 12:00am GMT 18th April 2013

Three winners will be selected randomly by random.org through Rafflecopter, one for each prize, entrants cannot win more than one prize.

About the Author: Oliver Neely

Oliver is a 20 year old web-enthusiast and entrepreneur from the UK. He enjoys Marketing, SEO, Technology and Business.

Gag me with a koopa.

Ugh.  Just watched that SXSW vid.  Wow, completely off putting.

In response to concerns about extracting the OUYA ROM and flashing it on a phone or other device:

OUYA's a controlled environment.
Every piece of content that you will buy and download needs to have -- you, know -- is behind the server; Needs server authentication.
We're doing other tools.

We will be as secure as other Android devices (which probably doesn't make everybody that thrilled), but I think we will be more, as well.

Translation: Pay To Win + Always Online DRM == OUYA!

But it's the ecosystem, it's the developers that are coming.  We've got Exclusive Content that you're not going to find anywhere else.
[cites two games that will be coming to OUYA, not necessarily exclusives.]

I mean, there's some real excitement and momentum behind this open game console.  That is the momentum that we're just trying to keep leveraging and delivering on.

Ah, so you're "leveraging" the hype for all its worth then?  Great plan.  What happens when you ride a wave of momentum and excitement is that the wave crests eventually...

So, it's open, but it's a controlled ecosystem?  Hmmm, isn't it impossible to "control" that which is "open"?  Sounds like it's just an App store with always on DRM to me.   

I just want to put a $0.99 price tag on my game and just distribute & sell that, but I can't on OUYA.  I have to devalue the game with a free demo that I'll have to waste time (money) creating.  How is this giving me the freedom to choose how I sell my game?  Sounds like taking away some choices to me.

[Holds up a dev unit]
There is NOTHING special about this board!

Yep, It's just an app store plus DRM non-features, minus the prime benefit of an app store since OUYA won't host my "full version" data, I have to do that myself... Why am I giving them a cut then?  Advertising?  The opportunity to be in their app store?  I mean, if it's so "open" and "hackable" then folks can just sideload my games from my website then, and I get 100% of the profit -- OR, add another App Store to the OUYA that'll host my full version files for me -- you know, like ALL the other ones.

I really hope I'm just misunderstanding the ramblings of a crazy woman.

[coder]

I am a programmer who sometimes makes games.  Thus, my little brother thinks I can do anything... Even draw an anime version of his girlfriend wearing a cute Star Trek uniform.



Damn it, Jim!  I'm a coder not an Artist!

Guess I'm working on my crappy art skills?
ELBOWS!  How do they work!?