So, while planning for this challenge, a number of very ambitious ideas crossed my mind, but I've participated in Pyweek enough times to know that when pressed to launch fast, you should perhaps aim low and polish the result. And thankfully I don't have the benefit of soul-crushing unemployment to give me extra development time.

Still, on Sunday I spent most of my time procrastinating. Rather than coding, I spent most of my time exploding trolls, orogs and other humanoids in Baldur's Gate. The problem, of course, was that even when I decided to aim low, my idea still seemed too big, and some parts of my brain were trying to tell me that by draining all my motivation away.

So, here's perhaps a list of ideas that I've considered before picking the current idea. Mind you, they were all platformers:

While those might still be feasible for other styles of games, their ideas are way too tied to platforming in my head, and getting the platforming right alone might be more than I'm capable of in a week considering full-time work and other personal life things taking my time. Those are ideas I'll think about, but not now. Now I need something simpler.

That's where the current idea comes in. I can easily display you a grid. I can also easily let you move left, right, up, down unconstrained or constrained to a grid, doesn't matter. I can also very easily check your intersection with rectangles, prevent you from walking over solid objects, harming you when you come in contact with harmful things, rewarding you when you come in contact with rewarding things, and so on. The world without gravity is incredibly easier.

So, I get that done in a couple of hours. Put on a simple straightforward visualization of maps and challenges on the screen so I can design the level, and then the actual fun of the competition begins. How many ways can I find to display to you the information about this map without downright showing you the map? Vertical and horizontal histograms of solid blocks? Noise frequency to indicate distance to the closest enemy? A detailed text description of the level and of your location?

I have a very strong feeling that in terms of being fun, this game will fail miserably. We typically don't like unfamiliar interfaces and we also typically don't like unfamiliar presentation of data, and this game concept has both in spades. I do, however, hope that the idea can at least feel fresh and that despite the general suckiness of the controls, that I can come up with a couple of interesting mechanics and level designs that will make it at very least a fresh experience.

The good aspect of the idea is that its core mechanics get done fast. And everything else in the game. Each new information visualization I can show you constrained entirely to how much time I have available to polish this idea for the game. And should I run out of ideas, I can always just work on the quality of the presentation of the data and menu. Sounds like the kind of game idea I should have tried to work with many competitions ago, but only now had the clarity to work.

Or I could simply be completely wrong and this is going to be another DNF for my belt. :)

I'll be making development of this awful game as open as I can. See the git repository here. If you decide to check it out and see anything that makes you want to rip your eyes out or happen to have less intense comments about the code let me know. ;)

In my latest commit I have made it possible to interact with an uninteresting scene. There's not much yet in terms of a game, and production value is pretty much zero. But for those curious about what it is that I'm building, you can already start having an idea. Launch the program and move right and down. Look at the map and at how the histograms update.

Now think, for a moment, about how much you'd hate if you were only allowed to look at the histograms in this game. Welcome to my game. It's horrible.

I took what is to me an unconventional decision early in this project. The "scene" is a 1x1 board. By 1x1 I don't mean 1 tile, though, but a continuum (well, a floating-point interval) between 0.0 and 1.0. Due to the fact that I'm going to be designing mostly views to the map, it makes it easy for me to reason about how much space I want a thing to take when a 0.3 means always 30% of the length or height of the map, rather than 34, 67 or 103 tiles being the same. The oddity here, being that the player will have variable size between levels, and the player's level will indicate how big the level actually is (his speed is defined as a function of his size, so it still works)

The trade-off here is a loss in precision. I could be the case that dynamic entities' movement get visibly distorted due to floating-point operation updates, but my expectation is that the views you're going to get to the levels are going to be unclear enough that such imprecisions won't be noticeable. At the very least, I hope that they won't introduce game breaking bugs.

Today's work was establishing diagonal movement and reworking of the dynamic entity to wall collision detection and handling. I initially produced a bogus diagonal collision, so I thought of restricting player movement to 4 directions. After some sleep, I was able to think more clearly and adopted a lazy approach drafted from some ancestral memory. The code is not particularly beautiful, but it works.

I also got started with the concept of a Matcher. It's basically a filter of entities in the scene/level, allowing the view to select a subset of entities to describe. At the moment I'm suspecting that a better approach would be to assign a subset of views to each section of the screen and cycling through whole views, but the idea of cycling just through matchers might still be viable. Let's think about this again tomorrow after a good rest and an exhausting day at work.

Forget "polished". Let's aim for "playable, somehow".