Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411280 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 06:18:35 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsWobbledogs
Pages: 1 ... 29 30 [31] 32 33 ... 37
Print
Author Topic: Wobbledogs  (Read 229760 times)
JobLeonard
Level 10
*****



View Profile
« Reply #600 on: January 10, 2018, 01:04:43 AM »

Thanks everyone! Glad people like the dog names. I actually just added in a few new ones.



Turns out the secret to good dog naming is just to list different types of food.

Been awhile since I've tossed some encouragement and applause your way so I'll let you in in a lil' secret...this is my kid's favorite devlog and she's really looking forward to playing around with some wobbly-dogs.  Every time she catches me perusing tigs we gotta come over this way and laugh at the gifs. 

Stay the course, keep at it and as always awesome work!  Gentleman

Aw, I really love this!

all this recent update stuff is nice, but what interests me the most are the crystals. what do they mean for the lore of this world? does dog magic exist? would it be possible to modify a dog with crystals to give it powers? i know the lore is what matters the least right now, but you're still making me curious

You'll just have to wait and seeeee!

--

Some updates! First of all, I finally went back and squashed the last of my major issues with dog physics meshes flashing across the screen when separated under extreme circumstances.



I've talked about the idea here before. Basically I store joint offsets on load, check against them regularly, and snap joints back to their default positions if things get past a certain tolerance. I'd done work to fix this in the past but had missed the physics joint between the main visual dog mesh and the actual colliding dog mesh. Pretty solid now, though!

After this I spent a few days upgrading unity to the latest version along with every 3rd party asset I had integrated. This took a bit longer than I'd have liked but I'm happy to report that it's now all smoothly up to date. I hadn't done many asset upgrades for a long time so this was needed.

The biggest change here was that I upgraded the unity post processing stack from V1 to V2. They changed some pretty major aspects of this so it wasn't super straightforward. Certain things, like color grading, I had to completely re-do as the fields weren't 1:1 between versions.

The larger issue with this post processing update, however, was a little more insidious. There's some aspect of the new stack that causes swimming pixels, even if every single effect is off. This is only possible to get rid of (as far as I can tell) if you completely disable the component. Again, this happens even if the component shouldn't be doing anything so I don't think there's much I can do without diving into their code itself. The pixel movement isn't detectable to the bare eye but it IS detectable for my main gif recorder, gifcam.





With this new stack it can't correctly greenscreen out parts of the screen that should be stationary. In this case the entire frame is motionless but still produces a 3.37MB 57 frame gif with shimmering pixels. This is without any effects or post work. With some other effects enabled the result becomes even worse.

I haven't found a solution for this, there might not really be an easy one, but fortunately for me, other gif recorders seem to handle this a bit better. For now, I've found that LICEcap still produces reasonably sized gifs without horrible shimmering. I don't like LICEcap's workflow as much but I think it'll be my go-to for the time being.

In any case, I'm otherwise extremely happy with how everything's looking with the new stack implemented.





And then my last bit of big news is that I just launched a patreon for the game!

https://www.patreon.com/thomasAstle

Unsure of how well this will end up doing but it's still exciting. Feels kinda legitimizing somehow. I'll be able to finish the game regardless of how this campaign shakes out but anything I get will be really helpful for the art/sfx/music contracting that I'd like to do later on down the line, as well as for convention/festival travel and display expenses.

Here's to another year of progress!
I wonder if this is a rounding error that could be fixed by setting the last bit in each channel to zero (so making it 7 bits per channel) before conversion.

Other than that:

https://gif.ski/

https://kornel.ski/lossygif
Logged
ActualDog
Level 3
***



View Profile WWW
« Reply #601 on: January 16, 2018, 08:11:54 PM »

I wonder if this is a rounding error that could be fixed by setting the last bit in each channel to zero (so making it 7 bits per channel) before conversion.

Other than that:

https://gif.ski/

https://kornel.ski/lossygif

Ah possibly, though that isn't something I really know how to do. So far LICEcap's been doing pretty good for me so I'll probably just stick with that for the time being. Definitely bookmarking both those links by the way, thanks!

--

Since last time I started doing some work on a temporary tutorial. I want to get something in for that so that I have the intro flow roughed out and I can start to better figure out pacing. It's slow going so far because besides not being very exciting work, it's also been revealing lots of related usability issues.

The biggest thing in that area is cursor icons. I've always meant to add cursor icons eventually but it's never been a big priority. When working on this tutorial I made a list of all the things I thought were necessary to teach the player within the first 5-10 minutes and I believe that several of those things can be taught implicitly, or at least less explicitly, through cursor feedback. So I started work on that.

The graphics I'm using for the cursor are temporary, but they're going a long way towards making it feel nice and functional. The first issue I ran into was relatively large. You've probably noticed already that the cursor de-syncs when grabbing onto an object. The reason for this is simple, 2D input mapped to 3D movement.

There's a lot of ways this issue can come up but as a simpler example, imagine that you're holding an object with the mouse and you have the scroll wheel mapped to movement in the Z direction.



The mouse doesn't move but the object does, and since the camera is tilted the cursor desyncs.

This was always a bit weird, but with the addition of cursor iconography it started to feel even more egregious and I wanted to fix it. Probably the "best" way to fix this is to do a completely virtual cursor so I can control its motion directly, but that would be a pretty huge undertaking for me. Probably a few days of work at least. I'd need to update a ton of places where I do cursor raycasts and would have to change a bunch of UI code and structures.

The first alternative solution I tried was a bit overly complex.



Essentially what's going on here is that the moment I click on the dog to grab it, I hide the real cursor. At that point I create a virtual cursor. There's some desync in the beginning because of how I set the grab position (this is solvable but not important for the time being), so I lerp the virtual cursor's position from the actual cursor's position to the grab position. After that the virtual cursor moves 1:1 with the object it's grabbing. Then when you let go, the virtual cursor lerps back to the real cursor's position, unloads, and then unhides the original cursor.

This worked OKAY, but if you weren't aware of what I was doing I'm pretty sure the moving cursor would feel like a major bug. Moving the player's cursor a tiny tiny bit on grab/release isn't too bad but you can end up in large desync situations where it flashes halfway across the screen and I pretty much guarantee people would be frustrated by that.

I then briefly looked into ways to hard set the hardware cursor's position so that I could move it to the virtual cursor's position after it was unhidden, but from what I saw the implementation would be platform-specific and not that straightforward. It was feeling too hacky for me to be comfortable.

What I tried next felt like a good compromise!



Instead of lerping to/from a virtual cursor, I decided to just try hiding the cursor without a replacement. Since you see the grabbing visualization there's no confusion about where things are but since the visualization doesn't look like a cursor itself, it doesn't feel that strange when the cursor unhides in a location a ways away from where the dragging was stopped.

I did like having the grabby hand icon for when you were holding the dog, but I'm otherwise happy with this solution, especially since it's much cheaper than the alternatives.

And then the real win for having cursor iconography is that petting now feels even better than before!



Would love to do what the Petz games do with an animated hand, but for the time being this is solid. In addition to dog interactions, the cursor also updates accordingly when you mouse over clickable objects and UI elements, and it greys out when you mouse over disabled elements.

Today I moved off of the tutorial stuff for a bit in order to start working on the advertisement mechanics! A while back I had a realization that I could make my life much much easier while still retaining all of the charm I wanted out of this system and at this point I'm thinking this change actually makes the system better as well. Instead of commercials, I think I'd like to switch things to print ads. This obviously reduces the complexity of setting up scenarios by a ton, but it also hugely simplifies the sharables flow (saving off pictures is WAY easier than saving off gifs or videos) and gives me a way to add in some more direct gameplay.



My idea right now is to let you take X number of pictures of X amount of time during the scenario, and then let you go through them and choose which one to use for the ad, at which point it'll get the appropriate filters and text plastered on top of it. If it feels right I can even add in some simple scoring based off of stuff like whether or not the dog is in the frame, rule of 3rds positioning, the expression/behaviors of the dog in each photograph, etc.

So far I've got a basic photography system working, and it saves out the resultant images without all the UI, motion blur, and star particles.





It's already kinda fun. I need to tone down the shutter flash a bit (I have a few ideas), but otherwise I'm really liking the way it's going and I've got a bunch more ideas for polish.

Looking forward to getting all this more fleshed out!
Logged

Fuzzy Branch
Level 0
***



View Profile WWW
« Reply #602 on: January 17, 2018, 02:20:03 PM »

I wont comment on the cursor stuff since it's hard to judge how it feels without actually using it, but regarding the advertising element:

I think print ads sound like a good idea. I was curious to see how you would approach TV ads because there are a lot of complexities there, like how to control cinematography / editing, lots of labor time designing scenarios (hand-crafted vs procedural), how to handle scoring / evaluate quality of commercial, and on and on. However, I'm glad you don't have to worry about many of those as much with your current direction!

That's not to say that print ads will be a walk in the park, of course. Your initial progress looks pretty good! How are you handling the scope of player control? i.e. Player picks the contract, picks the dog, and then only controls camera -- or will there be a round of set dressing where player arranges props, positions the dog, choose basic lighting etc.? Might be interesting to be able to do something like hold a treat up to temporarily get the dog to look at the camera, then the player has to time the shot right.
Logged

ActualDog
Level 3
***



View Profile WWW
« Reply #603 on: January 17, 2018, 06:17:13 PM »

I wont comment on the cursor stuff since it's hard to judge how it feels without actually using it, but regarding the advertising element:

I think print ads sound like a good idea. I was curious to see how you would approach TV ads because there are a lot of complexities there, like how to control cinematography / editing, lots of labor time designing scenarios (hand-crafted vs procedural), how to handle scoring / evaluate quality of commercial, and on and on. However, I'm glad you don't have to worry about many of those as much with your current direction!

That's not to say that print ads will be a walk in the park, of course. Your initial progress looks pretty good! How are you handling the scope of player control? i.e. Player picks the contract, picks the dog, and then only controls camera -- or will there be a round of set dressing where player arranges props, positions the dog, choose basic lighting etc.? Might be interesting to be able to do something like hold a treat up to temporarily get the dog to look at the camera, then the player has to time the shot right.

Haha yeah, I was starting to get worried about the TV ad scope even without having a solid plan for the interactive aspect of it. The more I thought about it the larger an undertaking it seemed to be. I'm extremely happy to have pared things down to photography.

For the time being I'm just planning on going ahead with the basics. No pre-shoot management or set dressing or anything like that, just the photography itself and then choosing the picture you want to use. Depending on how all that feels I'd maybe like to experiment with letting the player arrange the ad itself a bit (moving elements around on the page), but otherwise I'm thinking that I'll keep things relatively simple. I imagine I'll be doing some light event scripting for many of the scenarios themselves, and as of right now I'm thinking it'd be fun to have lots of little photo grading cues so the pictures you take and choose actually feel like they matter.

The other aspect I was considering was maybe offering some general photo bounties for things you could complete inside your pen. This might be a little more complex than I'm imagining so I'm not sure if I'll do it or not, but it might be a fun way of getting the player to be on the lookout for rare events.

A general photo bounty system presented sort of like the quest structure in Kirby's Air Ride could be pretty appealing.



I'd need to flesh this idea out a bit more though.
Logged

ActualDog
Level 3
***



View Profile WWW
« Reply #604 on: February 01, 2018, 06:39:33 PM »

Been a bit longer than I realized!

Let's see, so I did a bit more work on the photography tech front. I got the photos rendering out in a scrollable list with overlaid ad graphics.



And then I also put in some basic controls for resizing and constrained placement so you could do some basic customization.



Also some basic UI for number of photos remaining.



Afterwards I moved back to the start of the game and the tutorial stuff I was talking about last time. There's another demo event opportunity coming up this month for me and I'd like to be able to show a legit demo of the game as opposed to the Dog Builder sandbox I let people play around with last time. My goal is to get a little intro loop and tutorial in place and polished up decently nice. If that goes well then I'd like to kinda treat this as a runway towards making the game's actual post-tutorial content.

So I've been doing lots of polishing and usability stuff, most of which isn't too exciting to talk about. Lots of little tweaks and additions. It's the type of thing where it feels like I've barely done anything because there aren't many big visible changes but when I look over my commit history, there's actually been a lot going on.

One of the bigger changes I've made is this UI for user action types.



Obviously the icons are temporary, but the idea's that I supply a little chooser UI for the different actions your mouse can do. The previous way I had it set up of just clicking a grab/pet toggle wasn't very intuitive and would never have scaled past those two commands. For now it's just grabbing vs petting, but I think I'd eventually like to add scolding here as well. This probably needs a bit more iteration (it might be better to display it as a toggleable element that shows both its states, the active one being larger) but it's better than before.

I also spent much too long polishing up this little intro opening sequence for when you get your first dog. It looks even nicer now. Right after I took this gif I figured out a few more things I could tweak. There's DOF during the zoom out and the timing's a bit tighter.



Another larger change is that I made a slight update to how grounded checks work for dog feet. Previously they'd just check to see if they were hitting the ground with their soles, but now they also check normals. I ignore hits that fall outside a certain range, meaning dogs don't count their feet as grounded when they, for example, hit the pen roof. I do some special physics stuff when legs are grounded (increasing torque power, for example), so this makes dogs behave much less awkwardly when you toss 'em about. They don't unnaturally course correct their rotations when flung against walls, basically.

Last big change is that I put together a little prototype for goop mixing. Twitter link for this one because it's not a gif and I don't wanna upload it to youtube to share it here.

https://twitter.com/thomasastle/status/956596463248719872

Essentially it's just an idea for a system where you can increase mutation chances by stirring up the pupating dogs. The UI isn't good right now but it's enough to get the idea across. I like that it's something you have to actively do but I'm not 100% sold. Mostly my issue is that moving the cocoon around feels a bit awkward. I think I'll probably have to implement a custom movement system for that to really sell it. Still, it was fun to try out.

And lastly, a bonus gif of some dimension shifting cinematography I accidentally created while massively screwing up some camera code (there's only one dog in this gif).


Logged

JobLeonard
Level 10
*****



View Profile
« Reply #605 on: February 02, 2018, 02:33:39 AM »





That last gif though...
Logged
ActualDog
Level 3
***



View Profile WWW
« Reply #606 on: February 09, 2018, 06:46:07 PM »

Lots more UI work since last time!

First up, I finally went back over all the temporary cursors I borrowed from random internet sources and replaced them with my own sprites. Still probably temporary but I feel better not having random assets in the game, especially in a place where they could conceivably get overlooked and left in. Most of them are pretty standard though the "grabbable" cursor turned out a bit scarier than expected...



Just in general there's still a decent amount of work required to get the cursor icons fully implemented. Any unityGUI sections I'm using have to be wrapped so I can have them auto-override the cursor icons, there's lots of little edge cases with certain icons having to override others, and sometimes the wrong icon will show up because of UI elements hidden behind others. It's 95% there but I suspect I'll be supporting this feature for a bit.

I also revisited the cursor context switching UI from last update. It was definitely overkill to prematurely decide to support an infinite amount of command cursors and the UI wasn't as clean or usable in practice as I wanted. This actually took a bit of time to get right.



The "SHIFT" key (as opposed to a controller button) doesn't really have an immediately obvious symbol, plus it's not necessarily obvious that it refers to the key instead of the concept. I put a rectangle behind the word to try and make it more similar to the key, but it's still not super clear what the key is gonna do. Adding in the circular arrows helps byindicating that those elements are gonna shuffle around, and the placement of everything being a bit reminiscent of gears further drives that home.



Combine that with some animation and visual feedback and (I think) it's pretty effective! Obviously need to see some folks actually try and use it for the first time though. Clicking the element switches your active command and holding down SHIFT temporarily swaps to the other. Works quite nicely in practice for me so I hope it does for others as well. One super minor thing I'm pretty pleased with here is that I went in and frame-by-framed the arrow dropshadow so it stayed consistent during the rotation.

Moving on from command UI, I also went and tweaked the new mail behavior so it plays this obnoxious bouncing animation whenever you have something new to read so people will hopefully not just ignore it.



It works great on me though I suspect I'll have to tone it up even further because I always manage to underestimate the average player's ability to ignore things. I really don't want people to miss their mail because it's essentially what'll be giving you new "quests" and game content.

And then the last new thing I've been working on is a special screen for mutations! A problem I've always had is that dogs can mutate fairly slowly. It's something I ultimately think is somewhat of a good thing but it also means that after any given mutation the changes a dog undergoes really might not be that obvious to you, and in a lot of cases you might not notice anything at all. This has the effect of making mutations feel fairly uneventful, which is definitely not what I want.

My idea for a solution is to try and treat mutations like leveling up. Make a big show of it, give you a special screen with some exciting UI that highlights all the changes, etc.

It's going pretty well so far, barring a few renderTexture mishaps.





The screen is not polished at all yet, and it doesn't show every change (notably it still needs to list out swapped parts, like mouths or eyes) but it's already been nice to get in.



It's so far led to some interesting design problems/insights. I've lowered the length of most genes, for example, because most of the time something mutated it was by a value way too small to be visible. I'm also realizing that I have to be extremely smart with which properties I show. Like, the dog's "Tail Size" gene might mutate but if the dog doesn't have a tail, that's not really relevant information to show the player. I definitely see how some people would still care about inactive gene mods, but for now I'm making the choice to simplify this stuff as much as I can. I'd rather make crafting the perfect dog a little more difficult while making the average player's experience less overwhelming. Besides, it SHOULD be difficult to make a dog exactly as you want it.

The other interesting issue here is with color updates. More-so than with physical updates, color changes have a tendency to be near imperceptible. Right now I'm hiding the fact that the color's updated if the total change is less than a certain value, but I've been having a hard time balancing hiding imperceptible updates with making sure to always show perceptible ones. It's possible that I just need to keep tweaking the numbers but I sort of suspect I'll have to deal with always having the possibility of claiming there's a value update when the user really can't see the difference.

But yeah, it's coming along and I'm very excited to get this screen polished up and looking nice. I suspect it's gonna give mutations a lot more weight and I'm looking forward to getting it all working.
Logged

flex$
Level 2
**



View Profile
« Reply #607 on: February 10, 2018, 04:16:31 AM »

i think the mail icon will do the trick, using the red iPhone bubble-style will help trigger that desire to check it. i also think using shift to swap between petting/grabbing would work quite nicely and visually i dig what you did there.
Logged

ActualDog
Level 3
***



View Profile WWW
« Reply #608 on: February 23, 2018, 04:14:36 PM »

i think the mail icon will do the trick, using the red iPhone bubble-style will help trigger that desire to check it. i also think using shift to swap between petting/grabbing would work quite nicely and visually i dig what you did there.

Thanks! I'm really pleased with how that turned out.

--

Another long-ish stretch of time without any updates. Sorry about that. The game's been in sort of a weird state recently, which I'll speak to more at the end of this post. So, updates!

First off, I'm pleased to announce that a small demo build is currently being shown at Bar SK over in Melbourne as part of their Year of the Dog Exhibition! Since I had the Dog Builder stuff working from the previous public appearance the game had at Glitch City last year, it wasn't too much work to fix that stuff up and get a build put together. Last year I wouldn't have been super comfortable sending this off anywhere where I wouldn't be nearby to step in in case of confusion or disaster but with all the recent interface improvements, bug fixes, and camera updates I think the important aspects are actually fairly self-explanatory, usable, and stable at the moment (or at least they're better than they used to be).

The game'll be up for about 2 weeks. If you're nearby, check it out! If not, here's some tweet peeks.


Most of the new work I've been doing has revolved around that mutation screen system. Some bugs, as usual.



But also, accidentally shrinking dog heads as shown here led me to go ahead and put in a full head size gene modifier because it was too good not to.



Otherwise the mutation screen work was mostly centered around fixing up display edge cases, figuring out when things should or shouldn't show up (no reason to show a tail size gene update if the dog has no tail, for example), and doing some light genetic balancing. The screen still isn't flashy but I'm glad I put it in. It's been useful for both game and debug reasons.

I also took a pass at the goop mixing stuff I'd prototyped earlier. Physically dragging the cocoon around felt awkward and it meant that you were forced to look at disruptive UI whenever you grabbed onto a cocoon. But I realized recently that I had another way of interacting with things... petting.



This isn't as grossly evocative, which is too bad, but it's way more streamlined so I'll take it. I still think its' pretty funny.

And lastly on the content front, I prototyped a system where dogs get genetic modifications based on the food they eat.



Essentially they'd get these colored ticks that store for each bite they take and then those colors used during mutations. Probably not going to keep this around but it was interesting to try out.

Anyways this all leads me to my next bit of news, which is that there will potentially be some very big news soon. Nothing related to like, opportunities or anything, just about the direction of the game itself. I know I've made a big deal bout the photography/advertisement stuff in the past, but it turns out there's still some core issues with those aspects of the game (namely scope, particularly that the scope is entirely separate from the dog simulation and pens, but also some pretty large design concerns). I've started exploring a promising idea. Not ready to talk about anything yet but it's the kinda thing that'll warrant a pretty large post if it looks like it'll pan out, so just a heads up that I might be kinda quiet for a bit. Or not, who knows! Maybe it'll come together quicker than I'm imagining.

The new stuff I'm considering would require some pretty massive changes, but that's kinda how I know it's worth looking into. In the past most designs I tried to explore were layered on top of what I already had. This would integrate with it and inform every aspect of the game, content, and surrounding systems.

I don't wanna get too ahead of myself but I have a feeling that the game's gonna make big strides this year, one way or another. There's a reason I haven't really been able to move the thread's progress bar for so long (hint: I've had no concrete designs) and I'm very much looking forward to changing that.
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #609 on: February 25, 2018, 04:03:53 AM »

Quote
This isn't as grossly evocative
... he said, as he vigorously rubbed up and down an eggsack full of potentially mutated spiderlegged wobbledog

╲/\╭( ͡° ͡° ͜ʖ ͡° ͡°)╮/\╱\ 
Logged
ActualDog
Level 3
***



View Profile WWW
« Reply #610 on: March 12, 2018, 05:53:19 PM »

Okay so, I think I have a game design now. Like, for real. I can't promise that I won't be eating these words a few months from now but I'm pretty hopeful this time!

The past two weeks I've been working on a pretty rough prototype and even though it's janky and missing a lot it actually feels like it's going somewhere and I think it's turning out to be fun and compelling. The big thing here is that this is a large shift in direction (which was sort of unavoidable since I've been lacking a concrete direction for the past 2 years). That means that there's lots of restructuring for me to do. Some of the cooler systems and features I've worked on will need to be ripped out or reworked. It's a little sad but it's also extremely necessary. Ultimately, nearly everything in the game was added as I came up with it because it felt cool. It all fit together but never actually formed a complete picture. I'll talk more about this at the end of the post.

If you remember my big Failed Prototypes post from last year, two things will stand out to you as you read all this new info. First is that I previously seemed pretty excited about the advertisement idea.

I was really excited about it at the time but it had a few major flaws that I sort of willingly ignored in the hopes that I'd come up with solutions for them later. The advertisement stuff itself was do-able and I even put together a pretty fun little prototype for it but it was still completely divorced from the pen gameplay itself.



I had hoped that advertisements would spawn consequences and goals that'd spill out into what you did in the pens but that was based on the assumption that breeding and mutation would be so compelling on their own that they'd be able to carry your gameplay experience. This never really turned out to be the case and it was naive to think I would "just figure it out". Additionally, going all-in on the advertisements would still have meant that I was developing 2 separate games, and that's a problem for me scope-wise.

The second thing that you'll probably notice is that the idea I'm about to describe is very similar to one of the prototypes I said had failed. That prototype would be the second in the list, the egg economy. When I first tried out that idea I was approaching it from the wrong direction. My main issues with it were that it took the focus away from the individual dogs and that it provided zero moment-to-moment engagement and my current prototype solves both of those issues. These are problems I might've been able to solve back then as well but stepping away from things was ultimately pretty helpful.

I also wanna really quick be transparent and say that a lot of this design came out of a long conversation I had with Ben Esposito. He helped me figure out a lot of the stuff I'm gonna be talking about here and I'm super grateful.

Anyways, I've got a lot to say so buckle up.


The Game

The basic idea is that you raise dogs in order to sell their eggs. They key here is, however, that dogs no longer produce eggs based on an internal timer. Instead, they produce eggs once a set of conditions has been met. They can't be hungry, they can't be tired, and they can't be bored.

In order to keep dogs producing eggs, you have to take care of their needs. To make things more hands on, one of the first things I changed is how dog stats work. In the past, everything was based off of timers, with certain behaviors also causing stats to go up or down. This makes sense from a simulation standpoint but from a game standpoint it encourages dead air unless you're dealing with a huge amount of dogs (I'm capped at about 10 for performance reasons). Now a dog's stats only go down when they lay an egg. This means that in order to keep eggs flowing, you get to take a hands on approach to filling a dog's needs.

The game's broken up into short day/night cycles. Once eggs have been laid, they must be kept safe until nighttime, at which point you'll be able to sell them. This is made slightly more complex given that bored dogs will actively try to cause mischief. If you leave a bored dog near a bunch of eggs, there's a good chance it'll break 'em. Being fragile, eggs also don't usually play very nicely with vacuum pipes.



Money you get from selling eggs will be pumped back into your little dog ecosystem. You can buy more dogs, more rooms, better food, room/object upgrades, aesthetic customizations, etc. Since I'm limited to about 10 dogs at a time for performance reasons, the game will be less about making a large habitat and more about maximizing potential. Egg value will increase as dogs are better taken care of (quality of rooms, food, etc), and there'll be a good assortment of upgrades and buildables aimed at increasing productivity and making management more manageable.

Aside from being the point at which you can sell your egg haul, dogs will also pupate and mutate every night.



I'd originally had the dogs just conk out here but cocoons seemed like a more natural fit since that was a mechanic I still wanted to have integrated. Additionally, I was concerned about the readability between dogs napping during the day to fill their energy need and being completely asleep and impossible to wake up at night.



Mutation inherently effects the core gameplay loop since most mutations have an effect on how efficiently dogs can move, but that's not quite interesting enough on its own. This is the least-defined aspect of the design but I'd like to break dogs up into breeds. A breed would be defined by a specific genetic string. A dog would be considered "of a breed" if its genetic code was within a certain range of that breed's genetic code. As dogs mutate they'd be able to shift breeds (and I'd like this to be something you can influence), and each breed will have some unique characteristics. Different temperaments, types of eggs, requirements, etc. I've got some fun ideas for this system but it's ultimately something that still needs to be prototyped so I'll save the rest of my thoughts for another time.

In any case, I wrote out a design doc with all this info and more. I've got the rough outline of how everything fits together plus concrete examples of objects, rooms, and upgrades. I've got plans for food cultivation and lots of dog "status effects". Both are features I'll go into more another day.

The prototype itself was a little tricky to get started on but I'm feeling good about it now.

After defining the egg conditions, I tried putting some dogs in a room to see how it all felt. It felt awful. It was completely unreadable. A dog would lay an egg, then you'd drag over food for it to eat, you'd pet it to stop it from being bored, and you'd watch it sleep for a bit. When it woke up it'd lay an egg again. The more dogs I added the more chaotic things got and not in an interesting way. I tried making the room bigger and spacing out the objects some more. This helped a tiny bit, but it was still bad. It was still visually chaotic and trying to drag the dogs around to speed things up was more annoying than anything.

Then I got the idea to split things up into rooms. Instead of dogs being able to sleep anywhere, they had to go into a dedicated sleep zone. Instead of dogs being able to lay eggs anywhere, they had to go to the nesting room. Food would always spawn in at the same place.



The result was immediately interesting. My camera system is set up to mostly only let you focus on one pen at a time. This means that while you're tending to the needs of a dog in one pen, the dogs in the other pens are out of sight. This might sound bad but it's actually great. You end up in this little dance of bouncing between rooms while tending to the needs of the dogs as you go. Since the dogs are autonomous, they'll usually sort of do what you want them to, but they're also not the most efficient movers and still have a mind of their own, so you really do have to keep an eye on things. They're probably fine but you can't really leave them out of sight for too long.

Once I had that figured out, everything else started to fall into place. I added some thought bubbles to the dogs so you could tell what they were attempting to do next. Seen here: Buster wants to lay an egg.



This makes a huge difference when you're manually moving the dogs around from pen to pen to keep things efficient.

From there I added in the day/night cycle, threw together some debug purchase options, spent some time doing a bit of balancing, and hey, I've got a little game.



There's a lot more detail I've figured out design-wise but I think I've probably already gone on too long so I'm gonna wrap things up with some broader thoughts on this all.

The biggest reasons why I'm excited about this design are also some of the biggest reasons why I'm scared of it. Since it's actually a game with concrete mechanics, a lot of the stuff I've built already is going to have to be thrown out or reworked. This sucks because there's some great stuff that's gonna get lost but it's also really good because it means I've got an actual direction to inform the game's content. The only way to realistically keep everything I already have is to layer a new game on top of the existing stuff, which means making two games. That's one of the reasons I'm not going forward with the advertisements concept.

So, let's talk about this.

What's changing?

  • Memory-based Pathfinding: I still love this as an idea but I'm going to have to rip it out. In practice it was hard to maintain, a bit expensive performance-wise, and not super visible to the player. It was really fun to implement but ultimately when it worked, it was sort of indistinguishable from a more traditional pathfinding system. A lot of what it did well, dogs exploring their world and remembering things that might've changed, could've also been accomplished with some logic wrapping a standard pathfinding system. Additionally, with this game's new direction, dogs need to know the entire world's layout from the moment they spawn. In reality it just isn't fun to wait for a dog to see the entire pen before knowing what's there, especially once you have something specific that you want them to do.
  • Behavior and Object Associations: I'm going to be 100% honest. These systems never worked that well to begin with. The ideas are still really cool but my implementation of them was never that great and even if they worked well, they'd mostly only be noticeable in very long-term play, if they were noticeable at all. This is more of a speculative removal. I've never had the chance to give these systems the love they'd need to really shine and since they won't add much to this new design, I think it's best to rip them out.
  • Fixation/Distraction AI: This is probably the removal I'm most sad about. This system did actually work, and it worked really well. It was readable and relatively simple to implement and maintain. The problem now is that dogs have a job to do and they need to be a bit more efficient at it. If there are no gameplay goals, it's fun to see dogs get distracted and wander off. Once there are gameplay goals, however, this very quickly becomes frustrating. That said, I already have some plans for new gameplay systems that will fill in the gaps left by this system's removal. It'll be replaced but by something else good, I promise. I'll talk more about my plans in a later update
  • Pen Construction: This isn't being removed but it is going to be simplified. This is 100% a good thing. The current construction mode is fiddly and overly-complex to no benefit. I have plans drawn up for a new construction mode that'll give a little less flexibility but be 10X more usable without really sacrificing anything practical.

What's not changing?

  • Dog Appeal: I of course realize that the dogs are the real stars here. I would never ship this game with dogs that aren't fun to watch and play around with. I'm not gonna do anything that'll sacrifice their charm.
  • Mutations: The mutations and variety of dogs has been a core aspect of this project for a long time now and it's not going anywhere. Hopefully the breed system I have in mind will take care of all this but if not, I'll keep searching for a good way to keep this integrated.
  • Goofiness: If you think this design update is gonna in any way remove the charm and goofiness of this project, then I'm not sure what to tell you. I can not and will not be contained.


I kind of expect that there'll be a a few people disappointed in this new direction but I hope most of you are excited. This shift means that the game is actually gonna be fun! For the past 2 years I've had a project that created great gifs but wouldn't really hold interest for that long and definitely wasn't a game. It wasn't going to be possible to finish because I had no clue what "finished" looked like. I've got a lot of this new stuff designed and scheduled out and I'm pumped to dive into it for real now that I'm happy with the prototype. If I can stay on track I'm hoping to be ready for full content production by the end of the year.

This game is gonna be good!
Logged

whistlerat
Level 1
*



View Profile
« Reply #611 on: March 13, 2018, 12:57:12 AM »

Your devlog has consistently been one of the more fascinating ones for me, both as a potential gamer and as a dev making, in a lot of ways, a really similar game. Having the guts to lay out your challenges, failed solutions and ideas for new directions has been both inspiring and encouraging, especially since I've encountered a lot of the same issues as you, and it's been invaluable to see how you approach them.

For what it's worth, I think your current direction is the right one. I was a Petz fan growing up, and always thought that a more sandboxy, undirected experience would suit Wobbledogs best. Egg economy suits this perfectly, I think. The advertisement stuff was cute and creative but did seem disconnected. Ultimately I wondered if you would ever go for a real open-ended, toybox game, but am glad you're keeping some element of 'game' to it. It'll be a bit like the Sims (fancy that!!) where individual goals and challenges are up to the player, with the game imposing a simple set of rules over you (pet needs, money needs to improve pens) to provide some focus and drive.

I'm curious to see where you'll go with the idea of breeds, as it's also one I want to implement myself. So as a future player and a fellow dev, it's looking great! Keep up the excellent work!
Logged

ActualDog
Level 3
***



View Profile WWW
« Reply #612 on: March 23, 2018, 07:03:38 PM »

Your devlog has consistently been one of the more fascinating ones for me, both as a potential gamer and as a dev making, in a lot of ways, a really similar game. Having the guts to lay out your challenges, failed solutions and ideas for new directions has been both inspiring and encouraging, especially since I've encountered a lot of the same issues as you, and it's been invaluable to see how you approach them.

For what it's worth, I think your current direction is the right one. I was a Petz fan growing up, and always thought that a more sandboxy, undirected experience would suit Wobbledogs best. Egg economy suits this perfectly, I think. The advertisement stuff was cute and creative but did seem disconnected. Ultimately I wondered if you would ever go for a real open-ended, toybox game, but am glad you're keeping some element of 'game' to it. It'll be a bit like the Sims (fancy that!!) where individual goals and challenges are up to the player, with the game imposing a simple set of rules over you (pet needs, money needs to improve pens) to provide some focus and drive.

I'm curious to see where you'll go with the idea of breeds, as it's also one I want to implement myself. So as a future player and a fellow dev, it's looking great! Keep up the excellent work!

Thanks so much! I've got massive respect for any game in this kind of genre at this point, haha. There are a lot of super tough design problems involved with making something like this that I never would've expected and I love seeing how other people approach things. I've been keeping tabs on your project as well (your genetics system is way cooler than mine) and I'm really curious to see how it all comes together!

---

Construction Mode Revamp Part 1

My first big task has been updating Construction mode. Not done with this yet, unfortunately, but I think I'm making headway. In a lot of ways it's kind of frustrating work, since I'm essentially rebuilding functionality that already existed, but it's also really necessary and I'm excited for this stuff to be polished up.

The old Construction mode had a lot of problems. Ultimately it was too fiddly. It offered pretty decent control over what you were building but there wasn't actually much of a real benefit to that control. Also the code governing it all was super not extendable and very bad in a lot of ways. The main goal of this system update is to make it as easy as possible to build things. I'm sacrificing a bit of control to accomplish that but for now I think that's the right way of approaching things. I can always add back in some more advanced features in the future if it really seems necessary.

My first thought with this update was that you could only attach pens to pre-existing ones. My hope was that massively shrinking the possibility space would make things way more straightforward to grasp for the player.



In an effort to further increase usability, I made it so pipes would auto-connect the newly built pen with the pen you were expanding off of. I also decided to remove any sort of building in the Z direction. I never took advantage of this in the old system and it also massively complicates the camera system, so it seemed like a no-brainer.

The next thing I wanted to do was make pipes bi-directional. Pipes only moving dogs in one direction made more sense in the old construction mode where they could intersect with rooms at any point. With this new system I've limited pipe/room intersections so that they can only attach at predefined locations. The main reason for this is that once I've gotten further into art-land, this will let me have rooms of way more varied shapes and sizes, since they no longer will have to auto-construct themselves out of composite parts as pipes blast their way through them. This does unfortunately mean more setup work for each individual pen, but I think it's a worthwhile trade-off.



The other fun thing about bi-directional pipes is that it gives me a little bit of gameplay. I made it so pipes reverse their direction whenever something new enters from the opposite end (much harder to get working than I expected, by the way). This means that objects traveling through pipes can potentially have their direction reversed. Good chaos potential.

It also makes for some pretty fun little setups.



After this was in, I got to work on the real challenge. Auto-routing for pipes. The worst part about the previous system was that pipes were incredibly annoying to build. Having to manually route them through 3D space was not fun and it was not intuitive. Making this easy and fun to do was not only going to be a massive undertaking, I'm also not convinced the extra control there would've been that huge. It's one of those things that sounds really fun to have at your fingertips, but as someone who's tooled around with this game for thousands of hours I can tell you that ultimately the only things you usually care about with pipes is where they start and where they end up.



Auto-routing is gonna open up so many usability doors. It's already way quicker to build basic setups this way. Plus, I'll be able to make it so that pipes re-arrange themselves as rooms are added, destroyed, and moved around. It's really great. Obviously I haven't taken a UI or polish pass on this feature yet but the base is there and I love it.

HOWEVER, there is one pretty large issue with this still, and that's performance. Pipes operate on a 3D grid. The grid isn't gigantic by grid standards, but that third dimension really causes a lot of issues. A 60x60 2D grid is only 3600 cells, but pop in the 3rd dimension and make that grid 60x60x10 and now you've got 36000 cells to work with... cool...

So... pathfinding. I don't have this shippable yet but here's where I'm at. My first pass was doing a BFS from point to point. This is fine in super contained cases but very very quickly becomes a performance nightmare. There are some other pathfinding algorithms out there obviously, I'd like to play around a bit more with A*, Bi-directional searches, and jump point searches, but ultimately I think this is gonna take a sort of custom approach.

My current optimization, which works great in simple cases, is to restrict the search depth along each axis to only a single grid cell beyond the min/max grid cell indices that have been blocked off on that axis. Pipes never need to go further than 1 cell away from an obstacle, so this is perfectly valid and results in some very large speed-ups in a lot of common cases. It doesn't, however, help at all for situations where pens have been scattered far and wide across the grid.

I have some ideas for how to speed things up but I'm taking a break from that for the time being to move ahead with some other aspects of this rework. I'm fairly confident I'll be able to make this work, but we'll see.

Anyways, last up. Things were coming along okay but it still wasn't feeling as nice as I wanted. The pen building in particular had gotten a little too simple for its own good. I'd sacrificed a bit too much player control and also created some design problems for myself. How would I handle pen upgrades that increased the size of the pen itself? What happens to orphaned pens if you delete an existing one? What if you don't want the auto-attached pipe to be where it is? etc. etc.

Taking a step back I could make a few observations.

  • First of all, pipes don't need to auto-attach. The whole point of the pipe auto-routing is that placing pipes is easy now, so there's no need to also place them for you when you build a new pen, especially since they might not always go where you want them.
  • Second, the relative pen placement system would still let you effectively end up with pens anywhere on the grid since I would still let you delete existing pens, and not all pens will be the same size. The relative placement system was actually making things more complicated for the user in the case they wanted to fine-tune their setup.
  • Third, since I've dropped the z-dimension for pen placement, there's not really a compelling case to having 3D camera controls during construction mode. It just makes things more fiddly.

So, solutions.

First, pipes no longer auto-attach when placing pens. You always have to manually set them up. That's ok, however, because I'm making that process easy. I also decided to move back to a grid-based system for pen placement. It's only in one dimension this time, and the extra control is worth it in this case. It's also, in my opinion, a little more straightforward since this is a paradigm a lot of people are already used to. And lastly, if I can remove the need for you to ever have to rotate the camera during pen construction, then I can make the camera view orthographic and effectively have you operating in 2D space, which is even simpler!

I spent most of today on that last point, and I'm pretty happy with how things are coming along.



All the grid display stuff is happening with shaders. I'm writing grid info to a few textures and then using those textures to draw and color in this grid. Since it's all driven through shader properties it's incredibly easy to tweak (and even animate when the time comes) and it looks way smoother than straight textures when zooming in and out. There's some uneven lines in the above gif because of how shrunken the screen is when I recorded but it looks pretty slick normally.

The last design problem here is figuring out a way to represent pipes attached to the back wall of a pen, since right now this is happening in 2D. That feels solvable to me though, so I'm confident.

Anyways, that's about it for now. I was hoping to be done with this rework soon but it's a bit more complicated than I expected it to be so I'll probably need another 2 weeks to finish it up. Then it's back into AI!
« Last Edit: March 24, 2018, 07:52:21 AM by ActualDog » Logged

JobLeonard
Level 10
*****



View Profile
« Reply #613 on: March 24, 2018, 07:56:37 AM »

I finally had the time to sit down and read the last updates. Looks really good Hand Thumbs Up Left Smiley
Logged
ActualDog
Level 3
***



View Profile WWW
« Reply #614 on: April 10, 2018, 06:07:23 PM »

I finally had the time to sit down and read the last updates. Looks really good Hand Thumbs Up Left Smiley

Thank you! My tasks lately have started to trend more towards large systems so I've been favoring more infrequent but detailed updates here. I realize this makes it kinda daunting to sit down and plow through them though, haha.

---

Construction Mode Revamp Part 2

Still hard at work on construction. I'm about a week behind schedule because I got super sick last week (I'm fine now) and wasn't able to get too much done, but stuff's coming along.

First up was pipe re-routing. Since you don't have directly control over pipe pathing, it's pretty important that pipes don't block room placement. This means keeping track of pipe positioning separate from room positioning and allowing intersections between the two. In the case that a room is placed on top of an existing pipe, that pipe will try to re-route itself. If it fails, it gets destroyed. I'm not planning on having pipes cost any money to build, so hopefully this is just a minor inconvenience.



After this I also went back and shrunk the pipe sizes a bit so they better fit inside of the grid cells I'm using. I can technically support larger pipe segments but this actually creates some technical issues. If the segments overlap multiple cells without filling them, then multiple pipes can share a cell without technically overlapping. I could prevent this but it'd severely limit the space pipes can fill. If I don't prevent it, then pipe data management becomes that much more complex. It's all do-able, but I didn't really need pipes to be as large as they were, so shrinking them was the easier solution.

Moving on, another issue became pretty apparent. Pipe visualization.

Take a look at a setup like this one below.



All things considered this is a pretty simple set of pipe connections, but it's sort of a visual disaster. This is a consequence of moving construction to a 2D camera while still having the pipes operating in 3D space. Pipes can cross behind pens and other pipes and that's not easy to represent in 2D space. Certainly just showing the pipes directly like this isn't acceptable, at least.

My immediate thought was to try some sort of additional overlay that'd stand out more than the flattened 3D graphics. Visualizing the pipes like a subway chart seemed like a sort of natural fit and that led to this mockup.



This is definitely better. At the very least you can parse the individual routes going on. There are still a few issues here, however. For example, look at that orange line. The visualization looks strange for that pipe because the 2D visualization backtracks over itself. The 3D pipe looks fine but in 2D space the z coordinates get compressed and that results in some strangeness. This is a solvable problem though. We can detect this case while building the line and can artificially stop the visualization from backtracking.



The larger issue here is that it's still a little messy. Overlapping lines are possible to parse but it's not an ideal way of representing them. There's also the technical question of how to determine which line should be on top. It's obvious by looking at the setup which should be on top, but implementing that isn't the most straightforward task, especially once you get into the territory of multiple crossovers.

I'm keeping all these concerns in the back of my mind as I move forward but the average use-case looks pretty nice so I think it's worthwhile to forge ahead for now. I honestly would love to deep dive into this but I'm trying to stop myself from getting too bogged down in details.



So far all the visualizations I've shown in this post for the pipes have been mockup images. Getting everything into the engine took a little longer but was actually much easier than I thought it'd be. I used unity's line renderer for the line itself, duplicated it for the dropshadow, and then overlaid 2D sprites for the start and end caps. The 2D backtracking detection was fairly straightforward to implement and there's also a first-pass on depth sorting. That's gonna need to be re-visisted, but for now I'm just trying to get everything in base-level.

Here it all is with some UI integration as well.



I forwent the room labels I'd mocked up above because it was getting a bit visually messy, especially when pipes overlapped. I'll try to work those in again later if it seems needed.

Another thing I tried to reduce the visual complexity a bit (and also speed up the average case of pipe pathfinding) was to try my hardest to limit pipe routing to the 2D grid when possible. Basically, 3D pipe routing is messier to visualize and much more expensive to calculate. In a lot of cases there are 2D paths available, so everyone wins if I can pick out one of those. Since the 2D paths are nearly free to calculate, I now attempt one of those first. In the case that fails I re-do the pathing in 3D. I still need to speed things up when the 3D pathing becomes necessary, but this was still a huge win.

Pipes are still too expensive to re-route en mass in real time, so I do need to hide them when you're dragging a pre-existing pen around, since leaving them up looks messy and bad. My solution was just to leave behind the start/end line visualization caps. Way cleaner to look at and it still conveys most of the info you need. Since colors can repeat, I know I'll need more work here in the future, but for now it does the trick great.



For the rest of the UI I was mostly able to re-use what I'd had implemented for the old construction mode. I had to re-organize a few things but it wasn't too bad. I dunno if it'll all be final but it's perfect for now. I added in some instruction text support for the pipe placement mode and I might try to re-use that for the other modes as well. Also needed still is full cursor icon support for all the elements, visual updates for the highlighted/held construction elements themselves (you should probably be able to tell which thing you're selection for deletion), and a few other miscellaneous things like that, but it's pretty close to being good enough that I can move on.

Lastly, you might notice that one of the bigger construction features I'd mentioned before is nowhere to be seen. I'd still like you to be able to build/upgrade objects inside of the rooms themselves, but after some consideration I decided that there's no reason to do that from inside of construction mode. Instead I plan to have in-world "slots" you can click on that open up their own UI elements that control object building and upgrading and the like. This'll simplify construction mode a ton and honestly, I think it'll be easier for the player to figure out as well. We'll see, of course, but I'm optimistic! On that note I've also decided to ignore room upgrading for now. I'll move ahead with each room tier being its own separate buildable because that simplifies pretty much everything. Again, I can always revisit this later.

Ok, that's it! Before I go, here's a dog whose idle balancing makes it look like a JRPG character.


Logged

Fuzzy Branch
Level 0
***



View Profile WWW
« Reply #615 on: April 11, 2018, 09:49:01 AM »

Great progress in the face of an absolute nightmare of a problem, I don't envy you.  The pipe routing in 2D vs 3D plus visualization in the 2D plane plus supporting arbitrary room arrangements while keeping everything legible -- OOF! I can see how you could get lost in this for months.

The last construction gif looks good! It feels very smooth and easy to re-arrange. I like the idea of free automated pipe-routing so the player doesn't have to micromanage at all while moving rooms around.

In order to further avoid 3D pipes, could you allow pipes to connect to tiles other than the center one? (forward/back in camera-facing direction) That way the routes themselves could be 2D but wouldn't intersect each other as often due to being offset in Z by 1 tile? However, that might conflict with other systems like the room decoration though...

Looking good!
Logged

ActualDog
Level 3
***



View Profile WWW
« Reply #616 on: April 16, 2018, 11:17:09 AM »

Great progress in the face of an absolute nightmare of a problem, I don't envy you.  The pipe routing in 2D vs 3D plus visualization in the 2D plane plus supporting arbitrary room arrangements while keeping everything legible -- OOF! I can see how you could get lost in this for months.

The last construction gif looks good! It feels very smooth and easy to re-arrange. I like the idea of free automated pipe-routing so the player doesn't have to micromanage at all while moving rooms around.

In order to further avoid 3D pipes, could you allow pipes to connect to tiles other than the center one? (forward/back in camera-facing direction) That way the routes themselves could be 2D but wouldn't intersect each other as often due to being offset in Z by 1 tile? However, that might conflict with other systems like the room decoration though...

Looking good!


Haha, thanks! It's definitely been way harder than I (naively) expected but I'm really happy with how it's come together. Excited to add in some more polish later on.

I think I get what you mean by offsetting pipes in the Z direction to avoid clashes, but I'm a bit concerned with how that impacts room object placements, yeah. I think I should be able to make the current setup work but we'll see how it goes when I get into some more practical testing. Fingers crossed!

---

Very small update. I completely ripped out the old construction system, hooked this new one up to all the necessary areas, fixed some bugs, and then implemented one final feature before closing out construction work for the time being.



Temp graphics, but I added in physical in-world arrows that you can click on to move between connected rooms more easily. In practice, especially with larger setups, it was kind of a pain to transition between rooms. You'd have to zoom out a bunch, drag the camera round, and then select the room you wanted. That's okay for when you wanna survey the landscape but too fiddly for when you just want to follow a dog through a pipe. This system makes things much nicer in that regard.

Anyways, now that this is in I'm moving on. Diving into the AI rework this week and hoping to move through it as quickly as possible. After this is working I'll have real systems driving the prototype I built earlier and I'll actually be able to tweak settings and test stuff under much more legitimate circumstances.

Excited to get to new systems and move this stuff forward!
Logged

Fuzzy Branch
Level 0
***



View Profile WWW
« Reply #617 on: April 16, 2018, 07:43:20 PM »

Good stuff! It really looks a lot tighter now and more satisfying to use. Have you had any issues with ceiling pipes' warp arrow being obscured by the clock UI? (Super minor, sorry if too nitpicky)
Overall it really flows well - looking forward to AI and behavior updates, they're always good gif fuel
Logged

jctwood
Level 10
*****



View Profile WWW
« Reply #618 on: April 18, 2018, 02:49:44 PM »

The idea of navigating between rooms using the in world arrows is very smart! So great to see this going strong and the ad creation gameplay was always my favourite when you were experimenting with different ideas!
Logged

ActualDog
Level 3
***



View Profile WWW
« Reply #619 on: April 27, 2018, 06:31:46 PM »

Good stuff! It really looks a lot tighter now and more satisfying to use. Have you had any issues with ceiling pipes' warp arrow being obscured by the clock UI? (Super minor, sorry if too nitpicky)
Overall it really flows well - looking forward to AI and behavior updates, they're always good gif fuel

Thanks! The clock UI definitely gets in the way right now (good catch) but I'm not too worried about fixing that until I'm even sure if my current UI setup is gonna stay the way it is. I do think I'm gonna need to spend some time tweaking the arrow display and usability but for now I'm more focused on getting it all working base-level!

The idea of navigating between rooms using the in world arrows is very smart! So great to see this going strong and the ad creation gameplay was always my favourite when you were experimenting with different ideas!

Thank you! Unfortunately the ad creation is out at this point but I'm pretty excited about the new stuff as well, especially since it has more potential for a cohesive experience and actual gameplay. I think it's gonna be good!

--

Lots of AI work since last time. At this point the game is officially past where it was during the last little prototype, albeit working through real systems and feeling way better than when it was all being hacked together. Feels good!

The first part of all this was ripping out all the old systems and code I'm not taking advantage of anymore. Unlike construction mode I decided not to rebuild everything from scratch, but I did need to rip out a ton of pretty deep tendrils and it took a while to get everything running again. There also were still some new systems involved, namely I had to re-implement pipe pathfinding.

The old system used dynamically placed nodes to figure out broad phase pathfinding info for the dog and then once we knew exactly where to go I used unity's navmesh system to generate an actual path to follow. Pipes were handled separately, however, and it essentially meant that I planned multiple paths (one for each room involved in the total route).

This new pathfinding system is slightly similar but it's much cleaner. The broad phase now uses an internal mapping of all the rooms and their connections to do a very short search from the dog's starting position just to make sure we can theoretically get to the room holding the object we want to interact with. After that I do one single path plan and save that off. I'm now making use of the navmesh's built in portal system to account for pipes so that a single path plan call is all I need to generate a complete path.

The portals proved to be a bit more complicated than I'd have liked them to be.



You can probably see that there's some more optimization I could do for the actual navmesh (pen roofs and pipes don't need to be navigable) but that's for another day. The important part here is those curved lines going between pipe entrances. This stuff is generated when pipes are placed/removed in construction mode. I grab the pipe entrance/exit positions, project them into the pen, and then raycast down to find the nearest point on the navmesh. Some special cases had to be made for roof pipes. Normally pipes are bi-directional but dogs can't route themselves into a pipe on the roof so for the purposes of routing, roof portals are exits only.

The real problem with all this, however, was tying it into the dog routing system. The nodes marked as portal entries aren't actually the real portal entry positions. Dogs still have to walk further to get into the pipes themselves. Walking to the portal entry points only gets them partway there. This is necessary because navmesh blockers have to be placed in the pipe entrances so dogs don't accidentally wander in. Anyways, adding a new point to a generated path that's inside a pipe entrance is easy enough but the real problem is detecting when a path actually takes you into a pipe. Unity's pathfinding system clearly knows when a portal is used, but none of that info is surfaced publicly. All it returns is the final path. To make matters worse, the path node positions returned are NOT guaranteed to be the same as the actual portal positions. Fun.

My solution for now involves me saving off all the generated portal positions I build and associating them with the actual pipe they reference. After a path is generated, I go through all the nodes and compare them to these portal positions. Since the positions won't actually match I instead check them with a rather large error tolerance of .2f. If this hits, then I assume the node is entering the respective pipe and I add in another path node that's inside the pipe itself. I really don't like that my error tolerance for detecting these nodes is so high right now, and it's definitely possible even with a lower tolerance to get a false positive here, but unless I wanna build my own navmesh and pathfinding system, or unity makes this code accessible (I have to imagine this'd be a really easy fix on that end), this is what I have to work with. It's working well so far, so fingers crossed it keeps holding up!

ANYWAYS, enough about pathfinding. At this point dogs have an accurate map of the entire world at all times. This means they don't have to discover something to know where it is. This sounds like a feature removal, and it technically is, but I gotta say, in practice it's way more interesting. The idea of having dogs discover and remember their world is cool but especially combined with their slow and inaccurate movement, it mostly just meant that they always had huge aspects of the world that they never knew about and would never interact with. It was frustrating to build something new only to have all the dogs ignore it. Now they investigate and interact with everything! It's much better!

After getting in all these basics, I set about fixing bugs and shoring stuff up. First up, I got dogs able to play with each other again, which had been broken for a while.



Targeting in general is working better than ever. Dogs have always in theory been able to jump straight to their final pathing target if it's close by but it's had some deep seated bugs that I think I've finally cleared out. It's been fun to see them grabbing a hold of stuff with wild abandon.





I also went ahead and added a re-targeting feature to their AI. Previously, once they'd acquired a target they'd be locked to it. This makes sense for some cases, like when trying to play with a specific dog, but in a lot of cases it results in them looking really dumb. For example, smashing their face into a piece of food but not eating it because it's not the one they actually chose at the start of the behavior. With re-targeting, however, they'll now be able to dynamically update their target if the circumstances permit.



This works for objects as well as rooms, and it just generally makes it way easier to get them to do what you want them to. It's also less confusing because you don't end up in as many scenarios where they seemingly "refuse" to run a specific behavior you know they're trying to run.

And of course, to support the higher-level gameplay I had to make sure dogs could target rooms themselves. If they wanna sleep, for example, they have to go to their bedroom. This still is gonna need more work, because right now I don't have a great way of telling them WHERE specifically to go inside the room, but it's enough to let me move forward. The randomness of the pipe physics usually works well enough to separate the dogs anyways.



During all this I also took a brief break to build the dogs a little physically simulated space mobile for their bedroom.



You can knock into it and it's all actually balanced physically as well. I probably shouldn't have taken the time to do this but it was a nice little mental break and I think it's cute. Also a good little visual indicator of the room's purpose.

Now that all the basics are in and the more nefarious bugs have been squashed, I'm moving onto some new stuff. First up, I wanted to take a quick pass at how I'm displaying stats.

Stat bars made sense with the game's old setup, where stats would decay over time and be minorly effected by behaviors, but now the stats serve a very specific purpose, and that purpose is to tell you how close a dog is to being able to lay another egg. I now control stat changes very tightly and they mostly go up/down in set increments. To this end, I thought that a tick display setup would be more appropriate and easier to parse at a glance. I also finally got rid of the visual indication of "fear", since it's mostly unused right now and doesn't figure into egg laying.



The problem remained, however, that you could still only see one dog's statistics at any given time. The solution I'm trying out for now is to show a little tick that grows as its relevant statistic is filled. This way you can see what's going on stat-wise with any dog in the world even if it's not being focused on.



The tick is way too small right now but the systems are in place and I'm sold enough on the concept after trying it out. Lots more visual experimentation needed, but it's the right idea.

That's it for this update! The next biggest thing on my plate is probably to make it more clear when a dog can lay an egg and what the prerequisites are. The above UI work was a step in the right direction but it's still not clear enough and isn't clean enough design-wise. After that I'm going to be focusing on the minute-to-minute interactions around the pen. There's some more stuff I want to add to make sure you always have enough to be doing and that there are things for you to buy upgrades for later. I wanna get this core loop as tight as possible. Excited to get into it!

Until next time.


Logged

Pages: 1 ... 29 30 [31] 32 33 ... 37
Print
Jump to:  

Theme orange-lt created by panic