Hello Game Dev Thread! I've decided to try to make something in the Unreal engine using blueprints. I've followed along a basic tutorial series on YouTube on making a deck of cards UI, logic for moving cards around, etc, etc, but now I'm trying to go from following along to my own thing. As someone mentioned up thread, it's probably a good idea to get some basic architecture created before I get too far into the the coding. My personal goal is to keep myself from scope creeping too much and just get a working game that I can then expand on. With that said, here's the quick design outline:
What if Sid Meier's Pirates! but it's a deck builder / deck management game?
Single player, 2D, turn based.
Information to track during the game and that can be saved & loaded:
Captain Name
Current Gold
Location on Map
On_Deck – Array of Cards currently ‘On Deck’. During Encounters the player will draw from this deck.
Cargo_Hold – Array of Cards currently in the Cargo Hold of the ship. Players can move things in and out of Cargo Hold freely at Port and may have a limited ability to move things in/out while At Sea.
These should be all of the different UI Screens the player needs to see and interact with, though some will have sub-screens:
Main Menu
Port
World Map
Encounter
Building off the few tutorials I've done, my plan is to define each UI screen listed above as a Blueprint User Widget. When the game starts, I'll create a Player Controller object, and that Player Controller's BeginPlay Event will create the Main Menu Widget and add it to the ViewPort. When the player transitions from one screen to the next, the current UI widget will create the next screen's widget, add it to the Viewport, and then remove itself from the Viewport, which will also destroy that instance of the widget.
Two questions for experienced Unreal developers here - 1) does the above make sense? I'm not confident I understand the default structure and flow that Unreal expects - for example I'm not using Levels at all as part of this. Should each of these different screens the user will see and interact with be a different Level? I know there are probably many right or good enough ways to do it, I'm trying to make sure this isn't wrong for reasons I don't understand about Unreal yet.
Question 2) Where should the above variables live? Is it okay to have those defined in the Player Controller class and reference there or better to have an instance of the Game Instance class and always refer to that?
I just started Unreal myself, and know even less about widgets and the 2d tools that I do the rest, so I'll refrain from offering an opinion. I think you'll still be putting everything in a Level with how unreal works, even if it's a blank one? That's how the extremely rudimentary start screen I made worked, anyway.
On my project, I've got my block spell (that parries in its first few seconds) working and looking...okay (I didn't key enough things so the arm looks weird) and my enemies reacting to whether I'm neutral/blocking/parrying/iframing when they make contact with their attack, using an event dispatcher on the player character that passes an integer from 0-3 and a switch on int node.
Decided to make sure that wasn't stupid and took it to one of the big UE discords, which recommended using an enum instead of an integer for readability. That made sense so I went looking into that. Everything said to not do it in blueprints, to set it up in C++, and since that looked really simple I decided I'd try to bumble through that.
I managed to brick my project for like three hours because it didn't want to launch, asked to recompile, then failed to recompile. Turns out 5.4 dropped support for VS 2019, but none of the errors was helping me figure that out and none of the older threads I could find about it was helping me since that's so recent.
Finally got it running again. Was going to give up and just use an integer after all, but it's probably best to push through and figure out how to do one or two very minor things in C++ when I absolutely must.
edit: Got it working.
Though I've also discovered that Unreal's Gameplay Ability System and the associated GameplayTags system could handle exactly this right out of the can if I took the time to learn it.
I guess I'll at least try it out, see if it's worth the learning curve, after I put together my first real enemy. I just deleted the test enemy I've been tinkering with, since it was an abomination of stacked up tutorials and free assets that was more distracting than useful at this point.
Two questions for experienced Unreal developers here - 1) does the above make sense? I'm not confident I understand the default structure and flow that Unreal expects - for example I'm not using Levels at all as part of this. Should each of these different screens the user will see and interact with be a different Level? I know there are probably many right or good enough ways to do it, I'm trying to make sure this isn't wrong for reasons I don't understand about Unreal yet.
Question 2) Where should the above variables live? Is it okay to have those defined in the Player Controller class and reference there or better to have an instance of the Game Instance class and always refer to that?
1) One level where everything happens is fine, keep in mind when changing level only the GameInstance will keep its data. PlayerController, PlayerState, GameMode and GameState all get recreated when you change level. Depending on context and use, one way I do ui is to have my main UI panel attached to viewport and then switch what sub ui panel is visible instead of attaching and detaching ui elements with the player controller.
2) GameState and PlayerState are mostly useful for multiplayer games and replication. For a single player game it is less important. The current game data can all live inside the player controller. I usually use the GameInstance for managing save/load data objects and to hold the gameplay key/value tables for gameplay event or things like "has the player defeated boss X". Mainly I use GameInstance for stuff that needs to be saved and loaded between sessions and PlayerController is fine for the current active session.
Kupi's Holy Crap Two In A Row?! Weekly Friday Game Dev Status Report
Amusingly, the thing I said I was going to do this week I managed to finish in the same day I posted my last update. I then went about improving it to a point where it's presentable.
With the maps generated, I moved on to integrating them into Godot's A-Star pathfinder. It's designed for euclidean coordinates, but you can override the cost functions to take into account whatever you want, so I was able to make it calculate distances in terms of hex tile manhattan distances instead. Then, based on the unit that's actually performing the pathfinding, it applies various transit costs based on the units. For instance, it's a general rule that forests slow the unit down a bit, sand by a lot, mountains by even more, and water almost completely. However, armored units suffer more than usual in sand, and horses have higher penalties everywhere that isn't the plains. Birds, on the other hand, completely ignore all terrain costs.
However, one thing I noticed in the original implementation was that every unit had the same idea of what the best-cost path was, leading to narrow lines of units passing through a very specific path. So I added another feature: every tile tracks the number of paths that go through it. Then, the transit cost of a tile is increased by a tiny amount per path across the tile. This results in paths that are still optimal in terms of transit time, but avoid overlapping one another in a way that improves the aesthetics of large groups.
The next milestone (aside from cleaning up the code I've written) is getting the basic battle logic working. I'm excited to see how the core concept works out; the idea is that instead of the individual units having HP, they just both make an attack roll and a successful attack kills the target. A unit with high attack power increases the odds that it will kill the enemy; a unit with high defense power has lower odds of dying when attacked. After they clash, both units (if alive) back up and go into a "resting" state in which they cannot attack, then resume marching. While I'd like to avoid explicit unit-type interactions (like Fire Emblem's "sword beats axe beats lance beats sword"), there probably needs to be a system of declaring which attacks beat which kinds of defense and other unit differences-- like "hammers ignore part of the enemy's Armor defense", "arrows ignore most of the enemy's Evasion defense", "swordfighters have weak attacks but a low rest time", "spearmen can counter-attack even during their rest", and so on.
My vision is that instead of micro-managing your units the way Fire Emblem or Advance Wars would ask you to, instead you create unit templates that are given different priority levels and weights, which you can change during play if it doesn't seem to be working out for you. So, for instance, you'd select a particular command post or fortress and tell it "Generate armored units to stand in all tiles up to distance 2 from the fortress, then generate 50% swordfighters and 50% pikemen directed to attack the nearest uncaptured enemy outpost". The idea being that you direct strategy rather than tactics.
But, we'll see how it comes out! I feel like I'm working from a place of experimenting with getting the gameplay right instead of starting out with a story I want to tell, which is a new angle for me that might just actually work out this time. I'll see you next week for the report!
My favorite musical instrument is the air-raid siren.
I have restored all the functionality that I lost in my character BP, turns out redoing stuff goes way faster than figuring it out the first time.
Next up is figuring out my first real enemy (as opposed to grabbing a random free asset and having it headbutt me to test stuff). So I need to figure out how to make a monster of roughly the right shape with appropriate bones using, I dunno, a bunch of spheres in Blender, and I have to figure out how I actually want my enemy AI to work.
I have three options to consider and test: Behavior Trees, State Machines, and just scripting everything directly in their BP. I guess I should probably try making the enemy's AI in each and see how I feel about them.
My vision is that instead of micro-managing your units the way Fire Emblem or Advance Wars would ask you to, instead you create unit templates that are given different priority levels and weights, which you can change during play if it doesn't seem to be working out for you. So, for instance, you'd select a particular command post or fortress and tell it "Generate armored units to stand in all tiles up to distance 2 from the fortress, then generate 50% swordfighters and 50% pikemen directed to attack the nearest uncaptured enemy outpost". The idea being that you direct strategy rather than tactics.
This once-removed approach kind of reminds me of the way FF12 and FF13 placed players at a higher level of control compared to normal JRPG combat with gambits and the class switching thing. Which I actually liked, though I think overall reception was mixed.
Kupi's Whoooooooa Nelly! Three In A Row!! Weekly Friday Game Dev Status Report
Did not get much actual work done this week. I've been trying to navigate some sticky design issues in terms of giving units orders, and around Thursday I said to myself that it didn't need to be addressed right this moment since the current state of play for the prototype is that there aren't even enemy units. So I decided that before I work on higher-order design problems I should at least have the bare minimum of battle logic.
So that's what I did! Thursday afternoon, I went through the whole process of creating pallet- and horizontally- swapped sprites to represent the enemy faction, rearranged the bookkeeping for the "avoid tiles already transited by ally paths" so that it was tracked independently for both teams, gave units the ability to delete themselves (instead of just cycling back to the blue fortress when they reach the red one), and set up the minimum viable combat logic: when units come into contact with one another, they both die. War is hell.
I had the good luck for my very first test case to randomly generate a map with two separate best-value paths, so the soldiers divide themselves around the mountain (other than the birds, who fly over it). Zen out to this video for a minute if you like:
So now that I've got soldiers fighting each other, I've got multiple possible avenues to continue down: either giving units their own stats and handling what happens when they collide and don't die, start adding UI and design tools so that it feels more like a real game earlier in the process, or really nail down how I want to handle the "then what?" question.
By which I mean: it's easy enough to handle units whose orders are to guard a particular area. You give them a tile, they pathfind to it, and then they hold position forever. For attacking units, however, if they aren't attacking the load-bearing command post (and certainly you'd want to have maps with multiple objectives on them), and accomplish their goal... then what? If you directed them to take the southern fortress, and they take the southern fortress, what do they do next? Certainly you could give them a list of objectives, but that just pushes the question another layer down. They take the southern fortress, and with southern fortress captured they attack the south-east fortress... and then what? One possibility is that they retreat to their home base, another is that they march for the final boss, and another is that they simply pursue whatever appears to be the nearest objective. But the more autonomy you give the units, the more opportunity you give them to frustrate the player by accidentally setting off the story tripwires by attacking too aggressively or whatever. Fire Emblem or Unicorn Overlord handles this by giving you few enough units that it's tolerable to micro-manage them, but that's exactly what I'd like to avoid in this game.
Well, that's for me to solve over the next week. Or, if not, realize that I need to be grasping for something closer to my reach again.
My favorite musical instrument is the air-raid siren.
Have the basics down for the skills and systems I need on my character for my first level implemented and working without bugs. Normal versions of spells and held versions that will consume more/alternative resources (haven't hammered down specifics of balance yet), where everything freezes so you can place the more powerful spell precisely.
I might have situational variants of the spells that can activate if you've found the right information about the enemy/situation you're facing, i.e. the basic melee spell's 'flurry of slashes dropped on a point' charged version might become a single massive chop or stab to a weak point or a bigger flurry of slashes that cut apart the magic lines feeding a powerful being, or whatever, if you've learned the right things before the fight and aim the spell at the right place. But that kind of thing can wait for later if I even go with that idea.
Got dialogue working nicely and communicating with my gameinstance and characters to progress events.
Got caught up in decision paralysis when it came time to start implementing enemies in my first level, because I know it's like the single most important thing for my game. Was split between figuring out models, animation, AI, etc., and ended up progressing on none of them.
But the decision to just implement everything for the moment as spheres and cylinders with attacks implemented just as simply for now has helped me get going again, focusing just on AI.
Not sure I can wrap up a (hideous but) playable level by the end of the month as I'd hoped, but the first week of July isn't out of reach.
I've settled on the enemies for my first area, at least in terms of gameplay. I'm calling them (the zombie might actually be a zombie):
Zombie: Quite slow, hard-hitting, might lob a projectile at you at range
Bat: Flying, Mario Boo logic for movement but only attacks (will have to figure out something spooky) if you turn around and it's close
Rat: Fast, very aggressive, very weak in health and damage, rarely alone
Xenomorph: Most dangerous non-boss, fast and aggressive ambusher that will retreat and try to ambush you again if you do manage to injure it.
The first three were pretty trivial to get working at a rudimentary level, no surprise, though none of them is even close to done even from a gameplay perspective yet.
I have quite a few other ideas for enemies that could make nice encounters alone or in combination with these, but that can wait for a later level.
Plus two unique boss type encounters, one that'll serve to teach the basic idea for the optional bosses (you can avoid them completely, maybe interact with them in some non-battle way, or defeat them), and the other a level boss that requires some level of engagement, even if it's just escaping it. I expect these to take up a lot of my time to get right.
So I might have let Elden Ring and other stuff derail me a little...but not completely. I'm still putting in a few hours (or more) most days, they've just been going to cleaning up a lot of things and redoing all of my AI because it was a real mess, like it was doing what I planned...mostly.
But changing anything or fixing anything that didn't work was eating up way too much time because it was so piecemeal.
Fortunately, Behavior Trees are far less daunting now that I understand the basics a bit better.
So as it turns out someone already made my game! Turing Complete is basically what I was going to make, eventually. They even do verilog exports! Though apparently not for something that includes a ROM, disappointing
I haven't quite probed it's limits yet, and it's interesting seeing the different approaches. All the problems I had with variably sized wires and gates disappears when you force people to do things bit by bit and route 20 wires on top of each other or specifically N-bit fixed widths. Which I didn't want to do because it would be incredibly tedious and/or messy, and as it turns out, it is! And they unlock their custom component thing much much later than I was going to do it, I was going to do it at the first adder
They are also doing things architecturally different, lots of buses and output enables whereas I favoured muxes. A lot of the same underlying restrictions though, no multiple outputs, no combinatorial loops (which I was looking at possibly allowing). I don't think multiple clock domains are a thing and given the headaches it caused me I'm not surprised
At the very least there's only simple displays available not dot by dot so they're likely not expecting super high evaluation rates. Trivial circuits can be evaluated at megahertz but that's basically an empty circuit. Someone has a NES WIP that runs on my machine at... 12 kHz, about two orders of magnitude too slow. This is about what I would expect given a non-compiled evaluation
Working on something very important and very boring today, saving and loading.
Also have to work on the equally boring and important UI for the detective/puzzle solving component of my game.
Basically, you can observe things, interact with dead spirits, etc., to learn stuff from exploring an area. You can combine these things in a UI to come to certain realizations and get custom variants of spells to use in encounters, like your big flurry of blades becoming a targeted slice to a single weak spot, your healing spell becoming poisonous to an enemy or curing their madness, that kind of thing.
I want the game to feel tense and scary if you're just getting through, but shift towards action horror if you take the time to explore and learn things. Fear as ignorance, knowledge as power as key themes for the gameplay and story.
But that UI stuff is completely beyond me at the moment, feels a bit daunting to get started on.
Simplest advice I can give anyone to deal with networking as someone who's done lower level stuff not in the game industry:
Don't trust the clients at all, ever.
You want to make the clients dumb and just stream data from the server. Have the client send packets like "I'm moving forward" and let the server handle all the trig/vector math instead of having each client do it in a peer-to-peer system. Server sends packets on state of the chunk players are interacting in several times (who's there, locations, speeds, animation states, equipment states, etc) a second and the client just renders that stuff onto the screen.
Obviously some of those you only need to send when the player enters (equipment) or if there's a state change (change equipment) so you can save bandwidth by only sending things that need to be sent.
Or you could do what minecraft does and hammers all the clients with everything constantly.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Clients have to be doing some sophisticated guessing for anything quick to feel good regardless, don't they?
Sometimes.
Desync is what causes that rubber banding of old but in the age of broadband it's less of an issue and there's really not a super large need to do prediction and interpolation of vectors and all that.
Hitchy movement is better than desyncs, at the end of the day, don't prematurely optimize, get it working first.
Eventually this discussion becomes "do you want to give the players with high or low ping the advantage?" You can see the pitfalls of "slam the client with as many packets as possible per second" with a bare minimum of client prediction in minecraft with how people bounce/zoom around the screen and how nodes respawn/despawn randomly sometimes.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Clients have to be doing some sophisticated guessing for anything quick to feel good regardless, don't they?
Sometimes.
Desync is what causes that rubber banding of old but in the age of broadband it's less of an issue and there's really not a super large need to do prediction and interpolation of vectors and all that.
Hitchy movement is better than desyncs, at the end of the day, don't prematurely optimize, get it working first.
Eventually this discussion becomes "do you want to give the players with high or low ping the advantage?" You can see the pitfalls of "slam the client with as many packets as possible per second" with a bare minimum of client prediction in minecraft with how people bounce/zoom around the screen and how nodes respawn/despawn randomly sometimes.
I guess I'm mostly thinking about fighting game rollback netcode. Which is all about guessing and checking, from what I know. Obviously a lot easier with only two people and the limited potential decisions at any given moment in a fighting game match and a lot more important to a genre where every frame counts.
In my game I'm doing fighting game-style rollback, currently limited to two players.
The data I'm currently transmitting is the player input, along with the frame number, redundantly sending the inputs from the last X frames each frame.
I haven't gotten properly started on debugging the desync yet. I see how I can send some additional data to detect desyncs, but I'm less sure about figuring out why they're happening.
Physics is the usual culprit. Floating point math being what it is, those little errors begin to add up. In Unity at least, the default 3D physics engines, Physx, is non deterministic. I'm not familiar enough with Box2D to know if that's case there or not.
Floating point math is often unfairly maligned! IEEE 754 operations are specified to the bit. Transcendentals and compiler optimizations are where you can run into reproducibility issues, but not if you run the same binary on the same CPU which it seems like you are
With a fixed timestep, your most likely source of nondeterminism is input time or just a clock desync in general. You need to process inputs on the same tick on both sides, you can't process it at T at the source and T+1 at the destination without rewinding
Other than that, anything that uses randomness needs to sync and pull stuff in the same order (per-object seeds) and any time things like object orders in a list matter it must be sorted by something shared
Clients have to be doing some sophisticated guessing for anything quick to feel good regardless, don't they?
Sometimes.
Desync is what causes that rubber banding of old but in the age of broadband it's less of an issue and there's really not a super large need to do prediction and interpolation of vectors and all that.
Hitchy movement is better than desyncs, at the end of the day, don't prematurely optimize, get it working first.
Eventually this discussion becomes "do you want to give the players with high or low ping the advantage?" You can see the pitfalls of "slam the client with as many packets as possible per second" with a bare minimum of client prediction in minecraft with how people bounce/zoom around the screen and how nodes respawn/despawn randomly sometimes.
I guess I'm mostly thinking about fighting game rollback netcode. Which is all about guessing and checking, from what I know. Obviously a lot easier with only two people and the limited potential decisions at any given moment in a fighting game match and more important to a genre where every frame counts.
This discussion suddenly reminded me of Arma Reforger's dev post about how they made the vehicles Server-Authoritative. It's a very interesting read, at the least.
Clients have to be doing some sophisticated guessing for anything quick to feel good regardless, don't they?
Sometimes.
Desync is what causes that rubber banding of old but in the age of broadband it's less of an issue and there's really not a super large need to do prediction and interpolation of vectors and all that.
Hitchy movement is better than desyncs, at the end of the day, don't prematurely optimize, get it working first.
Eventually this discussion becomes "do you want to give the players with high or low ping the advantage?" You can see the pitfalls of "slam the client with as many packets as possible per second" with a bare minimum of client prediction in minecraft with how people bounce/zoom around the screen and how nodes respawn/despawn randomly sometimes.
I guess I'm mostly thinking about fighting game rollback netcode. Which is all about guessing and checking, from what I know. Obviously a lot easier with only two people and the limited potential decisions at any given moment in a fighting game match and more important to a genre where every frame counts.
This discussion suddenly reminded me of Arma Reforger's dev post about how they made the vehicles Server-Authoritative. It's a very interesting read, at the least.
It's honestly hands down the best way to prevent cheating too.
Can't fly a car around and through buildings like cheaters do in pubg if the server is doing all the physics and assorted calculations!
Big fan of server authoritative honestly. Fighting games are a different beast ime, hope peewi figures it out!
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
isnt rollback in itself a form of server authority
obviously not in the literal sense as usually one of the clients *is* the server, but the principle is the same... in rollback, there is a notion of game state that supersedes the client itself and can rubberband the client if things hash out differently than the client prediction
I'm almost petrified by seeing the gap between my own runs through an area I've put together and anyone that isn't me.
It's so very, very easy to lose sight of how an enemy feels knowing everything about it. I'll just sorta wander through my enemies doing stuff and feel bad because they're super trivial to get through without being touched even once, then I'll watch someone try to play through and treat ever enemy as the unknown threats they area--and get murdered by them because of it.
Also, how visible something you feel is basically in the spotlight and completely unmissable really is. Etc.
I found something in my code that would certainly cause desyncs. It's something really simple that I knew would be a problem. And I guess I forgot to write the one line of code it takes to work around it.
The game uses analog inputs. To reduce network traffic, I decided to convert the 32 bit values to 8 bit values. (and then back again when using them in gameplay logic.) It's not strictly necessary, but it felt smart and I assumed that no one just playing a video game would notice the reduced precision of the inputs.
When the player object requests input, I was converting to 8 bit and storing that in the input history, and then just returning the original 32 bit values. So if that frame never got rolled back it would have inputs with inconsistent precision.
isnt rollback in itself a form of server authority
obviously not in the literal sense as usually one of the clients *is* the server, but the principle is the same... in rollback, there is a notion of game state that supersedes the client itself and can rubberband the client if things hash out differently than the client prediction
There's no idea of a server, at least in what I'm doing. It's fully symmetrical peer-to-peer. Each client tracks the past game state individually.
My two cents are perhaps outdated given I've not used Unity physics and animations and state machines recently. But I'd say not to use physics unless you want to do exact physics simulations.
Instead use simple application of gravity, momentum and friction vectors.
If you want to juice up movement, it's far easier to add that functionality to a script you yourself wrote.
As an example, have bullets deflect along Perlin noise as their momentum lowers.
Have control inputs to turn also add a temporary bank. Add oversteer! Add coyote-time on drops... Mostly, make the game do what the player expects without having to worry about what Unity thinks a physics body should do. Especially if Unity is calculating physics far from the world origin...
TLDR, games aren't physics simulations, use roll your own vectors!
Once you've removed all of the 'behind the curtains' stuff Unity was handling, it should be easier to troubleshoot race conditions.
I've been struggling with burnout in my career as a web dev, and I'm taking a hiatus to recharge and rediscover my passion for it. I've been working on a hobby project for a social web game platform to teach myself Next.js, which I'm going to start focusing on full time and see where it goes.
My inspirations were a number of web games we would play in my team's socials in a hybrid setup:
I was running these meetings and trying to bring new games, but found the online selection wanting, and it's hard to play anything physical if anyone is remote. So my thinking is that I'll try to build what I wished I had then, which is a customizable lobby with decks of cards that have a shared state between participants. Right now I'm working on the admin panels:
Progress is a bit slow because I'm taking the codebase seriously and building out infrastructure, unit tests etc. But I should be able to have something shareable pretty soon.
The worst part is that since I don't have my journal set up yet, I'm not entirely sure what information I'll want here and might have to come back to add or change stuff. And I have to reprogram my observations again since now I'll just be passing around the names of the observations and pulling the relevant data instead of working with objects containing all of it.
Was actually quite simple to fix it, though now I have to go through each enemy, observable bit of the environment, and pickup to change out ObservationObject references for ObservationIdentity names.
Like a week ago I had to do this to change out the text variables they offered up to be the objects which contained the stuff the structs in the data table contain now.
But this should be basically it...
...though I want to change the appearance again, I had swapped over to widgets displaying observations that were attached to the thing being observed but I think I want to go back to them being in fixed places on the UI so they're less missable and if you run past an enemy or something I don't want you to have to pop open the journal to see what you missed.
...which might mean doing it yet again, since at the moment that stuff up there is inside the widget component on the observable actors, unless it's possible to get those widget components to stay within a certain area of the screen even if the enemy or whatever leaves that part of the screen...
Small update, I ported to Android and got lots of stuff that was going very wrong going right by simply looking wherever in the scripts I did a 'check for editor' and then didn't code for case !editor.
So the next batch of issues were UI based, and I got those stowed away, so far so good.
Then I needed to switch the player movement from keyboard buttons to, well, on-screen buttons.
I forgot that Unity does not support onDown or anything like that. Buttons do onClick and that's it. You can have a script that watches a button to see if it's being clicked, and they even have a built-in state to make that easier to do, but then you need to run a function for each button separately because the button has to be fed into the function in a specific way to get the state....
I mean, I originally stopped using the Unity UI because it wouldn't respond to transparency in the button sprites well (or at all, I forget).
So I'm porting over the extremely fancy roll-your own interface I made for my previous game which uses a screen grid to define buttons, gives feedback to gameobject buttons in the game space, on-the fly adjustments of the grid and the gameobjects to camera angle or screen size changes, and flipping from portrait to landscape and back.
It requires a lot of refactoring, starting with the existing interface. Allt he buttons will have to go, but I'd written a popup generator and was generating lists etc. which I have to fit into a new paradigm. This time based on using a simple scaling mechanism to draw everything as if the screen is 1200 * 800 and then adjusting it to the actual screen size.
Before, because I came from some serious spaghetti code, I was creating pixels based on the screen size compared to the default canvas size, making percentages of those pixels, then feeding those into a resizer that does the EXTREMELY weird thing Unity does for scaling UI elements, then doing the actual scaling, then attaching the newly resized and positioned elements to the proper canvas parent. There was some redundancy in there, but hopefully now I'll be working in my pretend 1280 *800 canvas and then doing all the hard work in a single function at the end.
Godot 4.3 is out, with a ton of cool features; the ones I am most interested in are the graphics interpolation for 2D (so sprites are automatically lerped between their position circa the last physics tick and the current physics tick, producing smoother movement when the framerate exceeds the physics tick-rate) and GDScript exporting in a binary format so extracting your game's source-code isn't as simple as right-clicking the PAK file and opening it with Notepad.
My current plan is to make an absolute dogshit MVP of the Phantasy Star-like JRPG I've had in my back pocket for a while, putting no effort whatsoever into making the graphics and audio feel good, just getting the scaffolding of the game in place and seeing if the mechanics work. That's the current plan. The current reality is noodling around on the Internet and trying to get a salaried job.
My favorite musical instrument is the air-raid siren.
Hm. Can't quite commit to how I want resources to work.
Right now I have focus (a limited resource you acquire by finding magically active objects or recent bodies) that is used for much stronger versions of spells and two kinds of mana, each tied to certain spells, with which one and how intensely regeneration happens depending on the environment's magic (something you can alter by messing with religious icons and the like). Using a mana vial consumable gives you a decent infusion of both kinds of mana regardless of environment.
I'm pretty sure I don't like that.
I could make mana regenerate way faster, especially without threats nearby, but cap depending on how intensely the environment favors a particular magic--with some spells simply not available at all if the environment doesn't support a sufficient cap.
I could get rid of mana and have consumable spell catalysts that are relevant for certain spells, i.e. an ammo system for magic, but with a discount or cost increase or something depending on how the environment leans.
Or get rid of focus and have the two manas exist to serve the same role focus currently serves, but only for relevant spells, with the catalysts being the base resource for any cast.
I could make it so that you don't have mana, only the environment does, and using mana thins mana in an area (maybe not even a full map, but like, a room or two), such that it regenerates to a lower maximum. And you'd often need to figure out how to increase mana in the environment through exploration before you could do anything hefty, you would rarely just be able to blow everything away right off the bat.
I might also add the discovery and learning aspects of the gameplay to the spells, reducing resource costs or limitations over time if you do everything.
This first level also doesn't have the gun the character will have from the second level onward, so I need to bear in mind what that'll do, too.
Dunno. I'm still not 100% sure where I want to set the baseline capabilities and maximum capabilities of a player, I just know I want one set of spells and decisions to make things feel more stealthy survival horror and the other to shift you towards action horror.
Anyway, not terribly far from having my first level playable from beginning to end. Not sure I'll be able to meet my original goal of a real vertical slice that plays and looks the way I'd want the full game to play and look by my birthday next month, but it's not impossible.
An animated GIF demonstrating the ability of Godot's RichTextLabel to display character-by-character with minimal scripting and convience features to improve the presentation of wrapped text.
My favorite musical instrument is the air-raid siren.
It's kind of interesting, noticing how different the mindset for developing skills is between creative writing and game dev.
Most modern writing advice will tell you that if you don't read short fiction and don't want to write short fiction, you shouldn't write short fiction (advice was different in years past, where short fiction was an important step on the path to publication).
Pretty much every game dev advice along those lines is the opposite, i.e. you should make a million little casual games before you do anything else.
Of course, I can see the reasons for it to some extent, how to program a health system and respawn logic for Space Invaders carries over to a AAA MMO cleaner than, say, writing a character for a 5000 word story does to writing a character for a 100,000 word story.
Though a lot of indie dev advice also seems heavily focused on programming rather than making games. Feels like the majority of hobbyists I've seen seem more interested in taking on unique programming challenges than completing a game. edit: Feels like maybe I'm letting my frustrations cast shade in a way I didn't mean to. More accurate to say that I've found it easier to find discussion and advice on the programming aspects of development/development of games that rely on more intricate programming than, say, in-depth discussion of the nuance of different ammo economies.
All this to say that I'm still occasionally second-guessing just jumping into what I wanted to make first (well, something a bit lighter but with features that will carry over almost unchanged into a later project) instead of trying to remake pong etc. But not so much that I'm changing course.
Anyway, I'm off work today and have nothing on my schedule, so I think I'm going to try to put 8-10 hours into getting this first level somewhere close to done (gameplay/story/etc-wise, aesthetically it's lol). Scope of it crept quite a bit and I lost some energy once I had to start making decisions, but it's all been to its benefit.
I think there's a lot of aphorisms out there that turn into atmospheric wisdom, repeated over and over by people who don't even apply them. You're likelier to find real information from something like a GDC talk or just practical experience than anything posted to r/gamedev. As ever, people who do the thing and people who post about the thing on public cesspit forums are rarely the same population.
These days I don't even feel like I fit in the "actually does the thing" group.
Specific to the miniature projects angle, I grant that it's similar to the argument that before you can draw a full render you need an understanding of volumes, but it also has shades of... "no, you cannot start out with Super Mario Brothers fanart. You must instead draw eighty dogs, to gain the necessary skills first". Nothing will kill your motivation faster than putting a bunch of bullshit you don't care about between you and goals. I say start with whatever inspires you. If it turns out to be beyond your grasp you'll have a better sense of why.
EDIT ADDENDUM: I also think you're far likelier to find frustrated failed game devs from the programming side than the art side, because you can make a great game with good art and passable programming, but good data structures aren't going to create something that's nice to look at or even feel good to play.
Kupi on
My favorite musical instrument is the air-raid siren.
It's kind of interesting, noticing how different the mindset for developing skills is between creative writing and game dev.
Most modern writing advice will tell you that if you don't read short fiction and don't want to write short fiction, you shouldn't write short fiction (advice was different in years past, where short fiction was an important step on the path to publication).
Pretty much every game dev advice along those lines is the opposite, i.e. you should make a million little casual games before you do anything else.
Of course, I can see the reasons for it to some extent, how to program a health system and respawn logic for Space Invaders carries over to a AAA MMO cleaner than, say, writing a character for a 5000 word story does to writing a character for a 100,000 word story.
Though a lot of indie dev advice also seems heavily focused on programming rather than making games. Feels like the majority of hobbyists I've seen seem more interested in taking on unique programming challenges than completing a game. edit: Feels like maybe I'm letting my frustrations cast shade in a way I didn't mean to. More accurate to say that I've found it easier to find discussion and advice on the programming aspects of development/development of games that rely on more intricate programming than, say, in-depth discussion of the nuance of different ammo economies.
All this to say that I'm still occasionally second-guessing just jumping into what I wanted to make first (well, something a bit lighter but with features that will carry over almost unchanged into a later project) instead of trying to remake pong etc. But not so much that I'm changing course.
Anyway, I'm off work today and have nothing on my schedule, so I think I'm going to try to put 8-10 hours into getting this first level somewhere close to done (gameplay/story/etc-wise, aesthetically it's lol). Scope of it crept quite a bit and I lost some energy once I had to start making decisions, but it's all been to its benefit.
Well I don't think anybody is really saying that you should make games you don't give a shit about. But in game dev there are a ton of logistical issues with making a big ambitious project by yourself. Like if your dream is to make a AAA MMO as a hobby project... that's impossible. Perhaps you're more realistic and your dream is to be hired to work on said MMO - even then, completed projects are likely more impressive to a recruiter than abandoned moonshots, and it's important for motivation to have goals that are attainable.
Posts
What if Sid Meier's Pirates! but it's a deck builder / deck management game?
Single player, 2D, turn based.
Information to track during the game and that can be saved & loaded:
These should be all of the different UI Screens the player needs to see and interact with, though some will have sub-screens:
Building off the few tutorials I've done, my plan is to define each UI screen listed above as a Blueprint User Widget. When the game starts, I'll create a Player Controller object, and that Player Controller's BeginPlay Event will create the Main Menu Widget and add it to the ViewPort. When the player transitions from one screen to the next, the current UI widget will create the next screen's widget, add it to the Viewport, and then remove itself from the Viewport, which will also destroy that instance of the widget.
Two questions for experienced Unreal developers here - 1) does the above make sense? I'm not confident I understand the default structure and flow that Unreal expects - for example I'm not using Levels at all as part of this. Should each of these different screens the user will see and interact with be a different Level? I know there are probably many right or good enough ways to do it, I'm trying to make sure this isn't wrong for reasons I don't understand about Unreal yet.
Question 2) Where should the above variables live? Is it okay to have those defined in the Player Controller class and reference there or better to have an instance of the Game Instance class and always refer to that?
On my project, I've got my block spell (that parries in its first few seconds) working and looking...okay (I didn't key enough things so the arm looks weird) and my enemies reacting to whether I'm neutral/blocking/parrying/iframing when they make contact with their attack, using an event dispatcher on the player character that passes an integer from 0-3 and a switch on int node.
Decided to make sure that wasn't stupid and took it to one of the big UE discords, which recommended using an enum instead of an integer for readability. That made sense so I went looking into that. Everything said to not do it in blueprints, to set it up in C++, and since that looked really simple I decided I'd try to bumble through that.
I managed to brick my project for like three hours because it didn't want to launch, asked to recompile, then failed to recompile. Turns out 5.4 dropped support for VS 2019, but none of the errors was helping me figure that out and none of the older threads I could find about it was helping me since that's so recent.
Finally got it running again. Was going to give up and just use an integer after all, but it's probably best to push through and figure out how to do one or two very minor things in C++ when I absolutely must.
edit: Got it working.
Though I've also discovered that Unreal's Gameplay Ability System and the associated GameplayTags system could handle exactly this right out of the can if I took the time to learn it.
I guess I'll at least try it out, see if it's worth the learning curve, after I put together my first real enemy. I just deleted the test enemy I've been tinkering with, since it was an abomination of stacked up tutorials and free assets that was more distracting than useful at this point.
1) One level where everything happens is fine, keep in mind when changing level only the GameInstance will keep its data. PlayerController, PlayerState, GameMode and GameState all get recreated when you change level. Depending on context and use, one way I do ui is to have my main UI panel attached to viewport and then switch what sub ui panel is visible instead of attaching and detaching ui elements with the player controller.
2) GameState and PlayerState are mostly useful for multiplayer games and replication. For a single player game it is less important. The current game data can all live inside the player controller. I usually use the GameInstance for managing save/load data objects and to hold the gameplay key/value tables for gameplay event or things like "has the player defeated boss X". Mainly I use GameInstance for stuff that needs to be saved and loaded between sessions and PlayerController is fine for the current active session.
Which is pretty funny, now that I've realized it's not that hard to fix what I erased.
There are certainly worse ways I could have learned my lesson about understanding the system and using it properly...
Amusingly, the thing I said I was going to do this week I managed to finish in the same day I posted my last update. I then went about improving it to a point where it's presentable.
With the maps generated, I moved on to integrating them into Godot's A-Star pathfinder. It's designed for euclidean coordinates, but you can override the cost functions to take into account whatever you want, so I was able to make it calculate distances in terms of hex tile manhattan distances instead. Then, based on the unit that's actually performing the pathfinding, it applies various transit costs based on the units. For instance, it's a general rule that forests slow the unit down a bit, sand by a lot, mountains by even more, and water almost completely. However, armored units suffer more than usual in sand, and horses have higher penalties everywhere that isn't the plains. Birds, on the other hand, completely ignore all terrain costs.
However, one thing I noticed in the original implementation was that every unit had the same idea of what the best-cost path was, leading to narrow lines of units passing through a very specific path. So I added another feature: every tile tracks the number of paths that go through it. Then, the transit cost of a tile is increased by a tiny amount per path across the tile. This results in paths that are still optimal in terms of transit time, but avoid overlapping one another in a way that improves the aesthetics of large groups.
The next milestone (aside from cleaning up the code I've written) is getting the basic battle logic working. I'm excited to see how the core concept works out; the idea is that instead of the individual units having HP, they just both make an attack roll and a successful attack kills the target. A unit with high attack power increases the odds that it will kill the enemy; a unit with high defense power has lower odds of dying when attacked. After they clash, both units (if alive) back up and go into a "resting" state in which they cannot attack, then resume marching. While I'd like to avoid explicit unit-type interactions (like Fire Emblem's "sword beats axe beats lance beats sword"), there probably needs to be a system of declaring which attacks beat which kinds of defense and other unit differences-- like "hammers ignore part of the enemy's Armor defense", "arrows ignore most of the enemy's Evasion defense", "swordfighters have weak attacks but a low rest time", "spearmen can counter-attack even during their rest", and so on.
My vision is that instead of micro-managing your units the way Fire Emblem or Advance Wars would ask you to, instead you create unit templates that are given different priority levels and weights, which you can change during play if it doesn't seem to be working out for you. So, for instance, you'd select a particular command post or fortress and tell it "Generate armored units to stand in all tiles up to distance 2 from the fortress, then generate 50% swordfighters and 50% pikemen directed to attack the nearest uncaptured enemy outpost". The idea being that you direct strategy rather than tactics.
But, we'll see how it comes out! I feel like I'm working from a place of experimenting with getting the gameplay right instead of starting out with a story I want to tell, which is a new angle for me that might just actually work out this time. I'll see you next week for the report!
Next up is figuring out my first real enemy (as opposed to grabbing a random free asset and having it headbutt me to test stuff). So I need to figure out how to make a monster of roughly the right shape with appropriate bones using, I dunno, a bunch of spheres in Blender, and I have to figure out how I actually want my enemy AI to work.
I have three options to consider and test: Behavior Trees, State Machines, and just scripting everything directly in their BP. I guess I should probably try making the enemy's AI in each and see how I feel about them.
This once-removed approach kind of reminds me of the way FF12 and FF13 placed players at a higher level of control compared to normal JRPG combat with gambits and the class switching thing. Which I actually liked, though I think overall reception was mixed.
Did not get much actual work done this week. I've been trying to navigate some sticky design issues in terms of giving units orders, and around Thursday I said to myself that it didn't need to be addressed right this moment since the current state of play for the prototype is that there aren't even enemy units. So I decided that before I work on higher-order design problems I should at least have the bare minimum of battle logic.
So that's what I did! Thursday afternoon, I went through the whole process of creating pallet- and horizontally- swapped sprites to represent the enemy faction, rearranged the bookkeeping for the "avoid tiles already transited by ally paths" so that it was tracked independently for both teams, gave units the ability to delete themselves (instead of just cycling back to the blue fortress when they reach the red one), and set up the minimum viable combat logic: when units come into contact with one another, they both die. War is hell.
I had the good luck for my very first test case to randomly generate a map with two separate best-value paths, so the soldiers divide themselves around the mountain (other than the birds, who fly over it). Zen out to this video for a minute if you like:
So now that I've got soldiers fighting each other, I've got multiple possible avenues to continue down: either giving units their own stats and handling what happens when they collide and don't die, start adding UI and design tools so that it feels more like a real game earlier in the process, or really nail down how I want to handle the "then what?" question.
By which I mean: it's easy enough to handle units whose orders are to guard a particular area. You give them a tile, they pathfind to it, and then they hold position forever. For attacking units, however, if they aren't attacking the load-bearing command post (and certainly you'd want to have maps with multiple objectives on them), and accomplish their goal... then what? If you directed them to take the southern fortress, and they take the southern fortress, what do they do next? Certainly you could give them a list of objectives, but that just pushes the question another layer down. They take the southern fortress, and with southern fortress captured they attack the south-east fortress... and then what? One possibility is that they retreat to their home base, another is that they march for the final boss, and another is that they simply pursue whatever appears to be the nearest objective. But the more autonomy you give the units, the more opportunity you give them to frustrate the player by accidentally setting off the story tripwires by attacking too aggressively or whatever. Fire Emblem or Unicorn Overlord handles this by giving you few enough units that it's tolerable to micro-manage them, but that's exactly what I'd like to avoid in this game.
Well, that's for me to solve over the next week. Or, if not, realize that I need to be grasping for something closer to my reach again.
I might have situational variants of the spells that can activate if you've found the right information about the enemy/situation you're facing, i.e. the basic melee spell's 'flurry of slashes dropped on a point' charged version might become a single massive chop or stab to a weak point or a bigger flurry of slashes that cut apart the magic lines feeding a powerful being, or whatever, if you've learned the right things before the fight and aim the spell at the right place. But that kind of thing can wait for later if I even go with that idea.
Got dialogue working nicely and communicating with my gameinstance and characters to progress events.
Got caught up in decision paralysis when it came time to start implementing enemies in my first level, because I know it's like the single most important thing for my game. Was split between figuring out models, animation, AI, etc., and ended up progressing on none of them.
But the decision to just implement everything for the moment as spheres and cylinders with attacks implemented just as simply for now has helped me get going again, focusing just on AI.
Not sure I can wrap up a (hideous but) playable level by the end of the month as I'd hoped, but the first week of July isn't out of reach.
The first three were pretty trivial to get working at a rudimentary level, no surprise, though none of them is even close to done even from a gameplay perspective yet.
I have quite a few other ideas for enemies that could make nice encounters alone or in combination with these, but that can wait for a later level.
Plus two unique boss type encounters, one that'll serve to teach the basic idea for the optional bosses (you can avoid them completely, maybe interact with them in some non-battle way, or defeat them), and the other a level boss that requires some level of engagement, even if it's just escaping it. I expect these to take up a lot of my time to get right.
http://www.fallout3nexus.com/downloads/file.php?id=16534
But changing anything or fixing anything that didn't work was eating up way too much time because it was so piecemeal.
Fortunately, Behavior Trees are far less daunting now that I understand the basics a bit better.
I haven't quite probed it's limits yet, and it's interesting seeing the different approaches. All the problems I had with variably sized wires and gates disappears when you force people to do things bit by bit and route 20 wires on top of each other or specifically N-bit fixed widths. Which I didn't want to do because it would be incredibly tedious and/or messy, and as it turns out, it is! And they unlock their custom component thing much much later than I was going to do it, I was going to do it at the first adder
They are also doing things architecturally different, lots of buses and output enables whereas I favoured muxes. A lot of the same underlying restrictions though, no multiple outputs, no combinatorial loops (which I was looking at possibly allowing). I don't think multiple clock domains are a thing and given the headaches it caused me I'm not surprised
At the very least there's only simple displays available not dot by dot so they're likely not expecting super high evaluation rates. Trivial circuits can be evaluated at megahertz but that's basically an empty circuit. Someone has a NES WIP that runs on my machine at... 12 kHz, about two orders of magnitude too slow. This is about what I would expect given a non-compiled evaluation
Also have to work on the equally boring and important UI for the detective/puzzle solving component of my game.
Basically, you can observe things, interact with dead spirits, etc., to learn stuff from exploring an area. You can combine these things in a UI to come to certain realizations and get custom variants of spells to use in encounters, like your big flurry of blades becoming a targeted slice to a single weak spot, your healing spell becoming poisonous to an enemy or curing their madness, that kind of thing.
I want the game to feel tense and scary if you're just getting through, but shift towards action horror if you take the time to explore and learn things. Fear as ignorance, knowledge as power as key themes for the gameplay and story.
But that UI stuff is completely beyond me at the moment, feels a bit daunting to get started on.
It's not a particularly exciting game, but the main point of it is that I'm trying to do online multiplayer.
So far I've mostly got it working, but it is desyncing and I don't understand how or why.
Multiplayer seems like a massive leap in complexity, I don't envy anyone troubleshooting that.
'Why doesn't this enemy do any damage if I just stand perfectly still' is bad enough for me to puzzle through without accounting for networking...
Don't trust the clients at all, ever.
You want to make the clients dumb and just stream data from the server. Have the client send packets like "I'm moving forward" and let the server handle all the trig/vector math instead of having each client do it in a peer-to-peer system. Server sends packets on state of the chunk players are interacting in several times (who's there, locations, speeds, animation states, equipment states, etc) a second and the client just renders that stuff onto the screen.
Obviously some of those you only need to send when the player enters (equipment) or if there's a state change (change equipment) so you can save bandwidth by only sending things that need to be sent.
Or you could do what minecraft does and hammers all the clients with everything constantly.
Sometimes.
Desync is what causes that rubber banding of old but in the age of broadband it's less of an issue and there's really not a super large need to do prediction and interpolation of vectors and all that.
Hitchy movement is better than desyncs, at the end of the day, don't prematurely optimize, get it working first.
Source has got a lot of good discussion and theory behind how it all works:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Lag compensation is a good topic in particular.
Eventually this discussion becomes "do you want to give the players with high or low ping the advantage?" You can see the pitfalls of "slam the client with as many packets as possible per second" with a bare minimum of client prediction in minecraft with how people bounce/zoom around the screen and how nodes respawn/despawn randomly sometimes.
I guess I'm mostly thinking about fighting game rollback netcode. Which is all about guessing and checking, from what I know. Obviously a lot easier with only two people and the limited potential decisions at any given moment in a fighting game match and a lot more important to a genre where every frame counts.
The data I'm currently transmitting is the player input, along with the frame number, redundantly sending the inputs from the last X frames each frame.
I haven't gotten properly started on debugging the desync yet. I see how I can send some additional data to detect desyncs, but I'm less sure about figuring out why they're happening.
While I'm not going to completely rule out anything just yet, I am using a fixed timestep.
With a fixed timestep, your most likely source of nondeterminism is input time or just a clock desync in general. You need to process inputs on the same tick on both sides, you can't process it at T at the source and T+1 at the destination without rewinding
Other than that, anything that uses randomness needs to sync and pull stuff in the same order (per-object seeds) and any time things like object orders in a list matter it must be sorted by something shared
This discussion suddenly reminded me of Arma Reforger's dev post about how they made the vehicles Server-Authoritative. It's a very interesting read, at the least.
It's honestly hands down the best way to prevent cheating too.
Can't fly a car around and through buildings like cheaters do in pubg if the server is doing all the physics and assorted calculations!
Big fan of server authoritative honestly. Fighting games are a different beast ime, hope peewi figures it out!
obviously not in the literal sense as usually one of the clients *is* the server, but the principle is the same... in rollback, there is a notion of game state that supersedes the client itself and can rubberband the client if things hash out differently than the client prediction
It's so very, very easy to lose sight of how an enemy feels knowing everything about it. I'll just sorta wander through my enemies doing stuff and feel bad because they're super trivial to get through without being touched even once, then I'll watch someone try to play through and treat ever enemy as the unknown threats they area--and get murdered by them because of it.
Also, how visible something you feel is basically in the spotlight and completely unmissable really is. Etc.
The game uses analog inputs. To reduce network traffic, I decided to convert the 32 bit values to 8 bit values. (and then back again when using them in gameplay logic.) It's not strictly necessary, but it felt smart and I assumed that no one just playing a video game would notice the reduced precision of the inputs.
When the player object requests input, I was converting to 8 bit and storing that in the input history, and then just returning the original 32 bit values. So if that frame never got rolled back it would have inputs with inconsistent precision.
There's no idea of a server, at least in what I'm doing. It's fully symmetrical peer-to-peer. Each client tracks the past game state individually.
Instead use simple application of gravity, momentum and friction vectors.
If you want to juice up movement, it's far easier to add that functionality to a script you yourself wrote.
As an example, have bullets deflect along Perlin noise as their momentum lowers.
Have control inputs to turn also add a temporary bank. Add oversteer! Add coyote-time on drops... Mostly, make the game do what the player expects without having to worry about what Unity thinks a physics body should do. Especially if Unity is calculating physics far from the world origin...
TLDR, games aren't physics simulations, use roll your own vectors!
Once you've removed all of the 'behind the curtains' stuff Unity was handling, it should be easier to troubleshoot race conditions.
My inspirations were a number of web games we would play in my team's socials in a hybrid setup:
- One Night Ultimate Werewolf
- Draw Battle / Skribbl.io
- Wavelength
- GeoGuessr Trivia
I was running these meetings and trying to bring new games, but found the online selection wanting, and it's hard to play anything physical if anyone is remote. So my thinking is that I'll try to build what I wished I had then, which is a customizable lobby with decks of cards that have a shared state between participants. Right now I'm working on the admin panels:Progress is a bit slow because I'm taking the codebase seriously and building out infrastructure, unit tests etc. But I should be able to have something shareable pretty soon.
Now, it's time...for spreadsheets...
The worst part is that since I don't have my journal set up yet, I'm not entirely sure what information I'll want here and might have to come back to add or change stuff. And I have to reprogram my observations again since now I'll just be passing around the names of the observations and pulling the relevant data instead of working with objects containing all of it.
Tragic.
Like a week ago I had to do this to change out the text variables they offered up to be the objects which contained the stuff the structs in the data table contain now.
But this should be basically it...
...though I want to change the appearance again, I had swapped over to widgets displaying observations that were attached to the thing being observed but I think I want to go back to them being in fixed places on the UI so they're less missable and if you run past an enemy or something I don't want you to have to pop open the journal to see what you missed.
...which might mean doing it yet again, since at the moment that stuff up there is inside the widget component on the observable actors, unless it's possible to get those widget components to stay within a certain area of the screen even if the enemy or whatever leaves that part of the screen...
So the next batch of issues were UI based, and I got those stowed away, so far so good.
Then I needed to switch the player movement from keyboard buttons to, well, on-screen buttons.
I forgot that Unity does not support onDown or anything like that. Buttons do onClick and that's it. You can have a script that watches a button to see if it's being clicked, and they even have a built-in state to make that easier to do, but then you need to run a function for each button separately because the button has to be fed into the function in a specific way to get the state....
I mean, I originally stopped using the Unity UI because it wouldn't respond to transparency in the button sprites well (or at all, I forget).
So I'm porting over the extremely fancy roll-your own interface I made for my previous game which uses a screen grid to define buttons, gives feedback to gameobject buttons in the game space, on-the fly adjustments of the grid and the gameobjects to camera angle or screen size changes, and flipping from portrait to landscape and back.
It requires a lot of refactoring, starting with the existing interface. Allt he buttons will have to go, but I'd written a popup generator and was generating lists etc. which I have to fit into a new paradigm. This time based on using a simple scaling mechanism to draw everything as if the screen is 1200 * 800 and then adjusting it to the actual screen size.
Before, because I came from some serious spaghetti code, I was creating pixels based on the screen size compared to the default canvas size, making percentages of those pixels, then feeding those into a resizer that does the EXTREMELY weird thing Unity does for scaling UI elements, then doing the actual scaling, then attaching the newly resized and positioned elements to the proper canvas parent. There was some redundancy in there, but hopefully now I'll be working in my pretend 1280 *800 canvas and then doing all the hard work in a single function at the end.
My current plan is to make an absolute dogshit MVP of the Phantasy Star-like JRPG I've had in my back pocket for a while, putting no effort whatsoever into making the graphics and audio feel good, just getting the scaffolding of the game in place and seeing if the mechanics work. That's the current plan. The current reality is noodling around on the Internet and trying to get a salaried job.
Right now I have focus (a limited resource you acquire by finding magically active objects or recent bodies) that is used for much stronger versions of spells and two kinds of mana, each tied to certain spells, with which one and how intensely regeneration happens depending on the environment's magic (something you can alter by messing with religious icons and the like). Using a mana vial consumable gives you a decent infusion of both kinds of mana regardless of environment.
I'm pretty sure I don't like that.
I could make mana regenerate way faster, especially without threats nearby, but cap depending on how intensely the environment favors a particular magic--with some spells simply not available at all if the environment doesn't support a sufficient cap.
I could get rid of mana and have consumable spell catalysts that are relevant for certain spells, i.e. an ammo system for magic, but with a discount or cost increase or something depending on how the environment leans.
Or get rid of focus and have the two manas exist to serve the same role focus currently serves, but only for relevant spells, with the catalysts being the base resource for any cast.
I could make it so that you don't have mana, only the environment does, and using mana thins mana in an area (maybe not even a full map, but like, a room or two), such that it regenerates to a lower maximum. And you'd often need to figure out how to increase mana in the environment through exploration before you could do anything hefty, you would rarely just be able to blow everything away right off the bat.
I might also add the discovery and learning aspects of the gameplay to the spells, reducing resource costs or limitations over time if you do everything.
This first level also doesn't have the gun the character will have from the second level onward, so I need to bear in mind what that'll do, too.
Dunno. I'm still not 100% sure where I want to set the baseline capabilities and maximum capabilities of a player, I just know I want one set of spells and decisions to make things feel more stealthy survival horror and the other to shift you towards action horror.
Anyway, not terribly far from having my first level playable from beginning to end. Not sure I'll be able to meet my original goal of a real vertical slice that plays and looks the way I'd want the full game to play and look by my birthday next month, but it's not impossible.
Most modern writing advice will tell you that if you don't read short fiction and don't want to write short fiction, you shouldn't write short fiction (advice was different in years past, where short fiction was an important step on the path to publication).
Pretty much every game dev advice along those lines is the opposite, i.e. you should make a million little casual games before you do anything else.
Of course, I can see the reasons for it to some extent, how to program a health system and respawn logic for Space Invaders carries over to a AAA MMO cleaner than, say, writing a character for a 5000 word story does to writing a character for a 100,000 word story.
Though a lot of indie dev advice also seems heavily focused on programming rather than making games. Feels like the majority of hobbyists I've seen seem more interested in taking on unique programming challenges than completing a game. edit: Feels like maybe I'm letting my frustrations cast shade in a way I didn't mean to. More accurate to say that I've found it easier to find discussion and advice on the programming aspects of development/development of games that rely on more intricate programming than, say, in-depth discussion of the nuance of different ammo economies.
All this to say that I'm still occasionally second-guessing just jumping into what I wanted to make first (well, something a bit lighter but with features that will carry over almost unchanged into a later project) instead of trying to remake pong etc. But not so much that I'm changing course.
Anyway, I'm off work today and have nothing on my schedule, so I think I'm going to try to put 8-10 hours into getting this first level somewhere close to done (gameplay/story/etc-wise, aesthetically it's lol). Scope of it crept quite a bit and I lost some energy once I had to start making decisions, but it's all been to its benefit.
These days I don't even feel like I fit in the "actually does the thing" group.
Specific to the miniature projects angle, I grant that it's similar to the argument that before you can draw a full render you need an understanding of volumes, but it also has shades of... "no, you cannot start out with Super Mario Brothers fanart. You must instead draw eighty dogs, to gain the necessary skills first". Nothing will kill your motivation faster than putting a bunch of bullshit you don't care about between you and goals. I say start with whatever inspires you. If it turns out to be beyond your grasp you'll have a better sense of why.
EDIT ADDENDUM: I also think you're far likelier to find frustrated failed game devs from the programming side than the art side, because you can make a great game with good art and passable programming, but good data structures aren't going to create something that's nice to look at or even feel good to play.
Well I don't think anybody is really saying that you should make games you don't give a shit about. But in game dev there are a ton of logistical issues with making a big ambitious project by yourself. Like if your dream is to make a AAA MMO as a hobby project... that's impossible. Perhaps you're more realistic and your dream is to be hired to work on said MMO - even then, completed projects are likely more impressive to a recruiter than abandoned moonshots, and it's important for motivation to have goals that are attainable.