Don't wanna be here? Send us removal request.
Text
Here's me getting back on the wagon (or off the wagon, I don't know, whichever)
So I've been messing around with inheritance and trying to wrap my head around how it works in Godot.
Take the battle system for example. At the moment it's a combination of inheritance (basis -> controls -> utils -> battle scene) and components (the battle engine object).
Basically, say you have these functions in utils:
func do_thing(): some_function()
func some_function(): -do whatever here
And in a battle scene inheriting from utils you have:
func do_another_thing(): some_function()
func some_function(): -do other things here
Calling do_thing, which is located in utils, will actually call the battle scene version of some_function, not the utils version. I'm still kind of wrapping my head around that.
But with that in mind, I think I'm actually going to eliminate the battle-engine component and make it another layer of inheritance instead, between utils and scene. (Or the user can just put all their engine stuff in their battle scene script if they really want to.) The necessary functions can have dummy versions defined in basis or utils that can be overridden in the engine layer. This also eliminates the awkward way the battle engine is loaded, making the code overall cleaner and shit. And that's pretty neat.
1 note
·
View note
Text
I'm sorry, is this the new Palfriend? That's just Arceus's face, Dialda's tail, and Golisopod's hands... man
0 notes
Text
So in case you're wondering what I've been up to for the last month or so (no one is here), I've been working on this-
A CRUD app! Because that seems to be what everyone's making these days. It's an editor for monster data. Because, like, all the tutorials were for managing employee data and shit, but this is what data I have that needs managing. It's got a React js frontend and a javascript backend.
It basically runs off this list of data that spawns the entry rows and stuff, so I can add to it easily or reuse the base code between projects:
That's neat, but it was a real pain in the ass to have to start up both the client and the server whenever I wanted to use it, so I made basically the same thing but in Python with tkinter:
And as an example of reuse here's it being used for moves data-
A lot of things are made easier with this. Mainly there's only one data list, whereas the CRUD app needed the state hooks declared, then the data list including the "pointers" to the state variables and setter functions, then the backend needed its own list of the names of the SQL columns.
This version has some extra features like, if you add something to the data list it'll add a column to the SQL database for you. Plus Python is similar to GDScript, so I could bundle a basic version of it with the Mondo code.
Meanwhile I've been upgrading the battle system to handle multiple mons in one battle-
Next I'm probably going to step back a bit and document the code, because it's becoming a bit messy and I need to clean it up
5 notes
·
View notes
Note
There's nothing really that interesting about composite numbers. I mean, most Pokemon's stats are composite- your multiples of five and ten and whatnot. Now maybe if they were composites of "unusual" numbers, like 7/11/13, or larger prime numbers multiplied by smaller ones like 2 or 3, that might be slightly interesting.
The next Pokemon group (after UBs and Paradoxes) should have composite numbers as their stats, right?
It's a fun idea to have deliberately non-prime numbers as opposed to UB's prime stats (except naganadel's 121), but I don't think Paradox Pokemon had any pattern in their stats as they got composite and prime numbers. It's a fun concept but understandably not a requirement
23 notes
·
View notes
Text
>Pokemon company is engaging in legal action against Palworld
lmao based fuck em up
1 note
·
View note
Text
It says what it does and it does what it says. New posts coming soon(tm)
0 notes
Text
why the fuck did nobody ever tell me java was good for making programs with guis? this shit works great, what the fuck
0 notes
Text
I haven't been working on this as much because I've been job hunting (anyone need a mediocre dev?), so let's get back into it by trying to make a game in the engine as it is now.
I envision a game where the "mons" are just wild animals in a forest. You wake up one day and decide you're going to do on a journey and kill God, you know, typical JRPG plot stuff. Game won't be very long, something like 3-4 main areas.
Menus are fucked until Godot makes hboxes and vboxes work properly with items added by scripts. I could probably do something about this (ie not add items by script) but idgaf
Species: I'll be adding a single new stat, magic, which acts as a secondary attack stat with both attack and magic using the target's defense stat. So it's like gen 1 Pokemon's special stat but it's the defense stat that's doing double duty. Will this add a massive amount of intrigue and ingenuity to gameplay? No, but it's slightly different, so I'm doing it anyway.
While on my desperate quest to figure out how to get jerb I did end up making a species editor webapp that's made to work with Mondo, so I can use that to, you know, put together the species data.
Unique type system of course. Probably just single type per species. Not sure if they'll have abilities, probably not. Since you only recruit one of each species, no unique stats (IVs/natures), probably no EVs either.
Moves in the engine are currently very rudimentary. Priority of all things is fully implemented, but secondary effects and power points aren't… not sure this game will even have a PP system versus something like a mana pool. The species editor can be used to edit a moves database as well.
Battlescenes… none of the basic ones will actually be used. You'll always have all three party members (two early on) on the field, versus like 3-5 enemies per battle, and the mon-swapping mechanics/menu won't be used at all. (Neither will the items menu which I haven't made yet, probably.)
Sorting battle participants by speed is something very Pokemon-like, so I might want to do something different. Maybe have a random buff/debuff to each participants' speed before sorting, and have the resulting order for the turn visible to the player. That's a but like the old Pokemon contests actually, so maybe have moves that change the order in the next turn. Dunno if priority would be added on top of that. The speed-sorting function is in the basic battle functions, but it's only called on the highest level script, so the user can just swap it out there for a unique one.
In terms of balance I'm thinking something like, the weaker earlier critters level up faster while the later stronger ones take more EXP to level up. So both groups of party members have upsides and downsides, with later critters not being quick easy strength immediately. So EXP growth classes will be implemented.
For assets (mainly music and character models) I'll be relying heavily on OpenGameArt. Looking at the animals available gives some amusing ideas- how about you encounter a whale as a subboss in a lake halfway up the mountain?…
1 note
·
View note
Text
Updating my actual game project to use the things I've implemented in the default project and realizing I've forgotten half of what I've done, lol
0 notes
Text
I'm live-hyacking learning React by using the sandbox examples on react dot dev because setting things up is a pain
Best part is it works
I'm gonna make a dex editor, it'll be a good subject for a CRUD app probably and also I could actually use it
1 note
·
View note
Text
youtube
modern neutered gutted gormless "comedy" will never approach the level of two anime girls yapping about fentanyl on livestream
0 notes
Text
shuumatsu train review: meh
I think the best way I can describe what I'm getting from it is that it doesn't know how to engage with its own weirdness. It ends up feeling both too weird and not weird enough- too weird bcause all the weirdness just sits there at surface level like oh wow look how weird we is, and not weird enough because it doesn't know how to engage with its own weirdness and deepen and explore it.
The mushroom people episode for example was incredibly boring. I was hoping for a twist where, short gloomy girl wasn't being paranoid because she was the only one not shroomed but because she was the only one who WAS shroomed and it was messing with her head, or where the mushroom people weren't actually planning to trap the girls there but just grow some shrooms on them to add to the general population but since they wouldn't exactly mind if the girls stayed as well they come off as menacing… But no instead we get a generic DUDE JUST GIVE UP AND DIE LIKE ALL OF US LOL (or I guess not idk they just kind of give up at the end) and then GIVING UP AND DYING IS BAD YOU GUYS (unless you really want to idk you guys do what you want I guess) story. And then the mushroom stuff drags on for the next like three episodes because the writers don't actually have enough ideas, except the mechanics randomly change so now it grows on her butt and pulling it causes her brain to melt. Why the mushroom still? Why not have it be something from the other stops they just skipped over? Incredibly meh.
The characters are incredibly boring. One of the best things to do with a story like this (or any story ever) is to give the characters strengths and weaknesses and so on that can engage with the setting, be tested by it- both the setting and characters work to expand the other. Like in meguca, Sayaka's simple straightforward heroism interacts with the setting to make her a very complex character while also exploring the workings of the magical girl/soul gem/witch system, all very naturally. Again, episode two could have made something out of the gloomy girl being driven to shout "DUDE DON'T GIVE UP ON IKEBUKURO" when she originally was against it or unenthusiastic, but it doesn't actually set that up. And then in episode three the other characters helpfully inform us that she's the gloomy and cynical one, even though we just saw her not being that in the last episode. So her potential character development is erased both coming and going. We're also told that the gyaru "sometimes doesn't see the big picture" which is overly specific and a trait we don't ever really see from her besides her being the bullheaded and stupid one of the group. But thanks for telling us I guess.
Also they're obviously setting up some thing where the weirdness all ties to stuff main girl said to missing girl (anteaters and mushrooms and small people, waow what could it mean) but that doesn't really add anything to the story, or mesh well with it being caused by 7G outside of missing girl being the one to press the button (and then unpress it, and then press it again... this could all have been avoided by her not having pressed the button a third time man).
Lmao and now episode 6 starts off with the girls randomly getting on main girl's case about dragging them along even though they hopped on the train themselves. And they acknowledge that they all hopped on the train themselves then say pointing that out is insensitive somehow. Yay, I love forced drama!! Fuck off. … Actually this is even worse. The zombie stuff is too similar to the mushroom people stuff which had already been dragged out too long. The girls are banging on about "but if she ZOMBIE is she still FRIEND?" which is utterly meaningless because their friendships have barely been developed. And the delivery guy showed up. That doesn't really help to make the world feel big. Like, it was supposed to feel like the girls were going somewhere they never otherwise could have by getting on the train, but then this guy shows up like it's nothing. Coulda just hitched a ride with him in the first place if it was gonna be like this. It's not even like, this is the furthest edge of where he can go, or like they move a lot faster than he could. There's literally no purpose behind the train, just hotwire a van man. And they mention out of nowhere that the areas on this one specific train line are the only ones that still exist. So it's not even like he can go other places outside the train line. What is the point of either of these groups??
Man, I want some GOOD weird shit not this shitty boring stuff man…
0 notes
Text
On second thought the "super" thing isn't quite as useful as I thought, because the function to calculate stats needs to be overridden to, you know, change how the stats are calculated, and I'm pretty sure the base class code that sets the default stats will be calling the base stat calculation function not the extended one. I could probably do something stupid and circuitous to circumvent that (and I already have an idea what I'd do), but for now it's just a nice thing to know is possible.
… Actually, no, according to my highly sophisticated debugging techniques, calling setstats from the levelup function, which only exists in the base class, calls the extended version of the function (which then calls the base version). Neat!
Anyway, let's talk about level-up moves. The format for defining levelup moves needs to be able to handle the following scenarios:
Multiple moves learned at the same level (so you can't have a dict and get moves[level], unless you're willing to manage possibly getting an array of moves from that)
Moves learned on evolution, moves only available via move-relearner tutors (in the Pokemon games these aren't gated by level so could be listed as level -1, -2 etc, but I think being able to add a level definition could be interesting. Like, you evolve Vulpix to Ninetales after the level where Ninetales normally learns Flamethrower, it'll learn Flamethrower, but before that it learns Fire Spin. Or you hit a certain level and new moves are available via the relearner tutor.)
Other wacky shit (imagine having like a 1/5 chance to learn a move at a certain level based on the mon's unique data or some shit lol)
The simplest method would be an array of [level,move] pairs in some form. The only other Pokemon-like game in Godot I've seen, the Pokemon Uranium port, does this
Which actually seems kind of appealing. You could have an optional third parameter for additional data, defaulting to an empty dict or something, where you could pass in tags indicating a move is learned on evo, or relearner-only, or what have you.
However an even simpler method occured to me: two separate arrays, one for simple moves and one for moves with additional parameters. For the first array you expect each entry to be a two-element array, for the second a three-element array. That last element could be a dictionary or just an array of flags.
Performance isn't all that important. Even in the most insane case of some gimmick mon that learns five different moves per level (which sounds like a fun idea, actually…) it's only a 500-element array, which isn't that slow to iterate through. If it's assumed entries are sorted by level, a binary search method can be used to speed it up as well.
That all should be good, so I'm left with the last barrier to implementing levelup movesets: creating levelup movesets for everything. For the pointless placeholder creatures of the useless default project I can just throw in whatever, but for my couple of original games, well, it's time to get designing. In the meantime maybe I'll start theorizing on how to implement save files or something.
2 notes
·
View notes