I am Vector, and in this channel I share the games that I am working on! Currently I am developing a game called "The Tale of LUMI" a 2D action game.
Wishlist The Tale of LUMI 👉 store.steampowered.com/app/2334400/The_Tale_of_LUMI/?
I have been developing games and apps for over 9+ years and now I am on a new journey as an indie game developer! I have a lot of video ideas related to game development and the indie journey and I hope you find it interesting!!
I will also document the game dev process, and I will be doing timelapses as well to show what I usually do when I am developing games!
This is a cool trailer and makes me want to play the game, but I feel like a lot was going on. I wasn't really able to see the main action. Maybe you should zoom in a little when making trailers?
Hey!! Thanks! Good shout, there is a lot going on Will give that a go, I have a new trailer on the making for the game, so can update it to see how it looks 😁 Thanks for the feedback and suggestion!!
Hey! Great Video! I know this is a long shot, as the video is 3 years old, but if you could answer it would be great. Is it possible to have videos/animations instead of the images? Could you point me in the right direction? Thank you!
Hey thanks!! Yeah you should be able to do it Not sure exactly what you are trying to achieve with the videos, but you could have a raw image with a render texture in the UI and then a video player with the video you want That should give the videos playing instead of the static images
Could you explain a bit how your drawing the other textures as part of the tiles ? I would love to understand the logic here 😁 I looked at stencil buffer and passes, but I don't have thoses in godot4. But I will make it somehow, that's why your logic here would be very helpfull !
Sure thing! I simply add them on top of each other using Unity shadergraph - also I make sure that I use global UVs instead of object UVs And to add that as part of the tile I use the red color channel of the original tile There's also a noise that I control with a variable and it's applied to the red color channel as well Let me know if that helps!
@@vectorgamedev so you have a material on the other textures, or on the tiles one ? And how do you get them ? By the way I did it, but in Godot. So what I'm doing is, first I draw the textures I want (in the top of the scene tree) then I make them use a shader ( that turn there black part into rgb(0,0,1) so it's still black bit not for computer, Then, either you have your working space black, but ... so I just draw some black textures to act as the black mask, I SAVE this screen texture using backbuffers I put all I want in the scene , now order don't matter, and here I have my tiles, and when it's pure black I ignore it, else I draw the textures !
Thanks forn the share. The red is for texture mapping, the blue for a shadow gradient, the green for the shadow line and the black for the outline color
like the document best, a mindmap is just a thing to help you get a better picture. at the end of the day if it's just you just proceed with what feels best for you though, glhf!
What ever happened to just trusting your game designer instincts? You know what to do, you don't need this complicated huge document. The value dramatically drops when your doing anything more complicating that writing down small bullet points about the mechanic your are currently working on.
Yeah good point, now thinking back the only reason I started doing this was because I had other people helping me, but if I was on my own maybe just my todo list would suffice
A documentation does not need to be a document. Especially in the creative sector, the documentation is mostly visual. If you look at web design, most mockups and wireframes are considered documentation and I had some colleagues dabble with video documentation (e.g. recorded management presentations) very effectively. The "document" needs to convey the intent and help understand "The Plan" for the project. I am personally using Obsidian with a simple checklist segmented into versions where I plan out the next 2 versions while working on the current one. Documents are often used for pitches and management informations but never in my coding or design career have I seen a good document used for a project definition. If those are used to document the project, they often are outdated very quickly and updating them takes away a lot of resources that could have been put into the actual project. I like your visual approach with Mira and I considered it before myself. It helps with segmenting parts of the game and getting a quick visual overview. Zooming in and out can also help to get a feel for the current state of the project. Sometimes we tend to overlook how far a project has come already :) Nice project and video :) Keep up the good work!
Hmm dude, you hide explaining a standard practice behind a clickbait title and use all this to just advertise your game. Leaves a bit of a bad taste. To be honest :/
Usually what we do is simply assign a z value to each layer, and move them relatively to the camera at different speeds according to their z value. Why did it cause issues for you?
Hey Eliane! The effect itself wasn't looking great, so I had to customize it - then I went down the path of overworking on that And with the perspective camera was just easier to do it - also as a side: it was a little tricky to get it perfect when I had to position the player on a specific position on the map
I think you're missing the presentability of a GDD. This is navigable and usable by yourself... but a GDD is not primarily for one person. As the designer of the document and having good memory, I at most reference it once every few months, but I still made one with presentability in mind because of others reading it such as team members or a publisher so they can understand what's being made. Having everything just splayed out on a field instead of linear pages is going to make it less navigable and confusing to take in.
Ah I see what you saying, in this case yeah I agree - for us though its more about making sure what we discuss on a daily basis is updated instantly and we can see the thing (features, systems, characters etc) before we implement it in the game
I've been toying with using Obsidian as a nice, hierarchical way of organising many documents into a single GDD. If you've ever followed Tynan Sylvester's methodology, I think his idea repository and ToDo lists could be implemented and shared quite efficiently with the right plugins. Best of all, it's FOSS!
Kanka is what I plan to use, after I realized that campfirewriting was too restrictive. I need a tool to organize Dialogue, NPC's, Items, Skills, Quests and so on.
I think what was missing from your documentation was modularity. Others already mentioning Obsidian.md, (or any markdown editor) is perfect to make your notes more modular. That way it feels less like redoing a whole word doc and more in line with what your game development environment is like, all files and folders with separate assets. I think there is some value in keeping the 'old' notes in with the new notes. Could even silo them into an 'old' folder, but still link them in the new note. Just have a good versioning naming convention.
If you're already using Obsidian and haven't given Obsidian's Canvas feature a look, definitely consider doing so. While it isn't as out-of-the-box powerful as Miro appears to be, the ability to directly link your notes to and from the board might prove invaluable to you. Another option in Obsidian, if you specifically need something that works like a whiteboard, is a community plug-in that links Excalidraw canvasses and allows for them to be edited directly in Obsidian itself. Excalidraw looks more similar to Miro -- though seemingly still more lightweight -- but I haven't really used it all that much myself as Canvas works just fine for me. Hopefully you find something that works for you. Best of luck!
I have been using Miro for a long time and I can highly recommend it. It is good for concept, idea generation and collaboration. Later you can put it into a Design documentation and refer back to Miro if needed. I ended up using it also for producer related elements and it was also a strong assets combined with excel to manage a team. So it can fit a lot of use cases. Definitely make sure to see what other software that are onboarded with Miro. Jira was hard to use, but they made sure now you can refer to code related workflow so that is a huge plus.
Some may have said already, but tying your health to your magic system is BAD. You are saying that in order to achieve combat, you have to sacrifice health, making every encounter not only dangerous, but unfair to the player, who takes on damage from simply attacking.
Yeah, got a ton of feedback on that 😁 I failed to mention on the video as well that the kick (basic attack) doesn't require energy Working on fixing this though 💪
When I first saw the new UI I thought you would do something like each square is 1 health point and the 4 highlighted corners represent your available skills. So if you use 1 skill/consume energy you would lose one of those corners, the center square still staying the same. This goes on clockwise until you depleted all 4 of these outer corners. Now the next time you use a skill you would take 1 damage. However every time you take damage you move to the next square where all 4 corners are filled again. In theory players who use very few skills will often experience the feeling of loss because they missed out on 2-3 corners they didn't use before taking damage, so they might start using skills more agressively. On the other hand if the players use too many skills they either need to try and dodge more enemies so they can conver their HP more aggresively into energy without a fear of running out, or they might stop using the skills all the time and try to think more about when to use them and try to preserve as much HP as possible. This is just what I personally first read from the UI and thought what would happen. This system might have flaws and might not work for your game, but I thought I might share my expetations.
