etodd









Level 3 Re: MK-ZEBRA « Reply #43 on: February 22, 2016, 08:47:40 PM » New name [?]



To date, I have thrown out and rewritten the design doc and story seven times. This latest revision has lasted longer than the others, so I'm hopeful that it's the last.



"MK-ZEBRA" was originally a reference to







New humanoid model



I modeled, rigged, and animated a new placeholder humanoid model. It'll do for now.







Beneath a certain health threshold, the helmet opens to expose the head. It's not too visually distinctive. It'll probably get redesigned.







I'm using this to experiment with a "last-hitting" mechanic, as in a MOBA. You can't headshot an enemy until one of your ally units damages it.



Parkour



A while back I realized that I'm not quite done exploring the parkour mechanics in Lemma. There will be some parkour elements.



I'm taking the best bits from Lemma, refining them even more, and cutting out the garbage. With the new codebase, it's actually possible to build up momentum above the max speed, whereas Lemma killed your extra momentum whenever possible.



Here's the slide move filling in some transient yellow floor tiles:







Turrets, projectiles, particles



Things shoot each other. Lights flash. Sparks fly.







The red areas visualize the view range of enemy units. I hijacked the deferred point light renderer to overwrite the albedo color for those areas, rather than modifying the lighting buffer.



Also, film grain is gone.



Soren



This is a work-in-progress character. She's an AI who thinks she's a person, currently voiced by a text-to-speech program. The diamond frame grows and shrinks to match her voice.







Here's my amateur pixel art for her spritesheet:







Open source



The To date, I have thrown out and rewritten the design doc and story seven times. This latest revision has lasted longer than the others, so I'm hopeful that it's the last."MK-ZEBRA" was originally a reference to MKUltra . The story started out in the vein of paranoia fiction, but now it's drifted toward something hopefully a little less cliche. The current working title is "The Yearning". Let me know if you hate it. I have not yet encountered any major concerns with the new title.I modeled, rigged, and animated a new placeholder humanoid model. It'll do for now.Beneath a certain health threshold, the helmet opens to expose the head. It's not too visually distinctive. It'll probably get redesigned.I'm using this to experiment with a "last-hitting" mechanic, as in a MOBA. You can't headshot an enemy until one of your ally units damages it.A while back I realized that I'm not quite done exploring the parkour mechanics in Lemma. There will be some parkour elements.I'm taking the best bits from Lemma, refining them even more, and cutting out the garbage. With the new codebase, it's actually possible to build up momentum above the max speed, whereas Lemma killed your extra momentum whenever possible.Here's the slide move filling in some transient yellow floor tiles:Things shoot each other. Lights flash. Sparks fly.The red areas visualize the view range of enemy units. I hijacked the deferred point light renderer to overwrite the albedo color for those areas, rather than modifying the lighting buffer.Also, film grain is gone.This is a work-in-progress character. She's an AI who thinks she's a person, currently voiced by a text-to-speech program. The diamond frame grows and shrinks to match her voice.Here's my amateur pixel art for her spritesheet:The entire repo is now up on GitHub. I'm retaining copyright on the assets, but they're available for download, and all the code is MIT licensed. « Last Edit: February 26, 2016, 05:30:35 AM by etodd » Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #44 on: March 21, 2016, 09:20:59 PM » Train Jam



I was lucky enough to snag a



Here's my entry,







Roscoe



I got hired to make a secret game embedded in a website footer.



Right, on to the real stuff!



Design overhaul



The past couple months, I've been overhauling gameplay, going in some wild directions. The following is a synopsis of my "design" process (emphasis on the scare quotes).



Goals



The game has two main aspects. At any given time, you will be either a) parkour-exploring cool environments, or b) facing off against another player online.



Target emotions for parkour-land: freedom, delight, curiosity, relaxation. Basically the same goals Lemma had, or should have had. I'm not too worried about this mode; I've done it before.



Target emotions for multiplayer-land: tension, fear, triumph. This is new territory, and will constitute the focus of the rest of this post. I want to replicate and improve the experience of playing a one-on-one, sniper-only, one-shot-kill round of Call of Duty. Maybe the players only take 5 shots the whole game, but they're constantly trying to predict each other's moves and out-maneuver the opponent.



Detour into MOBA-land



In an attempt to improve on the CoD sniper idea, I tried to identify the things that make it interesting. I thought maybe the long-term player interaction differentiated it from your typical free-for-all CoD frenzy. The longer you're alive, the more interesting your interaction with the enemy becomes. As soon as you die, everything is reset and lost. I wanted to facilitate more methods of player interaction that didn't involve death.



I don't know much about MOBAs, but I think they have a lot of non-player-death interaction. Players are generally alive for a long time; dying is a big deal. And plenty of successful players go through a whole game without killing another player.



So I tried to identify compelling MOBA elements that could be transplanted into my game without too much fuss. I added auto-spawning minions, turrets, and big, granular health bars.







Only minions could attack turrets. Players could kill minions with a headshot, but only once the minion's health dropped beneath a threshold, which opened their helmet. This forced players to stay behind their minions and try to last-hit enemies.



Players could still kill each other with one or two hits, but it became a risky proposition to venture into enemy territory. I decided to visualize view ranges around enemy units to make it clear exactly where an enemy would start attacking. A bit like fog of war.



I hoped that all of this would give players more ways to interact with each other, albeit indirectly, killing minions rather than each other.



Progression



Again, I don't know much about MOBAs; I just can't get into them. But they clearly work for people. I wanted to extract the fun from them. I played a few (admittedly short) games of LoL, and more importantly, collected some feedback from MOBA players. I discovered there is no single feature that defines a MOBA, but one feature seemed at once pivotal and easy to transplant: player progression. In a MOBA, everyone starts each game on a (hopefully) level playing field, and becomes more powerful as the game progresses.



Mainly, they progress by leveling up their abilities. I decided to steal this, along with the idea of a team score.







Here I also experimented with colors, trying to brighten everything and make it more appealing, like a MOBA.



Killing enemy minions and players gave credits, which could be spent on abilities. Kill the enemy player five times to win. Easy. Ship it!



Problems



At this point, everything has at least 50-100 HP. I kept player attacks pretty powerful, but minions take around 30 seconds to wear each other's health down. In true MOBA fashion, they just stand still attacking until somebody dies. This works fine in a top-down RTS-like setting, but not in a "visceral" first-person game.



In general, my detour into MOBA-land was missing some of my target emotions, namely tension and fear. Giving players five lives, turning everything into bullet sponges, and brightening the graphics all worked to lower the tension. I could see that with some polish, the MOBA elements would accomplish the goal of long-term player interaction, but at the expense of everything else.



Backpedaling



I'm now back to the original prototype: you get one life. I think this is more impactful than an arbitrary score number at the top of screen.



I'm also back (way back) to darker colors. The vibrant, beautiful colors I love still have a place in parkour mode, but here the colors need to be dark and maybe even discomforting.







I also switched the reticle from a diamond to an inverted triangle, for several reasons. First, triangles are aggressive, especially inverted triangles. I noticed just that small change evokes a much more hostile feeling than the relatively peaceful diamond shape. Second, triangles and non-square angles are a theme I want to explore in this game, since my last game was all squares. I keep finding squares I've added instinctively and converting them to triangles.



Salvaged ideas



My goal now is to facilitate long-term player interaction without sacrificing tension. I'm keeping the "fog of war" idea, and even making it more central. Map control is one element I noticed was critical to MOBAs. I'm now experimenting with having players place proximity sensors around the map which "capture" areas. Maybe a bit like Splatoon.



Abilities and player progression are also staying, although I'm simplifying them so that only one ability can be equipped at a time.







Wrapping up



All this has not been very productive in terms of features making it into the final product, but I see it as a necessary step of my patent-pending "design by trial-and-error" process. The key is to have a set of design goals which you can use to judge potential ideas. Some of these crazy MOBA ideas work toward my goals, and so remain, while others get cut. Previously, my design goals have been, "make something I like".



I went to a great GDC talk about the narrative design of Dragon Age Inquisition's DLC. The writers picked movie references for their story; one was Captain America Winter Soldier; the other escapes me at the moment. But these two movies gave the whole team familiar references from which they could make decisions on every little detail of the game.



That's what I'm trying to do. I don't have any movie references for the story yet, but I'm looking. Unfortunately my movie literacy is pretty abysmal. I was lucky enough to snag a Train Jam ticket this year! Got to meet a ton of lovely people, hang out and talk shop, and of course play some of the amazing games they made Here's my entry, Haunted Heist , a 3D browser game. Rob a haunted mansion!I got hired to make a secret game embedded in a website footer. Check it out. Right, on to the real stuff!The past couple months, I've been overhauling gameplay, going in some wild directions. The following is a synopsis of my "design" process (emphasis on the scare quotes).The game has two main aspects. At any given time, you will be either a) parkour-exploring cool environments, or b) facing off against another player online.Target emotions for parkour-land: freedom, delight, curiosity, relaxation. Basically the same goals Lemma had, or should have had. I'm not too worried about this mode; I've done it before.Target emotions for multiplayer-land: tension, fear, triumph. This is new territory, and will constitute the focus of the rest of this post. I want to replicate and improve the experience of playing a one-on-one, sniper-only, one-shot-kill round of Call of Duty. Maybe the players only take 5 shots the whole game, but they're constantly trying to predict each other's moves and out-maneuver the opponent.In an attempt to improve on the CoD sniper idea, I tried to identify the things that make it interesting. I thought maybe the long-term player interaction differentiated it from your typical free-for-all CoD frenzy. The longer you're alive, the more interesting your interaction with the enemy becomes. As soon as you die, everything is reset and lost. I wanted to facilitate more methods of player interaction that didn't involve death.I don't know much about MOBAs, but I think they have a lot of non-player-death interaction. Players are generally alive for a long time; dying is a big deal. And plenty of successful players go through a whole game without killing another player.So I tried to identify compelling MOBA elements that could be transplanted into my game without too much fuss. I added auto-spawning minions, turrets, and big, granular health bars.Only minions could attack turrets. Players could kill minions with a headshot, but only once the minion's health dropped beneath a threshold, which opened their helmet. This forced players to stay behind their minions and try to last-hit enemies.Players could still kill each other with one or two hits, but it became a risky proposition to venture into enemy territory. I decided to visualize view ranges around enemy units to make it clear exactly where an enemy would start attacking. A bit like fog of war.I hoped that all of this would give players more ways to interact with each other, albeit indirectly, killing minions rather than each other.Again, I don't know much about MOBAs; I just can't get into them. But they clearly work for people. I wanted to extract the fun from them. I played a few (admittedly short) games of LoL, and more importantly, collected some feedback from MOBA players. I discovered there is no single feature that defines a MOBA, but one feature seemed at once pivotal and easy to transplant: player progression. In a MOBA, everyone starts each game on a (hopefully) level playing field, and becomes more powerful as the game progresses.Mainly, they progress by leveling up their abilities. I decided to steal this, along with the idea of a team score.Here I also experimented with colors, trying to brighten everything and make it more appealing, like a MOBA.Killing enemy minions and players gave credits, which could be spent on abilities. Kill the enemy player five times to win. Easy. Ship it!At this point, everything has at least 50-100 HP. I kept player attacks pretty powerful, but minions take around 30 seconds to wear each other's health down. In true MOBA fashion, they just stand still attacking until somebody dies. This works fine in a top-down RTS-like setting, but not in a "visceral" first-person game.In general, my detour into MOBA-land was missing some of my target emotions, namely tension and fear. Giving players five lives, turning everything into bullet sponges, and brightening the graphics all worked to lower the tension. I could see that with some polish, the MOBA elements would accomplish the goal of long-term player interaction, but at the expense of everything else.I'm now back to the original prototype: you get one life. I think this is more impactful than an arbitrary score number at the top of screen.I'm also back (way back) to darker colors. The vibrant, beautiful colors I love still have a place in parkour mode, but here the colors need to be dark and maybe even discomforting.I also switched the reticle from a diamond to an inverted triangle, for several reasons. First, triangles are aggressive, especially inverted triangles. I noticed just that small change evokes a much more hostile feeling than the relatively peaceful diamond shape. Second, triangles and non-square angles are a theme I want to explore in this game, since my last game was all squares. I keep finding squares I've added instinctively and converting them to triangles.My goal now is to facilitate long-term player interaction without sacrificing tension. I'm keeping the "fog of war" idea, and even making it more central. Map control is one element I noticed was critical to MOBAs. I'm now experimenting with having players place proximity sensors around the map which "capture" areas. Maybe a bit like Splatoon.Abilities and player progression are also staying, although I'm simplifying them so that only one ability can be equipped at a time.All this has not been very productive in terms of features making it into the final product, but I see it as a necessary step of my patent-pending "design by trial-and-error" process. The key is to have a set of design goals which you can use to judge potential ideas. Some of these crazy MOBA ideas work toward my goals, and so remain, while others get cut. Previously, my design goals have been, "make something I like".I went to a great GDC talk about the narrative design of Dragon Age Inquisition's DLC. The writers picked movie references for their story; one was Captain America Winter Soldier; the other escapes me at the moment. But these two movies gave the whole team familiar references from which they could make decisions on every little detail of the game.That's what I'm trying to do. I don't have any movie references for the story yet, but I'm looking. Unfortunately my movie literacy is pretty abysmal. « Last Edit: March 22, 2016, 05:15:01 AM by etodd » Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #45 on: March 30, 2016, 07:23:37 AM » Design epiphany



Until recently, I thought of the game as a series of alternating levels: PvP level, parkour level, PvP level, parkour level...



That's a lot of content. It makes a lot more sense to design each level to work equally well in both contexts. First, you play the level facing off against another online player. The game overrides the level's color scheme and render settings to achieve the feeling of tension I want, and to communicate critical information about the game state.







Then you play the same level in parkour mode, where each level can look and feel wildly different.







It's not a new idea, plenty of games do this. The tricky part is tightening up the design so that each element in mode X serves a corresponding purpose in mode Y.



Custom nav meshes



For reasons not yet clear, I find myself in need of a bot-friendly method of navigating around a level.



Now, I already have a traditional nav mesh for bipedal bots, thanks to



But this bot needs to be able to shoot itself around the level, attaching to walls and ceilings like the player does. I need a different kind of navigation mesh for this.



Here's the plan:



Task 1. Sprinkle points across all the surfaces in the level.

Task 2. Do a bunch of raycasts to determine which points connect to each other.



Of course this is pretty compute intensive, so I do it at build time.



Surface parameterization



I try to code up task #1 live on Twitch, resulting in this:







Eh, it's a bit off. The problem is, I want the points to be regularly spaced in a nice grid on each surface. This is closer to what I want:











Here's the process I end up with:



1. Loop through each triangle in the scene.

2. For each triangle, calculate two "basis" vectors for the grid on the triangle.

3. Use a standard triangle rasterizer to generate all the points on the grid, projecting each one back into 3D space.



The end result works pretty well, although I'm still struggling with thin triangles slipping through the cracks of the grid, and with sampling around the edges of triangles. Here's a shot of a particularly bad configuration resulting in a lot of missed points:







Adjacency calculation



Next, I connect each point with up to 48 of its closest neighbors, like this:







Here you can see the sparse point sampling completely missed the walkway. Not good. I'll probably revisit this problem at some point.



It takes about 5 minutes to generate and connect ~4000 points. The raycasts are really slow. I end up splitting the level mesh into chunks, which speeds up the raycasts immensely. The whole process takes less than 30 seconds now.



Most of the points in the graph are maxed out at the 48-neighbor limit. The connectedness of the graph is insane.



Pathfinding



I code up a



Turns out, when each point in a graph has 48 neighbors, the computational complexity of A* explodes. Even a path of only 2 or 3 hops takes a good 30 ms to calculate. Granted, it's unoptimized, and I could also try another algorithm entirely, but I suspect any algorithm would struggle with this graph. The good news is, since the connectivity is so high, and since points can connect to each other across long distances, I probably won't see paths longer than 3 or 4 hops in practice.



I end up putting A* on a separate thread. Similar to the Until recently, I thought of the game as a series of alternating levels: PvP level, parkour level, PvP level, parkour level...That's a lot of content. It makes a lot more sense to design each level to work equally well in both contexts. First, you play the level facing off against another online player. The game overrides the level's color scheme and render settings to achieve the feeling of tension I want, and to communicate critical information about the game state.Then you play the same level in parkour mode, where each level can look and feel wildly different.It's not a new idea, plenty of games do this. The tricky part is tightening up the design so that each element in mode X serves a corresponding purpose in mode Y.For reasons not yet clear, I find myself in need of a bot-friendly method of navigating around a level.Now, I already have a traditional nav mesh for bipedal bots, thanks to Recast . It's super nice and can even be modified at runtime.Butbot needs to be able to shoot itself around the level, attaching to walls and ceilings like the player does. I need a different kind of navigation mesh for this.Here's the plan:Task 1. Sprinkle points across all the surfaces in the level.Task 2. Do a bunch of raycasts to determine which points connect to each other.Of course this is pretty compute intensive, so I do it at build time.I try to code up task #1 live on Twitch, resulting in this:Eh, it's a bit off. The problem is, I want the points to be regularly spaced in a nice grid on each surface. This is closer to what I want:Here's the process I end up with:1. Loop through each triangle in the scene.2. For each triangle, calculate two "basis" vectors for the grid on the triangle.3. Use a standard triangle rasterizer to generate all the points on the grid, projecting each one back into 3D space.The end result works pretty well, although I'm still struggling with thin triangles slipping through the cracks of the grid, and with sampling around the edges of triangles. Here's a shot of a particularly bad configuration resulting in a lot of missed points:Next, I connect each point with up to 48 of its closest neighbors, like this:Here you can see the sparse point sampling completely missed the walkway. Not good. I'll probably revisit this problem at some point.It takes about 5 minutes to generate and connect ~4000 points. The raycasts are really slow. I end up splitting the level mesh into chunks, which speeds up the raycasts immensely. The whole process takes less than 30 seconds now.Most of the points in the graph are maxed out at the 48-neighbor limit. The connectedness of the graph is insane.I code up a quick implementation of A* and run it.Turns out, when each point in a graph has 48 neighbors, the computational complexity of A* explodes. Even a path of only 2 or 3 hops takes a good 30 ms to calculate. Granted, it's unoptimized, and I could also try another algorithm entirely, but I suspect any algorithm would struggle with this graph. The good news is, since the connectivity is so high, and since points can connect to each other across long distances, I probably won't see paths longer than 3 or 4 hops in practice.I end up putting A* on a separate thread. Similar to the threaded renderer , I communicate with the AI thread via a simple bytecode protocol written to a pair of ring buffers. Results are returned via callbacks. « Last Edit: March 30, 2016, 07:35:40 AM by etodd » Logged

ashtonmorris







Level 2 Re: The Yearning (née MK-ZEBRA) « Reply #46 on: April 04, 2016, 01:35:59 PM »



If others agree, the perhaps it is something to think about. If its just me then feel free to ignore my isolated idiosyncrasies. Hey there! Its looking good still. Just wanted to chime in and say that for some reason the name The Yearning really doesn't sound pleasant to me. I can't put my finger on it but perhaps just the sound of the word yearning is a little off-putting.If others agree, the perhaps it is something to think about. If its just me then feel free to ignore my isolated idiosyncrasies. Logged



Roah * Bomblsinger * Goliath * Wings of Vi * Lemma * Bit Heroes * Star Command Galaxies





http://www.ashtonmorris.com



Twitter: Ashton Morris - Composer & Sound DesignerRoah * Bomblsinger * Goliath * Wings of Vi * Lemma * Bit Heroes * Star Command GalaxiesTwitter: https://twitter.com/ashtonmorris

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #47 on: April 05, 2016, 06:56:10 AM » Quote from: ashtonmorris on April 04, 2016, 01:35:59 PM I can't put my finger on it but perhaps just the sound of the word yearning is a little off-putting.



Hey, thanks for the honest feedback. I picked the name for reasons related to the story and overall meaning, but if the word rubs people the wrong way, there are plenty of others that can serve the purpose. Anyone else have an opinion?



Some other ideas dug up from my week of namestorming:



Qualia

Sense Gap

Strive / Striver Hey, thanks for the honest feedback. I picked the name for reasons related to the story and overall meaning, but if the word rubs people the wrong way, there are plenty of others that can serve the purpose. Anyone else have an opinion?Some other ideas dug up from my week of namestorming:QualiaSense GapStrive / Striver Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #48 on: April 14, 2016, 02:32:53 PM » Lead indicators



From the very first prototype, it's been difficult to hit small moving targets (like heads). For a while I tried setting the player speed super high, which mostly worked, but you still had to lead your targets. Finally I buckled down and implemented lead indicators, which show you exactly where to shoot. You can see it proceeding ahead of the minion in this gif:







It's pretty satisfying to aim out into empty space and see everything line up as you fly toward the target.



That progress bar and "DETECTED" warning are part of the new sensor system. If you linger too long in an area claimed by the enemy, they'll get alerted of your exact location.



Glitches



I keep encountering glitches which make the game look way cooler. I would like to find a way to incorporate a glitchy aesthetic into the game somehow.







AI player



This still needs a ton of work, but I'm making progress. The navigation graph is pretty much done, and I'm now able to display what the bot is seeing:







I'm currently using two behavior trees running in parallel, one high-level and one low-level, plus a super-low-level system responsible for aiming and shooting.



Level design envy



I imported a cool map somebody made for Quake 3, just to see what it would look like. Now I kind of want to hire the guy:







New test map



For now though, I have a new, non-copyright-infringing test map in the works.







Blender SSAO



Speaking of level design, someone on the







Control points



I wanted to imbue the sensor mechanic with more utility and depth, so I added "control points". Every 60 seconds, you receive a credit bonus based on the number of control points within range of your sensors. They look like this:







They're very unassuming, and there are no attendant UI elements, so right now they're pretty confusing. I'll eventually think of a good way to make them more obvious.



This shot also shows the new compass, which is less cool but more functional. The red and blue triangles point toward the respective spawn points of each team. I kind of miss the old compass rose though. We'll see if this one sticks around. From the very first prototype, it's been difficult to hit small moving targets (like heads). For a while I tried setting the player speed super high, which mostly worked, but you still had to lead your targets. Finally I buckled down and implemented lead indicators, which show you exactly where to shoot. You can see it proceeding ahead of the minion in this gif:It's pretty satisfying to aim out into empty space and see everything line up as you fly toward the target.That progress bar and "DETECTED" warning are part of the new sensor system. If you linger too long in an area claimed by the enemy, they'll get alerted of your exact location.I keep encountering glitches which make the game look way cooler. I would like to find a way to incorporate a glitchy aesthetic into the game somehow.This still needs a ton of work, but I'm making progress. The navigation graph is pretty much done, and I'm now able to display what the bot is seeing:I'm currently using two behavior trees running in parallel, one high-level and one low-level, plus a super-low-level system responsible for aiming and shooting.I imported a cool map somebody made for Quake 3, just to see what it would look like. Now I kind of want to hire the guy:For now though, I have a new, non-copyright-infringing test map in the works.Speaking of level design, someone on the stream the other day told me that Blender now supports SSAO in the editor view. Hit "N" in the 3D view to open the property pane, then turn on ambient occlusion:I wanted to imbue the sensor mechanic with more utility and depth, so I added "control points". Every 60 seconds, you receive a credit bonus based on the number of control points within range of your sensors. They look like this:They're very unassuming, and there are no attendant UI elements, so right now they're pretty confusing. I'll eventually think of a good way to make them more obvious.This shot also shows the new compass, which is less cool but more functional. The red and blue triangles point toward the respective spawn points of each team. I kind of miss the old compass rose though. We'll see if this one sticks around. Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #49 on: April 22, 2016, 12:47:38 PM » Friend/foe colors



This has bugged me for awhile. I use red in the UI to convey "bad"/"enemy". I also had two team colors: red vs blue. It was pretty confusing when you were on the red team.



Now there are no red or blue teams. It's just "friend" (blue) or "foe" (red). Here you can see both players are blue on their own screens:







Crawling is back



I uncommented it again. This time I turned the speed down pretty slow; it's not meant to be a major part of gameplay. It just alleviates some of the frustration of being rooted in one spot, and it gives you something to do while waiting for the movement cooldown. The AI player also has some rudimentary crawling code. It also exhibits inaccuracy when trying to hit targets.







Sensor system



Currently, placing sensors is an ability that comes equipped by default. It's on a 20-second cooldown timer, which is frustrating. You have to keep track of it in the back of your mind, and it just feels arbitrary. Today I realized it makes much more sense to just charge a certain number of credits to spawn a sensor. If you place it near an uncontested control point, it will eventually pay for itself.



I'm considering another idea with the sensor system, which is to make players invincible when they are within range of their own sensors. To damage an enemy in their safe zone, you would first have to destroy their sensors, which is a risky proposition.



Maybe there's an expensive ability later on that cancels the invincibility. This could be something that both players save up for in the late game.



Parkour



The parkour code is 75% done. I started to re-implement animations from Lemma. My test level is also starting to look half-decent.



This has bugged me for awhile. I use red in the UI to convey "bad"/"enemy". I also had two team colors: red vs blue. It was pretty confusing when you were on the red team.Now there are no red or blue teams. It's just "friend" (blue) or "foe" (red). Here you can see both players are blue on their own screens:I uncommented it again. This time I turned the speed down pretty slow; it's not meant to be a major part of gameplay. It just alleviates some of the frustration of being rooted in one spot, and it gives you something to do while waiting for the movement cooldown. The AI player also has some rudimentary crawling code. It also exhibits inaccuracy when trying to hit targets.Currently, placing sensors is an ability that comes equipped by default. It's on a 20-second cooldown timer, which is frustrating. You have to keep track of it in the back of your mind, and it just feels arbitrary. Today I realized it makes much more sense to just charge a certain number of credits to spawn a sensor. If you place it near an uncontested control point, it will eventually pay for itself.I'm considering another idea with the sensor system, which is to make players invincible when they are within range of their own sensors. To damage an enemy in their safe zone, you would first have to destroy their sensors, which is a risky proposition.Maybe there's an expensive ability later on that cancels the invincibility. This could be something that both players save up for in the late game.The parkour code is 75% done. I started to re-implement animations from Lemma. My test level is also starting to look half-decent. « Last Edit: April 22, 2016, 01:19:39 PM by etodd » Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #50 on: April 26, 2016, 08:02:05 AM » Third-person



When I've shown the game to new players, it usually takes a good five minutes before they even vaguely understand what's going on. I think the biggest point of confusion is: "what exactly am I?"



The game is so strange that they have no point of reference. If you're making an FPS or a platformer, people are familiar. But in this game, the combination of vector graphics and strange movement is a lot to take in at first.



Another problem is the fact that at any given time, you can't aim at half the screen because it's blocked by the wall you are attached to. It makes sense, but it's confusing to a new player in first-person because they don't even realize they're attached to a wall.



A third-person camera alleviates some of these issues. I realized that as far as gameplay, nothing is really lost in the switch to third-person, except for the perennial problem of what to do when the camera is inside a wall. Right now, I'm just culling everything in the way.







Ideally, I would still render blocking geometry, but with low opacity. In fact I'll probably do that eventually. This works for now though.



I've always had a janky third-person option (as seen in the previous devlog), so this was just a matter of cleaning it up and making it work for real.



Ability overhaul



Here are my gameplay goals:



Create tension by making it possible to be killed at any point in the game.

Encourage a lifecycle of progression through the early/mid/late game without destroying the tension.

Minimize the number of mechanics and wring everything possible out of them by making them interact with each other.

I'm using an ability system with upgrades to accomplish goal #2 (progression). I immediately thought of a bunch of crappy abilities like stealth, skip cooldown, invincibility, etc. You would buy these upgrades at your spawn, then switch between them in the heat of battle.



The problem is, these abilities obliterate goal #3 (interaction between mechanics). So you press a button to become invincible for a few seconds; that can become an interesting idea (see TF2) but on its own there's nothing else for it to interact with.



These abilities do nothing but augment your ability to kill the other player, which isn't very interesting. There's much more potential for interaction if instead you augment the environment.



I already had a bit of this, since you could spawn a minion by capturing a certain point. But that doesn't really allow player expression; it's just a checklist for the player to fill out. Capture points A, B, and C.



All this to say: I turned the minion spawn mechanic into an ability. I actually cut it down to three abilities: spawn sensor, spawn teleporter, spawn minion. And there are no cooldowns, it's just a flat fee for each item spawned.



Here's the new menu that pops up automatically at your spawn point. Hold one of three buttons to upgrade that ability.







Sensors and minions are mostly done, but I haven't even started teleporters.



Lots of work to do! When I've shown the game to new players, it usually takes a good five minutes before they even vaguely understand what's going on. I think the biggest point of confusion is: "what exactly am I?"The game is so strange that they have no point of reference. If you're making an FPS or a platformer, people are familiar. But in this game, the combination of vector graphics and strange movement is a lot to take in at first.Another problem is the fact that at any given time, you can't aim at half the screen because it's blocked by the wall you are attached to. It makes sense, but it's confusing to a new player in first-person because they don't even realize they're attached to a wall.A third-person camera alleviates some of these issues. I realized that as far as gameplay, nothing is really lost in the switch to third-person, except for the perennial problem of what to do when the camera is inside a wall. Right now, I'm just culling everything in the way.Ideally, I would still render blocking geometry, but with low opacity. In fact I'll probably do that eventually. This works for now though.I've always had a janky third-person option (as seen in the previous devlog), so this was just a matter of cleaning it up and making it work for real.Here are my gameplay goals:I'm using an ability system with upgrades to accomplish goal #2 (progression). I immediately thought of a bunch of crappy abilities like stealth, skip cooldown, invincibility, etc. You would buy these upgrades at your spawn, then switch between them in the heat of battle.The problem is, these abilities obliterate goal #3 (interaction between mechanics). So you press a button to become invincible for a few seconds; that can become an interesting idea (see TF2) but on its own there's nothing else for it to interact with.These abilities do nothing but augment your ability to kill the other player, which isn't very interesting. There's much more potential for interaction if instead you augment theI already had a bit of this, since you could spawn a minion by capturing a certain point. But that doesn't really allow player expression; it's just a checklist for the player to fill out. Capture points A, B, and C.All this to say: I turned the minion spawn mechanic into an ability. I actually cut it down to three abilities: spawn sensor, spawn teleporter, spawn minion. And there are no cooldowns, it's just a flat fee for each item spawned.Here's the new menu that pops up automatically at your spawn point. Hold one of three buttons to upgrade that ability.Sensors and minions are mostly done, but I haven't even started teleporters.Lots of work to do! Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #51 on: April 30, 2016, 11:06:29 AM »



I have a JSON file with all the localized strings in my game, like this:



Code: {

"danger": "Danger",

"level": "Level %d",

...

}



A preprocessor takes this and generates a header file with integer constants for each string, like this:



Code: namespace strings

{

const int danger = 0;

const int level = 1;

...

}



At runtime, it loads the JSON file and hooks up the integer IDs to localized strings. A function called "_" takes an integer ID and returns the corresponding localized string. I use it like this:



Code: draw_string(_(strings::danger), position);



This all worked (and still works) pretty well for UI strings. Not so much for dialogue.



To write dialogue, I had to come up with a unique ID for each line, then add it to the strings file, like this:



Code: {

"hello_penelope": "Hello! I am Penelope.",

"nice_meet_you": "Nice to meet you.",

...

}



Yes, the preprocessor generated a new integer ID in the header file every time I added a line of dialogue. Gross.



I construct dialogue trees in



A better way



I keep the string system, but extend it to support "dynamic" strings loaded at runtime that do not have integer IDs in the header file.



Now I can write plain English in the dialogue trees. The preprocessor goes through all of them and extracts the strings into a separate JSON file, using the SHA-1 hash of each string for its ID. Once everything is loaded, I discard all string IDs in favor of integer IDs.



I couldn't find a simple straightforward SHA-1 implementation that worked on plain C strings, so



The point of all this is: I now have a single JSON file containing all the dialogue in the game. Ripe for automation...



Speak and spell



Penelope is an AI character. I'm using text-to-speech for her voice, at least for now. I don't want to integrate a text-to-speech engine in the game; that's way too much work. And I don't want to manually export WAVs from a text-to-speech program. Also too much work.



I create a free



I write an



Now I have a folder of WAV files, each one named after a SHA-1 hash. I'm using







Now when I display a dialogue string, I just have to look up the SHA-1 hash and play the audio event. Easy.



Disaster strikes



I don't hear anything. All signs indicate the audio is playing correctly, but nothing comes out of my speakers.



I look at one of the audio files in Wwise.







Looks like the file is corrupted. I play the WAV in a number of different programs. Some play it fine, others don't play it at all.



I edit my text-to-speech script to use Python's



Too lazy to care, I edit the wave library in-place in my Python distribution. YOLO.



After a bit of printf debugging, I pinpoint the issue. The WAV format is based on



4 bytes: an ASCII identifier for this chunk (examples are "fmt " and "data"; note the space in "fmt ").

4 bytes: an unsigned, little-endian 32-bit integer with the length of this chunk (except this field itself and the chunk identifier).

variable-sized field: the chunk data itself, of the size given in the previous field.

a pad byte, if the chunk's length is not even.

Turns out, IBM's text-to-speech API generates streaming WAV files, which means it sets the "length" field to 0. Some WAV players can handle it, while others choke. Wwise falls in the latter category.



Fortunately, I can easily figure out the chunk length based on the file size, modify it using the wave library, and write it back out to the WAV file.



Problem solved. Wwise is happy. Next I set up some Wwise callbacks to detect the current volume of Penelope's voice, and when she's done speaking.



Here's the result, along with some rope physics in the background being destroyed by the wonky framerate caused by my GIF recorder:



Allow me to regale you with an exciting tale: the birth of a janky dialogue and voice system.I have a JSON file with all the localized strings in my game, like this:A preprocessor takes this and generates a header file with integer constants for each string, like this:At runtime, it loads the JSON file and hooks up the integer IDs to localized strings. A function called "_" takes an integer ID and returns the corresponding localized string. I use it like this:This all worked (and still works) pretty well for UI strings. Not so much for dialogue.To write dialogue, I had to come up with a unique ID for each line, then add it to the strings file, like this:Yes, the preprocessor generated a new integer ID in the header file every time I added a line of dialogue. Gross.I construct dialogue trees in Dialogger . With this setup, I had to use IDs like "hello_penelope" rather than actual English strings. Also gross.I keep the string system, but extend it to support "dynamic" strings loaded at runtime that do not have integer IDs in the header file.Now I can write plain English in the dialogue trees. The preprocessor goes through all of them and extracts the strings into a separate JSON file, using the SHA-1 hash of each string for its ID. Once everything is loaded, I discard all string IDs in favor of integer IDs.I couldn't find a simple straightforward SHA-1 implementation that worked on plain C strings, so here's one for you The point of all this is: I now have a single JSON file containing all the dialogue in the game. Ripe for automation...Penelope is an AI character. I'm using text-to-speech for her voice, at least for now. I don't want to integrate a text-to-speech engine in the game; that's way too much work. And I don't want to manually export WAVs from a text-to-speech program. Also too much work.I create a free IBM Bluemix account. They have a dead simple text-to-speech API: make an HTTP request with basic HTTP authentication, get a WAV file back.I write an 82-line Python script that goes through all the dialogue strings and makes an HTTP request for each one. It keeps track of which strings have previously been voiced, to facilitate incremental updates.Now I have a folder of WAV files, each one named after a SHA-1 hash. I'm using Wwise for audio, so the next step requires a bit of manual involvement. I drag all the WAVs into the project and batch create events for them.Now when I display a dialogue string, I just have to look up the SHA-1 hash and play the audio event. Easy.I don't hear anything. All signs indicate the audio is playing correctly, but nothing comes out of my speakers.I look at one of the audio files in Wwise.Looks like the file is corrupted. I play the WAV in a number of different programs. Some play it fine, others don't play it at all.I edit my text-to-speech script to use Python's wave library to load the WAV file after downloading it from IBM. Sure enough, the library doesn't know what to make of it.Too lazy to care, I edit the wave library in-place in my Python distribution. YOLO.After a bit of printf debugging, I pinpoint the issue. The WAV format is based on RIFF , a binary format which breaks the file into "chunks". According to Wikipedia, the format of each chunk is as follows:Turns out, IBM's text-to-speech API generates streaming WAV files, which means it sets the "length" field to 0. Some WAV players can handle it, while others choke. Wwise falls in the latter category.Fortunately, I can easily figure out the chunk length based on the file size, modify it using the wave library, and write it back out to the WAV file. Like so Problem solved. Wwise is happy. Next I set up some Wwise callbacks to detect the current volume of Penelope's voice, and when she's done speaking.Here's the result, along with some rope physics in the background being destroyed by the wonky framerate caused by my GIF recorder: « Last Edit: May 01, 2016, 03:47:10 PM by etodd » Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #52 on: May 03, 2016, 07:38:17 AM » New terminal system



Here's the new workflow for each level:



Spawn into the level as a humanoid.

(Explore and find stuff, not done yet)

Activate a terminal, which looks like this:





Have a conversation with Penelope (main AI character previously called Soren), who starts the matchmaking process.

While chatting and waiting, you can still parkour around the level.

Once Penelope finds a match, she connects you with the other player and reloads the level in PvP mode.

New health system



Previously, health worked as follows: you started with 1 HP, and you could "capture" health powerups to get to 3 HP total. If someone hit you just right, it was still an instant kill. But most shots bounced off and subtracted 1 HP from you.



Now, you can only damage a player if you have the same or higher HP. If there's no chance to damage a player, you'll see a flashing "danger" sign. I also got rid of the instant kills; they felt more like random chance than skill.







Previously, when a player captured a health powerup, it remained theirs until you damaged them, resetting the powerup to neutral. At that point, they could recapture it to get their HP back, or you could capture it and get an edge.



Now, you can capture a health powerup even if it belongs to an enemy. You steal their HP. This encourages you to set up protections around your health powerups. Also, once you get to full health, you can't capture any more health powerups. This encourages you to run on low health so you can steal enemy HP.



This system makes things crazy if you happen to get into a fight near a health powerup. You'll start out at the same HP until player A damages player B, at which point player B is forced to capture the powerup before they can do any more damage. It gets pretty hectic.



In the early game, this sort of back-and-forth is exactly what I want, but I can see it dragging on in the late game. So I will probably design an expensive mechanic (available only in the late game) that allows you to "freeze" powerups in some way, to force the game to end in a reasonable amount of time.



Control point UI



Control points now have icons that change color depending on their owner. Here you can see one point inside my sensor zone, and one outside:







Each captured point earns 2 credits every 15 seconds. The UI shows this "credit delta" beneath your total credits (+2 in the above screenshot). Here's the new workflow for each level:Previously, health worked as follows: you started with 1 HP, and you could "capture" health powerups to get to 3 HP total. If someone hit you, it was still an instant kill. But most shots bounced off and subtracted 1 HP from you.Now, you can only damage a player if you have the same or higher HP. If there's no chance to damage a player, you'll see a flashing "danger" sign. I also got rid of the instant kills; they felt more like random chance than skill.Previously, when a player captured a health powerup, it remained theirs until you damaged them, resetting the powerup to neutral. At that point, they could recapture it to get their HP back, or you could capture it and get an edge.Now, you can capture a health powerup even if it belongs to an enemy. You steal their HP. This encourages you to set up protections around your health powerups. Also, once you get to full health, you can't capture any more health powerups. This encourages you to run on low health so you can steal enemy HP.This system makes things crazy if you happen to get into a fight near a health powerup. You'll start out at the same HP until player A damages player B, at which point player B is forced to capture the powerup before they can do any more damage. It gets pretty hectic.In the early game, this sort of back-and-forth is exactly what I want, but I can see it dragging on in the late game. So I will probably design an expensive mechanic (available only in the late game) that allows you to "freeze" powerups in some way, to force the game to end in a reasonable amount of time.Control points now have icons that change color depending on their owner. Here you can see one point inside my sensor zone, and one outside:Each captured point earns 2 credits every 15 seconds. The UI shows this "credit delta" beneath your total credits (+2 in the above screenshot). Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #53 on: May 09, 2016, 12:00:24 PM » Teleporters



I started out giving two possible actions for each ability. Hold the ability key (e.g. 1, 2, or 3) to spawn the item (e.g. a teleporter). Tap the key to execute an action with those items (e.g. teleport).



I ended up combining the two. Hold the key to simultaneously spawn a new teleporter and teleport to an existing one.







The particle shader needs some work. From some angles it looks like flying macaroni noodles.



Roll animation



Look, I did an animation!







There is no fall damage, but if you fall too far, you'll instantly lose all momentum and completely stop for a second. You can roll at just the right time to maintain and even increase your momentum.



New menus



I worked on some menu animations.







Notes / matchmaking



I planned out three systems for parkour mode. Notes are done:







Matchmaking is also done. One more system to go.



Todo



Balance and adjust PvP gameplay

AI programming

Level design

Writing

I'm headed to New York City this summer to teach people how to make games at I started out giving two possible actions for each ability. Hold the ability key (e.g. 1, 2, or 3) to spawn the item (e.g. a teleporter). Tap the key to execute an action with those items (e.g. teleport).I ended up combining the two. Hold the key to simultaneously spawn a new teleporter and teleport to an existing one.The particle shader needs some work. From some angles it looks like flying macaroni noodles.Look, I did an animation!There is no fall damage, but if you fall too far, you'll instantly lose all momentum and completely stop for a second. You can roll at just the right time to maintain and even increase your momentum.I worked on some menu animations.I planned out three systems for parkour mode. Notes are done:Matchmaking is also done. One more system to go.I'm headed to New York City this summer to teach people how to make games at MakeSchool . My hope is that when I return, the game will be in a playable state and I'll have some funding. At that point I'll probably start looking for some help on this project. Logged

etodd









Level 3 Re: The Yearning (née MK-ZEBRA) « Reply #54 on: May 16, 2016, 08:18:24 AM »



Just a few things of note:



Level design revisited











I resurrected this level and re-worked it in light of new design decisions. It now works pretty well in both PvP mode and parkour mode.



Stealth upgrade



In order to encourage you to plan for the long game, I must make it more difficult to kill your enemy at the beginning of the game. However, in order to make you feel vulnerable, you still need to die in a few hits.



This led me to the stealth mechanic: you're invisible while planted on surfaces that you "own".







Now you're safer, but you're cowering in your safe zones.



In the late game, I want things to get more hectic, more lethal, and less safe. Easy solution: pay X credits to upgrade your sensor ability and disable the enemy's stealth. This was easy to implement, so I did.



There are two problems with this design. First, when someone disables your stealth, you have no idea what happened. Your stealth just stops working, and now you're frustrated and confused. A UI element could solve this, but that's extra work, extra visual noise, and you still might miss it.



Second, it's not a "fun" upgrade. When I look at the upgrade menu, removing an element of the game looks unappealing, even if it's a good tactical choice. I want an upgrade for me, not a downgrade for my enemy. Maybe it's just semantics, but it makes a big difference emotionally.



Then I realized that you the player already have power to disable your enemy's stealth: you can spawn a minion to destroy their sensors. It's way more fun to spawn a dude that shoots lasers than it is to just buy an upgrade.



TL;DR: I trashed the stealth upgrade.



More health revisions



Previously I described how much fun it was to battle an enemy near a health powerup. You have to constantly switch between attacking your opponent and re-capturing the health powerup, depending on how much health you both have.



This is made possible by two important details: first, when you are damaged, the game resets your nearest owned health powerup to a neutral state, giving you a chance to quickly regain your health by recapturing it. And second, players can steal health powerups owned by an enemy.



This design has a problem too, though: once you are damaged, you immediately retreat to the nearest health pickup, since you can't do damage anymore. Your enemy follows close behind. Once you're both at the powerup, neither of you has an incentive to leave. You can always gain an upper hand by re-capturing the powerup. The game will end there, after an indeterminate period of back-and-forth.



The game should not end with the first encounter.



Here's where I'm at now: first, when you are damaged, your most distant health powerup resets. This forces you to make a significant retreat, probably back within your safe zone where you have an advantage. Second: in the early game, you can't steal enemy health. You have to buy an expensive upgrade.



This upgrade is much more appealing because it allows you to gain a huge advantage very quickly. It also splits the game into four different modes, depending on which of the two players have the upgrade. And it makes the game end more quickly as time expires.



Containment fields



Now there's another problem. In the early game, it's pretty easy to escape danger. You might be frustrated if an enemy slips through your fingers, but no worries, it's early.



However, in the late game, it's still just as easy to escape, making the game drag on endlessly.



The first thing I thought of was a "stun" ability. Pay X credits and now you can hit a button to temporarily freeze the enemy in place.



More design problems. First, it's frustratingly difficult to hit a button at the right time while frantically bouncing around chasing someone. Second, there's no way for the enemy to counter. Maybe they buy a counter-upgrade that makes them un-stunnable?



That is soooooo boring.



Here's what I'm experimenting with: you buy an upgrade that adds "containment fields" to your minions.







It's hard to see, but there's a transparent field around that minion. You can pass through it freely, while the enemy cannot. This accomplishes the goal of corralling your enemy, but is more interesting than a stun ability for two reasons: first, the field is mobile because minions walk around. Second, the enemy can counter it by killing the minion (which happens to be a lot of fun).



I've only playtested these mechanics against my not-very-smart-yet AI, but I'm hoping to do some real playtesting this weekend. In the meantime, there's plenty of level design, animation, and writing to do. I'll skip all the boring stuff I did this week... writing dialogue, fixing build errors on Mac, incrementally improving the parkour code, refactoring a bunch of templates out of existence, fixing rare AI crashes...Just a few things of note:I resurrected this level and re-worked it in light of new design decisions. It now works pretty well in both PvP mode and parkour mode.In order to encourage you to plan for the long game, I must make it more difficult to kill your enemy at the beginning of the game. However, in order to make you feel vulnerable, you still need to die in a few hits.This led me to the stealth mechanic: you're invisible while planted on surfaces that you "own".Now you're safer, but you're cowering in your safe zones.In the late game, I want things to get more hectic, more lethal, and less safe. Easy solution: pay X credits to upgrade your sensor ability and disable the enemy's stealth. This was easy to implement, so I did.There are two problems with this design. First, when someone disables your stealth, you have no idea what happened. Your stealth just stops working, and now you're frustrated and confused. A UI element could solve this, but that's extra work, extra visual noise, and you still might miss it.Second, it's not a "fun" upgrade. When I look at the upgrade menu, removing an element of the game looks unappealing, even if it's a good tactical choice. I want an upgrade for me, not a downgrade for my enemy. Maybe it's just semantics, but it makes a big difference emotionally.Then I realized that you the player already have power to disable your enemy's stealth: you can spawn a minion to destroy their sensors. It's way more fun to spawn a dude that shoots lasers than it is to just buy an upgrade.TL;DR: I trashed the stealth upgrade.Previously I described how much fun it was to battle an enemy near a health powerup. You have to constantly switch between attacking your opponent and re-capturing the health powerup, depending on how much health you both have.This is made possible by two important details: first, when you are damaged, the game resets your nearest owned health powerup to a neutral state, giving you a chance to quickly regain your health by recapturing it. And second, players can steal health powerups owned by an enemy.This design has a problem too, though: once you are damaged, you immediately retreat to the nearest health pickup, since you can't do damage anymore. Your enemy follows close behind. Once you're both at the powerup, neither of you has an incentive to leave. You can always gain an upper hand by re-capturing the powerup. The gameend there, after an indeterminate period of back-and-forth.The game should not end with the first encounter.Here's where I'm at now: first, when you are damaged, yourhealth powerup resets. This forces you to make a significant retreat, probably back within your safe zone where you have an advantage. Second: in the early game, you can't steal enemy health. You have to buy an expensive upgrade.This upgrade is much more appealing because it allows you to gain a huge advantage very quickly. It also splits the game into four different modes, depending on which of the two players have the upgrade. And it makes the game end more quickly as time expires.Now there's another problem. In the early game, it's pretty easy to escape danger. You might be frustrated if an enemy slips through your fingers, but no worries, it's early.However, in the late game, it's still just as easy to escape, making the game drag on endlessly.The first thing I thought of was a "stun" ability. Pay X credits and now you can hit a button to temporarily freeze the enemy in place.More design problems. First, it's frustratingly difficult to hit a button at the right time while frantically bouncing around chasing someone. Second, there's no way for the enemy to counter. Maybe they buy a counter-upgrade that makes them un-stunnable?That is soooooo boring.Here's what I'm experimenting with: you buy an upgrade that adds "containment fields" to your minions.It's hard to see, but there's a transparent field around that minion. You can pass through it freely, while the enemy cannot. This accomplishes the goal of corralling your enemy, but is more interesting than a stun ability for two reasons: first, the field is mobile because minions walk around. Second, the enemy can counter it by killing the minion (which happens to be a lot of fun).I've only playtested these mechanics against my not-very-smart-yet AI, but I'm hoping to do some real playtesting this weekend. In the meantime, there's plenty of level design, animation, and writing to do. Logged

etodd









Level 3 Re: The Yearning « Reply #55 on: May 19, 2016, 11:28:34 AM »



Still a lot of bug fixing, UI polish, parkour tweaking, etc. going on right now. But I built another level!







I think creating and exploring new spaces is a major part of why we make games, at least for me. This place didn't exist yesterday!



As usual, colors were difficult to get right. It doesn't help that there is absolutely Yesterday I set up itch.io refinery , which is basically itch's equivalent of Steam Pipe. It does binary diffs so you can upload new builds in seconds. I can now generate download keys for beta testers. I highly recommend this system for anyone who does any kind of beta testing. It's nearly as powerful as Steam Pipe, but only takes about 5 minutes to set up.Still a lot of bug fixing, UI polish, parkour tweaking, etc. going on right now. But I built another level!I think creating and exploring new spaces is a major part of why we make games, at least for me. This place didn't exist yesterday!As usual, colors were difficult to get right. It doesn't help that there is absolutely ZERO correlation between the colors I choose in Blender and the ones I get in-game. Logged

Pixel Noise









Level 10 Re: The Yearning « Reply #56 on: May 19, 2016, 02:50:25 PM » Wow, not sure how I'm just seeing this for the first time - but it's very cool to be able to skim through the last year's worth of progress. Really dig some of the concept art and level-design/architecture you've got going on. Super following! Logged

https://soundcloud.com/pixel-noise

https://twitter.com/PixelNoiseMusic

https://pixelnoisemusic.bandcamp.com/



Recently completed the ReallyGoodBattle OST! Pixel Noise - professional composition/sound design studio.Recently completed the ReallyGoodBattle OST! https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q

Pixel Noise









Level 10 Re: The Yearning « Reply #58 on: May 22, 2016, 04:34:54 PM » My mistake - I thought those pictures in your first post were concepts. Far from junk - this stuff looks great! My mistake - I thought those pictures in your first post were concepts. Far from junk - this stuff looks great! Logged

https://soundcloud.com/pixel-noise

https://twitter.com/PixelNoiseMusic

https://pixelnoisemusic.bandcamp.com/



Recently completed the ReallyGoodBattle OST! Pixel Noise - professional composition/sound design studio.Recently completed the ReallyGoodBattle OST! https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q