Happy holidays! I hope the final month of this… whopper of a year has gone relatively well for you. I’m sorry to say it wasn’t the best for me. I had some pretty bleak stretches where I just didn’t feel like I had any control over my life, largely thanks to some… surreal family issues. It was really hard to get anything done, and it didn’t help that I was starting to feel burnt out on building all this code in one giant marathon.
But things are looking better now! Earlier this week I finally got back in control of things and started putting the pieces in place again for Project Wild One. I’m happy to say the starter AI is complete! It did take about a month, though that partly involved building some supporting things up to make what I wanted possible, and since I finished that I’ve mostly been working on hooking up all the parts that I’ve spent all this time building, filling out sections I’d been leaving “for later when I know how this will work” and stuff like that. I finally got things “complete” enough to try compiling the project to see what happens yesterday, and the last two days have been a lot of debugging.
I still need to build a couple more things I’d left as “to do” before it’ll actually run, but that’s mostly plugging into the big conundrum I’m facing from here. This project has already pushed way longer to get to something playable than I’d like, and while I feel a lot better about presenting this engine with some kind of basic AI to drive it so you can at least have something to interact with, I still haven’t built any of the stuff to make this… actually a game. Save system, menus, some kind of progression, some kind of character list or generator, stuff like that. I feel like having these things would help a lot with making this actually a fun little game to mess around with and give you a basic feel for what you’d be doing, but… at this point it’s looking more and more like I’d better just push it out there as soon as it works at all, partly just for the sake of my health, to avoid burning out on pure coding. Matchmaker is going to be a lot of coding work too, so at this point I’m probably going to try for an update on MVOL next just to get out of the programming for a little bit.
For that matter, now that I have a few projects in my stable, I should probably start working on transitioning to a more “fluid” system like I’d been theorizing on when all this started, where I work on each project as the inspiration comes or when I start to get burnt out on something else, to maximize my uptime. I’m still not sure how well that’ll work for me, but it’s the only method I could think of to feasibly *make more game faster* on my own. So I’ll try and start experimenting with that once Wild One v0.01 is out there.
For now though, I’m basically trying to tie up the loose ends and just put up enough of the barebone basics in this project to make it playable at all, in the strictest sense. I’ll put off making it actually feel remotely like what I’m hoping to make for v0.02, so I guess v0.01 will be more like a… tech demo? Fingers crossed it’ll be interesting to take for a spin at least, there’s a lot cooking under the hood that may not be very obvious yet. It’ll be a tough call choosing exactly where to stop adding and just accept that it’s not going to look as good as it could, and that pressure is certainly there, that fallacy of “it’s taken so long it needs to be good” that makes projects end up taking even longer sometimes. I’m trying to find the right balance against that for my own sake just as much as to keep you guys from going too long without anything new.
I still can’t put a date confidently on the next release, but I’m hoping I’ll be sending a basic version to my proofers before too much longer. Testing this game for bugs may well be a whole new beast as well, come to think of it, since it has so many more working parts than MVOL. We’ll see how it goes! Thanks for reading, and I wish you a happy new year!
Dark thoughts for dark days. At least I hope. Would mean it will get better on its own.
The single biggest impact on staying motivated in a great coding project, I have found, is having an executable artifact.
At the end of the day, your code should always compile and some portion of it should be executable to obtain some sort of visible result.
True, for things like AI this is very hard to do. Test code, that will later be used for regression testing, may be written early to obtain a sort of “tech demo”, e.g. “for some randomised start scenario let the AI run for a predefined number of time steps”; the test may check invariants and postconditions aka “that what should not happen, does not”.
As testing dynamic systems is pretty tricky, it might even be sensible to spend one day to develop some sort of visualisation of what it does. A decision graph, say.
Of course on a more fine grained level, Unit Tests might be a sensible endeavour; depends a lot on the language you use – in such different languages as C++ and Groovy, code can often be written in such a way that erroneous code will not even compile (one can write their own compile-time checks). Java, in contrast, still does not have a functional Design-by-Contract API (javax.validation has existed for years but it is up to the IDE to make sense of it; bad luck if your IDE happens to be vi or Notepad++).
Verily, Unit Tests are just a form of Design-by-Contract, which is both very verbose and sadly runtime-checked.
That written, *some form* of Design-by-Contract is a very sensible thing to pursue. Far too many projects I have seen, where people do not spend a thought on pre and post conditions – and then drown in redundant null-checks, of all things. However would they deal with higher levels of complexity than “is this going to be null or is it not”? Well, they fail, of course. Trial-and-error programming, until the trial-and-error part takes up all the time spent on the project – and then death.
When working on a save-load system, ask yourself how you can make it the last one you build. You already had one for MVOL and ideally should only have had to port it to the new language you use now. (Which one, incidentally, was that?)
Similarly, as you begin building UI, think about what all UI screens should have in common and try to create a common template for all of them, such that after a couple of them you can concentrate on adding content without having to wonder how to arrange it. … UI framework programming is a thankless and brain-draining task, so I cannot stress enough the importance of relying heavily on frameworks for that. In some way each and every one of them sucks – *that is just how* thankless and brain-draining writing one is.
… I guess I’ll leave it at that, as far as good advice goes, and spend a few lines on the good parts of life. I am told I criticise too much and encourage too little.
Being able to operate a Debugger is something you can be legitimately proud of.
While generally not overly complicated (unless it’s GCD without manual) this is a skill absolutely vital to the serious software developer and yet I am far from the only one who notices, that many a strapping young programmer enters the business world without as much as a clue how to do it. These people have often planned years in advance to earn their money writing software, whereas you are “merely” side-grading your well established career into a new field. From here it is only a small step to also operate a Profiler and that is, again, an immensely useful skill for anyone writing software.
I applaud your decision to release the first version as a “mere” tech demo. The Minimally Viable Product is the kind of colossal first step, before which *everything* is but a dream, and after which *everything* is possible. Yes, defeat as well – but without such a kind of first step, defeat would be the default. It cannot be wise to artifically steepen that kind of a hurdle, which would end the race before it could begin.
This also ties into my first paragraph: Once you can run the program, it will become much easier to see-and-desire incremental improvements to how it does run. No run, no increment, no improvement.