This could work if we rebuilt the entire rendering queue every frame, but I knew that would be a huge detriment to the performance of the game, since elements would not be frequently (probably never) changing their z-indices, and therefore what I really wanted was a std::priority_vector. There is a container called std::priority_queue, but that will only provide access to the front element in the queue. In C++ there is no STL container that allows indexed access and automatically organizes them based on a comparison. What I did not realize, however, was that rendering things in the correct order being mandatory in a painterly renderer, would actually prove to be a nightmare of a challenge. I had intended to work out a simple painterly blitting rendering engine, because I thought it would be the most straightforward design where the least issues could crop up. I saw this as an opportunity to, as I did last time, use the game jam as a sort of excuse and motivation to further my progress on the mundane core subsystems of my game engines. I wanted to go into this jam using my custom 2D game engine, ArcticWolf. I was also looking at just over 24 hours left on the deadline when I had the theme nailed down, so I knew it would be a big challenge. I thought it was a neat concept, but I also knew that I had minimal experience with AI, and no experience with turn-based games. Eventually I came up with combining “turn-based” and “shooter” and then eventually I realized that “shooter” could be replaced with “battle-royale” if the enemies are roughly equally equipped and trying to kill each other as well. Unfortunately, my 3D-focused game engine did not have a completed rendering engine, and with 3D being somewhat new territory for me, I scrapped that idea. It’s been done before, and I recall positive reception. For example, I really wanted to do a “first-person platformer,” which would be a 3D game where you basically see something like Super Mario from Mario’s eyes. Even with this chart, I found myself struggling to come up with a theme, because as it turned out, many of the “good” combinations sounded like awful games, or they required some complexity that I knew would take longer than the deadline.
I created a very large, very time-costly spreadsheet of an incomplete list of game genres in an adjacency-martrix-like spreadsheet, which ranked the combination of any two genres as “good,” “neutral,” or “bad” based on how well it fit the theme, which is to say that a “good” combination was two genres that one would not expect to see combined. I believe this theme, by significantly raising the difficulty of creating a workable concept, likely created a bad first experience for them. That said, it is my opinion that Ludum Dare should be welcoming to new developers, as Ludum Dare is often some of the first exposures to the indie game dev scene that they will get. For those more experienced, I will grant that it does provide a unique challenge, and for that reason I was almost somewhat conflicted. For those of us that are relatively new to the game-design scene, the theme is asking us to throw out any convention of design that we may have relied upon to make a game that is not a complete flop. The theme for 41 was “combine two incompatible genres.” I know a lot of people had differing opinions on this, but it is mine that it is the worst theme yet. My struggle for this Ludum Dare originated at the outset of the theme announcement. I may continue working on the game in the future, but I am particularly averse to the theme and not satisfied with the idea that I was able to come up with. This was, unfortunately, my expectation for this one. Unfortunately, my Ludum Dare 41 project, a “turn-based AI battle-royale game” called “Turn-by-Turn Deathmatch” was not finished when the 72-hour deadline hit. I believe I’ve finally recovered from the mayhem and come through the better in the end. Ludum Dare 41 came to an end just a little more than a week ago.
0 kommentar(er)
