I think I may make a beat-em-up game out of this
@sara-objectionable.at.app.wafrn.net
Dutch game development student trying out all kinds of different computer related things. CW your posts and alt-text your media. Not asking. Permanentl[...] View full profile at https://app.wafrn.net/blog/Sara_Objectionable
I think I may make a beat-em-up game out of this
I don't really like the design of these requirements. Wonder how far I'm allowed to deviate...
Wait no
ig it's part of the optional requirements?
Idk
Just realised something
Around the same time that the teachers started mentioning they used ChatGPT for slides,
the assignment descriptions became a lot more verbose, and a lot less information-dense...
**I wonder if those two are related**
No idea what kinda game I'll be making yet,
the pre-designed requirements imply a lot of existing features??
like they explicitly mention smokebombs which aren't mentioned anywhere else
A blender scene with an untextured geometric approximation of a humanoid
a quick test dummy for this test game
Hmmmm, i should make a gdscript accessible version of my state machine logic :neocat_thinking_256:
It has some disadvantages, but for hard dependencies this is definitely the route i'd want to take
Okay, learning git-subtree now and yeah, that's much easier than dealing with submodules
I Looooove the HC godot-modules-template
genuinely makes doing this so much easier
Hmmm, I've been using the Authority" project as a testing ground, but I think I'd be better off separating the assignment part of this into it's own project
Time to give the behaviour nodes their own repository ig
Okay now to actually do most of the assignment:
- Three test behaviours (two pre-designed, one of my own design)
- Documentation (UML, State Diagram, textual description, video, aaaa this assignment is 80% documentation)
Godot add node dialog showing a hierarchy of classes inheriting from "Node", "BehaviourTree" and classes inheriting from "BehaviourNode". The classes are "BehaviourAction", "BehaviourRepeater", and "BehaviourSelector". An abstract class inheriting from "BehaviourNode" is "BehaviourComposite", which has inheriting classes "BehaviourAlwaysSuccess", "BehaviourRepeatUntilFail", "BehaviourSelector", and "BehaviourSequence"
All the behaviour tree node types implemented so far :neocat_happy_blep_256:
Godot hierarchy, BehaviourTree with a single child "BehaviourRepeater" with a single child "BehaviourSequence" with three children "BehaviourAction" with a script and a single child "Timer", "BehaviourAction2" with a script and no children, and "BehaviourAction3" with a script and no children
Getting there! This much is working right now (the actions are just printing for now, but it's working!!)
This is a really good resource, love both the theoretical and practical breakdowns:
https://icewyrmgames.github.io/research/behavior-trees-for-ai-how-they-work/
Though I think I'd first have to unfuck the issues and branches on it, cause it's a bit chaotic rn with how completely undisciplined I've been merging open PRs and pushing them without updating the issue tracker :neocat_woozy_256:
Maybe I should set up packages for that sometime :neocat_thinking_256:
Which in this case also means working on HC godot tooling
Okay, enough St. Antonius for the day, time to work on my other deadline
[EUPol, chat control (positive)]
Alright this makes a much clearer case for why this is positive. Although still cautious, I'm optimistic this might actually be the end of it
... see complete post
[EUPol, chat control (positive?)]
That's,
something? I think this is pretty good? I really hope it holds though
RE: https://mastodon.social/users/Tweakers/statuses/116215982368205922
If anything I think it could be argued that it's the reverse.
The current generation has grown up on graphics so good that they look basically-real if you squint.
So "retro"-styled becomes _novel_. Which makes it more appealing.
And that's only half the job. The other half is "what does the [designer/client/teacher/artist] _actually_ want from me"
It's never been about realism for its own sake, it was always about coherency and INTERNAL believability. Going all for realism always is like what a meathead would think people enjoy about works of visual art.
it seems 80% of my programming is asking the question "where would that data be stored?" and 18% is "how does that inform where this function should go"
and the last 2% is writing the code
is it german weewoo today?
I should go for a hike listening to this, that'd be nice i think
https://www.youtube.com/watch?v=FI6l1cub3Aw
The most cursed part of this workflow (editor executable in git repository) is that its _way_ more workable than I had anticipated
I'm never a fan of making UIs, but at least with godot the layout part is fun. And the functionality is easy :neocat_happy_256:
o shit
that's horrible