What are they suggesting for versión control?
We somewhat recently switched to Plastic and it’s been a godsend. If the free plans work for you I strongly recommend it.
Thanks for those links. Those are great. I already worked through one of them. I’ll look at the other tomorrow.
They mentioned Unity’s built-in version control (whose name I forget), but then asked us to start out with Github and Github Desktop. I’ve used git and Github before, so I am fine with that for now. I hate doing anything without version control, even tutorials!
I took a look at the Plastic website. Looks pretty snazzy! I’ll give it a spin at some point.
Edit: SOLVED! I wrote below that I was having trouble using Input Fields. The problem does seem to be that the new Text Mesh Pro version of the Input Field is not yet fully functional. The Legacy version works great. No code really required at all. You just put the method you want to trigger in a script in a parent object; link that to the Input Field; and tell the Input Field which method you want to trigger. So, never mind. :) I’ve retained the rest of the post below anyway, just for grins.
@Profanicus @Juan_Raigada Today I got stuck trying to figure out how to grab text input from an Input Field. I wasted an hour before I learned that the new TextMeshPro version of the Input Field apparently does not yet support the new UI Event system. I made somewhat more progress with a legacy Input Field, which at least I can plug into a parent object. But I’m still stuck. I’ve tried a variety of things, including this:
InputField getName = getPlayerName.GetComponent<InputField>();
getName.ActivateInputField();
getName.onEndEdit.AddListener(ParrotName);
ParrotName would be a simple function to spit out the name in the console. But the IDE balks at the last line, and I don’t understand why. Parallel code for buttons does seem to work. I’m not sure .ActivateInputField() is necessary. I can’t find a simple example in the docs, which are apparently out of date, or online. I’ll post in the Unity forums too, but no one ever answers my questions there. By any chance, you guys point me to some example code?
This task was part of the Learn series, but for whatever reason they gave no guidance at all on how to use an input field. The focus was more on data persistence, which I understand better than input fields!
Nice work! I’ve not done a lot of UI stuff but the whole thing sounds a muddled pain. :(
Are they even updating TMP InputField to use the UI Events? Because I think their path forward will be UI Toolkit, which I don’t think uses the Unity UI Events either.
Yes, most of Unity UI uses Unity events, and that works wonders (we use Unity Events for a lot of gameplay stuff too. Incredibly designer friendly). In general UI requires very little code, BUT…
The issue with a lot of UI stuff if twofold:
1- Lots of the typical event callbacks are iffy when switching input methods (say stop using the mouse and plug in a game pad). We ended up using just the most dependable ones (input component specific -Buttons OnClick, etc…- and some clear ones -OnSelect, etc-) and using a wrapping Unity Event using class that collected those into specific UI logic we wanted (show, hide, highlight…).
2- You really don’t want to use animator controllers with UI, but some of the most interesting transitions/UI look and feel needs animation. A lot of the time the animator controllers keep updating the canvases and that kills performance in platforms like the Switch. Unity recommends using tweeting logic, but that’s a little too limited. We wrote a wrapper around the old Animation class (that doesn’t trigger canvas updates unless it’s actually playing a new frame) that required a couple of loopholes but helped the designers use animations -which are fast to set up in-engine, good iteration, etc…- without the performance cost.
So mostly we use the included UI system, but work around it when we have detected it doesn’t suit our needs. Only really relevant when you need a lot of performance and design flexibility in non-powerful platforms.
Well, I’m getting the hang of simple UI solutions. I can make menu screens, switch between scenes, handle user text input, respond to button clicks, etc.
Now I worry that all the wonderful Unity learning resources tend to steer one toward 3D rather than 2D development. I have nothing against 3D, but I don’t want to get in over my head. I’ve made a bunch of small 2D games in Godot and Gamemaker, and I imagine I should start that way with Unity too. Especially as my goal is to create a hex-based strategy or wargame. Those can be 3D (Old World, Civ 6), but wargames in particular are still often 2D (War in the Pacific, War in the East).
Still, it’s great to learn about shaders, which is what I’m working on now. I’d never fully grokked them until the Learn series started making me create my own.
A lot of the core principals in Unity apply to both 2D and 3D, so it all contributes to a greater understanding of how the various bits fit together.
Might be time to kick of a small 2D prototype to put what you’ve learnt so far into practice. That’s usually the quickest way to identify any gaps you might have, in which case you can then target specific topics for a deeper dive.
Yep, that sounds like good advice. I’m trying to make a tiny 2d war game prototype now.
Should I be using Unity’s new input system? By default Unity comes installed with the old system, and that’s what I learned while doing the junior programmer pathway.
For most prototyping I think it’s easier to just go with the old input system. If you decide to take the prototype further it’s not usually a big issue to retrofit the new system, particularly if you’ve already separated your input and game logic.
The new system is really good, but for a mouse driven game it’s overkill (it shines with multi-type input, etc, and it’s amazing for consoles). Go with the old one for now.
Thanks for the advice on the input system. I’m using the old one for now.
I have a high-level design question for my little 4X prototype: WEGO or IGOUGO? That is, should a turn-based game be executed in alternating turns (like Civ) or in simultaneous turns, with a planning phase followed by a joint execution phase (like Combat Mission, AGEOD’s wargames, Battlestar Galactica Deadlock, Frozen Synapse, Grigsby’s War in the Pacific, Dominions (mostly), etc)?
Interestingly, I think Space 4X game are often a blend of the two. The strategic layer is often WEGO: you end your turn, and you see both your ships and the AI’s move on the strategic map at the same time. But MOO2 and Interstellar Genesis and others have IGOUGO tactical combat.
I tend to gravitate toward IGOUGO games, but I did have fun making a WEGO wargame prototype last year, and my favorite wargame is Grigsby’s War in the Pacific. So I have a foot in both camps.
I’m tempted to ask this question in its own thread here, but I’m always reluctant to clutter up Tom’s forum. I thought I’d see if you guys have any opinion first. I’m curious both what you think as designers and as players. Which system is more fun to play? Which is more fun (and easier!) to make?
I guess it depends on the game? If there is too much “stuff” going on, having everything happen at once might feel a little overwhelming. There was a very simple mac game Ares in the late 90s that nailed the 4x space gameplay in real time. It was simple, just a lot of fun to play, and I never felt overwhelmed as a player, even when being pressured in a defensive position. It was very simple, though.
I’m not sure how much of a difference simultaneous vs. alternating turns would make without knowing a lot about the game; from an aesthetic perspective I suppose I would prefer simultaneous, as a player… although most turn based strategy games I’ve played use alternating. X-Com is… sort of simultaneous in that your pawns’ movements can be interrupted by the enemy?
I played a different, very indie multiplayer game in the 90s with ultra simple graphics that used simultaneous turns that was a lot of fun… (I don’t remember the name and this would be a very hard game to find)… it was top-down with blocky, ugly, colorful, low pixel count art, but you were in this maze with other players (and bots) and you would have to plan your turn; are you going to run and pick up that weapon? Turn around the corner and shoot? Run away? Then, once everyone had planned their turn, it would play out simultaneously. It was rather hilarious over LAN because you could watch what the other players thought you were going to do, and if you guess correctly it was a big win… if you guessed incorrectly sometimes super funny, chaotic things would happen, especially with the broad selection of weaponry.
Sorry for the block of text… game design is ultra interesting to me, and this is a great thread.
Game design is real interesting to me, and I agree, this is a great thread!
Your thoughts on WEGO are similar to mine. Sometimes I love it; sometimes it’s tedious. In War in the Pacific, it helps simulate the uncertainty of finding anything at sea. I also think it works well in games with ranged combat, as opposed to melee, since it’s less annoying to figure out where to move, and fun to think about flank attacks and shields.
WEGO also works well with units that are often far apart (as in naval games), or wargames with low “counter density”. The old Operation Crusader, set in North Africa, had lots of room to maneuver, and its WEGO was fun. WEGO with units packed together, like the new WEGO Stalingrad, appeal to me less. I’d be interested to try (or design!) a WW2 grand-strategy game with WEGO, but I’m skeptical it could work.
On the other hand, I found Operation Synapse annoying. I just didn’t want to replay the turn 3 times to figure out who went where, who shot at who, etc. The AGEOD games left me with mixed feelings too; often I didn’t understand what had happened during the simultaneous phase. Also, IGOUGO gives you immediate feedback, and that can be gratifying. In Civ or chess or Panzer Corps, you know right away if you’ve won a piece or taken a city.
Should I repost my question in its own thread? I did just post something like this over in the Unity forums.
The question is quite relevant to my little 4X project. Right now, I can move ships around; I’ve constrained their movement; I’ve implemented rudimentary combat; and I’ve started on a UI. My next step is to figure out how to organize player and enemy turns. For now I’m just designing for one enemy, but I still need to decide: WEGO or IGOYUGO? WEGO strategic layer, IGOUGO tactical?
I’m assuming this is a single player game, yes? If so, you’ll need to consider how the AI will work and whether it’ll be more or less difficult to implement depending on which approach (WEGO vs IGOUGO) you decide to take.
In my mind WEGO seems like it would be more difficult since you’d have to anticipate what the human opponent’s units might be doing. Compare that to IGOUGO where the AI has a lot more ‘known’ information ie if it moves and attacks a human unit at position ‘x’, the unit will still be there and it can predict the likely combat outcomes, etc.
That’s a good point about AI. Indeed, I did make a little WEGO prototype wargame last year, and AI was a huge challenge. By contrast, I was able to make a plausible chess engine. There was lots of learning I could borrow for chess, and some of that same learning could apply to a 4X tactical battle. (“Score” the board; minmax algorithm for possible moves.) So yeah, I’m leaning toward IGOUGO for the tactical battles. And I do want tactical battles, with an autoresolve option.
For the strategic map, though, I’m still leaning toward WEGO. It “feels” right to send a ship off into space and have it execute its orders in a simultaneous movement phase. Just playing around with my prototype, it feels sort of strange to move ships incrementally toward other stars, or to move them in one jump. Maybe I’m just used to the conventions of the genre, which seems to lean toward WEGO at the strategic level.
Edit: I forgot to answer your question about the number of players. Right now I have the player and one AI, as I’m just trying to build a 10-minute game jam thing for starters. But ultimately I’d like a galaxy full of races, diplomacy, the whole 9 yards. A user on the Unity forums points out that WEGO works better with multiple players than IGOUGO, since otherwise you have to wait for every AI to take its turn. Obviously Civ and other turn-based IGOUGO games do manage to pull this off, but sometimes there’s a fair bit of waiting. AI turns in Shadow Empire can take 10 minutes or longer.
The problem with WEGO, imo, it’s not AI, but UX.
With IGOUGO the UX loop is simple. The player chooses an action and you immediate fly see the execution. A little more complex for the AI, but it still follows the same flow, so it’s easy to explain what’s going on assuming the player understands her turn.
With WEGO this all goes to hell. Not only you need to come up with good simultaneous rules that can be predictable (hard to do, many edge cases usually, and players don’t react well to random rolls they do not “click” to execute), but you need to explain how those rules work without the benefit of a clear input/output loop on a decision-by-decision basis. You are going to have a ton of input (all the orders) be a single output that need to make sense of all that AND the AI decisions).
In theory I love WEGO games, but in practice I have to admit IGOUGO probably works better most of the time for most people.
But you are making the game for you, so it’s ok to go for a challenge.
Good point about the UX. I entered a little WEGO wargame prototype into a game jam a year or two ago. (I made that one with Gamemaker Studio 2.) It worked well enough for me, but players were absolutely baffled by the UX, even though I thought I had included clear instructions. Most didn’t get to the “process turn” stage before giving up on it. It was a humbling disaster, but I learned from it.
But can’t some of this be mitigated by a WEGO strategic layer over an IGOUGO tactical layer? That way combat is still in control of the player.
My little space-strategy game is coming along. It seems to take me an hour to implement any single feature: five minutes to code, 55 minutes to debug, lol. But now I can select my units, get visual feedback on where I can and can’t move them, select a destination, see the route to that destination, and engage in simple quasi-random combat. Also, my AI makes random moves. :) I’ll post a screenshot soon.
I am trying to keep this first project small, so for now my victory condition will simply be: take this particular star and hold it for a couple turns. I will then have something that I think qualifies as a 10-minute game, lol. At that point I’ll have to decide whether I want to pursue it further or move on to something else. I have played virtually every 4X space game, so I do have a lot of ideas of what I’d like to see, some of which I think I could manage. We’ll see.
Also, Unity keeps releasing new versions, lol. I installed the last one but so far have skipped the new one. Do they really update every few weeks? Should I be installing each one the moment in comes out? It’s sort of a big install, and then I’m left wondering whether to uninstall the old one.
If you install a new minor version, uninstall the previous one. We just keep one of each main versions we are working on in the studio.
In general, a new minor version could introduce a bug and you might want to revert. For production stuff you generally make sure what will be LTS when you launch and keep to that year version and update accordingly until LTS is out, and then stay stable. This is specially important if you are going console or any uncommon platform. LTS versions really do get a lot of support.
In your car you can keep current so you can keep trying and getting experience with the new features.
Thanks. I’m using 2121.3.6f1. I guess that’s an LTS version? I’m not sure. When I first installed, I just picked what Unity recommended, and since then I’ve done one minor upgrade. I’m just a hobbyist for now, not a professional like you, but I still like to follow best practices.
Speaking of which: I’m debating about whether to use object pooling for arrows and lines that I draw to show the player’s planned movement. They’ll persist from turn to turn, and there will be maybe 10-20 on screen max unless this game grows unexpectedly large. So this is not like bullets in a FPS or such. In a small, simple turn-based prototype like mine, I imagine it doesn’t matter much whether I instantiate things on the fly or just pre-instantiate a bunch of objects and make them inactive until needed. The downside of object pooling is that it would require a bit more work and refactoring. But I do want to establish good habits. Any thoughts on this?