Post by Dragonfoxing in eXpat - Space Game

Viewing post in eXpat - Space Game

It has begun, eXpatriates! (A game forms out of the mist.)

Those Pesky Menus (Day 3)

I rather thought I was done with menus when I finished the main menu yesterday, but then I realized I also needed to get the games actual Pause menu done. Thankfully, I have a bad(?) habit of copying scenes to make new ones, especially when there's stuff I don't want to prefab or play asset footsies with.

That aside, working on the pause menu also meant I needed to work on my GameManager again. At least an hour -ish of work yesterday was spent on writing the GameManager and adding to it (including an input handling helper for later), but today it got added more to. Which is good. Not much to say on that subject.

Above this sentence you can see a look at my viewport camera setup as it is now. I was testing the main menu in scaled 4K resolution when I realized that the game is square. 4K is not. Adding a white box that is barely larger than the viewport cube, however, gives me a border. How convenient! Maybe tomorrow I'll duplicate the viewport cube and resize it so that you get that sort of scaled-up 'artsy' effect like some SHMUPs have.

The menus all work now too, loading each other's scenes so that you can actually get to the game from the main menu, and back to the main menu from the game. Huzzah!

Moving Through Space And Time

Player movement...oh how I hate thee. The passion of a thousand suns does not express my sheer and utter disdain for how annoying thou art to work on. CityScape required no player movement. My not-even-a-prototype prototype Click(); was a point and click style affair. Notice a pattern here? I genuinely dislike trying to get the player moving around and for that to play nicely with things. At least Unity's physics engine makes it convenient to prototype game physics, even if it's not perfect.

Until you try to make a space game.

On the positive side, a simple game like eXpat doesn't require forces and acceleration and a nulled out gravity scale.
On the negative side, coding the movement myself means I have to do collisions myself too.

So far, I have some simple space movement going. You move forward all the time - it's part of the theme of the game mode. Escape, run away, not "engage and open fire". You can presently "strafe" left and right too, and there is some basic animation so that it doesn't feel completely flat.

At the moment, I'm very tempted to leave space as sparse as possible, because adding in proper obstacles means writing raycasting procedures for detecting things you can't just magically move through.

At least it's not as bad as editing existing player controllers. Those raycasts were a nightmare to understand.

Bonus Screenshots

Above, the player ship front and center as part of a up-and-behind 3rd person view, with a "test environment" of cubes. Below, an example of a particle system that is meant to look like "space dust" flying past.

Tasks For Tomorrow

You might have noticed that I am slowly going along and crossing out or adding checkmarks to tasks on the Day 2 list. That's because it basically is the overarching task list.

Things I want to specifically work on tomorrow include...

Music.
- I need a break from programming. I've done at least 5 hours a day of work per day, and a fair chunk of it was programming - a little over 400 lines of code by now. I don't know if that's impressive or not and I don't really care.
- I specifically want to make a basic music track, possibly with FamiTracker, for the game itself. I can easily cut together a menu theme from a full theme just by grabbing a repeating loop.
✔ ~~Opening "cutscene".~~
- ✔ It's not very complicated - I want to animate two "ships" (flat pyramids) charging up their "hyperdrives" (cylinders with lots of edges) and vanishing. Sort of an "You're on your own now, buddy" thing.

Blooper Reel