Suggestions:
Switch to a proper game engine. Coding everything in Java is going to take you a lot longer, and end up a lot worse. An example is Adventure Game Studio.
Put a design document together, and then start looking at indie game forums for help. You likely won't receive anybody dependable since you're not paying them, but even a little bit of assistance makes a difference. Then you won't have to spend so much time focusing on the graphics.
Switch to a proper game engine. Coding everything in Java is going to take you a lot longer, and end up a lot worse. An example is Adventure Game Studio.
I appreciate the suggestion, but I'm not sure of any game engine that would be particularly useful to this project, since most of the features will relate to the Bayes net mechanics, and I'd be very surprised if there was any game engine that had been developed to help with those. I looked at AGS, but didn't see anything particularly useful in the feature list or getting started page.
Put a design document together, and then start looking at indie game forums for help. You likely won't receive anybody dependable since you're not paying them, but even a little bit of assistance makes a difference. Then you won't have to spend so much time focusing on the graphics.
I might do something like that later on, thanks. Currently I feel that a playable prototype would be more useful for getting people interested in actually contributing than a design document would, so I'll work towards that as the first priority.
Notice that only one answer states you should avoid a game engine altogether. Another answer suggests a game framework, which is closer to an engine than what you're doing. Everybody else say use a game engine unless you just enjoy building game engines. A game engine will simplify a lot of your current tasks like having built-in GUI systems for things like buttons, layers for hiding/showing or activating/deactivating different objects without moving to a whole new screen, a method for quickly positioning objects on the screen, a better graphic rendering system to reduce processing power requirements, etc. Designing a tool for handling bayesian probability is just a small part of the steps to building your game. AGS isn't necessarily the engine you should be using, but you should be using a different toolset than just Java. The time spent learning an engine is lower than the time required to do this from scratch.
The question does ask "or should I make my own engine", which is different situation from making a 2D game on top of basic graphics libraries that's not much at all like existing games. Game engines are generally expected to involve an extensive visual game world with many assets and behaviors to manage, and this project doesn't seem to have one.
For 2D GUIs, there are programming techniques like imgui for making a GUI while keeping the program architecture lightweight. Out of the free existing GUI frameworks, Qt is pretty impressive.
Make the text more clearly readable by spacing it away from the tables, or making more solid, lighter-colored lettering.
Thanks. Yeah, I've increased the size of the node graphics from the default, but the graph library that lays them out doesn't actually know that, so it places the text in a way that ends up overlapping with the graphics. Hacking that is on my to-do list.
Try giving the letters outlines by rendering the same string in white four times at (-1,0), (1,0), (0,-1), (0,1) from the final text position before rendering the actual black text at the center. That way it won't get visually tangled with the black graph parts.
Also, speaking of visuals, maybe take a moment to think about colors. The pure-channel #F00 / #0F0 red and green are too visually stark and have a different visual intensity. Maybe try experimenting with tweaking the colors and looking up general color palette design stuff to get some easy wins on making the screenshots look instantly visually nice.
Screenshot with some quick color tweaking experiments and an example of an outlined string
Great suggestion about the text, thanks!
Interesting suggestion about the colors. That might be worth doing, though it seems like a lower-priority thing right now, so I'll probably leave it for later.
See here for the previous update if you missed / forgot it.
In this update, no new game content, but new graphics.
I wasn’t terribly happy about the graphical representation of the various nodes in the last update. Especially in the first two networks, if you didn’t read the descriptions of the nodes carefully, it was very easy to just click your way through them without really having a clue of what the network was actually doing. Needless to say, for a game that’s supposed to teach how the networks function, this is highly non-optimal.
Here’s the representation that I’m now experimenting with: the truth table of the nodes is represented graphically inside the node. The prior variable at the top doesn’t really have a truth table, it’s just true or false. The “is” variable at the bottom is true if its parent is true, and false if its parent is false.
You may remember that in the previous update, unobservable nodes were represented in grayscale. I ended up dropping that, because that would have been confusing in this representation: if the parent is unobservable, should the blobs representing its truth values in the child node be in grayscale as well? Both “yes” and “no” answers felt confusing.
Instead the observational state of a node is now represented by its border color. Black for unobservable, gray for observable, no border for observed. The metaphor is supposed to be something like, a border is a veil of ignorance blocking us from seeing the node directly, but if the veil is gray it’s weak enough to be broken, whereas a black veil is strong enough to resist a direct assault. Or something.
When you observe a node, not only does its border disappear, but the truth table entries that get reduced to a zero probability disappear, to be replaced by white boxes. I experimented with having the eliminated entries still show up in grayscale, so you could e.g. see that the “is” node used to contain the entry for (false -> false), but felt that this looked clearer.
The “or” node at the bottom is getting a little crowded, but hopefully not too crowded. Since we know that its value is “true”, the truth table entry showing (false, false -> false) shows up in all whites. It’s also already been observed, so it starts without a border.
After we observe that there’s no monster behind us, the “or” node loses its entries for (monster, !waiting -> looks) and (monster, waiting -> looks), leaving only (!monster, waiting -> looks): meaning that the boy must be waiting for us to answer.
This could still be made clearer: currently the network updates instantly. I’m thinking about adding a brief animation where the “monster” variable would first be revealed as false, which would then propagate an update to the values of “looks at you” (with e.g. the red tile in “monster” blinking at the same time as the now-invalid truth table entries, and when the tiles stopped blinking, those now-invalid entries would have disappeared), and that would in turn propagate the update to the “waiting” node, deleting the red color from it. But I haven’t yet implemented this.
The third network is where things get a little tricky. The “attacking” node is of type “majority vote” - i.e. it’s true if at least two of its parents are true, and false otherwise. That would make for a truth table with eight entries, each holding four blobs each, and we could already see the “or” node in the previous screen being crowded. I’m not quite sure of what to do here. At this moment I’m thinking of just leaving the node as is, and displaying more detailed information in the sidebar.
Here’s another possible problem. Just having the truth table entries works fine to make it obvious where the overall probability of the node comes from… for as long as the valid values of the entries are restricted to “possible” and “impossible”. Then you can see at a glance that, say, of the three possible entries, two would make this node true and one would make this false, so there’s a ⅔ chance of it being true.
But in this screen, that has ceased to be the case. The “attacking” node has a 75% chance of being true, meaning that, for instance, the “is / block” node’s “true -> true” entry also has a 75% chance of being the right one. This isn’t reflected in the truth table visualization. I thought of adding small probability bars under each truth table entry, or having the size of the truth table blobs reflect their probability, but then I’d have to make the nodes even bigger, and it feels like it would easily start looking cluttered again. But maybe it’d be the right choice anyway? Or maybe just put the more detailed information in the sidebar? I’m not sure of the best thing to do here.
If anyone has good suggestions, I would be grateful to get advice from people who have more of a visual designer gene than I do!