Ten minute game jam!

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.

Thanks for your reply. I did add that component yesterday, and I tried to use it to trigger “Hello World” Debug.Log statements from objects and UI. I’ll try again.

I get that the Button will have events. But what if I want the system to respond to keyboard input that isn’t connected to amy particular button or anything seen on screen – e.g., a spacebar to continue the game? I suppose I link it to a gameObject not visible on screen, yes?

Also, can the new input system let me pause the game to get user input (e.g., "Y or “N”) without using Update()? That’s what I’d really love to learn how to do.

I made some nice progress with the input system today. I really love the default keyboard navigation setup for UI buttons and such – arrow keys, WASD. And I got my buttons working nicely. But what if I want to edit the default setup to allow TABs as well? I can’t figure out how to modify the navigation/keyboard map. I see it, with pink fields for each keyboard function, but I don’t see where to click to add another option to “up” and “down.”

Also, Keyboard.current.spaceKey.wasPressedThisFrame lets me get keypresses, even outside Update(), which is great. With a boolean, I can pause the game and wait for user input. But is this the best way to do it? I sometimes want to ask the player two or three questions in a row, and I want my text object to update each time with a new prompt and then sit and wait. Should I just keep using booleans? Use a coroutine? Or should I be listening for some sort of event?

Many thanks for suggesting I try it. I’m loving it so far. Already converted a fair bit of my game to it.

You probably sorted this already but the pinks are ‘composites’, added as a group when you ‘Add Up/Down/Left/Right Composite’.

They are used for stuff where the inputs are not exclusive, such as pressing left/up together to move diagonally. The composite for Up/Down/Left/Right will return you a Vector2 I believe.

So I don’t think you would add Tab there, since it’s a key likely used alone, and would probably break that vector anyway. Instead you’d make a new action for whatever it does, and bind Tab there along with equivalent controller bindings.

But if you did want to add something there, you can right-click an existing one, ‘duplicate’, then rename. :)

If you’re trying to make Tab into some kind of ‘Next Field’ control, that may be more difficult since I don’t think Unity’s UI Input component has support for that built-in.

This is basically emulating the old system and is not ideal. You want to use the actions you’ve defined rather than hard-coding any inputs to one device. Whatever needs ‘space’ to continue should do so via an event/callback/message, using actions so it works with controller and rebound keys too.

Then you can also poll the current device map, and display appropriate tooltips/icons. :)

This sounds like a bigger architectural question. No expert, but typically I’d consider a game manager state machine with an enum that tracks ‘game state’. Then everything has access to which part of the game you’re in, and the manager can do the pausing and change input context/map appropriately.

For sequences of prompts/responses, not sure if this is purely UI-based or not but maybe make a class/gameobject that generically handles one of them, and has links to next/previous prompt (so a linked list/stack/queue, depending on your needs). Instantiating a linked list of those would be your sequence of prompts/responses). Then you could hook up whatever navigation there, to go forwards/backwards through the list of prompts as needed.

Interested in @Juan_Raigada’s take on this too. :)

Yes, this all looks like you need to define an architecture.

I dislike enums defining game states in general (sometimes they are the easier option) and in Unity I tend to have logic GameObjects (even Scenes) we enable/disable to define game state. The advantage is that it’s flexible and expandable (enums , once the code gets too long, get hard to manage/maintain).

But no matter the approach, yes, you need a Game Manager that handles all this and changes inputs, etc (if you use the enable/disable method you can enable disable different input setups, and change everything without touching code).

My earlier projects did a lot through code, but I’ve learnt to appreciate Unity’s editor’s power. Now, my principle is that a great code architecture should enable game expression and design without the need for extra code. Basically code a framework and use the framework and the editor’s tools to design and iterate the game. Getting there is taking us years, though, and it’s obviously genre-specific. Real projects mean you take shortcuts.

For sequences of prompts, the enable/disable method works. Set up different GameObject asking for different stuff, and input confirm just disables itself and enables the next one (and sets the internal variable as needed).

Thanks so much, guys. I really appreciate your broad points about architecture. I wish I’d thought about this earlier. For example, I’m slowly realizing that I can process all mouse input with one object, since the new input system gives me eventdata about everything the mouse does – position, object clicked on, exit, entrance. Although I’m still struggling to figure out how to tell if the mouse clicks on nothing. (I’ve tried IPointerDown and IPointerUp; no luck. Tried a transparent image layer; it hogs all the clicks, even if at top of hierarchy. Any suggestions on this?)

Anyway, I’ve already got a separate object that handles UI input. That object solved my “prompt for user input” problem along the lines you guys suggested – just use a couple different objects and enable/disable them as needed. Works a treat, and with the input system, I can make pretty popup windows with nice pre-selected buttons and everything. But should I consolidate this UI handler with the click-on-rest-of-game handler, into one central Game Manager? It seems that’s what you guys are suggesting.

If nothing else, my game now runs with almost nothing in Update() anywhere. It “feels” more like OOP. Objects bark if they get clicked on, and things happen from there. I like it.

So I’ve now got a complete “game” – though it’s more like a 3-minute game than a 10-minute one. The player and AI compete for control of systems; they fight using auto-combat; and if one side has a majority of systems plus control of a particular system, they win. So yay, I’ve created a little game in Unity!

The question for me now is whether I want to go further with this. I’ve got a few ideas on how to do things differently for a 4X, but I know such a thing is a ton of work, and it’s hard to know which feature to try to implement first. Exploration and fog of war? (I incline toward this, using a variation on Interstellar Space Genesis’s system.) Exploitation and production and economy? (Lots of hard decisions and ocmplexity here. What resources to use? What if any role for individual planets? etc.) Manual turn-based combat? Tech tree? (Seems premature before other systems are developed.) Diplomacy? (Also premature.) That’s what I’m thinking about now.

This is more of a game development philosophy question, rather than something with a clearer right answer.

So I can’t give you an answer, but I can give you my thoughts on the matter:

In general, when developing commercial games, the most demanding constraint is time (well, it’s really money, but money always translates into time). That is, a game needs to eventually hit a release data and a budget or risk not being profitable. Depending on the specific project (and its circumstances, release date and/or budget can take priority, but even prioritizing budget you can’t expand a project too much, since extra time eats money too). Thus, the usual operating procedure is to create games in parallel. That is, you develop all main systems at roughly the same time (except clearly ancillary ones). The game thus takes shape by each system taking its own, mostly independent shape, and only later they are evaluated together, and if there’s money/time, iterated on. This is very effective and efficient, unless the design doesn’t work and you find out you need a rework when you tie systems together. Of course, there’s a high level plan and design that tries to make sure the overall design is going to work, and with an experienced team it mostly works. And it allows relatively fast developments of crazy sized games.

But while this is certainly a must in most commercial projects to an extent, I do not think it’s the ideal way of development. And in a small team/hobby project I can see it leading to a lot of frustration. I’ve thought about this a lot and I have what I think would be the ideal process for me for developing projects that can both fail (failure does not have a serious impact other than emotional, since it’s a personal project done at little risk) and take as much time as needed (constrained by health).

But bear in mind this is taking into account the way I think and process stuff, it might not be suited for other type of developers.

What I would love to do, if it was practical, is to do a focused development. That is, identify what’s the core mechanic of your game and make it really sing in isolation, with all other mechanics abstracted (for example, in your case, if you think something about the strategic layer is the most important, the tactical combat would remain semi randomized until much later). Once the full loop for that system/mechanic works, find the next (or handful of next) systems in focal importance and develop them to the best you can do. In the process you will have to add content to the main system (since there are more interactions now), but having something that works, you can evaluate that it’s still working. You will also have to expand on “lower” systems (for example, making the ships you have built and their equipment take part on the tactical randomization calculation).

The idea is you keep exploring expanding the design in the right direction until you find you don’t need to dig deeper, that the main mechanic still sings and that the supporting systems make it last.

And the benefit is that once you get that first main mechanic to sing, even if the others are underdeveloped, you still have a moderately fun, if perhaps shallow or short, game. So on the potential burnout, you are left with a project that feels “finished” enough and you can be relatively happy with.

If I had infinite time and no need to earn money (which are about the same thing) that’s how I would tackle a couple of personal projects I’ve had in my mind forever.

Hope that helps.

Thanks for that very thoughtful reply, Juan. I learned a lot from it. I had a vague sense that professional teams developed systems in parallel, but I had never really thought about it. That makes sense. As you say, for an amateur/hobbyist like me, designing in one particular direction might make more sense.

You mentioned health as a constraint. I hadn’t thought that would be a concern for me, but lo and behold my right hand started hurting a lot a couple days ago. It’s not happy with all the keyboarding and mousing I’ve been doing on this project. (This is not the first time. My aging hands hurt whenever I use them too much for fine-motor stuff.) I’ve taken a couple days off just to sketch UI and gameplay ideas on my iPad, which doesn’t seem to bother my hands at all.

Actually, what may bother me most of all is testing my game, not coding it. A 4X game requires some mouse movements, and even with my Ergo Touchpad, sooner or later that starts to both me. This has me wondering whether developing for iOS would be easier for me physically. But I assume one still tests iOS projects in Unity in Windows, only occasionally deploying a test build to one’s iPad?

My hand feels somewhat better today, but I’m being cautious, so after I type this message, I’m going to get off the computer and go swimming. :)

It depends what kind of bother the mouse is giving you, but a few years ago I started getting shooting pains whenever I used a mouse for too long. I switched to a vertical mouse and it stopped immediately, and I’ve had no problems since.

This may be too broad blue-sky, but has anyone done much with developing good character controls in Unity, that could share thoughts on the general approach?

Prototyping with built-in Unity controller with your own input code at first? Use some favoured Asset from the store? Fully custom of your own on-going creation? From scratch each time?

Physics-driven by applying forces, or not? (S)lerping envelopes?

I get its mostly dependant on the type of game you’re building, but I’ve not really done much with it before and right now I just want to get something simple in and then try develop a ‘good feel’, mostly as an exercise.

Just top-down-ish with no jumping, but an impactful dash to begin. There may be some basic physics interaction, like knocking trash cans over or something.

So my question is mostly ‘where to start’, then how to develop it further. :)

Ooooh.

This is my exactly in my ballpark.

This comes from my own process and evolution, and is definitely not the usual approach, so take with a grain of salt:

My approach has evolved over time, but in general (and keeping it very loose, because I really can’t be very specific), you want to keep precise control of your character behavior, while taking advantage of the built in collision detection/resolution/etc… plus keeping it compatible with physics for effects, reactions, etc…

My suggestion:

-Use your own code but make it generic/layered you you don’t end up with cascading decision points.
-Use physics, colliders and rigidbodies, but override character speed every frame. Your character projects physics, but physics do not control your character other than to avoid going into object, etc…
-Do not use forces or physically based acceleration. Do all the calculations of the speed you want in your own code (so you can control game feel).
-Detach your physical controller (what drives game logic) from its visual representation. Camouflage flaky interactions and get a more fluid sense of movement.

Great details, precisely the kind of insight I love - thank you! :)

What you’re describing there regarding physics is mostly a ‘kinematic controller’ yeah? Basically Unity handling the collides, with your code driving the movement?

The controller in our current game uses an asset store kinematic one. I’ve not worked on the control side directly, but I’ve done some stuff trying to get it to work with our standard physics objects. It seems to have limitations when imparting forces, no regard for mass affecting character velocity.

Obviously a limitation of the asset rather than the system, but is the approach you’d take here involve basically listening for collides, reading masses, and modulating your speed accordingly?

Everything else makes perfect sense and I’m grateful for your time. :)