So, the code I posted last time for the pause function had an obvious error in it, but one which was not actually related to the problem I was having (a lot of iterations of the script were being made). The problem being that the second if should have been an else if; otherwise, both if functions would end up being true.
The goal was to pause the game; in a paused state the world would not move, and the the user would be able to use the mouse (during normal gameplay I locked the cursor to make it impossible to accidentally click something when giving mouse input),
The problem I was having, however, was slightly more complex. For some reason, setting Screen.lockCursor = true did not seem to have any effect except in start (Screen.lockCursor does exactly what it sounds like; it returns whether the cursor is locked, and can be set to true or false as well). Part of the problem was figuring out the best way to define the function. Errors like the one I mentioned at the beginning of this post confounded the situation.
What ended up being the main error was the key I was trying to use. I had been trying to set ‘escape’ as my pause key. What I didn’t realize was that in Unity ‘escape’ also has the built in function of unlocking the cursor. A key like that is necessary; otherwise I could write a script which locks the cursor but does not provide a way to unlock it, making it impossible to pause the game or shut down the program by normal means. The moment I changed my pause key to “p”, things started working. Not everything, but most of it.
Right now, pause is almost complete. When paused, the player can’t fire, move, or change weapons, and all physics freezes in its tracks. All of this is done with manual checks (so the weapon firing script checks to see if the game state is “paused” before running). For some reason, an error gets put out to the console from the FPS controller script saying it can’t identify the GameStateController (as I posted earlier, gamePaused is a ‘static’ variable, meaning that it can be accessed by any script, and always has the same global value for all scripts. GameStateController is the name of the object to which the script containing gamePaused is attached). This error does not seem to cause any gameplay errors, so right now it’s mostly an annoyance.
I’ve also added the foundation of an aim function. The idea is that the player can hold a key to look down the sights of a weapon and aim more accurately, at the expense of movement speed and or field of vision (which is blocked partially by the weapon). Actually implementing the aim mechanics was simple. While a key is held, the weapon is relocated and re-sized to a graphically correct place, while the spread of the weapon and the motion of the player is altered. The problem is making it look pleasant. In the current implementation, the weapon simply appears instantly in the new position. Of course, it would be infinitely more preferable for the weapon to move smoothly from its regular position to the aiming position. I attempted several ways of doing this with scripting, but they were complicated and prone to failure.
So I asked how my brother (half of dastardlybanana.com) had achieved smooth motion into an aiming position, and was told that they had attempted the same thing I had, but found it just as unwieldy. He ended up creating an animation for the weapons that brought them into the correct position.
I’ve been purposefully avoiding animation in favour of code. When I was first outlining the project, I planned to use as little of it as possible, so as to have more emphasis on the coding. There are some clear limitations to code alone, however, especially in something as visually dependent as a game.
Furthermore, a lot of the stuff I want to add to the game now is not the player but the environment. Next week I start the AI for the game, and for the AI to do smart and clever and tricky things I think it needs an environment in which to interact with the player. Chasing the player around a huge open field is no good, but maybe long corridors, yes. And maybe the player can close doors, and try to lock them, but the AI can open them if the player forgets to lock them, or can go reset the locks somehow. A lot of these obstacles and environment pieces are going to have to start appearing in the game now.
There’s a lot available online, both free and paid (I’m willing to shell out a little for a nice bundle of multipurpose assets) so I shouldn’t have to do any modeling myself. I’ve started looking, and many aren’t animated; or, alternately, are much more expensive animated. If all I want is a futuristic door to slide open, I should be able to animate that myself. So it looks like I’ll be doing some crash course animation over the next few weeks. I’m not sure yet if/how I will adjust my schedule, if that turns out to be necessary – I don’t want to test the AI in an open field if I do not expect to put it there, for example.
It also means making some decisions about setting and theme which I’ve been putting off. Are we in a the future or the past? Indoors or outdoors? Obviously the project ultimately about the knowledge gained, rather than the final product, but even still, the final product should have focus. A lot of this will depend on what models I can find, and what is inexpensive (the free stuff is not exactly thematically consistent.. you’d have to mix and match to get anything.)
