lgwebaltctrlcwj

[lgwebaltctrlcwj]

Evaluation

For this project, I only did the technical side of it and focused on the coding while someone else worked on the art for the game. I think that this helped me to achieve a more functional game as I was able to put more time into ironing out the problems that came up and also be able to add in additional things that would elevate the game. There were a few things that I had to look up in order to implement, such as a screen shake, the dialogue appearing letter by letter, and adding images to buttons in widgets. This, however, didn’t help much as none of the tutorials for any of these things worked for me and I had to ask for in person help for the majority of these things. The screen shake was soon a scrapped concept after a long time of revisiting it and trying to get it to work, thankfully it wasn’t amazingly important to the game as a whole and was only one part of a visual effect at a specific point in the game, so the whole thing doesn’t suffer without it but it is still annoying that it was unable to work as I had also tried this in a project last year and had no success either. I think that I met the expectation of figuring out how to code new things within the project, one such example is the selection screens which I had originally managed to get working with arrow keys and I was really proud that I was able to do that. Something that went better than I had expected was the phone, I went in with the expectation that we wouldn’t be able to figure out how it worked and use that, and instead have to use additional wires on the exterior in order to have something functional, the phone itself essentially being nothing more than a glorified box for stripped back buttons. We were able to figure out how the mechanism inside the phone worked, and use it to control a game which I think is something that I will be proud of for the rest of my life at this point.

Most of the ideas for the concept of the project were created verbally after college had finished before the half term and were written down as short notes by Josie. The initial idea discussion took about an hour and a lot of the decisions for the premise of the project were all run under the same question of ‘Would this be funny?’ with a few being run through the question of ‘Would this make things more difficult for the player?’. We had originally intended for the game to intentionally screw the player over, and a fair bit of that mentality still remains, but that is another one of those things that has to be done right otherwise it would be infuriating to experience. There is a fine line between being given too much information and not being given enough and I think we lean too much on one side despite it being intentional in some areas. The dialogue required a lengthy discussion nearer the beginning of the project with a lot of back and forth and alterations to the exchange before it was given the go ahead to be written out near the top of the script document. By the end of the project, the dialogue became less thought through and had less back and forth and was created more of a basis of writing something out, replacing parts to make them either better or funnier, and then agreeing to use it. I don’t know about others, but I personally find the least thought out parts of the dialogue to be funnier, the funniest being created when we weren’t actively making up the dialogue. Most of the problems I came across during the project were often silly mistakes that barely took a second to fix when found, the issue was with finding them. Sometimes it was branches being linked to other things wrong, the occasional tag not being typed in, the player falling into the void because of a missing floor, or remnants of older code affecting newer things by not being changed to align with new controls. It often took a bit of time to realise these issues, but that was the hardest part about solving them. Nothing was breaking the game consistently like what happened in previous projects, so it was pleasantly surprising to not have things break on me.

While I think that I met most of the requirements in the project to an okay standard at least, and there are individual parts of the project that I am really proud of like all the selection options and the code for the dialogue and the rotary phone, I am not happy with the project as a whole. Normally I tend to have a dislike of projects I work on towards the end of the time limit, this time is no different. Logically speaking I did a good job with the code and with the phone and I should be happy with the game as a whole, but I am not. I am, however,  proud of the controller and specific parts of the game or code, just not the thing as a whole. I understand that I think the dialogue could be better if there was more time, and the game would look more finished with more time, but I don’t think that warrants the overall dislike for the game. I can point out individual reasons on why I wouldn’t be too happy with the project, but I don’t entirely know why I wish to not work on it anymore. The dislike towards the game also seemed to come suddenly towards the end of the project and other times dies out altogether, which is probably making it both more frustrating and confusing, there was a possibility to finish and polish the game in the next project but I simply wish to not work on it anymore, and I think that is slightly selfish of me when working on a joint project. Logically speaking, I think that the outcome came out well on my end despite the missing components that weren’t able to be added in or were continuously pushed back in favour of adding other things. From an emotional standpoint, I am not overly happy with it but I wouldn’t be able to describe why.

Something that I had known prior to this project was that humour does not work in media if it is forced, and even if it isn’t it is still a risky thing to attempt as comedy is very much subjective, what is funny to us is potentially not funny to others. We still tried it anyways, but it was a good learning experience in terms of how comedy works in different settings, and how it should be done in different ways depending on how the things surrounding it are structured. I think the dialogue could have been improved if more people were involved in the process of making it in order to get a selection of dialogue options that are humorous at least a little bit to the majority. I don’t often follow the time plans closely because I am very easily sidetracked by other things within the project so I don’t always do what I set out to do, also it is almost impossible to predict how long things are going to take ahead of time. I think if I try a bit harder to plan things ahead of time then maybe the time issues I frequently run into could be solved, although saying that, I did make an effort to plan ahead this project and make lists at the start of the day of what I should do during that time, but some parts required collaboration which wasn’t possible in some cases. In terms of ideas we had to have it on hold for two weeks due to the America trip, so there were times in the project where I was a bit lost on what I should be doing because I didn’t want to make creative decisions by myself in case that contradicted anything Josie wanted to do as it wasn’t always possible to communicate. If we were to work together in the future we wouldn’t run into this problem, and that gap in idea making is our own fault as we were aware of that before we decided to collaborate. I think next time I will work by myself again and stick to the silly little characters I tend to make and make something leaning more towards a fantasy world with less real life situations.

[lgwebaltctrlcwj]

Left Out Things

There were a few things that were left out in the end result in the game either due to time issues or from being sidetracked by other things within the project. For one, the NPCs were not added into the game despite one of them being completed with different reactions for the situation. Between a battle between the NPC and the dialogue, the dialogue was always deemed more important and became a focus quite a lot of the time. 

Another thing that was left out was a screen shake that occurred when the player was sick. I had tried multiple times throughout the project to follow tutorials in order to try and add it into the game, as well as trying to wing it multiple times to try and figure it out, but it never worked and was becoming increasingly frustrating to attempt, so near the end of the project it was agreed upon to scrap that idea altogether in order to focus on other things.

The names in the text boxes were never done, it was something that we were going to get run through but due to time and other things being of more importance, it got pushed back until there was no more time for it. In hindsight I could have tried researching how to do it, but other things fought for priority and won, the main culprits being the controls/inputs and the dialogue.

Conclusions were a late addition to the game after one of the airport scenarios were created. There is one in the game, and others exist in writing, but not for every scenario and I myself made the decision to not pursue adding anymore in as I would have rather had one in and working as a concept rather than only half being done or some of them being faulty or unfinished with little opportunity to fix it.

[lgwebaltctrlcwj]

Reworking the Buttons and Endings

Originally the buttons on the menu were only able to be selected by being clicked on, this didn’t work when one of the inputs on the phone forced the mouse to always move down (also it should have been assigned an input in relation to the phone anyways). I numbered each of the levels from one to three, making animations in the menu widget that indicated which of the levels was currently selected. There is a variable that is an integer, it works the same as the other selection variables where is gets assigned a different number depending on what was pressed or dialled, as well as that, the appropriate animation plays so the player can see what level is highlighted. When the third one is highlighted, the background also changes to an animated zombie apocalypse scene of the same setting, but this can only happen when the zombie apocalypse is unlocked from the funeral, otherwise the level remains locked.

Just so the game had an ending to it, I made a widget that appears once all scenarios are completed (minus the zombie apocalypse if it is still locked after the other two are done). The screen says that the game is finished and showcases how much ‘social skills’ you had left after each scenario. The screen then prompts you to restart the game by pressing or dialling zero. For some reason, the screen doesn’t appear every single time the game is finished, but the reset button still works, so to partially combat this problem, I put a small note on the menu screen that tells the player to reset the game if the screen doesn’t come up, because they are able to it is just that the prompt to do so doesn’t appear.

I also created a death screen that appears after the Ill during the Zombie Apocalypse scenario where the player is shot after being mistaken for a zombie. The screen fades in and then tells the player that they have died, saying that the game is being reset to the beginning so the player has to try the whole thing again. Because of this reset, I also added a fade in to the beginning of the game so that transition is more seamless rather than abrupt. 

[lgwebaltctrlcwj]

Conclusion & Definition

Some scenarios required more explanation, or simply we wanted to add more information. While not throughout the game, it would have been if there was time and it was a priority. These further explanations were done in two ways, a conclusion and a definition. The definition (above) was to explain the thought behind the phobias listed in the Airport Fearful dialogue. It gave a brief definition of two real life phobias, Aerophobia (fear of flying) and Valitsaphobia (fear of suitcases) and also said that Aerovalitsaphobia is the fear of flying suitcases which it isn’t as such a thing does not yet exist. The player mentions Aerovalitsaphobia, and not everyone would immediately be able to tell what that is even with the suitcases starting to levitate later on. The definition is an animated widget that starts off screen to the right and slides on for about eight seconds before sliding off again like a pop up, the box was made by Josie and the writing was typed in the widget using a font from DaFont.

The conclusion was to add in events after the scenario that would have dragged the levels on for too long otherwise. The only conclusion exists at the end of the Airport Sad scenario, explaining that the player is getting charged with assault, but the charges will potentially be dropped due to the security guard the player hugged too much to be concerned with the fact that they are upset about limbless snakes and they are generally worried about their mental health. The conclusion is a widget that appears after the scenario through the screen fading to black and a box appearing on top. The text is bound to the same data table with the dialogue, where a row has been added at the bottom for the conclusion. It was down that way so that the conclusion widget could be used relatively easily if more conclusions were to be added. The text fades to let the words on it change seamlessly before it reappears. There are conclusions written for the scenarios written after this point by Josie, but none of them will be added due to time concerns and it is better to keep one in as a concept rather then half having them and half not.

[lgwebaltctrlcwj]

An Airport For Aliens Currently Run By Dogs

An Airport For Aliens Currently Run By Dogs, or Dog Airport Game for short, is an open world game with stock photo dogs in an other worldly airport that had a similar style to Jazzpunk in terms of the random humour and less detailed models. The game allows the player to explore the environments that they are in and go around collecting various items from different shops or converse with the variety of dogs scattered around that all have their own interesting and sometimes questionable personalities. Everything about the game is strange and the characters are odd, but enough is explained about everything so that things make sense while still being amusingly weird. The game does a great job at not making the player confused while still having absurd interactions occur, furthermore the characters are all lovable and interesting to talk to.

I wish I knew of this game earlier on in the project so that I could use it more as a reference for the dialogue, it is the kind of weird and funny that I aspire to put into games, but I will definitely pick this game apart more in future projects and already plan to do so for the next one. The project so far helped me further realise that I much prefer to stick to making silly little non-human characters that are a bit strange, which was an idea that was more solidified by trying something new. I think the more strange settings within the game help add to accepting the strange situation rather than trying to have weird interactions happen within a realistic situation. Another good thing about the game is how likeable the dogs are despite being just stock images, they feel like they have personalities and the player is the same in that regard. In terms of being characters with even the slightest form of depth, the project doesn’t really have that, as we never sat dwn and discussed the traits of the characters or their general personality. The player interacts with someone who isn’t all too consistent and doesn’t have many motives in life or any form of solidified and consistent personality which makes it hard to make them too likeable or able to get attached to. This is something I hope to improve on in the future most definitely.

[lgwebaltctrlcwj]

Sounds

Sounds effects would help the interactions seem less awkward (although saying that it may have been a bit funny to have the entire game have nothing but cricket noises in the background) as well as potentially adding some comedic value to the questionably comedic scenarios. I spent time looking for sounds on freesound.org and then I used Adobe Audition in order to edit the audio to my liking. For the hiccuping it involved editing out some of the hiccups that sounded weird and amplifying the quieter ones to match the volume of the louder ones. For other sounds it involved adding in more silence at the beginning of the clip in order for the sound to be delayed in the game without delaying other parts of the code. On the sound of the plane used for the transition to the airport scenario, I added a fade in the beginning and the end so that it was smooth like the transition instead of starting and stopping abruptly. All of these things are very basic and I am in no means a sound designer, but it works for what sounds there are in the game. Previous experience with video editing helps make messing with sounds a bit easier.

[lgwebaltctrlcwj]

Score

I decided to add a score into the game that was called ‘Social Skills’ that started out as 100% and decreased over the course of the game. This would add more of a consequence to the game and be affected differently by the different outcomes of each scenario. If the bar reached zero then the player would lose. This idea wasn’t fully ran by Josie as she is currently in America, so there is a chance that this will be removed entirely if it doesn’t fit right.  I decided to have the bar’s decrease look smooth rather than abruptly dropping, so there are two different variables, one for the actual number, and the other for what is displayed on the screen. When the player finishes a scenario, the actual number has a value taken away from it depending on the severity of the situation. Then the display number has an awkward number taken away from it repeatedly until it reaches the actual number or below, in which it is set to be the same. The display float is bound to an orange progress bar which is in a widget of it’s own and only appears during levels.

[lgwebaltctrlcwj]

Rotary Phone Controller Pt. 2

After spending a few hours gluing wires onto the dial of the rotary phone, we figured out how the phone itself worked after connecting new wires to existing wires which were connected to a light on a Makey Makey. As it turns out, a rotary phone gives off a constant signal, and said signal gets interrupted when the phone is dialled. Not only this, but the signal gets interrupted as many times as the number dialled. This means that if the phone is connected to a Makey Makey and then connected to a computer with the input of say a W, then all we would have to do is have it to that on release of that key, the number of interruptions are counted and then compared to something. So that’s exactly what was done. On the bottom of the screenshot above is what counts the interruptions. W is constantly pressed, when it is released, an integer variable goes up by one, if it is interrupted repeatedly, then the number increases repeatedly. After and interval of a few seconds, that number gets reset back to zero.

Before that number gets reset to zero, however, it is set into another variable in order to be used in the code above it, which compares the number received from the interruptions to ten numbers (one through to ten) and then depending on the number it ends up being, fires off different custom events that correlate to those numbers. After a few seconds, that second number is also reset to zero. We also found out that the prongs that the handheld part of the phone rest on also interrupts the circuit, so it could potentially be used to quit out of the game, essentially forcing the player to keep a hold of the phone (unless they set it on the table, there really wouldn’t be anything stopping them from doing that).

[lgwebaltctrlcwj]

ASDF-Movie

I intended for the game to be funny in a similar sort of way to ASDF Movie in terms of it’s randomness and also potentially reference some of the jokes. In the end I decided to not outright reference some of the jokes because we didn’t know how many people would get said references, but some stuff remained, mainly the puking rainbows part which Josie seems to find incredibly funny apparently.

Looking between the current dialogue of the game and the jokes in specifically ASDF movie 1 there are somewhat noticeable similarities between them which weren’t originally intended but were inevitably rolled with. The thing about ASDF movie however is that it’s a lot older and a lot more iconic so it’s more likely to be found funny because a lot of people grew up watching it. Having similar attempted humour in something more recent is less likely to work although not impossible, not to mention comedy in general is a difficult thing to do when actively trying too hard to achieve it. The project may be found funny by the majority, or maybe found funny by few people, it’s hard to gauge how it will be received without quizzing many people about it, but no two people are the same.

[lgwebaltctrlcwj]

Dialogue

Above is how the right dialogue is displayed for different scenarios. When an input is given, the code checks which scenarios the player is in and then checks which emotion is currently assigned to that number (aka which emotion has been taken out of the situation). All of the collapsed nodes in the middle look the same (see below) except with a different row of the datable selected and different tags dictating the situation, same goes for the collapsed nodes on the far right.

Originally I was going to add the dialogue in using flip books because I didn’t know any actual way of doing it (and I used flip books to make speech bubbles in my last project). Turns out you can use spreadsheets converted into CSVs to put things like dialogue in in order to pull information from. If a spreadsheet is exported as a CSV file then it can be imported into unreal engine as a datatable and can be used to pull information from when paired with a struct telling it which variable type it is, in this case it is a string. Below is what the code looks like in the middle collapsed nodes shown above. The code checks to make sure that it hasn’t already run through the scenario with any of the options, and then checks to see if it is currently running the current scenario, if not then it is given a tag to say that it is so that no other versions of that scenario can start. A specific row of dialogue is pulled from the datable and then set as the whole text to be displayed, the number of the column going up in increments of one so that the next button press displays the next line of dialogue. When the retrieved dialogue runs up empty then the dialogue is done, and a tag is added to show that and prevent any further interaction.

When the text appears in the dialogue box, it is animated to appear letter by letter (yet another thing I did in a previous project in am overly long winded way because I didn’t yet know the correct way to add it in, previously I did it in widget animations by changing the opacities of frame by frame images of the text box which is a great what to lose sanity). The whole text variable in the image above is pulled from a widget with the text box in in order to update it. This is a bind to a text box in the widget that constantly updates, an integer is created that is equal to zero that correlates to the end letter in the string. Every time the length of the string increases, the end number variable goes up by one until the whole string is displayed, the increasing string in question is set to a string variable called display text which is how the text looks like it is appearing letter by letter. It works in a similar way to an animated bar moving up or down.

[lgwebaltctrlcwj]

Colour Selection

Originally I had made the colour selection using the four arrow keys, but that was changed to be using the number keys instead after the idea for the rotary phone came into fruition. The way the arrow keys worked was by having each input check which number was already selected, and then setting it to a different number accordingly, so if three was selected and the down arrow was pressed, then the number would be set to seven. When numbers were used instead, then the code was changed to set the number of the selection to whatever the number that was pressed was. When on the selection screen for different scenarios, the player has different tags, so every time the player presses or dials a number, it checks to see where they are, and then changes the correct number as there are different selection numbers for the different scenarios.

That number is then sent to the blueprint for the specific grid to the scenario chosen, The grid is a sprite within a widget and there are different sprites that it switches between that have the different cells of the grid highlighted depending on what the number is. On an event tick, that number is checked and then the sprite switches accordingly. The switch is prefaced by a ‘Do Once’ that is reset by the other numbers being pressed so that it isn’t infinitely switching to the same sprite.

When the player presses nine or dials it, it selects whatever number is highlighted which will then give the player a tag that is constantly being searched for by the specific load outs of the specific scenarios. The tag determines the layout of the colours in the top left corner of the screen in the levels and will then determine what number correlates to what colour for any given scenario. All the colours change sprites depending on the selection number, although the coloured circles on the two by eight grids are actually flipbooks, there is no real reason behind it besides me simply forgetting that sprites can be changed initially.

The grid and load out where made to be physical sprites in the world rather than widgets as I thought that they would be easier to control that way, again, I know that there are ways to do it either way but at the time I thought it would be easier to do it this way as it meant battling widgets as little as possible. The reason that a selection screen is in the game in the first place is that apparently a choice of five emotions in a four emotion scenario was wanted. The selection removes an emotion instead of selecting four mainly for simplicity sake, but also to be a bit misleading. There’s a higher chance of the player choosing the one they wanted to play and accidentally removing it the first time around. Also just a small note about colour theory, the grey in the one and the three and six above are the same, but the surrounding colours make them seem different. Doesn’t add anything to this post just that colour theory is weird. 

[lgwebaltctrlcwj]

Project Proposal

For this project I plan to focus entirely on the coding aspect of game making as I am collaborating with Josie on the same project. We are splitting the work between us so that she is working on all the visual parts of the game, and I am focussing on the technical parts of the game. This will be a good opportunity to work on improving my skills at coding and problem solving. For the game there is intended to be buttons on the screen which I haven't worked with before, and after some discussion there is intended to be some features which I have not yet learned how to do such as camera shaking so the project will be a good learning experience for me. Another target of this project is to work on my teamwork skills as that is something that I have struggled with in the past. I tend to prefer having complete creative control over a project which isn't something that will bode well in a workplace so this is a good opportunity to change that. I realise that working with a friend is probably a different experience than working with someone I am less familiar with, but it is still a good way to get better with working in a team.

The premise of the game is the player being put into various social situations and having to navigate them in an appropriate matter via a selection of different emotions. The catch is that the player has the worst possible emotions for any given situation. Said situations would be things like ordering something from somewhere, maybe a job interview, a funeral or wedding or something similar. The player is almost always doomed to fail, but some options will make them fail harder than others. There could potentially be voice acting if we find the time and resources to do so, and most choices made are made with humour in mind, although comedy is difficult to pull of and subjective, so whether it is considers funny to most will be a gamble. In terms of the controller, the original idea that was within the realms of possibility was something mouse based like a trackpad, drawing pad or slider of some sorts, the second idea was buttons, but both ideas lacked a lot of creativity and could be better. The best idea and the one being followed through with is using a rotary phone and assigning the numbers to inputs somehow, most likely via additional wires exposed to complete a circuit or by using the existing mechanism somehow. Another idea added onto that is having the hand held part acting as headphones with parts of an old pair of headphones used to work if the origin speaker in the phone does not or cannot be used.

[lgwebaltctrlcwj]

Rotary Phone Controller

We settled on using a rotary phone as the controller for the game as it was at least somewhat relevant to the game we were creating which was centred around social interaction, but the main reason that this was chosen as the basis for the controller was because it would have been a really cool concept if done correctly, as well as getting the opportunity to take apart and older piece of technology to see it’s inner workings which is always a really interesting thing to do. Saying that, the first time around didn’t yield much information on how it worked, but there was still an idea on how to use it as a controller. If wires were attached to the individual numbers and a grounding wire was attached to the metal stopper(?) at the bottom then the player could complete a circuit using themselves as a connecting wire. If the player touched a wire and then dialled the phone so that they touched the metal at the bottom at the same time, then the circuit would be complete and that specific wire would are off and would act similar to a button input, so the whole thing was similar to a long winded way of pressing the number keys (the game can be played with number keys as well, for testing purposes it was sort of necessary to know the code worked so that the phone could be tested correctly).

Hot glue was used to connect the wires to the underside of the clear plastic dial. There were times where it was a struggle to fit the wires in without the mechanism catching on something when it turned to prevent it from revolving for a millisecond. This was resolved partially by trying to shift the wires around. but it was difficult to make much of a difference with it without pulling out the wires and redoing it, the trouble with this is that wires were often connected to other wires, so trying to take out one would have likely resulted in taking out all of them in order to redo them and I didn’t want to use too much glue but they would all have to be taken out later anyways which I will explain later. An issue I found while testing the phone was that it was a safety hazard. There was a point where I was dialling the numbers faster than I should have been, and I didn’t realise that I had sliced my finger until it was sliced multiple times and then stung like hell. Luckily it didn’t draw blood, but it was safe to say that if the wires weren’t removed altogether then some measure would have to be added in order to make sure that injuries didn’t occur.

[lgwebaltctrlcwj]

Transitions

As mentioned previously, I added transitions that play when the player is transported from one location to another to make that shift smoother rather than abruptly having the scene change. All the transitions are in a single widget except for the second half of transitioning back to the menu which is in the menu itself because its a widgets going into another widget and widgets layer on top of each other and I am currently unaware of a means to change that if there is any. Above is a longer version of the code that was shown in a previous progression post that showcases the widgets appearing on screen and the appropriate title card moves across the screen, slowing down in the middle so that it can be read by the player. The transitions appear on the screen in order to hide other widgets disappearing which can be seen above, it is delayed by a few seconds because the transitions fade in and they take a few seconds to become fully opaque and hide the screen. The idea is for these transitions to have sounds accompanying them that relate to the scenario, so something like a plane taking off for the airport and something like crying for the funeral and so on and so forth. All the transitions are the same except the one going back to the menu which just fades to black instead of having a card fly across the screen.

[lgwebaltctrlcwj]

Progress

Once again saying that none of the artwork showcased in these posts are mine, all artwork is done by Josie, I am doing the coding and general placement of things. Above if the layout of the buttons which I was able to get working, it was a lot simpler than what is said online where I followed two overly complicated tutorials to no success. Online tutorials went on about putting various components in a widget and compiling them together and then referencing those widgets into other widgets which didn’t work for me. After I asked about this issue it turns out the solution was much simpler than what an tutorial said, which was binding an image to the button which only took about two clicks from a mouse, and the same could be done for when the button is hovered over or clicked so that there is a visual indication for those events besides the mouse. When a button is pressed, it gives the player a tag that is checked through an event tick and the player is then sent to the place with the corresponding tag, so the ‘dead’ tag would send them to the funeral, the ‘zombie’ tag would send them to the apocalypse and so on. We had originally planned out about six different scenarios, but due to possible time constraints, we narrowed that down to three; a funeral, airport security, and a zombie apocalypse.

Above is the start of the transitions that were created to smoothly move from one area to another, I will explain them in more detail in a different blog post, this is just to reference that they were worked on at around this time in the project with the buttons and teleportation and general basic functions of the game.

Below is the funeral background which I received from Josie and added into the game as a sprite against the wall. I ended up having the backdrop be a sprite that the player looks at rather than a widget as I thought that that would be the better option, but in all honesty I am not sure if it changes much in the grand scheme of things besides that widgets decide to hate me quite frequently and I figured that this would be a safer option with a less likely chance of angering the UE widgets demons. In the top left corner is a back button so that the player can exit a scenario for whatever reason, like the buttons on the start menu, pressing the X button will give the player a tag that is checked through the same tick as the others and will send the player back to the menu if they have the menu tag.

Below is an example of code from the event tick that checks through where the player should sent at any given moment. If the player has a specific tag then a transition widget is added to the screen, the relevant animation playing while the start menu widget is taken off of the screen when the transition widget is fully opaque before fading away and revealing wherever the player is supposed to be. There is a tag that says ‘mouse’ at the end that is removed, there is another one that is added in the button code, although I don’t think it worked all too well, and there is now code elsewhere that checks if the cursor is visible with every mouse click and makes it visible if it isn’t, the tag system was simply never removed as it never interfered.

[lgwebaltctrlcwj]

Crows Crows Crows

Crows Crows Crows are a game developing studio in Berlin who are likely known the best for making Stanley Parable: Ultra Deluxe, and while the game is a strange experience in and of itself, they have created other weird and wonderful games and interactive experiences. One such example is The Temple Of No, which is a free experience created with Twine and published on Itch.io. The wording and the general ‘personality’ of the narrator in both of theses games is something I would like to draw inspiration from when creating dialogue or narration in games. Crows Crows Crows are really good at making text blocks like this interesting and funny to read (bonus points that you can mess with the narrator in both experiences which is always fun). 

Crows Crows Crows was created in 2015 by William Pugh after the first Stanley Parable game was created, their first game was Dr. Langeskov, The Tiger, And The Terribly Cursed Emerald: A Whirlwind Heist, in which the player goes through the backstage behind the scenes of a game which they are waiting to play, because somebody else is already playing it. At various points they help the game to run smoothly for whoever is playing it, by triggering events to happen from behind the scenes. You can also mess with the disembodied voice in this game as well (I am sensing a theme here), the example that comes to mind is the image below where you can press the buttons you were not told to press on the right, and everything about the situation gets worse.

Both the style of the games made and the general ideas and dialogue are something I aim to achieve with my projects both present and future. I really like games where they are a bit strange and involve interesting characters who are weird in some way or another, and it’s definitely the types of games that I enjoy making the most (at least out of what I have made so far).

[lgwebaltctrlcwj]

MoSCoW

Must Have: A selection of buttons on screen, working dialogue, a way of selecting a level, a way of going back to the main menu, a main menu.

Should Have: Sounds appearing at specific lines of dialogue, background noise, a score system, low chance alternatives to choices, locked levels or options.

Could Have: ‘Coffee mode’ where everything goes fast, voice acting, background music, the second round of dialogue, said second round of dialogue being influenced by the first round.

Won’t Have: Anything 3D, movement of the character, a visible player character.