next »

[eigenbom]

Thx everyone.

Any progress to show us? 

Oh I wish I did. Come back in a month, that's when my work on moonman officially starts back up again, and I'll be sure to do around 2-3 posts a week.

[ninto]

Hey, I've been lurking this dev log way too long. Finally thought it was time to pitch in that I love the graphic style, keep with it man.

[eigenbom]

Thx ninto!

Update: So I wanted to try out Visual C++ Express, as a few people had raved about it. Several hours later I've finally got it all set up properly (and what?! no built-in c++ refactoring?!) Anyways, the code-completion stuff is much smoother than eclipse, so I'll see how it goes.. :S

Game update: Refactored some of the block stuff, I had two data structures Block and BGBlock, one for actual blocks you interact with and the other for blocks in the background. Anyway I was duplicating a whole bunch of code, so I merged the two. I also added a few new block types, and spent 5 minutes in-game making a scene out of the different blocks available.

Click to see the full scene.



Also, I think it's time to increment the percentage counter.

[BlueSweatshirt]

I love how maximalist it feels. 

[Ashkin]

This. This is the right graphical style.
What would it look like if the dirt also had those lines that the trees/rocks have?

[eigenbom]

thx guys, ashkin - i tried your suggestion but it doesn't really work. I'm also planning on adding a 'damage' layer, so the blocks will look more complex with that on.

Update: Moonman was having difficulty convincing Purple to give up his treasure.

[Ashkin]

Man that purple stuff is sinister

[eigenbom]

Moonman wanted to explore, but wouldn't leave his c64 unattended.

[BlueSweatshirt]

Does moonman have the ability to walk without raising his head? 
AMAZING!
(dat ceiling)

[happymonster]

Looks super! I would say stick with this style!!

[eigenbom]

Update: Added deathly spikes of death (currently harmless).

[Andy Wolff]

most of these look good, but that last one doesn't have enough contrast between the background and the foreground. textural complexity is probably the greater offender here than brightness. specifically, the dot pattern of the top left and the mid-bottom left

[Ashkin]

Yeah. Decreasing the contrast between the dots should help.

[eigenbom]

Hmm, yeh I see what you mean. Actually I didn't have the AO shading on in that image, but I think it's on the other ones -- it gives a slight dark outlining of foreground objects to separate them.

I had a little play but couldn't find a suitable replacement, just a single colour with no texture seems a bit flat. I don't actually have any trouble when I'm playing the game, but I'll take another look later..

Update: adjusted more tiles to fit the palette..

[eigenbom]

Update: Simplified the data structure modelling a single block in the world. It is now basically this:

Code:

struct Block {
  uint16 type;
  uint16 data;
};

block.type is split into 6 bits for the mod id and the last 10 bits for the sub-type of the block. This means that each mod can register up to 1024 block types, so lots of room for future expansion.

block.data has 16 bits available for the block states, this includes whether the block is flipped (in the case of slopes), or which variant of the block is being used (e.g., the tree block has 6 variations), and the other bits will be used for other things.

Each block.type has a corresponding BlockInfo which stores information relevant to that type..

Code:

struct BlockInfo {
  string name, doc;
  BlockSprite sprite;
  DamageType damageType;
  ...
};

I was originally going to store block damage and lighting in the Block, but now I think I'll handle the damage externally, doing a minecraft-like temporary damage model, and, as for lighting, I'm not sure it'll make it into the game at this stage.

Also, I'm spending way too much time making things in-game instead of coding.. O_O