I really need to subscribe to this thread rather than pop in once in a while and realize I have a crazy backlog to reply to. :D
Thanks for the tips, guys. I guess turn based combat could work If I follow Weltall's advice of making it superfast. My plan is to make combat "optional" if the player doesnt want to do it, as it would be limited to specific areas of the game world, like ruins and a forest, so if the player wants combat to get itens he or she could sell instead of farming, the would actually have to seek it in those areas.
Without going quite literally to the extreme of that game, why don't you look a bit into Half Minute Hero for inspiration on superfast / optional combat?
Yes, although nothing is really complete yet. For example everything I made for that town is in this screenshot. There is nothing more yet. And if look closely the NPCs running around are the main party characters. I've still got a lot of work to do!
That's still crazy beautiful for the work of a single person over a couple of years. Getting strong Chrono vibes and frankly I can't think of much higher praise.
As a rule it not good to be have a character looking over they shoulder make them look shady and shifty, but love the style.
Yeah, I was going to say that that character portrait may be the only thing I didn't like, the eyes look odd / derpy to me. As a general rule character portraits should be, well, portraits, like police mugshots; artwork with dynamic poses is best used for other purposes.
A bit of an off topic question, for the expert programmers. Im starting Information Systems in college, and also starting game development on Game Maker Studo 2, so programming is still very new to me. Im following tutorials, and such, but something is bothering me a bit. Currently Im starting data structures, and the number of functions and syntaxes are growing exponentially for me to remember. The question is: through trial and repetition, you guys eventually start remembering all the functions and parameters? Or is kinda normal going after the documentation for every single thing?
I have zero memory and often can't remember the parameters for my
own functions; you absolutely need not memorize any of that because any decent IDE has autocompletion and contextual help where typing a dot after an object displays a list with the functions it has, and typing a parenthesis after a function name displays all its parameters. In most IDEs you can also invoke it with ctrl+space after typing a few letters to see what objects / functions match those letters. So basically absolutely don't worry about memorizing anything, and just focus on
learning what they're used for what and the differences between each structure type are.
Also you might want to check my post a few pages ago about the amazing Coursera / University of Michigan game dev courses. It's what I used to get started with Unity and they're fantastic.
I was thinking something along the lines of:
Hit % = 200 - ((atkAccuracy / defSpeed )* 100) but it seems extremely silly. I'm sure there's an easier and more intelligent way to do it, I just can't put the finger on it.
That formula seems wrong: besides the potential zero divide, unless my math is wrong, the hit chance is lower at higher accuracy and higher at higher speed of the target. I'm assuming you meant to do the division in reverse, but even so it still has issues (anyone with more accuracy than the target's speed has 100% to hit, for example).
Dividing accuracy by target evade seems intuitive but the issue is that it makes actual chance to hit fluctuate wildly at low levels (when players and enemies have 1-10 accuracy), then become almost fixed later on when everyone is in the higher range (80-100). For this reason some games simply substract them instead: the simpler solution is sometimes the best. How about this?
Hit% = 80% + (Acc - Dodge)
This makes accuracy and dodge a race that's always meaningful to stay ahead of by a few points. You can cap it between 0% and 100%, or you could use 1% and 99% (or 5% and 95%, or anything else) to always provide a chance, however small, for attacks to miss or hit.
Damage calculation also should stay rather simple. I'm going with:
Damage = (Power *2 + SpellPower) - Defense
I need to test this out a lot of course, but I'm thinking of using spell power ranges from 5 to 999.
Interestingly if I understood correctly (that SpellPower is a fixed atttibute of the specific spell), in this case I would do the opposite, i.e. multiply the character's power and the spell's power. If a character's spells do 2 and 10 damage, it makes sense that the character levels up and the first spell does 4, the second does 20, not 12. In fact as you level up powerful spells would become comparatively weaker, especially per MP.
What do you guys think? Would really appreciate some input from you :)
I love all things math-related so this was fun, I'll be glad to give more opinions on anything. :)
So, this may sound a bit silly, but I just finished my first script, to generate a "crop" from an object list when pressing a mouse buttom. So happy, hahaha. That marks my second week in game development!
That's pretty cool, reminds me of one of the uses of the celestial brush in Okami. :)
I'm using Godot engine.
I don't know if there's some pixel perfect flag but i experimented a little and i can get a pixel perfect look in orthographic mode if one of the screen dimensions is a multiple of 64(my number of pixels per textel), that way i can use some int values for the FOV resulting in int scaling for pixels, for the other cases i still have to see.
That sounds promising, care to share a screenshot? It's a shame this solution only works in ortographic; the problem is perspective... I keep thinking about it.
About your "madness", if i understand it correctly you are suggesting to just stamp the sprites, but sprites are affected by lights and produce and receive shadows, so they need to "stay" inside the scene.
Of course, you're right. I don't shade my sprites (actively disable shading) to stay faithful to the arcade look, but your case is very different. It would have been a pretty crazy "solution" in any case, but yeah, you got the gist of how it'd work.
About the filter... sorry but i won't undergo my poor sprites to that lol.
You don't think the monster there looks at least better integrated / less "corrupted" than the main character? You don't need to do such extreme filtering but I personally think at least some filtering is better than having some pixels take one screen pixel and others taking four... :/
That said some precisations:
-all that applies to the orthographic projection(the 2d-like one), in the perspective projection there will always be some deformation(unless i keep the character always at the exact same distance from the camera, i'm definitively not a fan of this solution but i guess i'll consider it) but all the images i posted come from a 1024x600 window, so low resolution hence deformations are big and evident, on a 1080p screen deformations, while still present, aren't as evident.
That's also a good point. It should also depend heavily on your original sprites' resolution; I think there's a "sour spot" where deformation would be most obvious, and unfortunately your screenshot sprite / screen resolution ratios landed right there. With higher resolution sprites you wouldn't notice their individual pixels: with lower resolution sprites, their pixels would be so big that each individual one would barely get deformated.
-i'm still veeeeeeeeeeeeeeeery early in the development and i'm still experimenting things, so i'm not doing refinements and small things... At this point you may ask: "if it's so early in the development then why you are already doing trivial optional things like 2d-like and retro looks?" Well, because most of the time i code things that don't have an evident impact on the game or work on assets that aren't still ready to be in the game and so on, so sometimes i need some visual "gratification". :\
I don't think anyone in this thread would ask anyone else why they're doing something before something else, we're all doing stuff in weird order as we feel like doing them. :D My only advice is to try to have a fully working slice of the game as soon as possible; a prototype if you will. This is extremely useful both for checking what is fun and what isn't before you're too far committed to your design to change anything, and also to show the game to people (and even let them play them for feedback). Hell, use placeholder / ripped assets if you have to. You seem right on track with that already, so you're good!
