next »

[eigenbom]

Update:

The mountain region is progressing well. My auto-orographic explorations have ended for now and I have a decent system in place which generates basic templates. The following images show some output from the generator -- the small squares are stone, the dark blue is one kind of cave, the stippled grey will be mineral deposits, and the white outlined rectangles are man-made rooms.





There are a lot of new terrain and block types in this area, including a snaking-pattern cave wall, graystone bricks and tiles (which come in various decorative forms), snaking platforms, gold blocks, etc.







If you're interested in some of the code behind the scenes, here's a snippet that places 2x2 decorative graystone blocks at the corners of rooms.



Some interesting challenges are starting to arise. For instance: consider that two rooms are created next to each other, but one is raised and they are connected by a door. It doesn't make too much sense that there would be a vertical drop after the door, and so I have to start coding in context-sensitive solutions to join the together. Here's an instance where the system has created a little staircase out of decorative blocks to join the two rooms. Some other possible solutions would be to make a jutting out balcony and ladder, a bridge or platform that goes all the way across, or to lift the floor level of the lower room with more blocks.

[bornander]

It was a while since I checked up on this devlog and I am glad I got around to it, awesome progress.

The snow looks good and it really does make the environment seem that much more dynamic. Will the snow fall be a constant thing in some parts of the map, or will the weather change from snowing to now snowing in one location?

[woodsmoke]

Beautiful!
Moonman sure is a cheerful guy, always smiling.

[Igor Sandman]

Man I'm impressed how much visual style you can accomplish with so little color variations.
I especially like the poisonous dungeon mockup. Sweet colors on thoes chains and on the pillar.

[eigenbom]

Thanks guys, yep I'm still going, 155 pages later! Haha

Will the snow fall be a constant thing in some parts of the map, or will the weather change from snowing to now snowing in one location?

In the mountain the snow fall changes based on altitude. Other areas will have a small random chance of snow.

[ernanir]

Hey,
There is so much to learn from these screenshots alone. Thank you for sharing your devlog with us.

[eigenbom]

Hey,
There is so much to learn from these screenshots alone. Thank you for sharing your devlog with us.

You're welcome

Update:

I've done a significant amount of work on the rendering system in Moonman this week. There's a few big things:

The game now (theoretically) supports large worlds. The limitation of this was the rendercache system, but I've built a system that keeps grabbing texture memory when it needs it, up to a limit that you can set in the settings file. I think 512 mb VRAM looks to be the minimum system requirements, although I might be able to make a 'light' build of moonman for systems with lower specs.

The game needs texture memory to cache the rendering of the world. It splits the world up into 16x16 tile clusters and then draws them to a render texture. It then only redraws them if they change (for instance if a tile is mined in that cluster). The texture memory then looks a little like this:



Once the system reaches the vram limit it re-uses old textures, which may incur some redraw time, but hopefully it's not noticable. Currently the alpha has a world of size 256x256, and I thin we can comfortably go up to about 4 times that in both dimensions before hitting some other problems (like reaching RAM limit for physics objects). I've done a bit of stress testing with different memory limitations, but in the next alpha update I'd definitely appreciate if you could test the system (I'll include a "large" blank world to try and load).

No more missing bits on tiles: in addition to updating the rendersystem I also fixed it so that the tops and sides of tiles no longer dissappear. That's been bugging me for ages so I'm glad I finally was able to fix it.

Fog of war and lighting work much better now. There are almost no instances of fog or lighting out of place, which just makes the game look tidier overall. It's a small item but it was very time consuming to fix -- most of that code is over 2 years old now. Nonetheless it's a lot tidier now.

Here's a screenshot of the debug mode I use when testing the lighting, the amount of redness is the amount of light energy in that tile, and the arrows show where each tile was lit from. There's an open window in the middle of this scene which lights all the tiles. Those dark splotches on the stone are bugs, which have now been fixed.

[ENDESGA]

Those bricky blocks are so beautiful wow. Trying to refrain myself from using them as inspiration  

Stellar work as usual Ben.  

[eigenbom]

Thanks E

Update: We started work on the seed region, which will be an organic landscape, with various strange polyps, clumps, outcrops, and congealments. A gloopy material sits in a layer just under the harder surface. As you can see, it's a new material type, one that is mined in clumps rather than single tiles.







This coming week I'll be building a basic seed world, combing these different elements. Meanwhile @narwolf will start work fleshing out the volcanic/hell region. Once we have the seed of the four regions in place we'll move on to refining and iterating on the different structures and subregions within those areas. My first priority is to get a goal into the forest level, and so the weaver den is probably the first subregion we'll be working on.
 

[eigenbom]

Update: Hey, I finished a year of daily pixel art! You can read about the last year here (also on Kotaku, HN, reddit, etc.) As for Moonman, work on Seed continues!





Design and concept stage of Ember has begun:





I added a better particle syste, now bigger chunks appear when you're mining. I've improved the melee system -- you can no longer hit enemies through walls or doors, and they can't hit you either. I've added a magnet-style pickup system where items are attracted to you from a short distance away, which also stops you picking things up if there's a door or wall in the way.

[SrGrafo]

Update: Hey, I finished a year of daily pixel art!

thats awesome man, so much practice 

Has been following this project for a big while, looks so smooth and evolving so nicely

the best thing is always the expression of the player xD

[Callan]

Moonman is looking amazing, keep up the great work, Ben!
I really like your overall coding style. Do you follow any published coding standard or is it a personal variation?

[eigenbom]

SrGrafo - Thanks!

Callan -- Cheers. It's just a personal style that's evolved for a decade or so. But actually it's changing a lot these days because of the dramatic shift in c++. So, for instance Corner tl = {a, b, c, d}; should now be auto tl = Corner {a, b, c, d};

For a while I was using the obj-c style enum naming convention kDecorativeGraystone, but I've reverted to using allcaps with the leading characters denoting the enum type B_DECORATIVE_GRAYSTONE, it works well. Although I want to move to more strongly typed enums like Block::DecorativeGraystone in the near future. It's a great time for c++!

[Callan]

@ben -- Do you mind if I ask about your naming convention for classes/structs, typedefs and member variables?

[eigenbom]

Sure, here's a made up thing ...

Code:

enum FooFactor {
  FF_LOW,
  FF_HIGH
};

struct Zot {
  FooFactor fooFactor; // public
};

class Zotter {
public:
  void processZot(Zot& zot);

  // helpers
  static std::string ZotToString(Zot& zot);

protected:
  using ZotMap = std::unordered_map<std::string, Zot>;
  ZotMap mZotMap;
  static int sTotalZotCount;
};

[eigenbom]

Oh, actually I'd use const Zot& zot for those functions that don't modify zot, and also would pass a Zot* if the zot's existence was optional. There's a great talk by Herb Sutter (at CPPCon 2014 or 2013) about modern c++11 style.

[happymonster]

Looking good!

Have you tried (or thought of offering an option) for rotated sprites fitting to pixel boundaries? At the moment they are rotated at higher resolutions which probably looks better, but clashes a little for me with the scaled up pixel work.

[eigenbom]

Thx HM. It doesn't help to think of the game as pixel art, it's past that. I considered using RotSprite earlier on and other tricks so that everything is aligned in a grid, but went in a different direction. Now so many things in the game aren't lined up to match the 'pixels', e.g., the character smoothly moves between those units, the plants sway slightly, and the weapons and other things rotate occasionally.

[happymonster]

Hmm.. then maybe you could Hi-res the pixel art completely.. 

 

[Andrew Brophy]

this is dope.