📰 The PixelCount Post - Issue #29
https://i.imgur.com/qTWImVV.png
https://i.imgur.com/suaaqNw.png
ISSUE #29 THE VALE, QUILL 26 MAY 2018 ONE BRASS
https://i.imgur.com/gebgb0k.png
This week I have been looking at getting some design docs updated and features filled out, like a large pie.
One of the upcoming features we need to get going on (the list is very long) is the cooking system, plus how food works.
There are two ways to cook in Kynseed. Firstly, a cooking pot where you can make stews and soups, as well as a baking oven for pies, bread, and cakes. Each one has its own UI and 'minigame'.
I got together with environment artist Matt and we developed some ideas for both, building on the original idea. However, we hit a roadblock.
We tried to think of a word to describe the different amounts of time ingredients take to cook, the ease at which the heat affects them if you will. Heat resistance? Robustness? Suggestions on a postcard please!
As for the food system: food will have an amount it fills you, a speed at which it fills you, a rate of burn off, and other buffs. It will be important to get a good breakfast or meal, but not to overeat (this can be drained off by visiting a toilet). If you are too full or too empty, it affects your speed and resistance to damage. We don't want the player to be constantly worrying about their food bar, but we want to make it so player's enjoy prepping and work out the best things to snack on or cook. It adds to the roleplaying aspect and gives a use for all those ingredients.
And you can sell anything tasty you don't fancy eating, of course. Is your bread the best thing since sliced...er...bread? Can your cakes cut it? Do your sausages come up to mustard? We look forward to baking with you soon! |
This week went by quite quickly! I did manage to progress and perhaps fix one of the longterm issues to do with audio. It was one that had gone unnoticed until the backer build started, where slowly over time the SFX would corrupt with distortions. Initially I was reluctant to look into it because it was an issue that showed after a few hours and as such difficult to know the factors that might lead to it and where the problem might lie. When time was available though, I looked into it and found that by repeating the same sound every frame for about 2 minutes that it would cause the issue. After doing so, I started researching to figure out if others had encountered issues and where the issue might lie.
The default assumption I had was that it was probably in the MonoGame framework itself, so I prepared to get the source code and build that and start to step into the unknown (code that I hadn't written and wasn't all familiar with outside the calling functions!). This didn't turn out to be that easy partly because it seems I had an unusual PC setup and so it was correctly generating the projects and then there were all the dependencies to get to...
So I went back to my side of the code to see if there was anything there. It was then I made the discovery that I had been creating instances everywhere... To get a little more technical: in C#, typically memory management is handled automatically and when an item is no longer referenced and used the next garbage collect will clean it up. These instances though were a mystery box of code from MonoGame that could be doing anything and it turned out was likely creating unmanaged memory, leading to this memory leak over time. So after making sure to dispose of the instances when they were done playing, it just started working - after 4 minutes playing the same sound there was no sign of the corruption!
I think this lead to a few learnings for myself:
1) I need to know a bit more about what is going on behind the scenes in MonoGame. It's interesting to me that I could manage to have coded this game for two years and not have known this! I think the reason is in part that the setup in this game is a little different to the usual way it is handled. Other source code examples I've seen use the content pipeline more heavily for audio, whereas I have resisted this so far to try and ensure runtime reloading (for both audio and graphics, the files can be edited and when the game window is refocused it will reload them).
2) Tutorial based code (which is where I found out about how to play sounds in the game) often does not have the detail to understand the behind the scenes. I guess the purpose of tutorials is often just to present a simple example, but in doing so it hides information that may become important later on...
In other news, development on the game this week has been going well with a really interesting coder likely to help out next month which we'll probably talk a little more about when he's involved! I did find though, that after a few smooth days, there does seem to be this mad rush towards the end of the week. I think I've been finding that whenever a deadline is set for one day then it seems like the night before there'll be a tendency to cram for it (late minute homework syndrome perhaps!).
The odd thing I've also found is that because of being my own boss, choosing to spend one more day on it seems to be really productive in getting further along. It's like the pressure of that first deadline bottles up the work and the addition of just one more day relaxes proceedings enough to take all the prep work and thoughts on the tasks at hand and just calmly go through them! It'd be nice if I could figure out how to just relax and get it done without the mad rush. |
What, it's been a week again already? Geez, time goes fast! This week, for me, meant getting some more smithy sounds into the game and testing them, as well as making a draft for a Poppyhill track. The track took a lot of time, but ended up not being fit for its intended spot in the game. This happens. There's another area that it may end up calling 'home'. But even if the draft was rejected entirely, it's crucial to realize that this is never a total loss. First of all, with every track, if you're pushing yourself to do better than the last one then you'll always be learning new skills as you go. And those skills don't cease to exist if the draft doesn't make it. But also, even small parts of a rejected draft can be used or can lead to other ideas that you'd never have come up with if you hadn't made this draft in this way.
Creativity doesn't go in a straight line. It curls, splits off into multiple directions, loops in on itself, and sometimes outright teleports elsewhere. Creativity is weird like that. For now, it's back to the drawing board. I have an idea of where to take this track from here and am currently writing short 'tests' where I experiment with groups of instruments, harmonies, and melodies, to see what sticks. This often results in very short demos of less than 20 seconds. It's just long enough to establish a vibe, and to see if it fits. It's an effective way to 'fail faster' (as Extra Credits once put it). That's a problem I ran into with my first draft: The vibe I wanted to try for that draft was so complex that I couldn't really make a simple version of it. I had to build the entire track to really see if it'd work.
Some ideas are like that; you can't reduce them to a 'core' because the entire thing in its full complexity is un-reduceable. You can't have a stargate scene at the end of 2001: A Space Odyssey without pulling out all the stops on the visuals. It can't be reduced. Luckily, that's not always the case, and I'm now back to some rapid prototyping. Wish me luck! |
Tuesday, 8am. There I was, sleeping quietly (I assume) in bed (I also assume - who knows what I do in the middle of the night). When all of a sudden...
ALARMS! ALARMS EVERYWHERE!
These were my building's alarms, coming from flush speakers within the ceilings. These were the worst kind of alarms. The kind with no snooze buttons. The kind that had bright flashing lights. The kind that could mean only one thing...
Fire.
Which was my first thought when getting woken up frantically at 8am. My instinct, aside from getting dressed, was to run to my desk and grab my computer and all my hard drives. Most people concern themselves with saving valuables like memories or pets or children. Me? I concern myself with saving the years and years worth of projects I've worked on.
But there's another possible meaning to these alarms that soon became clear. That these were, in fact, fire alarm tests. Which is what we were soon told as a voice crackled over the speakers. Upon checking my email, it seemed that my building was due for testing all alarms to make sure everything was up to code and to fix anything that wasn't. This would start daily at 8am and continue into the evening...for the next three days.
Lovely.
Downtown LA takes its fire safety precautions very seriously. Which makes sense, all said. But suffice it to say, it was a challenge staying productive this last week. What's more is that the building's water even got shut off on Wednesday. As I told Neal earlier this week, I felt like I was staying in some dystopian complex where alarms kept going off and strange voices kept talking over speakers and there was no running water. I half expected Judge Dredd to come rescue me at any moment.
The work that I did manage to get done was primarily to sort out a lot of organization. During busy times like earlier this month, things tend to get cluttered, ranging from project files to databases to support correspondence. So I've been doing some Spring cleaning while Spring was still in the air. I've also begun work on an extensive FAQ for the site and community. Not particularly glamorous work this week, but important work nonetheless.
I'm looking forward to next week being much more normal without any strange dystopiotic distractions. Because thankfully, as of Friday, peace and justice has been restored to my building. No doubt thanks to Judge Dredd, I assume. |
PUBLISHED BYᅠP I X E L C O U N TᅠS T U D I O SᅠLIMITEDᅠᅠ ᅠ
P R I N T E DᅠA TᅠP I X E L C O U N TᅠC A S T L E,ᅠT H EᅠV A L E
Copyright 2018 by PixelCount Studios (Limited).ᅠᅠAll rights reserved.ᅠᅠEdited and assembled by Matt Allen.
