itch.io

My partner and I just swapped to Love2D from Gameboy Studio the other day, we've been just brainstorming.  My partner is finishing their GBS game while we slowly look over APIs.

A friend of mine jumped ship to Godot and wants to learn it, but since I already know it (and they want to team up) we're playing with GB Studio instead for funsies. Love2D because GBS is too damn quirky for either of our tastes.

Explained in the TIPS section on the page, but I didn't wind up including the visual effect that would explain it, my bad:

you get a bullet back for killing an enemy (including if you use an exploder to do it)

Gosh yes, I was.  Thank you.  Now I have that weird Cross Origin Isolation & SharedArrayBuffer issue...

Just had to enable SharedArrayBuffer in the itch.io game page settings, now my game works.  Thank you for saving me!

I'm seeing a lot of conflicting information online about this.  I have Godot 4.0.2 with my project set to Compatibility mode, but there are no release templates for web for this version...and apparently there are still issues with 4.0's web exporter.

Wtf do I do to get this working?

TY Glitched_Design for reminding me that the mono version of Godot 4 isn't necessarily up to speed with the non-mono version.

I stream my code sometimes on Twitch or YT so people already get to see the staples and glue holding my work together. :D

Going to dip my toes into actually using Godot to make a jam prototype solo.  Been years since I did a jam but looking forward to it.

If you've read the game description, you know that it isn't a complete game.  It is in a stable enough place as a prototype that I feel comfortable uploading it and getting very early feedback.

To address the lack of features that I wanted to implement, I'm going to be working on a monthly update to add features and make the game that I want to see.  This might eventually include porting over to Unity or Godot, but for now this will just be code/sprite updates for the game in Pico-8.

Super Pico Wars Z - The Titular Update

It's a turn-based tactics game, but without variety and a large grid to work on, it's not much of a game about wars.  Let's fix that.

Required Features:

• Larger Grid
  • Grid sizes will be randomized, starting from 10x10 going up to 20x20 - square sizes only for simplicity's sake.
    • The maximum grid size might be up to 30x30 depending on testing.
  • Larger grid sizes will help to make unit variance and future mechanics (bombs, unit starting position choices) possible.
• Unit Variance
  • To start, 3 enemy/player variants which are TBD as of planning this month.  They will present different HP, Shield, Move, Attack Range, and Attack Damage values. Each variant will use a different sprite. 
  • At present, there are seven different unit sprites to use which permits a wide amount of variety.
  • In this version, each ship will be randomly cast to a Unit Variant.  Be sure to use the Infobar at the top when hovering over units to see their stats.
• Infobar
  
  • The infobar will be updated to shorthand various details.  "HP" and "SH" will remain, "move" will be "MV" (move value), "AR" for Attack Range, "AD" for Attack Damage.  "VA" may be added to indicate a particular Unit Variant code, if implemented.
• Camera
  
  • With the larger grid size, a perfectly centered camera will no longer be possible.
    

Optional Features:

• Message Log
  • Currently, damage functions push a message to the message log relaying what happened to what ship.  This is not exposed at present.
  • The Message Log will show at the bottom of the game window, showing the last 2-3 actions that occurred.
  • There will be an option in the Cancel Menu (hit X) that lets you view the full message log, which you can scroll through via up and down arrow.
  • This requires a fair amount of new UI and Input work which makes it unlikely it will be in this update, but you never know.

Testing Features:

• Unit Initiative
  • The current setup for unit turns is that the player takes their turn, and then the enemy does so afterwards.  This is one form of TBT turn order, but it doesn't have to be the final setup for this game.
  • I will try random initiative for unit turn order, which will require a bit of fiddling with turn order as it's coded right now.
  • This will likely not make it into The Titular Update.

If you made it this far, have yourself a cookie, you trooper you.  Even if you skimmed.  No judging here.

I mean hey, you had time for audio at all!  I was so busy trying to do programming stuff I haven't done before I couldn't even get cities to do more than trade food, nevermind get audio done. x3

This was pretty fun!  Pretty cool to see random generation in a four day project, not easy to pull off.

The only comment I have on the gameplay itself is it took a few tries pressing "E" to access terminals, and it seemed like enemy bullets automagically track you and never vanish.  That being said, I was still able to "win" on my first try.

The sound effects are perfect for a jam game.  I giggled every time I right clicked. XD

I wanted to make cities level up, but the most I was able to get done by the end of the jam was literally just getting cities to balance food out.

Thank you for trying my game!

Thanks!  I wanted to make an Android build and it's cool that you'd be able to play it.  It'll easily enough be built for Windows too, though.

For jam games, what platform(s) do you want them to be built for?  Windows, Mac, Android?  What'cha got?

I figure the answer is going to be a "no", since prefabs would make this challenge easier...but at the same time, prefabs with no game logic mostly just become shortcuts for packaging physics information (Collider/Collider2D and Rigidbody/Rigidbody2D) as well as art.  So it's worth asking the question, will prefabs be allowed or are they against the spirit/rules of the jam?

Hey there!  Thanks for the comment!  Yeah, this was mostly just a little cutesy thing I whipped together yesterday on Christmas Eve to pass the time, so the entire concept of the game was made on the fly.

That being said, if I come back to it, I'd most definitely add a proper "game over / you win" thing.  As far as breaking goes, that really depends on whether I decide to take a more absurd look at game mechanics and focus on how silly it is to forever accelerate forward and jump a truck over ridiculous distances, or focus on something ... less absurd.  Although jumping a truck without a ramp is pretty absurd in and of itself...

Thanks for your time and the constructive criticism!

Yeah, a sense of speed was painful to try to get working with such a limited space to work with.  Thank you for your compliment and constructive criticism!

I'm not entirely sure about that myself.  I'd have to say to check your scripts as well as your object hierarchy and canvas settings to see if somehow your canvas is being moved by something else.

On the canvas, I have it set to "Screen Space - Camera" in pixel perfect mode with the Render Camera set to my main camera (the one rendering to texture).

On the canvas scaler settings, "UI Scale Mode" is set to "Constant Pixel Size".

This should cause your UI to not only stop scaling with the screen size, but also to render to the camera itself, therefore rendering to the target texture.

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.

INCOMING! (Day 5)

It was already coming together fairly well, but now with the Enemy "AI" cinched, it's actually starting to seem like a real game...even if an old one, with "meh" level enemy "AI". :D

And today I come with more pictures!  Yaaaay pictures.

I'll Throw You Into The Sun

One of my tasks on Todoist for today involved making scenery for the game.  I quickly found out, however, that my shader makes that...almost impossible at this resolution.  Maybe given 128x128, or definitely given 256x256, I could have scenery that played well with my edge shader.  But no!  Pixel economy, man!  Pixel economy.

Above are some examples of things drawn at range.  Cube, cylinder, and sphere, to be exact.  The cube only shows non-edges because it has a completely flat side facing forward.  The other two?  Hell if you'd figure out what those were without passing them on by.  Unfortunately, I had the same issue when trying to make stuff to fly 'through'.  Not every idea you have works, but it makes me sad to not be able to develop the experience I was hoping for.

That being said, it's not all a wash.  I played around with the "planet" that existed before.

That planet?  Is now a sun.  Why?  Because I figured out that if I set a emissive shader (aka Particle) shader, it doesn't actually...push depth values to the depth buffer?  I don't quite get it, actually, but it works!  Now because of that I have a far-off object for visual stimulation.

Good Luck, Star Fox

There's enemies in the game now.  No, for realsies!  You can actually get shot by things now.  I cheated a bit on this, though.  I did not need to spend multiple days writing an AI that can path-find in space, especially not for a game that is basically a very short "Get The Hell Out Of Dodge" scenario packaged with pretty pixels.  Instead, I used a (relatively) inexpensive Asset Store tool called Camera Path Animator.  It's a bit much to learn eventually, but that's mostly in figuring out how to set up the paths and their orientation/etc points (making ships go the right way and the right rotation).

So, the API documentation on CPA is balls.  I mean, balls.  However, Visual Studio has intellisense magics that let you autocomplete function and parameter names.  What that also allows you to do is see public members of a class or object.  I, being a lazy twit who didn't want to dive into the non-web documentation, figured out the few parameter names I needed to work with fairly easily - animationObject being the only actual one I had to find.

With all that set up, I went about making the "AI".  It's fairly simple -

1. A Spawner object spawns x enemies every y seconds.
2. Each Enemy looks up all of the available CameraPathAnimators and picks one at random.
3. If a CameraPathAnimator is currently playing, the Enemy chooses again at random until it finds one it can use.
4. The Enemy attaches itself to the animator, tells it to reset+play the animation, and flings off on its course.
5. Once the Enemy is within the center ~50% of the camera view, it randomly chooses when to fire its single laser.
6. The Enemy goes to the end point and then stops.

That's it.  That's all!  It's fairly simple.  The randomization of animation paths, as well as semi-randomization of laser firing times ensures that things don't get too stale too fast.  I do need to make at least two or three more paths to work with later.

The Giffening! (Bonus Points Time)

Enjoy~

Super-Obligatory Task List Here

• Music.  Or something for sound at least.
• A few more CameraPaths for the enemies to animate on.
  • Add one camera path that sends a enemy ship whizzing by.
• Fix bullet hits not registering on the Hits counter.
  • Fix the Hits counter not even being scripted yet.
• Fix max Charge not triggering outro sequence.
  • Fix not having an outro sequence made.

-stares at Todoist again-

Wow.  That's almost it for eXpat.  With two days left that were planned for it.  Cool.

Challenges Update

I don't like lingering on a prototype too long during a game jam.  Eventually once all the major work is done, it gets fairly tedious to do more.  That being said, my basic Game Design Document is almost fully represented in the game and I feel it's acceptable to write off a few of the challenges.

Pacifism: Nothing's changed here, move along.  You're still playing a Dodge'em'up, after all.

Freak, Mitosis, Eco-Friendly: Heck no.  Not happening at this point.  I'm okay with that.  We'll see what prototype #2 brings, though.  I might bring Freak back for funsies, and it might be easier to do Mitosis too...especially if I plan ahead of time.

Wait, What?  'Prototype #2'?

Yes!  Even after taking a day's break yesterday and starting a day or so late (I think?), I'm still on track to having roughly a full week of time to work on a second prototype.

Genre?  Rhythm game.

It's meant to be a big ol' planet, essentially.  I put it there so I'd have something far off in the distance for the sake of visual composition, but I don't think it's really in the right 'place' yet, and I could do with some input on that.

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 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.

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

So You Want To Upscale Your Game

So you might be wondering to yourself, "How do I make low resolution games in Unity?  How can I scale them up without losing my original pixel grid?"  This guide answers to aim that.  If you really want to make your game be 64x64 in size, though, there's always Screen.SetResolution - though there are some participants on a 4K screen, and it will be even more impossible to play than on a 1080P screen like myself.

Thank you Kavehes from the Discord jam server for letting me know about Screen.SetResolution!

Setting Up The Game Scene

Note: This isn't exactly necessary, but it can be fun to see what your game looks like at 64x64 resolution!

Whether you're new to Unity or you're like me, bumbling your way through learning Unity without checking guides a lot of the time, there's something we need to touch on first.  The Game window needs a bit of setup so that you can see what actual scale you're working at.  It can do that!  It's magical and awesome (and extremely important for GUI testing in-editor).

Above, you can see the location of the resolution picker for the Game window.  Hit the + to add a custom resolution.  Below is the dialog you pull up.

The label is whatever you want.  Leave the Type at Fixed Resolution, for magical Unity reasons.  Width and Height are pixel values - you will want to add a 64x64 resolution setting for this Jam, as well as another resolution for whatever screen resolution you want to be testing at.

Next, you'll want to go back to the dropdown and pick your custom resolution - in this case, 64x64.

Voila.  Your game is now super tiny!  And potentially unplayable!

Setting Up Shop With RenderTextures

It's time for the real stuff.  If you're tinkering with Unity, you probably know how to add objects and check the inspector and look at your assets window.  If not, there's plenty of guides for that.  I'm assuming you know at least that much.

In order (images follow below!):

1. In your Hierarchy window/tab, Right-click > Add > Camera, and then  make a Cube.
2. Your cube will go in front of this new camera.  It doesn't matter what you name either of these, btw.  I like to name the camera "Viewport" to remind me of what its job is.
3. If you're starting from scratch, you likely already have a Main Camera in the scene.  If you somehow don't, go ahead and add a new camera to the scene.  Call it whatever you want.  I still call it "Main Camera", though.  This will be the camera that actually renders stuff.
4. In your assets window, create a new RenderTexture.  Give it a name, then click on it to change some stuff.
5. Dimension should be 2D, of course!  Size should be 64 x 64.  This is in pixels.
6. Set any of the other settings to whatever you want.  Play around!  Color Format can make for some interesting changes.
7. Set the Filter Mode to Point.  This is the most important setting besides size, because the other filters blur the resulting texture when scaled up.  You want that sweet retro pixel crispiness, I'm sure!
8. Click on your "Main Camera" from the Hierarchy panel, and drag your RenderTexture asset into the "Target Texture" setting. (You can use the dot to search for assets too)
9. Now drag your RenderTexture on to the Cube that is in front of your "Viewport".
10. Voila!  You have perfectly upscaling yet satisfyingly pixel-y lowrez gaming ready to go.

(Important Notes!  Don't forget to turn shadows off on your cube/plane/whatever you have your RenderTexture on.  Under the Mesh Renderer component, turn "Cast Shadows" off and un-checkmark "Receive Shadows".  Also, at the bottom of your cube's Inspector, there is a material block with whatever name you called your RenderTexture.  Make sure to hit the Shader dropdown - find Unlit > Texture.  Now your graphics should render the way you might expect them to.)

Image time:

Steps 1-2)  This is what you should have by now.  Use the Game window to help you align your cube to your camera perspective.  This is what I refer to as the "Viewport" camera and its cube.

Step 4) This is where to find the Render Texture in your Create menu.  Ignore the "TextMeshPro" bit, that doesn't come with Unity by default.

Steps 5-7) A look at my settings for the RenderTexture.

Step 8) This is where to find "Target Texture".

But Wait, There's More!  (Not Really)

If you're just testing inside Unity's editor, then there's nothing more you need to set up.  Changing the Game window's resolution setting will cause the RenderTexture to upscale because the Viewport camera is taking up the full viewport, and therefore it has to scale the image up.  Point filter made sure that your texture isn't blurry.

However, when you get to building your game, you will want to change some specific settings.  As I build for Windows/Mac/Linux, these are the player settings I use.  Your Mileage May Vary if you build for HTML5/etc.  In any case, I can at least link you to player settings stuff for various platforms that jammers are likely to cover:

• Windows/Mac/Linux Standalone: https://docs.unity3d.com/Manual/class-PlayerSettingsStandalone.html
• HTML5 (aka WebGL): https://docs.unity3d.com/Manual/class-PlayerSettingsWebGL.html

It's also worth noting that Screen.SetResolution will also allow you to scale up, not just down.  You could program a game that upscales to a resolution based on a portion of the user's screen resolution, for example.

And That's A Wrap.

Did I miss anything?  Was something unclear?  Leave a comment, and I'll see what I can do.  If not, then thank you for allowing me to eat your time with words and pictures.

Regarding allowing the game to scale up without losing the original pixel ratio, the render texture solution works - you can change the settings on the asset itself to allow for Unity's style of smooth scaling so that you get clean retro pixels, as clean as it gets.  "Filter Mode" gets you there.  Good ol' Point filter.

On my project, I have the player set to what seems to be the minimum size available, which is 256x256px, but you could conceivably scale it up further without losing the 64x64 pixel grid.  (I should have written this on my devlog...time to make an edit, I think.)

Also teased.  Looking forward to more.

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.

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.

Huzzah, he speaks. Have some news.

• The build that has been up since just after the end of the 1-Bit Clicker Jam has been renamed to indicate that it was made for the clicker jam. You will always be able to download that version for free, no exceptions. I like to think of it as a piece of history to look at, as I work on new builds and new horizons.
• City.Scape() will be growing, with new buildings, foliage, and more. I am already working on a new playable build for internal use, and from that, I will be making a new playable demo build. ETA unknown. It will have xbox 360 controls and an updated UI for mouse control, and it will only be for Windows. 32-bit, naturally.
  • Why only Windows? Because Unity's input manager is a potato, and a dead one at that. I have to go sourcing a new input manager, which is a bit much for me right now. (AKA, it potentially costs money, and I'm moving soon.)

I clicked, clicked some more, and clicked even more hoping there would be something rewarding.

I made it to "the end". I am not disappointed.

I'll be working on an experimental game. Looking forward to seeing how people interact with it.

Since there's already a rules thread, let's ask:

What are the rules on the optional challenge for collecting/collectables? If I were making a music based game for this jam, could I award the player with a stamp or coin or collectable for say, perfect completion of a song? (I will not be creating challenging content for this jam.)