Ten minute game jam!

As usual, a lot of this might be overkill. Object pooling has 3 advantages:

1- Stabilizes memory footprint. Mostly useful for consoles or unless you are going real crazy with the size of a scene. Likely doesn’t apply.
2- Gets rid of instancing “hiccups” these won’t really be very noticeable on PC except for the very first time you instance something. Even with pooling you need to be careful activating and deactivating stuff (I’m thinking of Animator, for example).
3- Get rid of the carga be collector hiccups you get when creating stuff on the fly in a C# (managed memory).

So best practice is to use pooling always. In fact, the best practice in Unity (and you need to go through some hoops to do this in some cases) is to avoid any instancing and any new keyword in your code other than scene/level initialization code (loading screens).

This means using catching and “pooling” in code itself.

Thanks for your reply. Okay, maybe I’ll get in some practice using object pooling.

I’ve read arguments, though, that optimizing can also make a game more brittle or bug-prone. And I can see, using the Profiler, that optimization is a complete non-issue for my tiny little game right now. I suppose it depends on whether one is truly making only a prototype, or whether one envisions a complete game. In theory, this is a prototype, but who knows!

Anyway, thanks again. I do promise to post a screenshot or two soon. :)

As they say, ‘premature optimisation is the root of all evil’. :)

If it’s really a prototype, it’s meant to be thrown away when it’s done. For a turn-based hobby project I wouldn’t bother too much with pooling, you’re mostly adding extra complexity for very little perceivable benefit.

If you’re doing a ‘bullet hell’ game, sure - pool those projectiles. But infrequently garbage collecting the odd arrow is not likely to cause any noticeable issues, imo.

The most optimisation you should be worrying about at this stage is making sure you’re not doing anything ridiculously expensive every frame during an update. :)

edit:

We use the latest LTS for production, which is stable and updated less frequently than the most recent cutting-edge version. But I have both installed anyway. You can tell what is LTS when you go to install an Editor from Hub:
image

Thanks for the info about LTS version and optimization. Much appreciated!

OK, some screenshots! First, my intro/menu screen, in all its glory. The “Start Game” and “Quit” buttons work. The “Load Game” button, um, is pretty.

Star screen

Next my main map.

As you can see, ships can dock and move. The player, in green, moves with LMB and RMB; the fiendishly clever AI, in red, makes very nice, completely-random moves, lol. This part of the game is WEGO, like MOO2 or Interstellar Space Genesis. My message log at top is mostly for my debugging benefit right now. I do have an ugly who-owns-what option, currently toggled off. It features ugly red or green spheres around stars. I want to code a borders function that looks better.

Finally, a mockup of tactical space combat.

I’m quite proud of those ship sprites – I made them myself in Clip Studio Paint, on my iPad Pro, using my finger. (I have an Apple Pencil, but pens bother my hands.) One art question is whether to paint shadows from top-down perspective, as I did here, or try to use a top-left shading system. I paint and draw in real life, and we never use head-on lighting like this, but illustration is a whole different ball of artistic wax. I may stick with this method, as I like these results. Obviously these ships all look like they’re on the same side, so I need more art. Will be fun!

Currently, my combat is implemented on the main map, Civ-style, with a quick win/loss decision. But I’d like at least to give the player some choice of which ships to fire first and which enemy to target, and ideally a choice of weapons, and maybe movement on a tactical map. This would all be IGOUGO, though maybe with alternating turns.

I don’t know how far I’ll go with this, but I at least want to implement a take-this-star victory condition so that I have an actual “game.” Right now I’m working on implementing fleet movement, as it seems inevitable that multiple ships will end up at the same spot. Then I’ll work on combat. Then victory conditions. At that point, I may indeed have a 10-minute game!

I’m open to comments and suggestions!

First off, congrats on nearly finishing a game!

Now is not the time to rest on your laurels though. To make a truly professional space 4X game, you need to add:

  • a ship designer
  • buildings that you research and then have to manually build at each planet
  • sectors, trade routes, and a civilian economy/freighter system to move needed resources between star systems
  • AI helpers to handle all the busy work that you’ve added to the game. These AI helpers should be visibly broken.

Lol! Thanks! I suppose I should also add lots of diplomacy options that never seem to affect actual diplomatic relations, too?

Actually, I do have some design ideas for a distinctive space 4X. I’m aiming for asymmetry, as in AI War: it’s you vs a very strong opponent. I want a navy feel, with distinct ship roles, task force missions (e.g., bombardment, “ASW”, ship-to-ship, etc), small task forces, basing, range and fuel constraints. Each individual ship should be a big investment, and losing one should hurt. I also am thinking about smaller, shorter games, with different victory conditions, like “seals” from AOW3 or take-that-hill or silence-that-gun or escort-x-off-map-edge, as in Advanced Squad Leader.

But ideas are cheap! Implementation is what matters. And wow, is implementation tough!

And now I skulk back into Unity, trying to build a UI. :)

Love your work!

Sounds like something I’d be keen to play - just make sure to have full controller support, and scale UI to 4K TV. ;)

Glad you like it! OK, I’ll get to work supporting CouchPlay. :)

Yeah, love me some asymmetry. Makes AI design and implementation slightly easier too since they can be playing a much simpler role.

Glad to hear you like that idea! Yep, partly I have AI in mind.

A separate question. What minimum resolution should one design a Windows game for these days? 1024 x 768? That’s about the iPad resolution too, I think. I don’t think my little space game would be suitable for an iPhone, but I do wonder about people who want to play games on their browser. Do they ever need 800 x 600 or lower? My UI designer wants to know. :)

As it happens, I run my desktop at 1280 x 800, so I’m previewing 1024 x 768 all the time, and things are fine so far. I’m just not sure whether to go lower than that. It gets hard to fit in UI elements below that resolution.

I’d focus on the game first, but it is good to at least consider this stuff. Go as low as you can easily support without needing to do too many different layouts or asset versions. And make source art based on your highest supported res.

Steam survey shows that around 90% of people run 1080p or higher:
https://store.steampowered.com/hwsurvey

The biggest number below 1080p is 1366 x 768 at 5%, so that sounds like a reasonable min spec - though consider 720p, which is Nintendo Switch handheld mode.

iPad from 10 years ago maybe… :)

Thanks. Hehe, yep, I was looking at ancient iPad specs. OK, I seem to be doing fine on the resolution front.

Now I’m struggling to implement nice-looking toggles or buttons in a UI layout grid – basically a menu of which ships you want to put in your fleet. I used Buttons until I realized that, by default, they don’t toggle back and forth. The Toggle does that, but it’s harder to texture. It’s this sort of thing that is easier in Godot. :) Still, I’m sure I’ll figure it out. I swear I’ve spent two-thirds of my time on basic UI stuff like this…

Not my game, but I thought I’ll put it here anyway. My son wanted to make games so I’ve been helping him to learn to code in C# and to use unity. He’s been churning out quite a lot of content :) it’s been amazing to see the progress he’s been making.

Here’s his latest. It was originally an entry in a ‘build a game in 2 weeks’ competition at his school. For some reason the competition was never resolved (maybe because the only submissions were his and another from a friend of his), but he didn’t mind and just continued working on it and even put it up on Google store (for free) so he can share it with his friends.

The cool thing is that he is now at the point where we talk less about coding, and more about game design. His take on what makes a good game is different than mine, and we get into long discussion about mechanics.
For example, the health bar affects how fast your turrets can shoot. I thought the effect should be negative, i.e. The less health you have, the slower you can shoot, because it makes more sense. He wanted the player to be able to shoot more, see more explosions and generally have more fun.

Oh, and of you do click on the link, please excuse the silly images and description. That’s 14 year old sense of humour (although I admit it made me laugh out loud).

Hey, congrats to your son! Really cool that he’s making progress with projects like that.

Major grats indeed! Smart kid. :)

So, Unity/C# experts, should I be using Update() or Coroutines to get player keyboard input? I’m using the old input system.

I’ve been trying to use a coroutine to halt execution of my code while waiting for a keypress from the player. The coroutine does get the keypress, using something like “while (!keypress),” but the coroutine doesn’t halt or delay execution of the function from which the coroutine is called. So my output appears out of order – the calling function finishes its work before the coroutine finishes its work.

Should I just be using Update() instead? It will mean lots of tracking of game state and such, which is fine. But I thought one point of coroutines was to allow us to pause the game outside of Update().

Sounds like the calling function’s “work” needs to be inside the coroutine ie where you’re yeilding until the keypress is received.

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!