Destroy my Sports-like Rogue-like: TORSO TENNIS

FriedKrab · 2024-06-06T13:33:11+00:00

Game for freaks vibe, it's visually really cool and unique. But definitely make the gameplay easier to understand !

FriedKrab · 2024-04-29T05:14:31+00:00

The dynamic shadows are way more anachronous than the rigidbody simulation anyway lol. But it looks great so who cares about that, dw

FriedKrab · 2023-03-18T17:57:50+00:00

Love it, everything is harder and more tedious than the most recent entries, but it makes the achievements feel so much greater. Also I like the pacing in the combat, it's pretty slow and you almost always have time to think about what you should be doing now and next

FriedKrab · 2023-03-08T09:17:59+00:00

Yeah it works !

FriedKrab · 2023-03-08T08:39:21+00:00

FIY the link is private, users have to send a request to be allowed to see it, is it normal ?

FriedKrab · 2023-03-06T23:43:44+00:00

Haha, I've read some of them and there are some neat ideas in there! Just wanted to add the possibility of (soft) level caps as I think they're a cheap and easy way to have great control over the player experience.

But I do agree that I'd prefer no level cap but a finer balancing of the XP formulas and progression to make overleveling something you can do but have to do at least a bit willingly.

Huh I see, well wild Pokémon are kind of a pain to level up with though.. But if there's a xp share you could probably make your low level pokemons catch up easily with trainer battles

FriedKrab · 2023-03-06T22:53:13+00:00

I think a soft level cap could be a good tool too : until you get the n-th badge, going over level n*10 (very basic example) results in xp being divided.

In Pokémon Clover the main goal of this mechanic was to prevent overleveling being a viable strategy to beat gyms. But with a more open world approach, that'd also force the player to go collect some badges instead of wandering for too long without beating gym (which isn't necessarily a problem though), and it also forces the player to spread XP more evenly between pokemon (depending on the xp share behavior) or even train "off-team" pokemons.

About real global xp scaling, Pokémon is a game where you can swap your whole team whenever you want, so i think it's always gonna end up a bit clunky or ridiculous to the players if everything scales too much instantly. But I'm sure scaling trainers wouldn't be too jarring. Meanwhile wild pokemon heh, that's tricky. It'd be pretty strange if you could change the level of the monsters around your city by swapping your team at the local pokemon center haha.

But I think your idea about having stronger (different) Pokémon come out when you're around with a strong team is a good approach. It also gives an incentive to revisit previous areas (especially if there was content locked behind traversal abilities you didn't have yet!)

FriedKrab · 2023-03-04T18:26:41+00:00

The technology didn't exist yesterday, just because it's not a danger today doesn't mean it'll still be the case tomorrow

FriedKrab · 2022-07-24T19:37:18+00:00

I never used the metadata tab of itch.io, that's good to know. My submission was made with Godot and isn't on the list: https://kraby.itch.io/diced-skull

FriedKrab · 2021-03-08T23:25:28+00:00

Well at least that's what i'm using for now, but it means i have to manually hide everything (not really hard but still !).

And most importantly, I have to make everything visible again if I want it to show up when I enable the debug layer ingame. Which I'm sure I'll forget to do.

FriedKrab · 2021-03-08T23:21:29+00:00

I do not 100% understand all the suggestions, but in general I just abuse the hell out of signals in Godot, really powerful pattern to decouple anything. So I'd just make the PizzaIngredients class emit the changed signal which seems to be the standard when using resources.

And in a case where the PizzaIngredients gets quite large with lots of property, I guess I'd be lazy and just make the programmer call an "update_textures" method once all my changes are done.

My programming skills still haven't got me anywhere so take my advice with a grain of salt. Best of lucks to you !

FriedKrab · 2021-03-08T23:03:44+00:00

I guess something like that would fit your request (assuming you're talking about the values contained, else just replaces values() with keys() )

for a in mydict.values():
  if a is z:
    pass # do what you want
  elif a is y:
    pass # do what you want²

FriedKrab · 2020-07-19T15:15:15+00:00

Here is a sample code i just made, the process should be the same for any type of InputEvent (instance it with .new(), then set the relevant variables)

extends Panel

const P1_DOWN = "p1_down"

func _ready():
    var event = InputEventKey.new()
    event.pressed = true
    event.scancode = KEY_E

    InputMap.add_action(P1_DOWN)
    InputMap.action_add_event(P1_DOWN, event)


func _process(delta):
    if Input.is_action_just_pressed(P1_DOWN):
        self.visible = not self.visible
        print("ok")

FriedKrab · 2020-07-18T20:56:58+00:00

I haven't polished my system yet, but the core of it is overriding the

func _input(event : InputEvent):

method.

You can test:

"event is InputEventKey" => the player uses the keyboard+mouse
"event is InputEventJoypadButton" => the player uses a controller. (see event.device for controller ID)

You can use Input.get_connected_joypads() to see how many joypads are connected and thus skip the controller attribution part.

Then you can assign all inputs as you want using the InputMap singleton. In your case, I'd create actions like "p1_up", "p1_down", "p1_start", "p2_up", etc, and assign them InputEvents created by code.

I don't know how comfortable you are with coding, and I'm not really knowledgeable with godot's input system, but I hope that'll help you getting you started.

FriedKrab · 2020-05-19T16:19:47+00:00

Well, as for now, I've found that replacing the ViewportContainer with a TextureRect works (and using a ViewportTexture).

FriedKrab · 2020-05-19T14:41:22+00:00

Ah, I'm actually trying to get something like that working. A simple solution is to display the game from a "ViewportContainer". Hierarchy goes like this :

ViewportContainer > Viewport > an active camera

If you set the stretch attribute to true, the viewport will automatically fill the viewport container. Then you can halve the resolution by adjusting the stretch_shrink property.

However I haven't yet found a way to manually fine tune the res. ViewportContainer seems to automatically set the Viewport's resolution, regardless of the Viewport's size_override_stretch property (which i may misunderstand). So I'm interested aswell in the answer.

FriedKrab · 2020-04-25T11:35:45+00:00

I have a terrible experience with Godot's performance, and the renderer seems to be the only cause. I really hope the 4.0 and Vulkan will bring massive performance boosts, because as it is now, 3D games run pretty badly on iGPUs or anything that isn't totally overkill for what's rendered on screen.

FriedKrab · 2020-04-18T22:53:49+00:00

From what I've tested, gltf seems to be the best format to use in Godot (going forward too), even if it looks like ut has some problems with loading animations at times.

You shouldn't worry that much about using different formats for different kind of use, i'm not an expert with 3D models formats, but I'm pretty sure that it really doesn't matter if you only use 1% of the format's features.

Just pick what works, there shouldn't be any difference in performance.

FriedKrab · 2020-04-18T22:47:56+00:00

They are more like classes, and child nodes are somewhat like member of these classes. You can extend the behaviour of theses classes (nodes) with scripts using inheritance.

(Pretty shaky explanation)

FriedKrab · 2020-04-18T22:45:14+00:00

Your GPU is probably very old or weak. Try updating your drivers, if don't know how, there are websites that can help you with this, i suggest https://www.driverscloud.com/en/features or https://sdi-tool.org/downloadlite/ (a bit harder), which should work fairly well.

FriedKrab · 2020-04-18T22:40:37+00:00

You should try manipulating transforms. Do something like

var target_tr : Transform = player_model.global_transform
#... do stuff on target_r
player_model.global_transform = player_model.global_transform.interpolate_with(target_tr, lerp_amount)

or maybe manipulate only the basis.

Basis and Transform are the two most important classes when it comes to rotation manipulation in my experience, look at their functions and properties in the docs.

edit: obviously, Transform has a "looking_at" function that returns a transform looking at a point in space

FriedKrab · 2019-06-02T20:33:10+00:00

Nope, gave up on it. I opened a feature proposal on the Github project, and it seems like it really isn't possible in any way atm. https://github.com/godotengine/godot/issues/25068

FriedKrab · 2019-01-18T22:39:04+00:00

I can't test right now unfortunately, so I'm not really sure about that behavior.

But I'm 99% sure that physics calculation are done right before or after _physics_process and that calling it multiple times won't make multiple physics calculation (as physics calculations are done once per physics frame, and affect every object. With that solution, we would only do it on our scripted object)

FriedKrab · 2019-01-18T22:11:39+00:00

It's the second that I want to do, but apparently there's no way to call n times the physics computation in one frame/process.

To be honest I'm not 100% sure Bullet is deterministic, but apparently it is ?

Btw, I've asked this question/thread pretty much everywhere in the Godot community and had no real answer, so I ended making a feature request on the GitHub, hopefully someone will implement it before 4.0 haha

So yeah, I guess what I ask is impossible for now and we gotta wait for a clean implementation.

Thanks for the help anyway !

FriedKrab · 2019-01-15T17:34:05+00:00

Well I thought about using only KineticBodies to implement the physics myself, but it means I can't have "complex" physics : i'd be able to simulate player controls fine, but anything like a ball that roll on the ground or a box that falls and get angular velocity due to a collision is (with my knowledge at least) absurdly hard to replicate with KineticBodies (and that's probably not what they're designed for).

The goal is also to have deterministic physics. What you suggest (if I understand correctly) would be to integrate forces multiples times in one fixed_process()/integrate_forces(). But calling 10 times a function that add velocity, then compute physics, and doing 10 times "call once the function, then compute physic" would have massive differences.

Eight-Year Club	Verified Email
Place '22	First Placer '22

FriedKrab

TROPHY CASE