overtopsdev - Tumblr blog

overtopsdev · 3 years

Text

That’s It For Now

So, we thought we better make a short post to draw a line under where the game is currently at. Harry and Shane worked on Overt Ops over the same period of time that our students worked on their end of year projects (between 2 and 3 months). That all ended a few weeks ago, and so have we decided to also stop working on the game for now. Our time since has been spent busily focusing on end of year obligations, and have decided to leave the game where it’s at for the moment. We will be coming back to finish it to a more polished and complete degree at some point, but that definitely won’t be until at least early next year.

For now, though, if you want to see where we got to with it (what I would probably call “first playable”), you can find it on itch.io at the link below;

https://toastgames.itch.io/overt-ops

Most things are in there, at least in a rudimentary sense…. It’s mostly just fleshing out details and populating it with content that remains (and honestly, that’s a “how long is a piece of string” situation…. this is the kind of game where we could keep populating it with content forever if we wanted to)

Then

Now

So that’s it for now everyone. Thank you for reading if you have. And thank you even more for playing.

0 notes

overtopsdev · 3 years

Text

A Slight Rearrangement of Time

There was no blog post yesterday. It’s the first day since we started this project that neither of us made a post. There will be no post tomorrow either.

This post here pretty much only exists to document that fact, and to put it into context.

Harry and Shane both have multiple other paid jobs besides working on this game. Those jobs have to be our priority because they are paid. The main one for both of us is our teaching gig, which takes up the lion’s share of our time usually anyway, but right now, we are at the pointy end of the year. This is the last week of classes. This is when it goes from busy to all consuming. We have barely touched the game this week because we’ve been helping our next batches of protégés get all their ducks in a row and be ready for the end of the schooling year to come to a close.

That will all be out of the way soon though, and we are both keen to get stuck back into Overt Ops this weekend.

0 notes

overtopsdev · 3 years

Text

Experimenting with Layout

So, now that we can have level chunks that are varying sizes, rather than having to keep them relatively homogenous, I’ve been experimenting with some smaller sort of “connective tissue” style rooms.

I’m finding it easier to go about this by duplicating an existing prefab, laying out several floor plans at the same time like in the above image, then if I want to save all 4 of these layouts, dupe the prefab 4 times, and delete the bits I don’t want to keep from each one.

I don’t think I am going to do this for larger rooms though. It only seems convenient for these small ones so I can compare them all side by side quickly like this.

0 notes

overtopsdev · 3 years

Text

Controlling Level Layout

So far, up until now, all rooms that a level is made out of have been seen as equal in the eyes of the level generator. There might be 5 possible rooms to choose from when generating a level, and every time it picks a new room to add, there is an equal chance it will pick any of the 5.

Well, today I started adding 2 new variables to allow for a more nuanced and controllable flow of a level from start to finish.

Firstly, “weighting”, which is a number assigned to each room based roughly on it’s relative size to other rooms.

This way, instead of what we were doing before, where the level generator would just spit out a set number of rooms (which kind of then necessitated all rooms to be fairly “samey”, so that a level generation didn’t vary too much from one to the next). Now, we can define a total value that we want a level to total, and every time a room is generated, it accumulates it’s weight until the total is reached. This allows us to have rooms that fluctuate much more in terms of size, but still have the overall level be roughly about the same size each time.

Secondly, “appearance Range”. This variable was hard to name, I couldn’t really come up with anything as clear and obvious as “weighting”. It’s actually a vector 2, and what it controls is it’s relative importance in the order of the level

So, if we imagine the start and end of the level as being defined by the numbers 0 and 100 respectively, then the 2 terms of the vector 2 define the minimum and maximum ranges of relative location that a room can exist within the level.

Now, this has an inherent problem that I haven’t solved yet, which is what happens if there isn’t a room to cover all parts of the 0-100 range? I’m going to have to find some sort of way to end up treating this more like a render queue or execution order style variable, except with a fuzzy range somehow. See, I don’t want it to just end up defining the exact order the rooms appear in, there still has to be some randomness to it. But, by giving it a defined range like this, rather than all rooms having an equal chance to spawn at any time, it allows for us to still create a relatively hand crafted ramp up over the course of the level.

0 notes

overtopsdev · 3 years

Text

It’s Ok to Take a Break

We’ve spoken a lot on this blog about ways to stay focussed, and maintain work habits in less than ideal conditions. I suppose that could then be extrapolated to the idea that you must work all the time no matter what, grind grind grind. This is not at all the case.

As mentioned in our last blog post, burnout is a thing, and it’s really important to try to avoid it. Good work habits involve a mix of on and off. You just need to make sure you have enough on to actually get the thing done, and also, when you are on, BE ON. But, as any personal trainer will tell you, you can’t just do reps 24/7 or you will blow out your muscles. It’s the same with your brain. You need to take periodic breaks to not destroy yourself.

At our main job teaching, both of us just finished helping all our students get all their end of year projects over the line, which were all due last Friday. So, in order to recover from that herculean effort, we’ve both decided not to touch Overt Ops this weekend. Not touch any work at all in fact. Breaks need to be had. We’ll be back at it tomorrow though. Game’s gotta get made after all.

0 notes

overtopsdev · 3 years

Text

Be Careful of Burnout

One thing we have had to be mindful of on this project, with probably varying degrees of success, is burnout.

This game is being made as a side project fit in between both of us having multiple other paid jobs that have to by necessity be our priority. But, as we’ve mentioned in a few posts in the past, we are determined to finish this thing and ship it, and in a reasonable amount of time too. We’ve both experienced side projects languish into nothingness in the past, and are determined not to let that happen to this one. That said though, we can’t be working on it 24/7. Overworking yourself is just as bad, and is well known to actually have negative effects on your output.

So it’s a delicate needle to thread, and we don’t claim to have all the answers. Normally when we make one of these philosophical posts that are more about the approach to working on the game than the game content itself, we have some advice as a takeaway. This time though, I’m not so sure we can safely say exactly “here’s how you do maximum thing, without thing burning you out”, because it’s something I feel is a constant challenge, and not one that I have a handy dandy toolkit of solutions to.

All I can really say is be mindful of burnout, and train yourself to notice the signs early so you can avoid it/do something about it. Things like despondency, lack of interest, avoidance, listlessness and lack of productivity even when you are working on a thing.

I wish I had a more definitive conclusion to this post, but I guess the best conclusion we have is; look after yourself, don’t overwork yourself. You will be more productive if you don’t. Even though it is tempting to wear yourself entirely down to the bone, because activity feels like progress. Sometimes it’s not, sometimes it’s burning you out.

0 notes

overtopsdev · 3 years

Text

Goal Adjustment

When we first started this project, we kind of thought that we’d just do it in parallel to our students working on their end of year projects. Something small that’s a bit of fun, that we’d wrap up in a couple of months, and then we’d have a little bit of a game at the same time as they did.

Not too far into development of this game though, we realised we wanted it to be a bit more than that. Not just a throw away little thing, but something we could both proudly stand behind, and maybe even be a bit of a stand out piece on our portfolios.

So, during development, we kind of changed our timeline and goals a bit to aim to have something not dissimilar to first playable when our students finished their games, and then for us to work on it more over the xmas break, and have a real (hopefully) polished gem by the time we go back to work next year.

Well, today our students submitted their end of year projects, and honestly, they are top notch, some of the best I’ve ever had submitted, which is excellent. For our part, the game hit first playable a couple of weeks ago, so we’re about where we wanted to be right now. Not everything is in there, but most stuff is, and between now and the end of the xmas break, we should be able to turn it into a fully fleshed out game.

Honestly I’m kind of looking forward to getting back to having more time to dedicate to Overt Ops each week… as the students have been getting closer to their deadline, we’ve had our hands more and more full helping them get their stuff finished, and had little to no time to work on our game which by necessity has to sit quite a bit lower on the priority list.

So, shout out to our students for doing some excellent work this year. Keep up the good work (if any of you ever read this), and go out there and keep making more amazing games.

0 notes

overtopsdev · 3 years

Text

Classic Technique

Need a quick way to placeholder in a different asset to try out some different behaviour?

Palette swap baby...

For us, for now, this is just for placeholder purposes until final assets can be made

However, this kind of palette swapping has been a feature in games forever, and while yes, it did partly come from the need to save memory by having less sprites, it also saved on asset design and creation time. Which is also a major consideration for us, so there is a good chance we may have to go with some palette swapped dudes in our game (although probably nothing hot pink like in the above screenshot)

0 notes

overtopsdev · 3 years

Text

A Note on Direction

There’s something that has been on my mind a lot lately about game dev, because I think we are at the point in this project where it is most pertinent. A little while ago we made a post about how the middle of game dev can just be a big slab of hard work, a slog of stuff to get through that a lot of game dev novices don’t necessarily know to expect, and so when it takes them by surprise it can often derail a project or stop it dead in its tracks.

Well, I think a less obvious, but related, and potentially far more derailing phenomena is the one of direction. Or rather, getting to the point in the project where direction stops “taking care of itself” as it were. Something that I don’t think you can truly appreciate until you feel it for yourself on a project of that sense of losing clarity when nothing about what you’ve been doing so far suggests there is any reason to lose it.

“We’re done-diddly-done for”

It’s something that took me years to even realise was a thing until I started seeing it crop up as a recurring part of development on every single project I worked on, whether the project got finished or not.

There’s this point, this weird sort of lull you get to, where the pervasive feeling is something along the lines of “so what the hell do we do next?”. But it’s not a fruitful question. It’s not like at the beginning of the project when you are defining the parameters of what is to come. It’s more like getting lost in a corn (or sugar cane if you are Australian) field, and sort of being struck with that feeling of no longer being sure that if you keep walking in the direction you are going is even going to get you anywhere at all. Like a step in any direction is going to leave you exactly where you are, and it becomes unclear that you should be taking any steps at all.

I do personally think this sort of sudden loss of direction is a huge project killer. I’m sure many people have got to this point on many projects, and even if every other planet had aligned to make the project be something that would have been finished and even potentially great, that slow drift to a halt while you look around and go “now what?”, can be the thing that undoes it all.

Because it can be hard to come back from. I think in large part because you don’t necessarily see it coming. You didn’t do anything wrong, in fact, you probably did everything right. And yet you look at the project and you can see it’s clearly not finished. And yet a step in any particular direction doesn’t feel like it’s actually going to get it any closer to finished.

Now, I know from having worked on projects that made it past this feeling, and DID get finished, that it’s kind of an illusion, and you kind of have to just push through it. But knowing that doesn’t make it easy to do, and it doesn’t make the way forward any clearer. In fact, and my students will tell you, I am a bit of a hair trigger when it comes to opining endless advice on any situation, but this, this is the one pervasive problem of game dev that stumps me.

Like, I don’t know of any good consistent strategies that you can employ to overcome it, other than at the very least being able to identify it when you see it. All I can point to from past experience is “stick it out”, but there’s gotta be better you can do than that, because I’ve definitely seen a lot of projects (both mine and others), that haven’t made it out of that mental desert, where you look around and think “we should be there by now… we aren’t, but which direction even is ‘there’ anyway?”

When we get to the end of this project, if I have any greater insight on this topic, I will post about how we addressed it.

0 notes

overtopsdev · 3 years

Text

Transition Effect

Inspired by the one from Doom, but with our own twist, here’s a transition effect (with placeholder assets) for going between game states that I have been experimenting with

What it does is, since the screen is already rendered to a plane anyway, it takes blocks of the UVs of that plane and offsets them on the V by a random amount per block. The next step here is to plug in a render texture of the screen itself as the image getting smeared rather than a placeholder image, so it looks like the screen itself is melting away.

0 notes

overtopsdev · 3 years

Text

State of Play

So, at this point, the game needs to start shaping up in ways to feel something a bit more like a game, and less like a tech demo. One of those ways is by fleshing out what is currently a fairly bare bones game loop into a full set of game states, with nice transitions between them etc.

So, first thing to do is whip up a quick diagram of what all those states need to be.

Next thing to do is to follow our trusty old first principle: “working not perfect”. If we sat down and polished each of these things to completion one at a time, then the workload/finished-game-ness balance would be way out of whack. So, the first thing to do is to quickly crap out a placeholder image representing each of these states, that can be used temporarily in game while the actual behaviour of these states is getting implemented.

Now we have some way of adequately seeing that the behaviour of our state changes is getting implemented correctly, without getting bogged down in all the time consuming “making it look cool”.

And then once we have the skeleton of our behaviour implemented, essentially switching between these:

Depending on what happens in game, and throwing up the corresponding image as needed.

Then, after that, we can start to make each one look pretty one by one (because in the end, they won’t just be simple still images)

0 notes

overtopsdev · 3 years

Text

One More Reason Routine is so Important

So, we’ve talked a bit on this blog about the importance of routine, and some ways to keep up motivation and to work on stuff when you might otherwise not want to etc.

One thing we haven’t really delved into though are the many reasons why that is so important.

I mean, it might seem obvious that one big reason is because then stuff will get done. Do work → work gets done, it’s not rocket science.

There’s a less obvious thing though that I’m sure probably has a fancy name because I guarantee it has probably been studied and investigated at some point. And that thing is the fact that the longer you put something down for, the harder it is to pick up again.

When you work on something every day, all the threads stay connected from day to day. All the little bits of connective tissue, many of which are so minor and incidental, you don’t even think about them at the time. Like, where did you put that file? Why was it named the way it was? But also bigger stuff like what was I doing next? And why had we made these choices about this system? Etc.

This doesn’t just apply to game dev, it applies to everything, and I personally believe it is the #1 killer of projects. The loss of momentum you get from stopping working on something for a while, it compounds like interest, the further you are from the time you last worked on a thing, the exponentially further you are from being likely to keep working on it again.

A personal musing of mine, and not really based on anything, is I think this is probably related to the concept of flow. Part of what defines flow is the slipping away of time, one moment just segues into the next seamlessly as you keep doing thing after thing after thing… once gaps start to get introduced into that flow, once your flow is broken, then it becomes harder and harder to get it back. Stop working on a thing for a month? Good luck coming back to it. A year? That would take a miracle.

Even just the last few days to a week that I have spent focussed on something entirely different (a talk I gave yesterday at the online conference Technically Games), coming back to Overt Ops today has felt a bit like this:

0 notes

overtopsdev · 3 years

Text

Final Quickie

Now that I’m not spending all my free time getting ready for the Technically Games conference (which was today, and great fun. I spoke about shaders, and briefly touched on Overt Ops), blog posts will be back to their regular length and content from tomorrow.

(this is a shot of our wall with sky shader)

0 notes

overtopsdev · 3 years

Text

Slight Deviation

No real blog post today, as I am preparing for a talk at a conference tomorrow… I will be talking about the Overt Ops shaders though, so that’s relevant I guess...

0 notes

overtopsdev · 3 years

Text

Face Time

0 notes

overtopsdev · 3 years

Text

Pew Pew Particles

0 notes

overtopsdev · 3 years

Text

Sometimes You Gotta Go Backwards

So, something that we’ve talked about a few times on this blog is the idea that you often have to cut out things you had hoped to do because there isn’t time enough to do them. It’s part of the territory, you either do less and finish the thing, or you keep picking at it forever and never finish it. You get to choose one of those two things.

One thing we haven’t really talked about yet is the comparatively much harder decision to have to cut the cord on stuff you have already done. You may hear this referred to as “killing your babies”, which I’m pretty sure originated in film production, not video games (the phrase I mean, not infanticide), but I’m not exactly sure of the exact origin of the saying.

Anyway, this came up for us recently, and even though you can know this is the right thing to do intellectually, that doesn’t make it any easier to leave your hard work on the proverbial cutting room floor.

So, a while ago, we wrote a post about the creation of a particular type of asset like this:

That would appear around levels.

I’m not sure we ever wrote a post about how they were to be used in the procedural generation though.

So, a quick summary of what they were for is as follows; I added a system to the level generation where I could add walls around the level that were flagged as “breakaways”. These were sections of level that the proc gen would randomly decide to turn on or off to further change the shape of room floor plan definitions.

The system worked great, like, there’s absolutely nothing wrong with it, in fact, it uses probably my favourite shader in the whole game.

To minimise the amount of human intervention, and maximise the amount of different outcomes, the breakaway system will randomly rotate these cubes of wall, and still maintain the correct dark/light versions of the wall texture depending on with direction the wall is facing.

That’s cool and all, but, as we’ve previously discussed, the ultimate limiting factor in everything is time. How much time is there to make assets? If there isn’t enough time to make assets for a system, then it isn’t going to get used. And after a recent re appraisal of our schedule and progress, it was abundantly clear that assets for this system just aren’t going to get made. So, rather than having one in the game, and it sticking out like proverbial dog balls because it’s the only asset of that type, instead of just mingling in with a large variety of assets as intended , the decision was made to take these out and stop adding more.

I’m not going to completely ditch the breakaway system, but it will need a significant overhaul to now work with the other, older system of walls changing textures based on the “room style”. Even so, the day’s worth of work spent implementing this, and then the several more hours it’s going to take to remove it and cauterise the wound is still better than the other 2 possibilities:

a single asset uses it, which will look lame

somehow magically a ton more hours and motivation get summoned from nowhere to make assets for it, which is a physical impossibility

0 notes