next »

[tjpalmer]

Given the complaints about my color schemes, the pain of adjusting them in graphics editors (in my case, Gimp), and the coolness of letting folks select a scheme for their own levels, I put some effort into color scheme editing in the game itself:



And here's a muted version of my previous color scheme. Something like this might end up the default:



More work is needed on this front, but it's a start.

[tjpalmer]

Basic energy block support is now in. This demo shows how I expect the gameplay to work:



Long ago, I'd imagined using a keyboard button to toggle the switch, but in my recent actual work on the project, I decided that puzzle solving gets more interesting if you have to approach the switch from the right direction or avoid it as needed.

All switches in a level toggle all energy blocks. Think of it like a room with one light circuit but multiple switches. Could be too simple for some things, but I still want to constrain the amount of hidden state in the game and also the complexity of level representation and editing.

The editor needs fancified a bit before showing how things look there.

Oh, and the final game also needs more juice: glowing blocks and fading in/out.

[marcgfx]

had a few beers (so bare with me). I'm not too fond of the graphics, I must admit. I would suggest the following: lower the contrast of the blocks, this will reduce the blocky appearance. I think even plain color blocks could look better, than what you currently have. the way it is now, nothing stands out, it's hard to tell where the important stuff is. it's kind of "noisy" and very obviously repetitive. how about trying grayscale and only give blocks with actual meaning a different color. e.g. the energy blocks can stay orange, deadly blocks red, etc. convey information with the visuals. keeping it simple is fine, but currently its not simple to understand.

[tjpalmer]

Thanks much for the feedback. The repeated blocks for energy and steel (the bluish ones here) bother me the most. I'll have to decide how serious I am about my rule of not changing graphics. At what point do I lose my claim of using old graphics? How far can I go?

[marcgfx]

the thing is: its a constraint you set for yourself. no one else really cares, so it wont increase popularity or playability and i would not consider them good old gaphics anyway. do yourself a favor and make something you find enjoyable and does not bother you. maybe try to get an artist who likes pixeling and using a limited palette? it all depends on what you want to achieve with your game.

[tjpalmer]

My commitment was to change no graphics. Some people liked that story (and I really appreciate the kind words from those who did!), but no parties unrelated to me actually claimed to like the graphics, so I've been reworking things some. And I think I'm better at coding than art, so I've gone to my usual interest in procedural generation. After tinkering with some options, here is a look at how I might go with the bricks:



I've kept unchanged low res still for a few reasons, including some commitment to olden days.

One big question is whether I can make 8x10 pixel humanoids to match that style. I might have to make good animation to make up for lack of pixel expression.

Still no limited palette here, which is officially kosher for pixel art. But I like color, sorry.

As an aside, graphics are tiny here on purpose. I wanted to fit large (many-block, complex) levels without scrolling on 320x200 back in the day. I want this more about visual puzzle/problem/maze-solving and less about exploration.

[tjpalmer]

What does it mean to break my constraint not to change graphics? I asked myself, "Would me of 20 years ago improve the graphics, given the option?" I would have answered, "Yes." At the same time, I've retained the same game ideas: approximately same play features (even reduced maybe), same pixel sizes, no scrolling, editor, same philosophy overall. The overall game still comes off my initial graphic, even if the art changes.

As an aside, because I don't like pure text posts, I do plan to keep color scheme editing around. (My kids are really into it, among other reasons.) Here are some examples of different material effects for different colors of bricks.



That's sandstone, snow, stone, and greenery. Each case has its own core HSB. The same variety is applied across all. It's not perfect, but I think it will work well enough for some individual branding, so to speak.

[tjpalmer]

Got good enough steel for the moment maybe:



That's supposed to be brushed steel, but sometimes it comes across a bit too much like wood grain (also depending on the color scheme, but maybe that's okay). Might need to revisit it later. I want some/better texture in the ladders and bars now, too.

But energy blocks are next. I'm a bit unsure of exactly what to do with them. Different ideas. Not sure what I can pull off properly.

My kids are still sad that I moved away from my intent to keep the old graphics, even those who think the new stuff does look better. Pondering a legacy mode that uses the old stuff, since keeping my kids happy is one of the big points. But that's some effort, too. Not 100% sure.

Any feedback on whether any of this is an improvement, or am I just spinning my wheels and/or barking up the wrong tree? Is this new stuff good or at least better looking at all?

Oh, and that's a stop button in the upper-left corner, since this is for both touch screens and keyboard.

[marcgfx]

I think it looks a lot better, but I ain't no kid. I would not shade the energy blocks with a gradient, maybe keep them one plain color but add a glow effect?

[tjpalmer]

Thanks much for the feedback (including the thoughts on the energy blocks). I really appreciate it.

[rj]

yeah i think togglability between 90s and 2015 graphics lets you have your cake and eat it too. hire an artist maybe for modern stuff! if you're commited to doing it yourself, look up derek yu's pixel tutorial (as well as tons of others) and practice, practice, practice

this devlog never stops making me smile

[tjpalmer]

Thanks much for the encouragement and constructive feedback.

And hmm, looks like I've written a text wall coming up. Sorry about that. Notes for myself, at least.

So far, no one claims to actually like the new graphics anymore than anyone claimed to like the old. Neither has anyone claimed to find the game plan itself engaging, although I still haven't gotten most of the new features done yet, either. So, it's hard for folks to know the full plan. I am glad people appreciate the development story of the game. Still, I need to assess my goals. These are among the current big ones:

• Actually finish a very old project.
• Maintain some commitment to the old plans.
• Try to make it fun and see if I can get people playing it.
• Have fun with my kids.

I want to promote the game, if I can make it good, but I don't expect to make much if any money on it. If I can finish it, here are my current deployment plans:

• Give it away for free (without ads or any other junk) on Android.
• Depending on the success there, either give it away or try to sell it on Windows and Linux.
• Depending on the success there, maybe get around to Mac and iOS.

I won't be hiring a pixel artist for two reasons: (1) I don't expect to make much money on this anyway even if I can get some people interested, and (2) I'd rather get personal experience. And I have looked up some pixel tutorials by now, including having previously looked at Derek Yu's. (Still thanks for the recommendation as it gives me context and reminders.) But it's pretty clear I'm not winning any visual awards right now, and I want to move forward anyway. So, here are my graphics plans:

• I'm not really a pixel person. I used pixels before, but only because that's how things were. Still, I'm sticking to them here.
• Also stick to the current new graphics for now, but I'm not committing to it or anything else.
• Don't necessarily try to conform to mainstream pixel art, but still looking good is nice, if I can figure it out at some point.
• Do stick to current tiny pixel counts (320x200 with 8x10 grid).
• Get more pixel-specific on rendering, including procedural animation. If I have just a few pixels, I might as well have fun with them.
• Back-fill support for the old 90s tiles as a display option at a later point, if I make the time for it.

I'd love to learn pixel shaders, but I'll defer that to the future. I can manage pixel-specific CPU rendering at 320x200 quite easily at 60 fps, if I stick to native code.

Pixel-specific rendering doesn't mean the gameplay changes, and as I introduce new features, I'll show where the feature came from in the old tiles and concept level layout. (I have sometimes fine-tuned ideas on how to use the old plans, but again, I currently still only plan to use features that were approximately intended in olden days.)

[tjpalmer]

Because I'm crazy, I've started my second rewrite. Now in C++ instead of Haxe. (I originally started in TypeScript.) My reason is that I switched to wanting pixel-specific rendering, and tile-copying in OpenFL was going to be a mess for that. And I'm seriously considering procedural animation on the characters and more.

Haxe can compile to C++, but it's sort of slow at that. And Neko was sometimes substantially slower at runtime for serious loops. And I was still trying to learn what was efficient or not in Haxe -> C++, too. I'd sometimes do this by looking at the C++. Just coding in C++ (with faster compiles now) is more straightforward.

So, instead of moving forward still, I'm catching up again. But I do have something new to show. I now have edge highlight/shade for bricks chopped off at edges.

Old ("enlarged to show texture"):



New:



And I'm using std::normal_distribution for Gaussian noise (still bounded) instead of uniform random sampling. And sadly, it seems that the different sampler causes a different set of colors to be chosen, making this slightly harder to compare. But the left and right edges of cut bricks should be visibly different, and there's overall more concentration toward mean values.

For details, I'm on raw SDL using C++11.

Going forward, instead of going into energy block rendering now (which I'd intended before starting over again), I should probably spend some time on UI and then figuring out how to procedurally animate the little dudes.

(Note: Post updated to include old version for comparison, along with a bit of discussion on the matter.)

[tjpalmer]

Quick tip: For SDL on Android, use the latest from hg, not the 2.0.3 release (especially if you want SDL_GetPrefPath to work).

Android was simpler with OpenFL/Lime, I'd have to say.

Anyway, latest code base nominally working now on Windows, Linux, and Android. Next chance I get, back to doing things (minimal UI then character animation).

[Flatgub]

Wow this looks great!
Keep up the good work! 

[marcgfx]

procedural animation... been reading to much on the rainworld thread? I must say, it's something I would like to try a lot myself. very interesting stuff. you also got one point completely right, if you are not going to make money at least you should be having fun.

it took me a while to understand and see the difference between old and new. half bricks now are highlighted correctly, got it. I was first assuming you were using some kind of lighting technique . now that i see it, it certainly looks better!

[Seaport]

I like what you've done with the bricks the new edge shading does make a difference
Be a shame to get rid of the old graphic style completely maybe have them as a bit of an Easter egg. With the new look steel blocks, as you're a little unsure with their current texture, you could change the texture to look like steel girders? They would tile well horizontally and should go well with your bricks/building theme.
Looking forward to seeing more 

[tjpalmer]

Flatgub, marcgfx, and Seaport, thanks to all three for the feedback! I do appreciate it.

I've done only limited reading of Rainworld. The well-established, long devlogs are hard for me to pick up as well as those I've been able to follow from earlier on. Really, I just prefer coding things to drawing things in many cases. Still, before I posted my plan on procedural animation here, I had seen just enough of Rainworld to hear that was on of the big draws there.

On the steel, I have coded some to where I think I have an improved texture over before. Girders is a great idea, though, and I might investigate that.

Enough people have been interested in keeping the option for old graphics that I might do that. But I'll still plan to do that closer to the tail end.

And yes, I have gotten some done, including a bit of trying to figure out what to do for the background. Not much overall, though, as life has been extra busy. Having chosen a ground-up rewrite at the same time as that hasn't gone well for progress here.

As one more aside, I've found that SDL's hardware scaling of my custom 320x200 bitmap often messes up individual pixels here and there, and it's very noticeable at boundaries. Seems a common issue with hardware scaling, and software scaling of my own has been too slow. Maybe a custom GL shader would do it? But as I don't have much experience in that, I'm deferring it for now.

For quick info, look carefully in the middle row here for the bogus pixels (and it can look worse in other contexts):



And here's the same with my own (too slow) software scaling:

[theperm]

another possible name is Bold Gunner, or Bold Gunnar(look it up)

[Seaport]

How's it going with this, any more news?