Hello there!  

You've hit my devlog for this weird game thing of mine.  If you check below this paragraph, you should see links to a variety of devlog updates - eventually, at least.  As of writing this, it's only my first day participating.

Feel free to reply to this thread, by the way!  That's part of the reason I'm doing links to the various devlog updates...other than the fact that I write a lot because I like the sound of my own thoughts.

I have an Imgur album up for more frequent, screenshot-based minilogs: https://imgur.com/a/SZueo

Devlog Updates

Day One - Link
Day Two - Link
Day Three - Link
Day Four - Link
Day Five - Link
Day Six (Postmortem) - Link

Super Micro Mini Game Design Document Round Go!

• Title: Untitled
• Codename: "Unnamed Space Shooter"
• Objective: Avoid the things shooting at you and make it to hyperspace!
• Aesthetic: Minimal/retro.  I love playing with glitchy retro effects, and it makes it easier to get going on a project when the required art work is lower.  The caveat is that, especially at this resolution, enemy designs and actions taken against the player have to be more obvious.
• Modes: Just one - GTFO!
• Story?: You are part of a human convoy traveling the stars.  When an alien attack squadron finds your convoy, however, you and others deploy fighters to engage them while the civilians escape.  Your allies have all managed to jump out, except for you.  Survive long enough for your hyperdrive to charge and Get The Frell Out of there!

With this game, I intend on hitting the following Jam challenges:

• Pacifist (Guaranteed): The player will not shoot anything at all.  Instead, the player is trying to run away from / through a swarm of enemies in order to escape the conflict.
• Freak (Likely): I'm all about being an ass randomly inserting difficulty spikes.  Plus, I can tie in my Mitosis idea as seen below.  Other ideas include an environment with set pieces that are semi unpredictable (randomized); the hyperdrive suddenly taking twice as long to charge; perhaps an enemy the player for enough damage will cause the player to maneuver left/right/up/down slower, making it harder to miss being hit.
• Mitosis (Likely): Either the player, an enemy type, or both will be able to split into two.  If it is the player, then it will be for "bonus points" as that presents double the hitbox for enemies to hit, and it will be temporary.  If it is the enemy, then...well, more targets to be shot by.
• Eco-Friendly (Unlikely): I want to attempt to add this in somehow, but I'm unsure how I'd pull that off.

Hey there.  It's-a me, a-Mario!

Low Rez?  Yes Please.  (Day One)

Originally, I wasn't going to take part, but I've had my eye on this jam for about a week thinking about it.  I love myself some weird/strict requirements, and making a game at 64x64px is definitely fairly strict.  It reduces what you can display by an immense amount and makes some image effects nearly impossible to use without making a game almost unplayable.  Starting a bit earlier in the night, I decided for fun to see how easy it would be to get Unity to do weird low-rez stuff.

Turns out, Unity already has a tutorial on part of this.  Combined with some player settings, I was able to get a 64x64 game going, scaled up to 256x256 for...readability?  Aesthetics?  I don't know, I just didn't want to squint at the tiniest game ever.

This is a 3D game presented in perspective view.  The edge shading is a modified Roberts Cross procedure based on Unity's old image effects.  I used this last in my 1BitClickerJam entry, CityScape.  This is the only asset brought over from an older project.  One problem with this shader is that UI...doesn't like to render if the canvas is set to "Screen Space - Camera".  Kinda had to cheat a bit here, by setting the scaler to "Scale With Screen Size".  See below:

Yay for UI magic.  Since the game is being presented in 256x256 resolution, the text forcibly scales up and looks about as low-rez as the upscaled RenderTexture does.  Low-rez achieved?  I think so.  By the way, the text on screen is thanks to Jack Oatley's Ikkle font as found in the resources section of the community.

Plans For Tomorrow

Right now, it's late and I've had other things going on during the day.  Plus, it took me over an hour to realize how to deal with the GUI/text!

• Basic movement script for the player.  Not reusing any old code for this.  Should be fun to code it from scratch.
• Some more objects in the scene, for camera perspective/fov & player movement testing.
• Possibly some starfield magic?  Likely just going to spew tiny spheres and let the shader handle shading them in.

------------------

Extra Thoughts

So, it seems like I can't even get Unity to render 64x64px.  It doesn't seem to build any further down than 256 x 256...glad I chose that as my upscale target, I guess?  I did capture a screenshot of it in Unity's game window for a comparison graphic though!

My gods, ain't that tiny.  So, so tiny.

By the way, I did also set up a test animation on the camera.  This was before the PostProcessingV2 beta stack crapped itself.  Perspective with so little detail is so much cooler than it is on games like CoD at 1080P.

Render Textures Don't Have To Be Blurry

So you might have noticed that there's no blur on my upscaled renders.  There's a RenderTexture setting for that - Filter Mode "Point" is your friend!  Also, don't forget to check the size that the RenderTexture asset is set to, because mine defaulted to like...256x256 if I remember right?  Gotta keep that premium 64x64 grid alive, after all.

Expatriates (aka eXpat)(Day 2)

So a name appears for the game, as well as adding on to the storyline.

Xpat story: You are one of a faction of humans who have fled Earth in an attempt to find peace...and perhaps find themselves.  Everyone who has joined your convoy was disenchanted with their nations, with the governing of the planet, and now you are a long way from home.  An expatriate, everyone one of you.  To the peoples of Earth, you are known merely as a faction called eXpat, and that name stuck amongst the crews of the ships you travel in.

After a long time spent traveling, forging a home through space travel and reflection, you have been noticed by distant alien nations.  Their long-range military forces have hassled you for a long time, and now they are putting the pressure on you and your fellow eXpats.  Diplomacy and communication are both impossible this far out.  Will you survive the onslaught?

Expanding On Game Modes

Mode 1 - "Escape": Alien military fighters have arrived en masse, a strong long-range force meant to destroy your colonial convoy.  You have launched in your own fighter to defend your convoy, but the engagement with alien forces has pulled you too far away from the hyperdrive bubbles of the colony ships, and laser fire knocked your weapons offline.  Disengage and survive long enough to charge your hyperdrive and join your convoy!

Mode 2 - "Defend":  The convoy has called on you to defend against a scout group of alien fighters.  Defend and destroy!

Mode 3 - "Engage":  Your colony ship has intel that there is a small installation of aliens nearby producing minerals and fuel for their forces.  Assess the situation and destroy their forward operating base!

Mode 1 is going to be locked to moving forward + left/right/up/down.  No moving back or around when you're running away.  Mode 2 will have all axes of rotation unlocked, as will mode 3.  Mode 1 will be completed for the game jam, 2 and 3 are possible but unlikely.  I'll do my best though!

A Task List Is Something You Ignore, Apparently (Main Menu)

Looking at the task list from the last devlog, it seems I was supposed to be working on the game itself.  WELP.  That didn't bloody happen.  It's okay, though, because last time I jammed, I left the main menu for the end and I don't want to repeat that error of judgement again.  Going to build a full product/prototype from start to finish if I can.

I forgot how annoying it is to make menus in Unity.  You could use the built in Event System, but that requires setting up some Input axis entries and hell if I want to do that.

My menu script is fairly simple - based on input, it increments an Int between a 'min' and 'max' value and changes the pointer's Y value.  Then, when 'enter' (aka Z) is pressed, it does things and stuff.  Presently, "Escape" doesn't do anything because I haven't made the game mode, but Quit does trigger Application.Quit() which forces the game to close.

I also got some preparation done for the rest of the game by getting my GameManager script set up with some input helper stuff.  Always good to put your ducks in a row early.

Don't Code While Tired, Kupo

Total time spent on Day 2's stuff?  Roughly 4-5 hours.

Total time spent realizing I hadn't called a method?  1-2 hours of the total time.

Yeah.  Coding late in my day isn't always the brightest of options.  I get the job done though.

Plans For Tomorrow

With the main menu out of the way, there's a game mode to be built and some music to be made.  I'm going to try to focus on the "Escape" game mode, but I might end up popping open FamiTracker instead.  I used it last time for CityScape, and I'll be making music and sound effects in it this time where possible.

Task list + notes for myself follow:

• Decide whether or not to run seperate game mode in seperate scene.
  • ✔ A seperate scene is cleaner to work with, has less active scripts at once.
  • A combined scene has everything in one place, doesn't rely on loading scenes.  There's not really an upside to this though.
• ✔ Player movement.
  • ✔  "Escape" will feature forward-only movement, with left/right/up/down strafing.
  • ✔  The player ship will be visible and close, so you will see input reflected with basic animation.
• Scenery.
  • Ideally, I'd be randomizing stuff so that every scenario feels different, but that doesn't get me play-testing early.
  • There will be a very basic "ship hull" (read: cylinder) to go through, but the player has the option to fly on the side of it.
  • ✔ There will be stars.  I've never done starfields in a 3D setting before, though, and it'll probably really basic.
• UI
  • There will be an element showing "hyperdrive charge" - textual, of course.
  • Other UI, potentially?  Unsure.
• Enemy AI
  • Enemies should shoot bolts of something.  It should hopefully be noticable as bolts of something.
  • Enemies should have various programmed patterns.
    • Drive-by: Enemy shoots at the player while flying past.
    • Strafe: Enemy shoots at/towards the player while flying past sideways.
    • Cone: Enemy appears, shoots a cone of beams (particle system?), then disappears.
    • Spiral: Enemy shoots beams in a spiral pattern towards the player.
    • Spray And Pray: Enemy simply shoots wherever it is looking.
    • Spray And Pray - Line: Enemy sprays untargeted bullets in the player's direction as it strafes across the screen.
    • Mitosis Pass: An enemy phases in, then clones itself, and then does a normal strafing pass.
  • Enemy shooting patterns can be achieved in code or in animation.
    • The Animator does not animate keyframeless values - you can rotate a ship with animation while moving it in script, for example.
    • For variety I can make multiple animation clips + motion values per type.
• Other stuff.
  • I'm too tired to remember everything.
• Music.
  • FamiTracker with Konami VCR6 expansion for extra Pulse channels.
  • Those extra Pulse channels help with SFX, too.
• Sound effects.
  • Enemies should make noise when shooting.
  • The ship should make noise when taking damage.
  • There should be noises for colliding with stuff?
  • Other noises?
  • Hyperdrive charging + "Hyperdrive @ 100%" noises.

For the trouble of reading all of that, have a picture of Day 2's final build

And for bonus points, the gif below :D

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

• Forgot to use GetKey instead of GetKeyDown for tracking player left/right movement.  Don't need to turn this into a tappy-hurty-finger game, do we?
• I don't honestly know why I have to have the Canvas at exactly 0.4 depth away from the camera for it to show up in "Screen Space - Camera" mode, but it works.  I guess.
• Don't need to do any UI scaling with the UI set to 1 PPU and the rendertexture handling scaling, do we?
  • The answer is no.  I think I wasted at least an hour if not more the past two days trying to fiddle with UI anchors and positions and NO GET IT AWAY FROM ME IT BURNS
• How many times I have written functions that work, only to forget to call them.  (At least five times by now.  No, I'm not counting.)
• Ew, Timeline.  Ew, playables.  EW.  EWWWWWW.
  • Don't ask.

It's looking really great! Thanks for the detailed devlog... 400 good lines of code can be really hard to make.!

I'm looking forward to this!

Have A GIF. (Day 4)

That is all.

Task List

• Music.  Someday.
• Enemies and bullets.
• Uh...other things?
• UI
  • Hits indicator has yet to be properly hooked up but uses similar stuff as the Charge indicator.
  • Escape Outro animation on success (involves delicious chromatic abberation.

Bonus Round - Bloopers

• Dyslexia is not my friend.  Dyslexia is not my friend.  Dyslexia is my friend.  F**K
  
  • You say that thing's at 21.9f?  Here, have 29.1f again.
• Sometimes I don't understand how Unity UI interacts with the world.
  • Sometimes it makes my brain bluescreen.
• Raster is your friend.  (TextMesh Pro font asset creation)
• Why does Unity always load Blender files with the wrong rotation?
  • I know why but it still makes little sense in the end
• Needs more coffee.

It's ALIIIIIIIVE (Day 6)

Welp.  It seems I hit my goal a day early.  Technically, I should have spent another couple days on eXpat, but for reasons you'll see below, eXpat ended up being finished a day early.

Post-Mortem Time?  Post-Mortem Time.

eXpat was a game prototype where I intentionally kept the design document short while defining the most important things - game mode, objectives, fail/win states, and an idea of how I wanted the game to flow.  I intentionally challenged myself to keep it short, keep it sweet, and keep it simple.  However, the final game as it will be uploaded later is somewhat simpler than the original design document would indicate.

The Problems

Custom edge-shader: In order to quickly start prototyping a game jam game, I chose to use a shader that I use rather often which shades edges.  I had not anticipated how that would actually cause some serious problems:

• I was unable to create Scenery elements beyond a sun in the distance because my edge shader would treat them like objects that were full of geometry to shade, regardless of whether that was true or not.  This is actually not normal behavior - it's due to the small resolution of the game itself.
• The edge shader also almost made it impossible to have bullets/lasers be a different color - thankfully, I accidentally discovered Particle/Emissive shaders in Unity's core library that allowed me to bypass that.

The Low Resolution:  You and I both would have thought this would have been the main problem, but it almost isn't...at least for 2D games.

• For 3D games, 64x64 pixels makes it extremely difficult to have objects of any distance in the scene without them fading out before they normally would.  It also made perspective more of a challenge to handle, especially for a third-person up-and-behind camera.
• The resolution was the main reason why my edge shader wasn't able to work as well as I'd have liked it to.  Given that at normal resolutions (1024px or greater) a 2 pixel line is not a big deal, at this resolution a 2-pixel line can take up almost a 20th of the screen.  Now consider that the substance of what you see on screen, for the most part, is either textual elements or edge-shading, and it quickly becomes a problem.
• The lack of resolution in conjunction with my font of choice made it difficult to make a UI that made sense.  I figured it out, though.

The Not-Problems

Self-imposed Time Limit: I had set a limit of 7 days to finish eXpat.  This might have become an issue, but by keeping my micro design document micro and pruning non-essential features that I couldn't implement or prototype quickly, I turned it into my biggest ally - given that this is only the sixth day of work on eXpat, that is.

Enemy AI: In the earliest stages of planning on Day 1, I had contemplated trying to make some complicated-as-heck AI (or complicated to me) that could maneuver on its own, pick when to shoot, and escape on its own self-informed escape vector.  I said to hell with that.  Instead of making some super-complicated AI, I made a very basic "AI" that determined its own path from a set of presets, has a pseudo-random chance to shoot and a pseudo-random time to shoot.  I turned what was going to be my biggest enemy into my greatest ally, because as it turns out, it's actually kinda fun - and not frustrating - to dodge these enemies.

Game Design Document: Traditionally, I have a hard time deciding on what to make or do.  While I had a genre in mind, my goal with this jam was to force myself to go through the full design process from start to finish.  I anticipated making the design document to be difficult at best, but when I sat down and focused on it, I was able to get it done and keep it...at least somewhat reasonable.

The Features That Got Cut

Going through the whole design process from start to finish meant that I had to practice a technique that I am not fond of - pruning.  The idea of cutting what could be a very nice piece off your game in order to get the game out the door is perhaps the most distasteful part of design and development to me.  For that reason, I had to make sure I practiced it and got used to it.

Enemy Bullet Patterns: I tend to look up to bullet hell games as a gamer.  I love trying to dodge the patterns, and I generally can stand the sheer frustration of not getting a run perfected.  When I looked towards making eXpat, I anticipated trying to emulate some of those bullet patterns in 3D - even at as low a resolution as the jam restricted us to.  I had hopes of doing this even as far out as day two, which is when I added the idea to my task list.

While working on enemy AI yesterday, I made the decision to prune this feature as I figured I would not finish by tomorrow.  While working on adding paths for the basic AI system, however, I found that I would not have completed this feature anyways!  Having two enemies spawn at a time firing relatively quick bullets at you is already difficult enough to dodge if you aren't trying to anticipate any of the seven different AI motion paths.  Trying to dodge a salvo of bullet spray at the same time would have been...vexingly difficult.  I do intend on exploring this post-jam, though, when I have more time to actually program bullet patterns.

Scenery:  I already went over this in the Problems section, but eXpat's "Escape" mode scenery got cut almost entirely from the game.  My edge shader wasn't behaving well with scenery, and in the end cutting the feature out - minus the sun - saved me up to a day's worth of modeling and editing.  It also saved me some collision code, which I felt would be a nightmare to handle in terms of what a player expects versus what I would implement, as well as...well, simply implementing it.

The Final Verdict

It's a game.  A space-y game.  With a single game mode, it might get repetitive, but it looks good and plays okay.

eXpat will be submitted to Itch.io later on in the night or tomorrow during the day.  I'm giving myself some time to mentally rest before packaging it up and being done with it.  I'll leave a link here once I've done that.