Archive

World Design

Well, I keep on getting distracted, but the distractions are all part of the project itself. There’s a distinction between the process of making a game and the process of making the game engine, the game editor, the game tools, even though these are a prerequisite – and, clearly, I’m more willing and able to focus on those right now than I am on making the game itself. I think this is okay for the time being: Part of what I wanted to do with project is to let myself go where my enthusiasm guided me to go, and clearly right now that’s in working on the tools. Now, whether that’s just because I’m more intimidated by the idea of working on content stuff, well that’s an open question. Eventually I’m going to run out of tools to work on, so I’m not stressing out about it. Yet.

Anyway. What are these tools he keeps talking about?

Well, first, I’ve got a somewhat working version of the room creator I was talking about last time. I got the solution to the point where it did maybe 80% of what it was supposed to and then tabled it, since I didn’t want to get sidetracked for too long with nothing to show for it.

You can see that some of the logic is there, with it placing the walls and some of the tiles connecting the angles correctly, but there’s a couple of tiles that are incorrect and some that just aren’t getting placed. Part of this is just the order tiles are getting placed in right now: Since each tile has to fit with each other tile, the tiles that get placed first don’t have to meet as many constraints as the ones that get placed last, and often end up being incorrect. Obviously I have to iterate through the placement more than once, but how do I know when I’m done? How do I know which tiles I still need to match with and which are now outdated by the new placements on the second loop? This is probably a problem that’s been solved, so maybe I can look it up. That may be another reason why I set the problem aside – it didn’t seem urgent to solve any more, now that the remaining issues were relatively small and easy to describe. Most of the time, at least when it comes to programming, a sufficiently detailed description of the problem contains a solution.

After getting that sort of working-ish, I focused on creating the entity editor. Once I can build levels and place entities, I basically have everything I need to create a game. However, there’s a huge range in what constitutes a level and what constitutes an entity, and some big decisions need to be made in order to meet those simple requirements. Up front, though, I had a pretty good idea what an entity was supposed to be: I want an entity to be an object with, most of the time, a position, dimensions, and behaviors in the game world. With a bit of shuffling UI around, I came up with this entity editor:

The top bar is a toolbar where I can drop any entity I want to use more than once and save it for later. The top-right is an editing window where I can rewrite any of the entity’s scripts, and the bottom right a selection window that I can use to look at and edit any of the entity’s properties. What is going to be interesting as this progresses, I think, is that any one of the entity’s properties could be a script, could be a script that rewrites another property to be a script, could be a script that copies another entity into a variable which gets used by another script to spawn versions of that entity, and so forth. What I want here is a system that eradicates as many barriers as possible between creating, editing, and scripting entities. To begin with, I used an XML-based scripting language since that saved me a lot of the trouble of parsing the scripts, since I could just use Haxe’s built-in XML parser. However, I’ve decided instead to roll my own scripting language – after some misadventures in using a very full-featured Haxe parser, which I guess we’ll just consider research now, I decided that my needs were simple and specific enough that I should really just make my own.

While I initially considered making a new simple animation system, I decided that too much good work had gone into the EverEnding animation system to discard it completely. However, the rendering paradigm I used for that project was completely incompatible with the standards used in OpenFL – one of the big reasons I wanted to step away from that project for a while, since bringing it up to those standards was a huge logistical pain in the ass. This was, therefore, an excellent opportunity to work on something that could benefit both projects. The necessary approach was so different that, in the end, I had to fork the class, but when it comes time to work on EverEnding again I can work on integrating both versions together in a way that captures the strengths of both. For now, I have a fast and efficient way to render every entity I want to the screen.

Aside from this stuff has been some minor progress in other areas, like making decisions on what the tileset should look like, fixing bugs in the collision code, and making a rough character sprite for use in testing. However, if you’ve been following the project, you might have noticed streams abruptly ceased a couple of weeks ago, which is rather contrary to my original concept of the project as something which I worked on entirely on-stream. Unfortunately, I came to a point where a few aspects of my life and this project came into conflict with one another: As I alluded to in my Problem Machine blog post a couple of weeks ago, I tend to have sleep patterns which could be generously described as ‘erratic’. I’ve been trying out ways to restructure the way I live and work in order to help address this issue, and one of the biggest changes I’ve made is to try to get a few hours of work done immediately after waking up, before taking a shower or eating breakfast or anything. So far I find this approach tremendously beneficial, starting my day off on a good precedent and ensuring that even if later on I do end up feeling fatigued or depressed I still have a few good hours of work done, relieving much of the pressure to do work that was keeping me up later and later at night. Unfortunately, while it’s a bit stressful to stream myself work, and it’s a bit difficult to get used to waking up and working right away, the idea of waking up and streaming working right away is just too much to countenance at the moment. With time, this may be something I can approach – it may be helpful to get away from my conception of streaming as something where I need to have a constant running commentary, for instance. Or maybe I can just eventually get to the point where I’m more comfortable vocalizing my thoughts immediately after waking up. At the moment, though, trying to do two things which aren’t readily in my nature at the same time just felt like too much. Hopefully, in time, the dev streams will return. In the meanwhile I’ll probably continue streaming gameplay a few nights a week, though this past week I have been remiss due to fatigue.

That just about does it for this month’s update. Next, I plan to finish this scripting system, fix the remaining issues in the room generation code, and probably start building out the first few rooms and entities and some more finished looking art. I think by next update we may be able to start getting into actual content, rather than tools – but who knows what rabbit holes I have left to fall down?

Advertisements

The new project is underway. I frequently miss working on EverEnding, and so far I haven’t gotten to do the sorts of things I really came to this project for, but I’m also getting really excited about some of the ideas I have for the future while I lay the necessary groundwork to proceed.

So, what have I been working on? There’s a lot, really. I got the basic collision system up and running, though that part is still glitchy as hell. I’ve created a simple but potentially very flexible scripting system which I’m going to use for all entity behavior in the game, which is going to make modifying entities in the editor largely a matter of literally copying and pasting the behaviors I want between entities and should make saving and loading pretty straightforward. However, the bulk of my time so far has been taking up on developing tiles, tools and editors for using them, and an understanding of how they’re going to be implemented in the game.

This is the tileset I’m testing with right now. It’s pretty ugly and rough around the edges, but right now I’m just trying to figure out a way to make all the tiles that I need for the game world fit into the minimum possible amount of space in a format that makes some degree of visual sense. If you do any art yourself, you may have noticed that the perspective here is, to put it mildly, kind of messed up. I’m working off the model established in the tilesets of the early Legend of Zelda games, particularly Link to the Past. The angles don’t really fit together or make sense, but it still creates a cohesive space for the player to navigate without obscuring anything the player needs to see. In the long run, the Escher-esque nightmare presented by this kind of world design may work in my favor, since I want the world to seem kind of surreal – but more on that later.

The big issue I’m facing at the moment is creating a tool to automatically fit these tiles together. There’s a small immediate and a big future reason I want to do this: The small reason is that figuring this out will allow me to build tools into the level editor that let me really quickly make rooms and connect them in a way that looks natural without having to individually place a bunch of tiles. The big future reason is that eventually I want to be able to generate rooms entirely using code using the same algorithm, and create procedural environments for the player to navigate.

That segues nicely into what my plans are for the project. Actually, none of these are plans yet, these are just ideas for now – plans will mostly wait until I have a playable chunk of game and can begin making hard decisions about what works and what doesn’t, what’s feasible and what isn’t. The setup I want to explore, here, is being trapped in a big creepy house – there are other people here, and it’s a bit up in the air how long they’ve been here. Some of them talk like they’ve been here a few days, some of them seem like they might have been here for centuries. Everything is blocked off in different ways though, bricked and boarded up, papered over, hidden behind secret passageways, and in order to begin to find your way out you need to explore and find tools both to open up passageways and to fight off the creatures that have taken over parts of the house.

That’s the basic idea. Let’s call that tier 1, where I just make a little Zelda clone and call it a day.

Here’s a more interesting version of that idea that I’ve been playing with. There aren’t monsters in the house, but in order to actually make progress you find different beds to rest in. Each bed you rest in puts you into a dream where you play as whoever the bed belonged to, and in reliving their story you can perhaps change it, and by so doing change the state of the house. Or maybe you just find the tool you need in the dream and bring it back directly, or perhaps you are able to recruit an NPC by telling them something they’d forgotten a long time ago. The dreams, of course, are infested with weird nightmare monsters, and you need to be able to defend yourself in the dream, so procuring equipment is still necessary.

That’s tier 2. This would be a much more substantial project, but I think there’s room to do some interesting things here.

I have an even bigger idea, though, and this is one that could get really out of hand. Take tier 2, but each dream world contains other beds, and you can keep pursuing nested dreams deeper. Past one or two levels, dreams begin to be procedurally generated, but the resources you get in each dream can be brought out of them and used to progress through the next. The game becomes an adventure game containing a roguelite, where progressing through the roguelite sub-game allows you to progress naturally through the world of the main game. Eventually, perhaps, getting lost in these many nested dreams could become a genuine danger.

Tier 3 is fun to think about, but for now I have to focus on tier 1 – or, really, tier 0, which is building the toolset that will allow me to build tier 1. That’s where I’m at right now, but if progress continues at this rate I should be able to have my toolset done by the time of the next devblog and can really start building out the most basic version of the game.

Way back when I started this blog, one of the first essays I did was about conceiving of a game as the combination of three related spaces – physical, mechanical, and narrative – and gameplay as the act of allowing the player to explore these spaces. I think this perspective is still useful, though sorely in need of revision now, five years later (I’ll likely return to it at some point in the future). However, whenever I think about how different games emphasize one or the other of these attributes, whenever I try to draw a hard line between where one space begins or ends, I run into a bit of difficulty making that division. The mechanical and narrative spaces are fairly easy to delineate – one is the actions you can take in an environment and how that environment reacts to those actions, the other is the story that is told about those actions and the context in which they take place. However, the physical space, which one would expect to be the most intuitive of the three, is a bit more difficult to delineate – and I think it has to do with how we create physical space in games.

The problem I keep running into is that the physical space of the games is actually created by means of mechanical and narrative elements. The mechanical aspect of the space is your ability to move around on some parts of it and to have your movement blocked by others, and the narrative aspect is the colors and textures and what they suggest about the world you’re in. Together they create something that feels like a chunk of physical world to explore, but there’s nothing actually physical there. A sense of physical space is created, but it is not separable from the mechanical and narrative elements that contribute to it – not in the same way that the mechanical and narrative elements are separable from each other.

It may be extremely obvious that the physical reality of the game world doesn’t exist, but it’s suggestive that we create the illusion of a physical reality through recreating the parts of reality which interest us most as humans. That is, when we encounter an object, our concerns are a) what can I do with this? And b) what does it mean that this is here? This, of course, has very little to do with the actual material world, where objects are made of many different bits and pieces, covered with bits and pieces of everything else, subjected to forces we have an incomplete understanding of. What’s noteworthy is not that we are simulating a reality, but that we are simulating outwards in, out from the superficial aspects we find ourselves most interested in, down into the more fundamental aspects such as mass and warmth only as we find those necessary to power the superficial simulation.

Tangentially, I am now quite certain that if we had any way to simulate texture and taste in games we would have done so long ago, as these are also superficial aspects of great interest to human perception.

It’s fascinating that we so many of us consider what we’re doing to be realistic. What we do with games is render exclusively that which can be seen: every 3d object is an empty shell, every character who is modeled is simply their exterior with nothing inside, and interior parts only created as they become necessary to render when they are ripped apart from the exterior (a common scenario in games). We see what a human, or a house, or a rock, looks like, and reproduce what we see, when that is inherently only the most superficial possible version of that thing.

Something from physical reality is translated into signals for our brain, is stored as a symbol representing that object; then our brain conducts our body to create an object that can reproduce those signals in another brain. That is what we call art – or, at least, representational art.

So, with games, we started from the simplest version of the most superficial reality, and from there we’ve managed to make more detailed and convincing forms of that representation. Perhaps we could simulate a reality based more on what we know to be there than what we see to be there? Even a primitive simulation of a more complete reality could lead to new and interesting artistic pursuits. Or, perhaps, since we are unmoored from the physical basis of reality, we could create a simulated world far wilder and stranger than we can while paying lip service to material reality.

Mostly, though, I just find it amusing how much we like to act like we’ve come anywhere near a reality simulation when our approach is in essence purely superficial. How very human of us.

Not too long ago, and for a lot of the history of video games, the visual quality of a game has been decided entirely on how ‘realistic’ the graphics are. Using photo textures, true-to-life lighting models, and increasingly sophisticated shading systems, we tried to – and, indeed, continue to try to – create rendered images that are completely indistinguishable from a photograph. On the one hand this makes a lot of sense – I mean, photorealism is often regarded, rightly or wrongly, as the height of technical mastery for a painter, so shouldn’t game graphics aspire to the same thing? On the other hand, what a tedious aspiration this is, for a medium that could do literally anything, portray any kind of weird and wild reality.

Fortunately this is no longer the aspiration for most games. This may have as much to do with the problems inherent in trying to produce to this quality of fidelity on a budget as with any shift in aesthetic priority, but the end effect is that realism is no longer the universal standard of quality – in most games, that is.

It’s interesting and a bit dismaying to look at the games where ‘realism’ is still prized. War games, mostly, and particular first-person shooters. These games are mechanically some of the most distant from their source material – wars full of permanent death, permanent destruction, permanent loss, portrayed in a manner where everything can be redone, remade, regained, with a quick checkpoint reload in single-player or starting the next round in multi-player. Sure, the same can be said of most games, which usually have dramatic stakes and some sort of loading/reloading system, but rarely does real and tragic loss sit quite so closely to quick and easy consequence-free gameplay. There’s something exceptional and grotesque about using real wars, some quite recent, as set-dressing for your shooty game, and selling that illusion with state-of-the-art graphics.

The reason why realistic graphics have become less popular, aside from budgetary reasons, is that we’ve realized that graphical style can communicate something about the nature of the game and the world it takes place in. The reason why it’s odd that realism is still the art style of choice for military-themed shoot-em-ups is that what this art style conveys is: “this is reality, this is what war is like, it’s gritty and bloody – and also painless and fun and inconsequential!”

Perhaps they’re pressured to adopt this realistic style by market forces – it is, after all, easy to appreciate realism because we know what reality looks like. It also makes them appear faithful and respectful to the realities of war in a certain way, since they study real war to make sure they can replicate its aesthetic, and perhaps the desire to use a realistic style is in some way a response to the massive narrative and mechanical disconnect noted earlier. They keep pushing this aesthetic harder, and though they still shy short of presenting the screams of agony, the begging for mercy, the child casualties, how long before they wear this, too, as aesthetic? How long before the fans defend these choices, as well, as being ‘realistic’ to the war portrayed, when realism is the furthest thing from the mechanics of the game experience?

Maybe this all seems very alarmist, but the reason why this bothers me is how often people who advocate real actual war position themselves as being realists, as just being pragmatic, when they talk about the necessity of armed conflict. The way we frame discussions of war as being willing to do what’s necessary, willing to see a hard thing through, it seems similar to the way we smear dirt and blood over things to make them seem real and true, wearing the aesthetic of sacrifice instead of trying to understand what is lost. And, to be clear – this isn’t just games. We wear blood and suffering as a costume, while quietly shuffling past all the actual blood and suffering, in all sorts of media.

So perhaps it’s just market forces that make it so every game that’s about being a person, about real and painful loss, looks like a cartoon – while every game about getting to be a cartoon, about being Itchy and Scratchy killing each other over and over again, looks like footage from a war zone. Perhaps I’m just worried about where the market is forcing us, and what will happen when we get there.

Games, as a medium, have been rediscovering the art of the secret, of the hidden. For a while, around the mid ’00s, it was incredibly rare for games to be anything beyond just what they appeared to be – and no more. The major studios didn’t want to pay for work that wouldn’t go directly into selling a game on day 1, and smaller indie games hadn’t really emerged into the market enough to fill the void left behind. Everything was exactly as it looked like. Surprise was dead.

It wasn’t just cowardice that made games so boring and averse to surprise: A substantial problem emerges when you make a game not what it appears to be, which is that, naturally, it no longer appears to be what it is. The problem with hidden depths is that they’re hidden, and many people who would love to explore those depths will never know there is anything to be explored. How can you sell a game like that?

Fortunately times have changed. Now that there’s a scale for game development below the nine digit development cost, we have a lot more leeway to make games that play with expectations. There’s room now for games to be strange and surprising, for them to have big secrets or sudden shifts.

One of the games most well-known for not being what it appears to be is Frog Fractions – and, at this point, if you have any interest in the idea of secrets and discovery in games and haven’t played Frog Fractions, now might be a good time to check it out Frog Fractions is, to first appearances, an educational game – this is, of course, just a facade. Underneath the surface, Frog Fractions becomes a series of strange, divergent mini-games that tell a surreal story about a frog’s adventures through space, with detours for a fanciful description of the invention of boxing and an exploration of the economics of bug pornography. One of the criticisms of Frog Fractions is that it fails to maintain plausibility as an educational game, being obviously absurd and lacking in educational value from the first moment. How, though, could this problem be fixed? This absurdity is necessary in order to signal that there’s something off about the situation, something to be uncovered, something to be found.

So we find we run into the same problem as before: How can you sell a game that is other than it appears to be? Not just in the sense of getting people to pay money, but even just getting people to pay enough attention to actually see the game for what it is. Holding something in reserve is an act of tremendous confidence as an artist, because it necessitates withholding the most special and exciting aspects of your project so that they can emerge later. Yet, still, you must have some way of signaling that something has been withheld, that something is hidden beneath, otherwise your audience continues sailing along the surface, unaware that anything unknown might hide within the depths.

A number of strategies seem to have emerged. Frog Fractions, as mentioned, is just a little bit too absurd, too out there to be quite what it appears to be. Dark Souls has messages from players scattered around, ensuring that those hidden things which a few players stumble across by pure chance can be found by other less observant or lucky players. Games like Axiom Verge, Anodyne, and Problem Attic signal that there’s something off in the world through the symbolism of video game glitches. Other games, such as Candy Box, just ask you to spend enough time with the game that the weirder elements of it will eventually become apparent to you just through exposure. Undertale uses all of these tricks to tell a stranger, scarier, and sadder story than it at first appears to.

Secrets are wonderful, but the only secrets we know are the ones we find – others fade away, merge into the vast sea of things we don’t know and never will.. It doesn’t help anyone if we squirrel around, hoarding nuts for the winter, only to forget where they have been buried and have all our work come to nothing.

EveHeader

I’m doing a terrible job of sticking to the schedule I came up with. I keep getting sidetracked by new tasks, improvements or things I forgot to put on the schedule. This last month, I finally got around to looking up what sorts of multi-threading solutions are available in Haxe/AIR. It turns out that Adobe AIR has supported multi-threading for a while now, with an implementation that is both very straightforward and kind of frustrating. AIR’s version of multi-threading is: Load another AIR program into your running program, and pass values back and forth. Simple enough in concept, but it still has all the traditional concerns of multi-threading with sharing resources and managing access.

So, much of this past month has been taken up with trying to get my particle system, the most demanding discrete subsystem of EverEnding, running in a separate thread. It took a lot of thought and experimentation to figure out a way to restructure a system which had presumed open access to a shared memory pool and make it run remotely with operations mediated by a single point of communication. After a week or two I got it running, but… not especially well. The benefit of the new system is a bump from 45fps to 50fps, which is not as dramatic or life-changing as I’d hoped — plus, for some reason, there are spikes of 30-50ms, which make the overall effect still somewhat disjointed and unpleasant. Still, I think these problems will be fixable, though it may be tricky to figure out exactly how they’re manifesting.

Aside from that I’ve mostly been working on building out the last section of the first area, the caves. I think I’m finally starting to nail down a paradigm of tile design for this game, based around the idea of areas which are lit, areas which are dark, and areas which are somewhere in between. Lit areas are mostly on the upper right and dark areas mostly on the lower left, with various transitional tiles to make them flow smoothly from one to the next. The cave tileset is starting to come together, though certain tiles still need some work. The background could use some improvement as well.

caves00

Also, looking back through my daily devblog notes, apparently I worked on collision in February as well. Strange, it feels like much more than a ago now. Well, most of the collision improvements are in place and working, but in the process some things broke, so those will need to be re-fixed. It’s basically guaranteed that any time I work on collision code I’ll end up frustrated.

So what’s next? I’ll probably focus on developing the level architecture and tilesets until I’m completely done with the caves, then go back and focus on populating this first area with enemies and details. Along the way somewhere I’ll spend a few days fixing all the things I broke getting the new particle system implemented and see if I can fix weird glitches there, as well as maybe a bit more collision work (sigh).

EveHeader

It’s been kind of a strange month for the project. I’ve made next to no progress on the task list I’ve created for the game, but I’m still largely satisfied with the work I’ve done. That is to say, I’ve been putting a lot of time in on things that it hadn’t previously occurred to me I would need, so I can’t really cross anything off a list when I get it done, but nevertheless the tasks I’ve done needed doing.

So, what are these tasks?

  • Created a system to modify hue/saturation/brightness of animations, and implemented controls for this into existing particle systems and associated editors, as well as creating a similar system for modifying tileset colors
  • Fixed up the detail editor to make it more flexible and easy to use, including the ability to modify multiple details at once
  • Created a seeded random number generator so particle systems that use random numbers will generate consistently from one play to the next
  • Created a simple collision system for particles, which can be used to make them only spawn on top of tiles or perform special behaviors when they collide with tiles
  • Added the ability to have particle behaviors that only trigger once on spawn rather than updating continuously
  • Collision improvements and implementation of water tiles and combination platform/slope tiles
  • Fixed the way perspective is calculated on details to center the vanishing point rather than have it locked to the upper left
  • Stripped out a non-functional zoom in/out system in favor of a much simpler one that actually works
colorchange

With all these color controls I have a lot more ability to customize areas without creating all-new assets

On top of that I’ve been building levels out, which is on the list but also takes a long time to make progress on. It’s really difficult to say much about the process of building levels, because 90% of it is just spent on making sure tile boundaries line up and making tiny aesthetic tweaks. In that way it’s a lot like working on the animations after I created prototype animations: All of the concept is mostly there, I just need to elevate it to finished quality.

I’m getting close to the end of my ad-hoc list of unexpected and unscheduled problems/improvements, so I ought to be getting back to the game schedule soon. Worst case scenario is I’m a month behind of where I wanted to be: Best case scenario is that I end up making up the time I lost by leveraging some of the improvements I’ve made. We’ll see. In any case, I’m probably going to be spending the coming month or two getting early-game enemies fully animated and operational. The first couple of enemies will be the most difficult by far, I believe – after those are complete I should be able to copy and paste from them for almost everything I’ll ever need an enemy to do.