First off, congrats on nearly finishing a game!
Now is not the time to rest on your laurels though. To make a truly professional space 4X game, you need to add:
Lol! Thanks! I suppose I should also add lots of diplomacy options that never seem to affect actual diplomatic relations, too?
Actually, I do have some design ideas for a distinctive space 4X. I’m aiming for asymmetry, as in AI War: it’s you vs a very strong opponent. I want a navy feel, with distinct ship roles, task force missions (e.g., bombardment, “ASW”, ship-to-ship, etc), small task forces, basing, range and fuel constraints. Each individual ship should be a big investment, and losing one should hurt. I also am thinking about smaller, shorter games, with different victory conditions, like “seals” from AOW3 or take-that-hill or silence-that-gun or escort-x-off-map-edge, as in Advanced Squad Leader.
But ideas are cheap! Implementation is what matters. And wow, is implementation tough!
And now I skulk back into Unity, trying to build a UI. :)
Love your work!
Sounds like something I’d be keen to play - just make sure to have full controller support, and scale UI to 4K TV. ;)
Glad you like it! OK, I’ll get to work supporting CouchPlay. :)
Yeah, love me some asymmetry. Makes AI design and implementation slightly easier too since they can be playing a much simpler role.
Glad to hear you like that idea! Yep, partly I have AI in mind.
A separate question. What minimum resolution should one design a Windows game for these days? 1024 x 768? That’s about the iPad resolution too, I think. I don’t think my little space game would be suitable for an iPhone, but I do wonder about people who want to play games on their browser. Do they ever need 800 x 600 or lower? My UI designer wants to know. :)
As it happens, I run my desktop at 1280 x 800, so I’m previewing 1024 x 768 all the time, and things are fine so far. I’m just not sure whether to go lower than that. It gets hard to fit in UI elements below that resolution.
I’d focus on the game first, but it is good to at least consider this stuff. Go as low as you can easily support without needing to do too many different layouts or asset versions. And make source art based on your highest supported res.
Steam survey shows that around 90% of people run 1080p or higher:
https://store.steampowered.com/hwsurvey
The biggest number below 1080p is 1366 x 768 at 5%, so that sounds like a reasonable min spec - though consider 720p, which is Nintendo Switch handheld mode.
iPad from 10 years ago maybe… :)
Thanks. Hehe, yep, I was looking at ancient iPad specs. OK, I seem to be doing fine on the resolution front.
Now I’m struggling to implement nice-looking toggles or buttons in a UI layout grid – basically a menu of which ships you want to put in your fleet. I used Buttons until I realized that, by default, they don’t toggle back and forth. The Toggle does that, but it’s harder to texture. It’s this sort of thing that is easier in Godot. :) Still, I’m sure I’ll figure it out. I swear I’ve spent two-thirds of my time on basic UI stuff like this…
Not my game, but I thought I’ll put it here anyway. My son wanted to make games so I’ve been helping him to learn to code in C# and to use unity. He’s been churning out quite a lot of content :) it’s been amazing to see the progress he’s been making.
Here’s his latest. It was originally an entry in a ‘build a game in 2 weeks’ competition at his school. For some reason the competition was never resolved (maybe because the only submissions were his and another from a friend of his), but he didn’t mind and just continued working on it and even put it up on Google store (for free) so he can share it with his friends.
The cool thing is that he is now at the point where we talk less about coding, and more about game design. His take on what makes a good game is different than mine, and we get into long discussion about mechanics.
For example, the health bar affects how fast your turrets can shoot. I thought the effect should be negative, i.e. The less health you have, the slower you can shoot, because it makes more sense. He wanted the player to be able to shoot more, see more explosions and generally have more fun.
Oh, and of you do click on the link, please excuse the silly images and description. That’s 14 year old sense of humour (although I admit it made me laugh out loud).
Hey, congrats to your son! Really cool that he’s making progress with projects like that.
Major grats indeed! Smart kid. :)
So, Unity/C# experts, should I be using Update() or Coroutines to get player keyboard input? I’m using the old input system.
I’ve been trying to use a coroutine to halt execution of my code while waiting for a keypress from the player. The coroutine does get the keypress, using something like “while (!keypress),” but the coroutine doesn’t halt or delay execution of the function from which the coroutine is called. So my output appears out of order – the calling function finishes its work before the coroutine finishes its work.
Should I just be using Update() instead? It will mean lots of tracking of game state and such, which is fine. But I thought one point of coroutines was to allow us to pause the game outside of Update().
Sounds like the calling function’s “work” needs to be inside the coroutine ie where you’re yeilding until the keypress is received.
ah Ok, I’ll try that. Do you typically get keyboard input via Input() or via a Coroutine?
Oh sorry, missed that question!
I tend to have a dedicated ‘InputHandler’ monobehaviour which reads all user input via its Update function. It then triggers ‘global’ events which subscribing systems then act on.
Awesome! That sounds sensible. Thanks!
I’m not saying it’s the “best” method for all situations, but I find it easier to debug knowing all input starts from the same place.
Yes, this is the most sensible approach using the old input system. Isolate input in a single class/layer and use game-specific functions from there on.
I officially hate the old input system, though. The new one is amazing and basically does this by default while being very good at being configurable and reactive to many different inpit events.
@Juan_Raigada As it happens, yesterday I started a new test project to try the new input system. It was fun to set up the basic Input actions asset, to assign actions and bindings, etc. I also noticed that by default hitting “enter” pressed a button on the UI. Very nice. Also, I love the idea of an event-based input system.
But I had no idea how to hook up my input-actions asset to objects or UI in the game. I generated a C# script from the asset, and then I tried to write scripts for UI and other objects to accept input from the input asset. But I couldn’t get them to work.
I do see lots of useful videos on how to do this with action-oriented games. But for a turn-based game like mine, I need the input system mostly to handle mouse and keyboard input. Is there a tutorial somewhere on how to set up the mouse and keyboard?
You have to set a Player Input (I think that’s the name) component on your manager. Then those can send Events (function calls you can set in-editor without code) to work call specific code.
For a turn based menu game is different, it’s the buttons/UI elements that have the different event lists that are called at different times.
So you set up what mouse/keyboard actions select/move/confirm UI stuff nd then your Button has a series of Events on click you can assign in-editor.