Archive

Tag Archives: Eve

I always hate doing these updates where there’s not a lot of progress to report. The last couple of weeks in particular have been devoid of any progress on the project, or even any work on it – at first because of a shoulder injury, which was making it particularly difficult to focus on any of the complex problems I needed to solve to work on the code part of the project, and then on a short family vacation. Before that, I was working regularly on the project – well, except for the week or so where the new meds I was trying out were making me too groggy to think straight – but, still, not making a lot of progress.

Part of the problem with working on a project the size of a game is that sometimes even the components of the project, the discrete chunks you’ve written down as tasks on a task list, come to substantial undertakings in their own right. Especially when one’s focus is split between several of these, it can be entirely possible to spend a lot of time working on them, not running into any particular roadblocks and making what feels like good progress in the moment, and look back and not see anything new actually finished. This is basically how things have been for the last month – In particular, the storytelling system has taken much much longer than I’d expected it to, leading me to do a bunch of rewriting of the music system. The reason why the music system had to be rewritten was so that I could readily sync the storytelling lines with the music when I wanted to, in a way which I didn’t have to custom code for every story and every music track. I now have a system where any music track playback can intelligently jump around – that is, once I put in a number of valid points it can jump to in a track, say if a certain section can end in three different ways, I can give it a destination range in the music and it will find the shortest path to get there. I didn’t expect to have to read up on pathfinding algorithms for my music code, but here we are.

Now that I’ve got that component of the storytelling system figured out, there’s still one major roadblock to finishing it: Text rendering. This is something that should be easy in Flash/AIR, but just due to how I have entity rendering set up is a bit tricky. At this point, I have two options: Either I modify the entity rendering system, which would be a nuisance but not too difficult, or I find a way to convert the text into graphics rendering commands that I can send to the entity draw command queue. I’ve found a library that does this, but it hasn’t been updated for 8 years, so it might not be an ideal choice. If it doesn’t work out and I don’t find an alternative, though, then I’ll just have to rewrite the entity draw command system, because writing a whole text renderer to handle this problem would be an obscene waste of time, albeit presumably an educational one. At some point, as well, I’ll have to create a typeface for the game to use, possibly several. I think that will be fun.

The other two major things I was working on last time were the health bar and the awakening animation. The awakening animation has turned out to be a bit of a quagmire as well – I had the motion of standing and grabbing the weapon looking pretty good when I realized that I hadn’t really planned out how it was actually going to fit into the level where it was supposed to happen. This was something I can only describe as an extremely foolish oversight on my part. I’ve begun reworking the animation and I think I figured out a way to do so without completely starting over (again), but it required me to redraw the tree which was the main prop in that area. Honestly, I’m glad I was forced to do so, because the previous tree looked pixelated in a way which I had thought looked okay – but, I can see now, really did not. It looks much better now.

Of course, now I have to be concerned that making this tree look better will make the rest of the game look worse in comparison, and lead to an endless cycle of revisions. For now I’ll just have to enjoy the journey I guess, because I can’t say when things will start looking ‘good enough’ to me.

As for the health bar, progress is being made on it, but the storytelling code took priority and I didn’t want to split my attention between two programming tasks. I’ve also been working here and there on music for the next area, but though I have a number of promising ideas down, most of which will probably find their way into the finished version somewhere, none of them really feel like the right place for the song to start. For now, there, too, I keep experimenting, waiting to be visited by the spirit of satisfaction.

So, for this next month, I intend to finish the storytelling system, finish the awakening animation, finish the health bar. From there I’ll probably start in on other necessary animations – though I also think it quite likely that I’ll look at the tilesets I have to bring their level of quality up to this tree asset. It’s gotta be about the pleasure of the journey, because at this point I have frankly no idea when this project is going to go anywhere. I wish I knew how to work on it faster, but at this point it seems like it’s work slowly or not at all, and hope one day to accidentally, habitually, fall into a more rapid pace.

Advertisements

Another month has gone by, and though a short vacation, a nasty little cold, and a number of other minor distractions got in my way, I still managed to make a little bit of progress.

First, and most importantly, I put quite a few hours into writing the music for the first boss of the game. I may have gone a little bit overboard on this one: The concept I wanted to pursue was a track with multiple phases that mapped to different parts of the boss encounter, bouncing back and forth between them until finally reaching a conclusion. I’m not sure if I can possibly create a boss encounter that stays interesting long enough to accompany this track, coming in at almost 9 minutes long, but it will be fun to try once the rest of the chapter is complete.

The phases of the track are:

0:00-1:47 Intro
1:47-4:13 The Chest
4:13-6:16 The Mask
6:16-7:49 The Heart
7:49-8:40 Conclusion

This one honestly ended up getting quite a bit out of hand, and I spent quite a bit more time than I’d originally expected to on it, but I’m quite pleased with how it turned out. I also just enjoyed doing music work again! I’m going to carry on with composing the soundtrack even though I’ve effectively completed all the tracks for the first chapter of the game now, which is the part of the game I’m focused on finishing. The reasons why I’m going to continue doing music work, despite otherwise attempting to contain my efforts to this first chapter, are several-fold: first because, as mentioned, I like making music and I want to do more of it, second because if I can’t make this game in a timely fashion I can damn sure make its soundtrack, which is a discrete sub-creation that I can be proud of in its own right, and third because I find music so compelling that I think just having the soundtrack to the game will motivate me more to finish the rest of it. There’s also a fourth, more pragmatic reason: Inspired by UNDERTALE’s soundtrack, I’m really trying to integrate motifs from different characters and locations into tracks with a narrative connection to those characters and locations. It’s going to be really hard to do that until I know what those motifs, for later parts of the game, actually are! I’m not really going to be able to consider chapter 1’s soundtrack complete until I’ve written the rest of the soundtrack and know better what my overall thematic tools and goals are.

Anyway! Aside from music, I’ve been working on a few things. I’ve been feeling my way around programming the main narrative component of the game, the storyteller. This is going to be something pretty similar to what Supergiant does in their games with an ongoing narration element, except I would like to integrate these narrator lines a little bit more closely with the music, syncing the lines up with particular parts of the track and so forth. Additionally, I want to have text appear in the world synced with the audio, so it’s a bit like playing a storybook. Figuring out how I’m going to pragmatically handle the synchronization of these elements and making them play nice with a player who may or may not be interested in the narrative taking place is going to be a challenge, but I’m getting close to having a simple version ready to test so that I can iterate on it.

I’ve also been thinking a lot about what the interface of the game is going to look like. There are really only two elements that need to be displayed under normal circumstances: The player’s current health, and how many sparks you’ve collected, which also maps to your max health. I could just have a red bar along one side of the screen, but that felt inelegant. A sphere that fills and empties like the health meter in Diablo might have been a bit more thematic, since there’s some sun/moon symbolism I’m playing with in the game, but it felt like a circle would take up a lot of screen real estate for how much info it would impart and probably wouldn’t look very good. What I’ve come up with instead is an idea that’s… actually a little bit difficult to express here. It’s basically a life bar along the left side of the screen, except it looks like an engraved stone tablet. Only a small part of the tablet is visible early on, but as you gain more power the tablet expands and you can see more of it, and the engravings on it. I can actually directly tie the health meter into the narrative of the game in what I think is a pretty interesting way. However, because you don’t gain power at a constant rate, but instead end up collecting more and more as you defeat more powerful opponents, I’m going to have to figure out a curve that reveals the tablet at a rate that’s satisfying over the course of the game. I have a logarithmic function in mind that may work well, but it will have to be tested. I’ll also need to figure out how to have the tablet build up in such a way that it feels satisfying, and ensure that no matter what its interim shape is it still gives satisfactory feedback as a health meter. This will all take a bit of experimentation, but it’s an idea I’m excited about.

Finally, I’ve been working on the game’s first animation. I mean, I’ve already built several animations, but this is the first one that will play in the game: The player character awakening, standing up, and taking her weapon at the very beginning of the game. I started creating this animation, and then had to start over after working on it for a few hours because my first take on it sucked. I think my second take on it has potential, though it’s still very rough the motion feels good to me.

The actual removing-sword part of the animation still needs to happen, and of course all of the detail and the tween frames need to be added, but I think I’m on the right track this time.

So, the plan for August is to finish working on these things, write the music for the first area of chapter 2 (I’ve already started), create more main-character animations, and maybe get some basic sound design in. Of course something else may capture my fancy and I’ll end up working on that, but as long as I stick to my big task list I think I can maintain forward progress.

Well, I’m back to working on EverEnding. That side-project ended up being exactly what I didn’t want it to be, an excuse to work on a whole bunch of tools without ever making an actual game to go with them. We’ll call it a learning experience. What did I learn? I learned that I have a habit of avoiding the scary unquantifiable parts of a project in favor of working on parts that feel like safe investments – that I feel, somewhere inside myself, that if I pour my efforts into making tools and systems that that’s a safer gamble to me than pouring them into the actual core of a game. Art is scary! The more time you have to put into making it, the scarier it gets – in the first place, making art is like putting a message in a bottle and letting it out to float on the sea, and it only gets more stressful when you spend more than a year creating that message. The solution is not, I think, to spend another year developing new bottle and paper and ink production facilities to make creating each message that tiny bit less terrifying, but it’s an appealing option to take whenever it presents itself.

Oh, also in addition to those big existential questions I guess I learned a lot about making a scripting system and working with OpenFL. So that’s good too.

Once I decided I’d basically dead-ended, it was clearly time to head back to EverEnding. However, I’d left the project in uh… not a great place. I’d completed about half of the OpenFL port, and lots of systems weren’t running and I’d left lots of bugs in the systems that were running. Eventually, after lots of debugging and deliberation, I ended up rolling back a number of the changes I’d made and reverting back to Adobe AIR… for now. The reason for this is that switching to OpenFL would not only require me completely rewriting all my rendering systems, it would also make a couple of the special effects I’m planning extremely difficult. I really want to be actually working on a game now, so I figure rather than resolving all these issues right away I can defer them for a while. A big thing that enabled that is that OpenFL now supports Adobe AIR as a target platform, so with a few checks in my code to handle cases that are unique to OpenFL (most of which I’d already implemented) I can have something that can run on that version of OpenFL with no changes and, perhaps soon after, build to other OpenFL target platforms. Even if I’m not prepared to implement OpenFL just yet, with my experimentation here and with the side-project I think I have a pretty good idea how I’ll handle it when that time comes.

So, back to working on EverEnding: There were a few big design decisions I’d been deferring, one of which was specifically how to handle the narrative of the game and the other was creating some sort of special moves the player could unlock over the course of the game. I think I figured out a good system for creating a narrative in the style of sort of a story-book, with narration synced to music and text fading in – this is probably something I’ll want to prototype, though, to make sure it actually feels right. The special moves are like 75% figured out, but only the smallest slice of that stuff will be in the first chapter of the game, which is the one I’m focusing on right now, so I can figure out the last of that later. After I got that stuff basically sorted, I created a big task-list for creating chapter 1 of the game. I already had a task-list, but I made one that was bigger and more thorough, and had accompanying time estimates for each task. I tried to overshoot every estimate, but if they’re accurate than I have something in the region of 1300 hours to put into the project before the first chapter is complete. That’s a lot. Then again, I’ve put that much time into TF2, and I didn’t even make that game.

I have my work cut out for me. I’m going to start scheduling myself a bit more strictly again, though I may only get a few days to work to that schedule before I have to leave for a family thing, but with all this down and planned out I feel – well, not exactly optimistic, but determined I guess. I just turned 35, I’m starting to get the tiniest bit of grey in my beard, I got a blood pressure monitor for my birthday. I really do need to actually finish a project.

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.

Oh well this is awkward.

Effective, um, like 5 days ago, the EverEnding project is going on hiatus. For how long? I’m not sure! I’m pretty confident it’s not permanent, but I’m also pretty confident it’s going to be for at least a month or two, and maybe as much as a couple of years depending on how those next couple months go.

The natural question to ask at this point is: Why? Good question! I’ve been feeling for a while that, while I still feel passionate about this project, I also have it backwards. I really feel that the optimal game development process is about getting a simple version of the game up and running and then iterating on that and navigating by your artistic sense towards the most interesting version of that game. However, with EverEnding, I’m constantly stopping and planning and designing and concepting before I even have part of the system up and running. This is still true even now when, OpenFL port notwithstanding, there’s nothing stopping me from getting the game playable and iterating on that bit by bit and improving it that way, rather than constantly trying to make Big Design Choices and Sweeping Revisions. I keep thinking about the forest that will grow here someday and forgetting to plant the trees.

Which segues naturally into what I’m going to do now: I haven’t decided. Or rather, I’m specifically avoiding deciding anything but the most basic generalities of the project. It is going to be a game, and I’m going to be streaming its creation – I dunno if it’s a stream anyone will be interested in watching (so far it seems not to be, judging from the 4 streams I’ve done already) but these streams are just as much for me as for any hypothetical audience. The streaming is to keep me honest, keep me focused on the task at hand for a couple of hours with no web browsing or procrastinating. It also provides a way to document the history of the project, so I can see exactly how much progress I’ve made in a week or a month or a year from now.

Now, while I’m trying to avoid deciding as much as possible, I know this much about the project: First, it’s a top-down adventure game in the vein of the Zelda series. Second, it takes place in one big area instead of discrete dungeons, probably a mansion, possibly haunted. Third, I want to fill it with secrets and details, most of which I’ll figure out on the fly as I work on it. Right now the working title for the game is The Third Story, as a slight play on words both for a large mansion and for uncovering the stories contained therein, but that’s likely to change any time I think of something better. For the time being I’ve been mostly just laying the foundational code – which is mostly pretty tedious to watch, likely one reason the streams haven’t been popping. However, as the project progresses I want to do all of the scripting and level-building within the game itself – so, once I reach that point, the streams will be a lot more level editing/scripting and a lot less walls of code.

That’s all in the future, though! For now, the game is just blocks that move around and spit text at each other – no graphics, no collision, no sound. I intend to keep up the monthly DevBlogs here, but the contents will be related to the new project. I don’t want to rule out the idea of doing more work on EverEnding, though: Since I’m developing this new thing in OpenFL, I should be accumulating a lot more familiarity with how things work in that API, and this may give me exactly the energy and confidence I need to finish the port and get the project up and running again. Also, just looking at and listening to the materials I’ve created already makes me a bit homesick for the EverEnding project, so I’m not sure how long I want to stay away… But I’m confident this is the right thing to do. For now.

I already feel tremendously better morale-wise, just being able to work on a project where I feel like it’s always moving forward. If nothing else, I’ll be able to apply some of the methodology I’m picking up here – not just in terms of OpenFL and game development, but also in terms of livestreaming and documenting development and using that process to bolster my creative energy.

It feels good to be seen – even when no one’s watching, just to be willing to be seen is worth a lot.

I’ve been procrastinating on writing this post, since it’s always galling to admit this: Very Little progress has been made on the project over the last month.

This is not to say I haven’t been working on it – though between a week-long trip and focusing on more immediate work to pay rent I have perhaps not been working as much on it as I ought to. The issue is more that most of the work I’ve been doing has involved slowly revising the code base to work in OpenFL, which really doesn’t give me a lot to show.

It can be discouraging sometimes when the project is in this state. In general I kind of enjoy the work of refactoring, streamlining, and optimizing that goes into revisiting an existing part of the code base like this. However, particularly when it comes to a major restructuring like this, it means there’s a long period of time where the game as a program that can be run and experimented with ceases to exist. Right now, when I want to work on EverEnding, there is precisely one part of the project available for me to work on, and that’s this programming work. Not even especially interesting programming work, at least for now – once the fundamentals are in place I’ll also have a job of making sure the drawing routines are optimal and testing/improving the replacement displacement map filter code I wrote (as it turns out shader programming wasn’t necessary to create it, but I may look into creating a version implemented that way once I have this version working).

For now, there’s not much to say. I don’t know, a lot of the time I feel like I might just be wasting my time here, like I don’t know how to access the kind of discipline and productivity to make a project of this scope feasible, at least not in my current living situation. I wonder a lot if a different project might be a faster or better way to achieve the expression I have been straining towards with EverEnding, or if there’s some way to scale back or streamline this game conceptually which would allow me to work on it in a more effective and productive fashion. It is always difficult to tell which doubts are warning signs to be taken seriously and which are just self-sabotage.

Regardless, I am nearing completion of the changes I’ve made to the Particle System to make multi-threading stuff entirely self-contained within the system itself so I don’t need to negotiate that in the game program, as well as I guess in any other games I hypothetically make with the same tool in the future. There’s definitely a hint of programmer-itis there, where I find myself creating a more general purpose and fool-proofed tool than is actually needed – after a certain point I just gotta accept that sometimes I take the long route just because I feel that it’s more proper, even if it’s less pragmatic. Within this week sometime I think I’ll be able to get back to more interesting work on the project. It sucks getting stalled, but it doesn’t last forever – and, regardless of my doubts about where all this will eventually go, I think I can pursue it with no regrets as long as I enjoy and believe in my process.

It hasn’t been an especially productive month for the project, but things are grinding forward. I decided I was still dissatisfied with the performance, even after all the improvements I made to the particle system a year or so ago, and so I’m working on getting the project running in OpenFL, an open-source project that emulates Flash/AIR’s API but builds in C++ and tends to be faster. This isn’t really a smooth process, since there are a few Flash features that didn’t get ported and the ways file i/o and multi-threading are approached are very different. The file system stuff is no big deal, and I believe I’ve fixed the issues emerging from that already, though since I’m still working on the other stuff I haven’t been able to build the game to test those fixes yet. The multi-threading thing is more difficult but I think I’ve got a handle on it now, and the challenging part is mostly sequestering my Flash multi-threading code away so that I can write the special cases that change from platform to platform without turning everything into a total spaghetti mess. The features that aren’t supported… might be an issue. The only one I’ve found so far that looks like a big deal is that OpenFL currently has no equivalent of the DisplacementMapFilter, the processing effect which I used to make that water effect I was so proud of and which I also would like to use for a few other special effects. I’m going to have to look into creating a replacement – which sucks, but might end up being a blessing in disguise, since this will be a fairly natural way to explore the wide worlds of shader programming and, indeed, of contributing to open source projects if my solution ends up being of sufficient quality to submit as an OpenFL component.

Aside from this, I mostly worked on building the behaviors for the Feral enemy type which I shared a few sprites for last week. These behaviors are mostly finished now, but haven’t been tested yet since I didn’t have a complete set of sprites to test with – not strictly necessary, but since most of the code is reused from existing enemy types I’m not worried about any major malfunctions. I also realized a substantial obstacle towards completing the first area of the game was that I just wasn’t really sure what the space was supposed to look like. I had some vague ideas, but I didn’t know what the area’s history was supposed to be, what really was going on there now, or what the symbolism of it was. I spent a bit of time writing out some notes on it, and I’m confident that when I get the game working again and return to develop this area I’ll have a lot to work with.

My work is basically cut out for me now. Get the game building in OpenFL, handle any new bugs, rewrite the display code as necessary to take advantage of the improved performance. It’s always a bit of a drag getting railroaded into one big task that has to be done before I can make more substantial progress, but in this case there’s no way around it – particular as, in the interim, something weird has happened with my development environment to make launching the AIR version seemingly impossible. While I’m sure that will all get ironed out eventually, in the meanwhile it leaves me no avenue to working on the AIR version of the game, so really all I can do is drill in on the OpenFL port. Soon, at least, I’ll be able to take advantage of this tedious chore to tackle a field of programming I’ve been wanting to study for a while: Shaders.