I think the most important ability when it comes to gamedev (especially solo) is being able to tell when a system is working well enough for now and moving on to other less developed areas of the game (other systems, narrative, art, etc.). I think what breaks many people is spending weeks and months fleshing out a single system to perfection, only to realize that you need to rework it later when it doesnt really fit with the rest of the game.
EXACTLY. i've seen it happen to so many developers that i talk and work with that its ridicolous how many actually fall into this trap of perfectionism. I think the best way to get rid of this line of thinking that everything needs to be perfect all the time is by doing lots and lots of gamejams. There you just don't got the time to actually work to perfection so it forces you to jump from one problem to another.
My modo is don't spend any effort on other systems / art until you have a fun working game mechanic. Once you have a fun mechanic test it with people to verify. If its fun with bad art and ascetics then it will be that much better with polish... Or else you just wasted effort on things that will get scraped eventually. @@jembawls
Until your game is done (or like 90% there) it's basically impossible to know what "perfect" even means for any given asset / system / whatever. You can sit there and come up with an idea of perfect, but you're just pulling it out of your ass. Maybe the thing you pull out of your ass ends up being pretty close to correct, or maybe not. The point is, even if you dedicate years to getting some sub system "perfect," your idea of perfect is extremely likely to change down the line. Except now you're in an even worse position than if you'd only spent a month on the system. Because now instead of considering throwing away a month of work, you're having to consider throwing away years of your life. So you end up with things in your game that aren't a good fit simply because you've spent too much time on them to remove them. On the other end of the spectrum, sometimes you cant know if a system is a bad fit for your game, or if it just needs a little bit more work. Exactly how much effort to put into a proof of concept is extremely hard to figure out. There's no way through except to just learn to trust your instincts, and to get extremely comfortable leaving things half-finished. If you have deadlines, leave AMPLE time for having to go back to systems you thought were good and reworking them.
That's awesome progress! I'm in 150% agreement that supporting internationalization at the start is *way* easier than shoe-horning it in later. Def make sure all the text is at least UTF-8 encoded too.
This video is a treasure, Jace! I really love to see not only how your development is going, but what problems you're hitting and how you're overcoming them specifically. I'm especially happy to see that you're adding so many accessibility features (including dialogue history!!!)! Thank you for sharing! I can't wait to see where your game goes!
It seems you should be able to do collisions with just one TileMap/TileSet. Add a second physics layer to the TileSet, set its Collision Layer/Mask accordingly. Then create Alternative Tiles for those you want to use on the upper floor. Paint the two Physics layers onto your tiles and alternative tiles according to which level they are supposed to be.
For ramps, instead of setting the dampen modifier directly, i would suggest setting the angle of incline and a surface material. Later during gameplay the dampen modifier would be calculated from those. The advantage is that you can always modify the global material to affect all surfaces using that material.
Initially I had the dampen derived from the incline, but preferred the extra control by manually setting it myself on the tiles. The material for global change is a decent idea but I don't anticipate my game having many different surface material types and so I'm not too sure it makes sense for me to go that route. But I think having some way to more easily, globally adjust dampen ratio is a potential quality of life improvement to my workflow that I hadn't considered 👍
I like your solution for choosing which animation direction you use when moving. Pretty intuitive to stay in the same animation as long as you keep moving in that primary direction.
You literally are your own community manager, and that's just awesome! Love watching your forray into Godot! Going through my own and a GameJam, vids like these are always helpful and motivational. 🎉
Jace, you're a jem of a human being :) As a freelance writer, I've often wondered how the writing differs for a video game. Perhaps in future while you are doing the writing portion of development, perhaps you could tell us a bit of the process into how the writing needs to be done, as opposed to the specifics of what you are writing. Could be entertaining. Also, informative for everyone watching you go through this process :D
Been inspired by your work on learning Godot to try and pick it up to work on an idea I've had on and off for like a decade. Catching up on your streams and trying to figure out little problems of my own has been really helpful with unwinding from my day job the last few weeks. Keep up the good work on your project and thanks for sharing your progress with us, it helps a lot Jace!
I'm developing a game in Godot right now so this is awesome to see. I appreciate you talking about these workflows and recognizing the importance of them. Overall, I feel a few parallels between your 1.5 month development period and my ~1 month development period so that gives me a lot of confidence.
Wow, this is really interesting to learn about. Thanks Jace! :D I know you're too busy for it but you'd do really well teaching how to code/game dev in general (okay i might be biased and just want you to teach me everything) LOL But it's so cool seeing all that you've done already
Certainly a great deal to deal with. Good luck digging in and continuing with your dream project! Have you thought about designing so the map/world can be rotated 90° with like Q and E, allowing a different perspective hiding an item behind a ramp/walkway, upper levels, and such? Would have to design the ramp/step tiles so they looked/handled everything at all 4 perspectives dynamically
You got this. ❤🤘 You didn't fail, you just took a curved road and it can curve right back on course. Each time I go off schedule I call it "Rebooting" my days and get right back to it.
Subbed and rang the bell! I also just started my Godot game dev journey. Although a bit in my off time for now. I'm very hyped to follow your game dev journey!
Hi Jace, awesome progress on the framework and solving these pain points early! One suggestion: For your walk_left and walk_right animations @6:49 update #1 and #3 so it looks like he is stepping forward with different legs respectively, as right now it looks like he keeps stepping forward with the closer foot. Keep up the good work and the transparency, love it!
Thank you! And good point, didn't even think about that with the animation! I may not update it as it is just a placeholder but still good to note. Thanks!
I have implemented path finding in a 2.5d setting exactly with the restrictions and problems you describe before. What I did which you usually can't do in traditional games but which is really not a problem at all in a 2D game is to just generate a directed graph from the tile information. I wrote a function which you can pass in two tiles and it returns you a cost of walking from the first to the second and then you just flood fill from every entrance and npc spawn position, populating a graph. After that you can just use Dijkstra on the graph. This way you can even account for ramp walking speed or swimming speed for example. You could use some A* heuristic either with just basic Manhattan or with something custom that tries to encompass the fake veritcality but you really don't need any of that. Running basic Dijkstra on an optimized directed graph is fast enough for a few dozen or even a few hundred NPCs especially because you can run that in threads. The only other difficulty you might encounter with such an approach is dynamic changes in the environment. As you might know most games use a hacky implementation where the AI does close proximity path finding based on actual colliders but uses its navmesh for the general long distance path finding. In this case it might be smarter to just build the graph in a way you can easily adjust it. Maybe link graph nodes to obstacles like doors that can be unlocked so you can dynamically add and remove the nodes from the graph. This approach became unwieldy in my case because in addition I had to build something that could handle the extra layer of pathfinding that could pathfind across multiple maps (over 3000 different connected maps between 100² and 200² in size each actually) and that made the dynamic part a lot harder. But even in that scenario this approach scaled well enough to run dozens of agents in real time. The graph generation for my case was too much to run in realtime. It took minutes which wasn't too bad to do at build-time and I could have had it running in the background and pause it if I needed navigation on already explored areas but that gets messy very quickly so in that case just a few minutes to generate the graph when building the game was fine. But if you don't do navigation across multiple maps (which is especially slow because maps in 2D games like this are not related spatially so you can't really use an A* heuristic and have to Dijkstra everything for the search) you can easily generate the navigation graph on the fly on map load. My path finding graph with 3000 maps grew exponentially because I needed to precalculate every entrance and exit on every map and all their combinations across maps and run a regular path finding search for every entrance and exit pair on every map so you can imagine how many magnitudes faster just a single map is going to be even on large and complex maps. I dare to say that depending on how large and complex your levels might end up being you could even run this in the main loop without a significant frame drop if you really had to (but you of course really shouldn't do that).
This is that good shit...How the sausage is made. We saw rare glimpses of Dev Jace on the satisfactory streams. Here we get him in all his Glory and im here for it. 🤓
I really like the logs idea for missed/forgotten dialogue. I have been seeing this pop up more in games and always wondered the purpose they served, but now it makes a lot of sense!
i'm on the same boat i'm jumping back on the horse to relearn godot and understand how to use the engine more better. and it's a lot of fun. like you i'm solo deving as well taking on different role for art, design, and programming and the engine is very friendly. awesome stuff on your game epically the translation of different language for other gamers that want to try the game.
Keep it up Jace! we're all rooting for you, amazing to see how happy you are when actually diving into the logic of your game. can't wait to see what you can come up with!
The story is that it's based on the play _Waiting for Godot,_ because of something about anticipation of great things. The name is French, so it's pronounced "Go dough".
17:30 I was about to say, the way I solved this was with multiple tilemaps depending on where I will place the "hill" or whatever and just draw different collision maps. I tired to make it work with collision layers but maybe I misunderstand the feature because it doesn't do what I'd expect/want. Maybe I should look into it again.
impressed with the spritesheet / tilemap editor / level editor in godot from your video... it looks much nicer than that of unity's (from what little I've touched 2D in Unity) in being able to just paint sprites into scenes.
@jembawls As you do have a community and if you already know what items you need, it would be an idea to ask the community do draw houses, trees and other items for you. As thanks for those who contribute, allow them to name an NPC. But doing so, you need to write out strict rules (size, colors, transparancy,.. Unique / not stolen / No AI)
I'm most interested in seeing how you organize the various tasks that go into a solo project. Haven't seen your last video yet, so perhaps you've already gone over that. But as someone aspiring to release a couple games, I always find myself tangled in a birds nest of prerequisites
If you need alpha testers, when you reach that point, I would gladly volunteer my time. I'm that type of person that can and will find any and all bugs with a system, any system. If you need someone to do any testing to find bugs, I'll find them. Love to see the progress, inspirational (but not basic WB style lol). Makes me want to get my projects done even faster. I'm not a programmer, by any means, so any testing that needs done for code checks, it won't be me; but any mechanic testing, optimization testing (older hardware), etc, I'm here.
Like many Unity refugees, I was curious how you felt about Godot and you didn't discuss that much. That said, good job, you're making a game, I know firsthand how hard that is to do and the invaluable practice you're getting doing it. At the risk of souring your creative flow, I could suggest taking a pause from being elbow-deep in the engine to consider the direction you want your game to go. Systems like a dialogue system or a translation system can probably wait until you got the core gameplay loop together in an enjoyable place you want it to be. But, if the goal is just to get used to using Godot, you're already 100% successful in those aims, about the only thing to look out for is becoming too insular in your processes. To combat this, you could make some time to see what other Godot developers are doing, revisit the documentation, even see some advanced tutorials. Anyway, this probably comes off as a little mansplainy, I'm not sure if you wanted feedback on what I just watched or not, but there it is.
Yea im on the opposite end i have many franchisable multi media (games comic connected universes anime shows etc) but i havent even started on coding because ive been knee deep in base mesh modeling properly so it can be pixealized and ik rigged (for years using blender lol) BEFORE i get into the coding because the gameplay to me (as i visualize it ) is much more important but the engine does need to be started and all of these issues that i will run into trying these engines are what im trying to flesh out before i jump into the deep end with the coding aspect because i want full ik rigs and realistic physics and destruction mechanics and a blender to godot 2.5d pixalized workflow but i dont know if godot can handle all that....
20:07 with the npc movement, if you wanted to make it look more organic, you could create shapes that they walk randomly within, like along some path but with a random offset of some width that varies along it
Hi Jace! Great to see you've also joined the Godot crew, you'll be a great boon to the community! And if you want help with localization for ptBR, gimme a shout, I'm a professional translator and I'd love to help! Been working with it for 10+ years =D
Loving these videos, keep it up! You're doing the right things. I always start with similar fundational systems like translation and accessibility because as you said, retrofitting those is a pain. I'm very curious about how the unit testing capabilities of Godot and game dev in general are. I'm always nervous to see complexity build without the safety net of tests.
I'm a tech guy. I had the dream to create a game when youger, never tried and this shity situation with unity make me want to try godot. For now i have a lot of fun learning it
As a solo developer dealing with switching gears from programming, to art, to story, etc. Do you create any amount of documentation to cover how you got things setup to help when you switch back? So magbe explaining bits about the translation or waypoint systems. I'm more the developer so less familiar with art and writing but can imagine maybe tracking overall ideas or maybe even checklists of stuff to finish. I often have good intentions for notes but don't always manage it. I also only really use a loose version of Markdown for digital notes, i forget to check the syntax and rarely actually view them as rendered anyway. I keep wanting to find something nicer. Oh and i don't hand write notes, too many years barely writing so I'm slow and it's hard yo read lol.
I realize I'm very late to the party with the following crazy idea, but: this would be trippy in 2.5D with the levels zooming up and down as you ascend and descend ramps and stairs.
I would love to see a deep dive into the process of creating a tileset. Starting from which tool you use for creating the tiles, up until you import it to Godot. I can program, but I have no idea how to actually make graphics in a way they are usable for a game engine.
Yeah, having 2d-looking 3d or vice versa seems important. Currently playing Sea of Stars and you definitely get a sense that sprites have a real incline when you see hookshot collision based on your elevation, or the magnificent water submersion rendering. Another very inspiring game for me is Eastward, there they have very rich dynamic lighting implemented ina 2d tile context, was definitely a treat to look at.
@18:08, Have you thought of modifying the Godot Engine its self to allow the kind of collision handling you want? Maybe that is outside of the scope of what you want to do, figured I'd toss the idea out there. Or you could send a message to the devs as a suggested feature.
It's not an easy thing to implement but rather than put hardcoded paths into NPC movements, instead create an "intent" system where you can instruct the NPC what you want it to do, and your code then tries its best to do this. You can define paths to make NPC routing easier as it both simplifies path finding a lot, allows pseudo-3D to fits in easily as the path mesh is separate to the display (far too many systems the display of things is all there is and then awful work arounds have to be put in place to work around this). The extra big thing is that this makes scripting NPC actions considerably more intuitive and flexible. For example, it means that you can script an NPC to "go pick up something to eat" then "go sit and eat this", etc. You can expand the possible actions as you implement them, testing is easier, and the NPCs feel much less like robots on rails.
Background Dialog / Barks shouldn't be too difficult to implement either. By that I mean, unboxed dialog intended for use as mentioned, Background Characters, but also if applicable, combat barks and other bits of dialog you want to have that doesn't interrupt the gameplay with a dialog box. With the Boxes and Background Quips. These texts should NOT appear in the Dialog History, but can be used to attract the player to a side-quest more naturally by introducing it through Background Dialog.
Thanks for the video. I currently also have a foundation for a game a built but reached the exact same stage you are at but I'm reaching a bit of a block with level design and writing and would love to get some tips on how to approach that. Especially how you tie together the game mechanics you have with a story and level design.
Re: localization I'm really familiar with how Android does it, which is have any and all user-visible strings in its own resource file(s). This way, all you need to do to localize the text is to go in and make text files for each language you want to support. The downside to this is, it removes all context from those text strings, so doing stuff like hiring out the translation can lead to errors. Looking forward to playing with how Godot does it.
Does Sweden hook you up as an indie dev? I've heard they're very supportive of the arts and other things. I've been trying to get into a routine of making my game for a while, but my day job drains me out. I applaud you for taking the jump and going out on your own. I wish you success!
I got a total brain block making a NPC controller in Godot a little over 3 years ago (3.1 maybe?) which prompted me to take a break and I haven't gotten back to Godot yet.....
Год назад
Casually waiting for “Community Manager Simulator” in Godot 😊
Here's how I imagine a writing video montage... walking in a park, with a look of consternation, confusion, concentration, and constipation, a.k.a. your "poop face". Walking in the city with your poop face. Sitting at a traffic light with your poop face. Waking up with your poop face. Doing chores with your poop face. Sitting on the toilet with your poop face. A "pop" sound and a look of surprise that turns to awe, and then frantically writing on a paper notebook. Tear out the page and say "genius!". Fade to black with the toilet flush sound. Or something.
Neat - enjoy your videos. Suggestion : Game Endeavor "Adding Bridges to Our Indie Game - Devlog #4" show collisions working by changing the mask not the layer - maybe this will help ? Question: Why did you not use Dialogic 2.0 or Dialogue Manager ? What issue did you find that they did not support ?
The short answer: I didn’t know about them and I just needed to start somewhere with making my game and decided to start with localisation/dialog. So far no regrets. I really like the system I have and I’ve learned a lot about the engine while working on it! Oh, and solved the collision issues today with multiple tilemaps and collision flags 👍
@@jembawls Neat - I am supper lazy so if someone else has built something I just leverage there work and becuse most of it it open I can edit and maybe contrabute back. Good like with the multiple tilemaps - sounds like a lot of work when you go to the next biom.
For the collision height, isn't it much easier for entities to have a z-coordinate and then when colliding check if the z coord is within range of that of the entity you're colliding with? Duplicating the tilemap for each level(?) sounds like a maintenance nightmare.
Noticed the Godot Mascot in your game... I can't help but to have a sneaking suspicion that it's gonna become a Summon Monster ya get in the game to munch opposing baddies with... Or... it'll just be Shameless Godot Promotion. :P
Rather off-topic but your English is very fascinating to someone who's studied linguistics. I take it you spent some time in Australia? The faster you speak and the more stream-of-consciousness it gets, the more Australian you sound. In between is an impeccable international English with some surprising rhotics and North Germanic consonant-diphtong pairs. Would love to know from what influences/social groups you picked up those dialects! I guess a Scandinavian-born speaker who studied in the pacific commonwealth would fit, but from experience it's rarely as obvious at it might seem.
Interesting! I am Australian actually. I moved to Japan when I was 20-21 or so and lived there for 3 years (surrounded by a Japanese folks and also a lot of international folks), then moved to Sweden and have been here for around 9 years.
Given you have experience in Unity and Unreal, would appreciate when you talk about implementing features that you mention your experience in the other engines. Especially right now when people are trying to evaluate if the value is worthwhile...
Are your earlier dev streams saved on youtube or twitch? I'd love to actually watch everything from the beginning and see how you approach everything. I've been doing some C# learning and would love to start doing some basic game dev (it's been a dream of mine since I was like 5) but I have such a hard time actually getting started and figuring out what to do first.
I like the dialogue history idea, do you see that as a temporary history for that play session or available through the game for every bit of dialogue?
Instead of having another tile map to change the collision parameters, could you overload the method to for handling collision, and in your new method, you would use the custom-data on the object to consider the z-index of the player, and whatever other parameters (eg: which side the collision is on)?
