Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411273 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 02:02:38 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsAnn Achronist - a time-travelling narrative adventure game
Pages: 1 [2]
Print
Author Topic: Ann Achronist - a time-travelling narrative adventure game  (Read 5151 times)
MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #20 on: September 15, 2018, 04:10:43 PM »

Beautiful Nightmare

This week I had an important realisation. I’ve been working so hard on making the menu and ending look amazing, commissioning art for the purpose and tweaking tweens to within an inch of their life to get them perfect, that I didn’t even account for the fact that players are going to be spending 90% of their time spent on this game on the actual game scene, not the menus. If the menu and endings are going to be so gorgeous, the least I can do is give the main game the same treatment.

I will be the first to admit that my eye for visuals has a very high tolerance, which isn’t great when it comes to making an application that looks not just easy on the eye, but breathtakingly beautiful. The minutae that go into the adjustments that make a button go from flat to tangibly tactile can make a huge difference. So I’ve been spending some time thinking of ways I can augment the simple pixel graphics I have in the game to take it to the next level.

Although I was very happy with my dialogue UI design, my brother — who is somewhat of a UI expert — gave me some pointers on how to make it better. Moving the picture to the left gave it more immediacy, and the name tag still stays in a prominent position before the text.





I finally got around to properly re-designing the response UI. I had originally planned for the responses to be right-aligned to match a text conversation layout, but in practice the elements were so far apart there was such a disconnect that sometimes it wasn’t even clear that any options had popped up — especially if it was just one response at the bottom of the screen. The new design is in keeping with the rest of the dialogue. I’m slightly concerned that one or two interactions will have too many responses (such as when browsing the market stall), but I’ll cross that bridge when I get to it.



A tiny but impactful change: I added drop shadows to the dialogue UI elements. Subtle, but smooth — the best I could hope for, really! I do need to experiment with better hover options, but this is fine as is for now.

An obvious candidate for a makeover was the water in Alderdale. This was my first experience creating my own particle systems but I was blown away with how quickly you could get results. At first I experimented with a shimmery sprite I have, but in practice it looked muddy and unnatural. I instead settled for a much smaller thin line that shrinks and grows. I would like to add a particle to the cliff edge too, but I will need to do more research before I tackle that one.





You might have also notice that Ann and her companions have shadows, too. The shadows shift as the sun rises and sets, until nightfall where the shadow completely disappears as the scene grows darker. I’ve also been playing with fireflies, fog, and solar flares, but I haven’t made much progress on those fronts yet.

My plan is to spend the rest of this week working on beautifying the game, then pulling my sleeves up and re-tiling the entirety of the Alderdale overworld. I have a few problems with its current layout, as it’s too big and looks incredibly contrived, and what’s more I’ve used a mix of tilesets whose palettes completely clash. I’ll pare the map back a little and see which tiles best suit my needs, then stick in there and start ripping apart terrain.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #21 on: September 24, 2018, 05:09:57 AM »

Pipeline Snapping at my Heels

I’ve been working on a variety of tasks this week. I’ve been trying to avoid ‘cross-contaminating’ days — if I’m going to work on sprites, I should spend the whole day working on them. If I’m going to work on code, I should spend the whole day programming. Although it’s not always ideal, it’s been a good way to lay out this week where I’ve had to perform very different tasks each day.


Playing with shaders!

I’m having to really sharpen the focus on my productivity lately. I spent 2–3 days learning about shaders in preparation for prettying up the game, but after I’d done so it dawned upon me that October is drawing ever closer, and that’s the date I’d set for being able to get the game into testers’ hands. The game has already gone 1.5 years of development without any testing, so I really need to push this MVP out of the door ASAP. I think there was some merit to exploring what visual effects I could add, since I should move forward with those graphical enhancements in mind, but realistically even if the game looks like a steaming pile of stew, the testers’ job is not to worry about the aesthetics for now.


Not quite what I was going for...

Additionally, I have to be wary of the development pipeline. The writer has been waiting on my updates to the macros inside the excel document before she can continue, and the artist is ready for the next illustration commission which isn’t quite ready yet. I remember when I first starting indie game development, I used to rejoice that I could work on whatever I wanted that day. Strangely enough, this week has been quite the opposite!

So, in order to build towards an MVP, I’m working on implementing Selma, the witch character, into the game in her entirety. Her responses will update based on dialogue options and conditional environmental factors. I’ve been umming and ahhing about how to do this for a while, but I think I’ve finally come to a solution so I need to start implementing them now, since she is but one of 30 characters who need sewing together.

I’m also planning a full overworld map rework — I was initially happy with my designs for the town of Aldertale, but in practice it’s much too large and spread out and, if I’m going to be brutally honest, ugly. I’m working on condensing my tile palette to make the town look more consistent. I’m quite happy with the changes so far, but dynamic shadows on the buildings is proving harder than I thought. Again, that’s not a concern for today. The reason the town layout is important is because I have to code NPC movement throughout the town over the course of the day, and if I change the overworld that’s going to screw up all my pathing. Selma doesn’t move throughout the day, so she’s an easy first NPC to code.


A screenshot of the new buildings, put together in Tiled (free open-source software).

On top of that, I also spent a fair amount of free time perusing YouTube for game dev talks. I had about 5 that I’d pre-loaded and meant to watch a while back, so I finally found the time to sit down and watch them. The one I found most interesting was

. Schell’s A Book of Lenses was the first game design book I ever read and I fell in love with it, so I was super hyped to see a talk from the guy. Although the editing on the video is choppy and sloppy, I think it’s worth sitting through it just for the presentation itself.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #22 on: September 29, 2018, 07:18:28 AM »

City Under Construction

So the long-awaited rearrangement of Alderdale is finally here! It’s important to get this step perfect before I start coding character movement, as my current NPC movement system works on a timed system. The timing of every element of Ann Achronist has to be perfectly synchronized — any characters bumping into each other in the street need to both be at their place on time, and I thought it much easier to plan these movements based off time rather than a list of movements calculated by movement speed. So it cannot be avoided — remapping must be done now.

But why do I want to re-do Alderdale? There are a few reasons. First of all, the town just doesn’t look nice. The tilesets are iffy, they’re mismatched, some are missing parts (it’s like an 80-piece jigsaw with 76 pieces), and a lot of them are just not the right quality for the game. I started mapping Alderdale before I’d perused 100s of tilesets, and now I’ve find a few really nice ones I have a much bigger palette to choose from — from the get go.


Alderdale? More like Olderdale!

I also wanted Alderdale to feel more believable. In its current state, it is full of extremely harsh straight lines that border houses, rivers, cliff edges. The real world is not a series of geometric squares and rectangles. I want to break up the lines to add some character to the world and prevent it looking contrived and artificial.

Alderdale is just so, so spread out! It wouldn’t be wildly out-of-the-box to imagine a rural town having a lot of space between buildings, but my personal mission statement as a designer is to always put the player first. I don’t wanna spend half my playthrough tirelessly running up and down town! Holding the right key is not gameplay, folks, and by trimming the fat I can amp up the action in the game. I might have to speed the clock up now, since players don’t spend much time moving and mostly chatting (when time is paused), and I’m not sure how players will feel about a clock that ticks at double speed, but I’ll cross that bridge when I get to it (i.e. when the testers get their hands on it). I am slightly concerned about the visible lack of buildings in the town — a bakery, a cathedral, a castle, a farm and an inn — and could potentially add some random houses, but I wanted every location in the game to mean something. If it’s a house, it should be someone’s house, and there currently aren’t any NPCs without homes. If this changes, I’ll consider it.

Furthermore, the way I tiled in the past wasn’t very efficient. I was just getting used to the basics of tilemaps in Unity and didn’t want to overcomplicate the process. I’ve since installed the 2d-extras pack that Unity provides to add ‘rules’ to tilemaps — terrain brushes, for example, automatically draw in corner tiles or edge tiles based on their neighbouring tiles. Now that I can actually use these tools, prototyping is tons faster — and it means I can paint nice jagged borders with ease instead of painstakingly plucking jigsaw pieces from my palette and putting each corner in individually.


The new Alderdale, with revamped castle, a moat, and a much tighter central plaza.

An added benefit to these extras is that I can switch palettes in the space of 60 seconds. By overwriting my terrain brush file, I can switch out all the grass tiles to a different tile, just like that. The grass tile must cover 500 tiles, so being able to switch them out in the time it takes the kettle to boil is fantastic for the non-committal visual designer I am!


Below the river, the witch’s house and Lover’s Lane. As you can see, I experimented with switching to a darker grass here by simply replacing a few tiles in my terrain brush.

It’s no Picasso, but I think it’s a step up from before. I’m not focusing on perfection in terms of visuals here — but I definitely want to tie down the pathing as tightly and precisely as possible to avoid any re-coding of timed NPC movements.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #23 on: October 06, 2018, 10:05:13 AM »

MVP is the MVP

October is here already! As you know, I’m planning to have my MVP ready to play for October. My current timeline should have everything but the castle content ready by around mid-October, and by the end of October the castle content should be coded too. I chose to do it this way since around 7/9 endings don’t involve the castle at all and I want testing to start ASAP.

Speaking of the endings, the artist I’m working with is just starting the final two illustrations now. We left the beginning and ending right until last since they are the most important and the ones I wanted to be perfect. After all, their first impression will be based off the first piece of art they see, and the ending is the taste that will be left in the player’s mouth at the end. I’ve been working on some promotional posters so I can start sharing news about the game in more places. I know people will enjoy the game once they play it, but it’s getting players to that point in the first place that’s the hard part.



Since MVP is the only thing on my mind right now, it’s been quite liberating. Delegating art and presentation tasks until further down the road actually feels really nice — tweaking pixels left and right until something looks perfect is not something I excel at, nor something I enjoy. It’s also probably quicker to put them all off until the end — the menu screen probably needs 2 or 3 more buttons adding to it that I haven’t even considered yet, but if I add those buttons one by one, making them look perfect each time, I’ll be wasting a lot of time in the long run.

With all this talk of art, I should probably mention that I’ve found a new piece of software to help with making assets. I have been relying on Paint.net and GIMP for the longest time now, but the more time I spend using the programs the more features I find they are missing. This week I was introduced to Figma and I’m amazed by how complete it feels! It’s basically Sketch but made for Windows, and the best part is it’s completely free! Although it is designed with web developers in mind, I consider those features a bonus, not a must-have. Try it for yourself!

[img width=593 width=260]https://i.imgur.com/Zyvsanf.png[/img]
A couple iterations of a simple ‘interactable’ icon

The current interact UI is a horrible looking, semi-transparent E keyboard icon overlay. I needed to make something with more flexible sizing that didn’t cover the entire sprite of what you were trying to interact with and looked a little more… juicy! I chose to 9-slice the new interactable icon I created in Figma for added flexibility. It has a nice, soft bouncing effect so it draws attention to itself a little more. Of course, any interactables still twinkle as they previously did. I still love that sparkle animation!



A lot of interactable objects that I’d already added to the game had a lot of inconsistencies. I took the time to create a prefab for interactables so if something needs changing in the future I’ll quickly be able to update every single object in the game. There’s gonna be a lot of them!

I also did the same for NPCs. Selma was mostly implemented as my first NPC, but I just spent some time tidying her up. Her dialogue still makes me laugh every time!



My plan is to slowly populate the world with characters. The merchant has now been added to the game, along with Matt, the street urchin. The merchant involved coding in some extra features, such as a gold display, a way to gain or lose gold through the excel script, and some minimum and maximum gold requirements for specific interactions (trying to buy something with not enough money, for example, will provoke a not so pleasant response from the merchant). I find it odd how I set out to do specific tasks and then end up finding 3 or 4 additional tasks that I have to complete in order to finish the job. Not that it’s not necessarily a bad thing, since I’ll be doing them at some point anyway. Just curious.



There was a bit of a problem with the number of items available for purchase taking up too much room. I decided to split the items into two baskets for the time being. Not a perfect solution, but it will suffice. I might run into this same problem when the player has the opportunity to give the princess a gift from their inventory, but if I do I’ll solve both problems at the same time.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #24 on: October 13, 2018, 01:10:44 PM »

Check, Check, Check

Checklists have been my entire week.

I find them motivating. There’s a lot of satisfaction in drawing the line through a completed task, and by the end of the day — even if not every task got completed — you can see that you’ve made some tangible progress that day. When you’re working on something for multiple years, it can be easy to lose sight of that.

Monday

  • Create password input box
  • Add gold to game
  • Code metCharacter permanent variable updating (in order to ask Grant)

As previously mentioned, adding a character is never as simple as setting the dialogue paths and pressing go. Thunk, our resident bandit bodyguard, requires a password for entry into the outlaws’ wooded encampment. A correct password has a different destination to an incorrect password.



Coding the shopkeeper meant coding the gold. Adding, subtracting, setting, and checking all needed to be added separately. I’m currently able to check if a variable matches exactly, but not to check inequalities among numbers. Now, I can! For gold, at least. If I need it for other variables, I will have to code them on a case-by-case basis.



As part of the innkeeper’s implementation, I had to add the ability for Ann to be able to remember all the characters she bumps into across Alderdale. Ann can ask Grant about a character for extra detail about their background, but she can only ask about someone she has met herself. Since there are 30+ characters, having to write that many functions was a bit of a nightmare. With the way I had implemented it, I was going to have to create 3 times as many functions as characters that I had. To remedy this, I employed something called ‘reflection’ which allows functions to be called by a string rather than a direct reference. It might have taken me the same amount of time to write the extra 60 functions as it did to learn and implement reflections, but my thinking was that this way I learned something new at the same time.

Tuesday

  • Enumerate items, prevent inputting errors.
  • Updating variables so pick ups/removals show in inventory.
  • Buy new things. Mice, calendar, etc.


I spent a bit more time learning about enums today. Enums are to be used for a variable that has a finite number of items, so it fits my inventory perfectly. Re-writing the current inventory implementation was a little time-consuming, but changing to enums usually prevents errors and it was also an important exercise for me to make sure that every single item is accounted for, even the frog you fish out of the fountain. I also made variable updates also update your inventory display.



The mouse that I was using had been acting up over the past couple of weeks, and this week in particular it was getting worse and worse. I spent some time this evening just buying resources that I needed: a couple of new mice (I have an ergonomic one and a normal one), some extra paper resources, whiteboard resources and a proper calendar instead of some makeshift print-outs. It seems insignificant, but making sure you have the resources you need is incredibly important for working as effectively as you can. Work smart, not hard! Wink

Wednesday

  • Put the spreadsheet online so we can both work on it.
  • Put together timeline
  • Meetup


VBA was something I learned over the course of this project. The more I’ve worked with the excel-based script, the more functionality I’ve wanted to add to the document. Something I’d intended to do was add jumps, where the start of a conversation can jump to another conversation without any options being selected in between. Sometimes the same dialogue ensues from multiple options, and wiping out duplicates reduces the bloat of the script and also makes my spreadsheet showing how many expressions I need for each character more accurate. It would have been handy to have coded this a long time ago, but now I have that functionality I can go back through the script and insert it.

I went to a dev meetup today to keep myself sane and to network. On the train there and back I tried to make a list of jobs that are still to be completed from now to the end of the project. Needless to say, I ran out of paper. It’s sobering to see how much work is still to go, but a lot of those tasks are polish. I keep chanting MVP to myself, so I’m not too concerned about bells and whistles right now.

Thursday

  • Continue editing spreadsheet. Add editing for Remedio and Alexander. Add fates for Selma.
  • Split Grant dialogue

Having implemented the metCharacter variables, Grant was getting closer to completion. It hadn’t occurred to me that the 30 characters you can ask about all needed to appear on the menu and that it would be huge. In the same vein as my shopkeeper, I tried splitting the characters into a set of groups to make them more manageable to navigate. Also, since there are so many characters, I made some extra changes to help players navigate the options. “Tom” becomes “Tom, the baker”. When asked about him, it’s Tom’s image that appears in the portrait window, not Grant who is the one talking. Hopefully the visual aide is a huge help to players with a more visual memory.

The writer is working on re-writes and edits, and I’m working on manipulating the key names and variable assignments, and so far we’ve been passing the master document back and forth but it’s not working right now. Remembering where I’ve made my changes and syncing them to the document is a huge task, so I spent the day transferring the document to a shared google doc and combing through changes. I also took the opportunity to proofread the work so far, but with there being so many lines of dialogue I didn’t finish this.

Friday

  • Speak to writer about party re-write
  • Get drunk

The writer worked on a big re-write for the party scenes. About 20% of the game takes place behind the castle doors, and we decided to re-work is due to its complicated nature and the introduction of so many characters so late into the game. We pared down the number of characters and took out some of the less-important subplots so players didn’t have to keep track of so much information. I’m really happy with the changes, but wanted to double check that all the important features and conversations remained.

The rest of the day was spent continuing to proofread the document. I’m about 2500 lines in currently. I’m unable to compile the document until I’ve fixed any inconsistencies in the script, for example if the writer accidentally moved a key leading to a corrupted empty conversation. My macro json compiler is by no means perfect, and its rules are very regimented, but I can be in charge of fixing any problems within the script — it’ll just take some time.

Finally, I attended an Oktoberfest evening with friends. Some R&R is important, too!
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #25 on: October 20, 2018, 07:11:40 PM »

Blog #{blogCount}: {title}

Last week I decided to put the spreadsheet the writer and I are working from online so that we can both edit it and both have access to the most up-to-date version of the document. As part of this I had to transfer all of the changes that I made to the technical aspects. I got half way through the transfer when I realised I would have to finish editing completely before I could ever re-compile it for use within the game. I spent most of Monday finally tidying up any last errors and syncing up variable assignments.

After that, I decided to update to C# 6.0. Updating anything scares me half to death, but I figured that updating C# wouldn’t be too dangerous — if anything, features would become deprecated instead of being removed. However, if needs must, I will — and needs most certainly musted. I needed to use string interpolation as part of the function that allows variables from within the game to be input into conversations. I planned to make some custom-coded complicated implementation for this, but my brother mentioned string interpolation in javascript and suggested I try to the find the C# equivalent. I followed these instructions to get C# updated so I’d be able to tackle custom variables in conversations.



The following day I realised updating was a waste as, after all that, string interpolation only works on string literals — and my data was stored in a variable pulled from the JSON. Fortunately, there is a way around this — I instead had to rely on string.format — but that was a feature that existed in the previous version of C# anyway. Alas! We’re now all updated. Sadly, with the update certain characters have been replaced by a question mark in a triangle (presumably the ‘unknown character’ character). I’m not quite sure how to remedy this just yet, but for the time being the testers will just have to use their imagination to fill in the blanks!



“Say {sinCount} Hail Marys.”

The number of Hail Marys to say is linked to the number of sins committed. Unlock all 16 sin achievements to nearly knock the priest off his feet!
The deeper I delve into this project the more I’m finding that adding sophisticated features to the script saves me so much work in the long run. In almost every instance of dialogue, whether or not your ancestor is by your side has some effect on what is said. It would be strange for no characters to acknowledge your little shadow, but having to create completely separate conversation keys just for one small throwaway line in the middle that refers to Matt can make a lot of extra work and add bloat to the json script. Making life easier for the writer and I makes it less of a chore to add small little changes in flavour based on specific variables — like the way the merchant greets you with a different opener depending on what ending you’re currently on. The more of those, the more immersive the experience.

“Pick her pockets.[haveMatt:true: The boy’s too.]”

If the player has Matt in tow, the bandit leader will loot the boy of his money as well as Ann. Otherwise, Ann is the only one who suffers the mugging.

“Kill [haveMatt:true:them:her]!”

I even added some extra ternary operators in there — if you have Matt, he says “Kill them!”, otherwise he says “Kill her!”. This condenses what would have to be two back to back conditional statements into one, easy to read function. Also, this actually adds a little bit of extra functionality, as it allows me to have a != condition check. Not all my statements are true or false (the timeline you are playing on, for example, has 9 possibilities), so I might want to know if I’m NOT in a certain timeline without having to write 8 back to back conditions. Gross.

I needed to make sure that any lines that were completely blank due to conditions not being met were skipped to avoid flicking through empty lines of dialogue. If an entire line is blank as a result, it skips it entirely and moves to the next line. This repeats until the conversation is over or it finds a line that has some content. I actually borrowed this from the psychic dialogue system I had already built, where non-psychic Anns had to skip through any mind-reading lines. Unfortunately, I will need to re-import all psychic dialogue now as I have changed the way conditional statements are written. I think I can do it all in one fell swoop, I just haven’t got a round to it yet. (God bless find and replace.)

Once those were both in, I added the possibility to add multiple conditions. Just in case there are multiple variables that need checking at once.

With Remedio the priest now done, it was time to focus on Alexander. Alexander greets you enthusiastically every time you enter his library — he doesn’t get many visitors, so he talks your ear off the second you walk through the door. To get this to work I had to revisit my ‘incidental conversations’ that start when you enter a trigger zone. Fortunately the code I’d already written was pretty perfect for the situation, so I just custom-coded these interactions for Alexander. And that’s the important church characters done!


“Please stop talking.”

I thought I’d figured out all my interactable prefabs already. I have characters who face you when you interact, I have unchanging interactables (such as furniture and decorations), however I don’t have item pick ups yet. As part of the librarian quest you must fetch some books for Alexander, including one from the innkeeper. Before going mad and coding a new item pickup prefab, I wanted to know that it would be worth the time. Turns out I have a couple of books, a crown, and a potion that will need to follow the same rules, and there’s always the possibility that I’m forgetting a few other items, so I figured it would be worth my time. When picked up, the physical object deletes itself from the world and appears instead in your inventory.


The book in the inn.

In other news, all the illustrations for the endings have been completed! I’m so pleased with the work and can’t wait to get them properly coded into the game alongside their stories.
Logged

QOG
Level 3
***



View Profile WWW
« Reply #26 on: October 21, 2018, 06:32:02 AM »

Thanks for the in-depth updates, following with interest.
Logged
Devilkay
Level 2
**

Hi! First game-dev experience!


View Profile
« Reply #27 on: October 21, 2018, 11:46:48 PM »

Quote
Release is slated for the final quarter of 2018.

No news?
Logged
MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #28 on: November 02, 2018, 06:30:56 AM »

Glad folks are enjoying the updates. Smiley Sharing progress helps keep me motivated!

Final quarter of 2018 is still my expected release date, likely some time in December. The MVP for the outer area is finished, playable, and 6 endings can be unlocked as of today! The other 3 endings belong to the castle content which is gated, end-game content, quite separate from the rest of the game. For that reason I'll be coding the castle after this, but my testers are at least now able to run the first 75% of the game. Grin

(The post below is actually from Saturday, I just wrote it and forgot to post.  Facepalm )
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #29 on: November 02, 2018, 06:34:00 AM »

Toggle(Patience)

My stubborn side constantly reassured me that I wouldn’t need to code a skip function for my game. “The game isn’t that long!” “The dialogue is so witty!” “I can put in quick shortcuts once players progress far enough!” Fast forward to this week, and I’ve already had to code a macro on my new mouse just to let me skip through dialogue in the brief minutes I’ve actually spent playing my game. Given the fact that this game is so heavily repeated, I really was kidding myself thinking I could get away without a skip function. They’re very common in visual novels, so my audience should be quite familiar with when and where it’s used.

So, I relented. I would add a skip function. But there were a few ways I could do this. How fast should it skip? Instantly, or line by line? What key should be used? How should the skip work — as a toggle or a held button? I enlisted the help of my friend Matt, visual novel connoisseur. I decided to make the skip line by line so the player knows they’re in skip mode. If it auto-scrolled right to the last dialogue, there would be no chance to intercept, and you could inadvertently miss a whole slew of lines without even realising. Since both methods of skipping (held or toggled) seemed useful, Matt suggested I implement both methods. I’ve added a switch in the menu options for players to choose their input method for skipping. Hold is nicer for skipping through a long section of dialogue until a specific part, whereas toggled is nice for hastily skipping through a long series of dialogue options. I was concerned that players would forget they had left auto-skip on and start a completely new interaction that they wanted to read that is instead quickly skipped. I changed this so that toggle skips must be toggled on at the start of every new conversation (not on in-between dialogue options of the same conversation, though). This might be a bit annoying for players, but that’s something I can gauge with testing.


Provisional skip option in the menu

Players are only able to skip through dialogue they have already seen. Sounds simple enough, but unfortunately my new swanky conditional dialogue that I worked on in the past couple of weeks throws a spanner in the works. If you’re psychic, for example, there might be a line of dialogue that is different to the version that you have already read when you had that conversation as a non-psychic. There are plenty of instances of this happening and I feel that players would accidentally skip over a lot of them without even noticing with the speed of the current skip mechanic. Not ideal! So the system is coded to recognise if any lines are displaying differently using a bitmask. If this conversation is different at all, it is not skippable. Players can see if they have already run through a piece of dialogue as the colour of the response option is coloured differently — much like how a blue url denotes a non-visited link, and a purple one usually means a webpage that you have already browsed. I’m tempted to keep the colour-coding but still allow players to skip a conversation they’ve seen before, even if it’s slightly different to what they read the first time around. Then they are aware that there are new parts of the dialogue, but if they’re not inclined to hang around they can still skip through it. This can affect very long segments of text and not being able to skip any of it would counteract the whole point of having a skip function in the first place.


When dialogue is skippable, the UI prompt appears in the top right.

Sadly that’s all I managed this week due to birthdays and the likes, but I’m glad skips are in now. We’re creeping ever closer to the MVP for the non-castle zones — the bakers and the bandits are the only ones left!

I also have good and bad news regarding the artist. The good news is that all 11 illustrations have been done and they’re looking gorgeous! The bad news is that he won’t be available to do the 139 character portraits required for the game. I’ve started the artist hunt again — this time, at least, I know the right places to look!


The opening scene of the game
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #30 on: November 04, 2018, 06:21:21 PM »

Setting the Stage

As promised last week (but not proven), I worked on colouring the text of your response options based on whether or not you’ve explored them before. I wasn’t completely satisfied with the colours, but once I’d put them all together in Figma I managed to find a palette that I liked and was readable on the beige backdrop. I ended up following traditional hyperlink colours — blue for unvisited and purple for visited. I also added grey text to show when an option will lead to the dialogue simply closing. Most times it’s obvious, but just in case it isn’t the colouring is there.


If you’ve really been paying attention, you might have noticed the font upgrade. Whilst it’s not perfect, the higher weight makes the letters much more legible. Compare the ‘Enter to skip’ font — very skinny on certain characters and difficult to read if the colour contrast isn’t especially high. It was important to make sure the colours were right with the font, too. Those same colours didn’t read well on the other font.

I enlisted my friend Matt to help me completely re-vamp my JSON script creation software. VBA is, frankly, antiquated; he’s very well-versed in Python so kindly lent me a hand with a much slicker JSON builder. It was quite the experience having to share the dirty insides of my game’s code — he made a lot of suggestions on how the JSON formatting could be improved, for example. A lot of stuff we kept the same for the sake of ease, since it had already been implemented, but we did decide to update the JUMP system. Instead of having a crude JUMP statement at the end of the conversation, instead the conversation has one destination (whose text is simply ‘X’). That was a much cleaner way of implementing jumps, and it also condensed the script ever so slightly.

A long-forgotten feature was the ‘closing time’ kick-out interactions. I dismissed them in my head as a tiny, simple detail, and honestly — they were exactly that. It made them quite easy to get out of the way.


I wasn’t sure how big a job the baker and backstress implementation would be primarily due to the sheer number of teleports in their dialogue. Tom the baker saunters in from the back room in a ton of interactions, and sometimes Bess goes into the back, sometimes Bess gets pushed out of the way, sometimes there’s no one left on the shop front to talk to you at all! Conversation-based movement is very crudely implemented, making it a chore to type in the coordinates one by one, but the important thing is that they work.

Even more annoying than characters moving during conversation is the fact that Matt leaves you on several occasions only to be picked up again when you return to him. Ensuring the conditions are right for these situations is just awful — you need to have picked up Matt originally, but not have him anymore, but only pick him up sometimes. What’s more, the drop off dialogue is different the first time it happens — same goes for pick up dialogue. I know this is gonna be something I’ll have to check on during testing, but there’ll be plenty of time for that yet.


I have to pull out all the ‘cheat code’ crutches I’d been relying on for quick testing. I had actually already coded the ending unlock system, working one by one rather than having all endings unlocked from the beginning. This was a simple matter of hooking up the end of the game to the start of the game. Bish bash bosh! On a side note, I doubled the movement speed of Ann just to speed things up while testing the game, and honestly I think I should keep the new speed I’ve given her. She can sometimes overshoot her target when trying to interact with something you can walk over, but most of the time they have their own colliders. That’s the only thing stopping me from making her go any faster, truth be told! I might have to look at my guard sneaking minigame to make sure it’s still somewhat challenging with the higher movespeed, but otherwise it doesn’t have much affect on the mechanics of the game.

Finally, one last note — and it’s a big one! The non-castle zones are now ready for testing! At long last! The MVP has been a long time coming, but it’s finally here (quite hard to believe, honestly!) and I am oh so looking forward to starting testing. Honestly, testing is one of my favourite parts of development — finally getting to see the product in players’ hands. Smiley I’m under no illusion that the build is anywhere near finished, but at least getting the game loop solidified and a mostly-playable game ready is one major step of the way!
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #31 on: November 10, 2018, 03:20:08 PM »

1, 2, Testing!

I love the smell of testing in the late afternoon.



There’s something euphoric about watching people play your game. I think it’s why I’m so compelled to make games in the first place. Testing is the very first taste of that in the development process, and it tastes oh so sweet!

Of course, I’m only running the first 6 endings of the game, since the last 3 haven’t been implemented yet. That said, this is the first time I’ve been able to run it at all, so I’m happy to see the cogs turning in tandem in some semblance of a game experience.


The first two playtest sessions produced 3 pages of notes.

Testing was a good opportunity to write down the bugs that I knew existed but didn’t have the brain power to take note of while in the middle of coding a feature. With coding more than anything, I feel like the slightest distraction can throw you off — you’re normally trying to hold 3–4 changes in mind at any time, and forgetting any of those things will lead to a bug most of the time. Remembering the minutae while trying to keep the big picture in mind is super hard, so it was nice to just lie back and dedicate time to the task without any other taxing — activities on my mind.

I could have figured bugs out myself by simply playing the game enough, but there are certain insights that only someone unfamiliar with the product can provide:

-Tester didn’t see the small doorway to the library
-“How do you talk to people?”
-“Why am I illiterate again?”
-“How do you use items?”
-“Where did that ‘You’re my ancestor!’ line come from!?”
-Most interesting of all, the tester was scared to end the day and potentially lose progress. These are mostly usability problems that I can solve without too much trouble. The tester was already vaguely familiar with the game, too, so anything he didn’t know was doubly shocking to me! A less-savvy user would be left completely in the dark.

My biggest current concern is playtime. To reach the 6 endings, it took the pair of testers (it was a cooperative effort) less than 3 hours. I’m hoping for an average run through to last around 6 hours. So I just double the playtime, right? No pressure! Although this has worried me a little, I’m forgetting that the two testers were playing together and whenever one was stumped the other knew exactly where to go and what to do. On top of this, the castle content isn’t in yet — a whopping third of the script takes place within the castle doors. Finally, the easter eggs, distractions and embellishments aren’t implemented yet. The royals touring the town, arriving at the inn, the priest’s optional sidequest, even the signs aren’t in yet. I’ll hold off on worrying about the game length until I’m closer to the goalposts.

Testing only took up two of my evenings, however, so I had plenty of time to crack on with coding too. I quickly mowed down 2 of the 3 pages of changes I took from the playtests and condensed the final page. What I left was the complicated, mainly UX-focused quality of life improvements. I will get to them, but as I keep hammering home — M. V. P.

As part of the MVP, it’s actually crucial to have ‘permanent knowledge’ implemented. These are things that Ann can remember from one playthrough to the next. In order to get Matt to follow you in certain timelines, this permanent knowledge is necessary. Whilst I was working on this system, I wanted to give achievements a quick pass. The way I currently store permanent data is — to be blunt — a pain in the arse. I need to write two custom functions and have three dedicated variables to it. I’m not convinced the architecture is set up very well, in truth, but I’ve made my bed and now I have to lie in it. To save myself the grief of separating the 14 achievements, I instead opted to store them all in a single integer using bitmasking and the FlagsAttribute class. Manipulating the flags was a little experimental at first, but I actually got it working on my second attempt!
   
And finally, it’s here. I’ve been putting it off for what feels like forever. I need to finally code the castle content.

The writer and I actually had to go back through the reworked castle ball dialogue to ensure that everyone had something to say at all times. I think there are still a few missing lines here and there, but they’ll become evident once the area gets playtested. The party works in four time windows — between each window, all the guests move and the player can engage in a new piece of dialogue with *everyone*. Yes, this happens four times.



I took to Figma (God bless Figma!) to help me arrange the party guests before putting them into Unity. The diagram shows the layout of the guests in Window 1. The white boxes in the screenshot show all the possible interactions that exist throughout the ball — but they aren’t all active at once, naturally. If you still don’t believe that this was nothing short of a mammoth task, behold:



This is the planning for the children of the party. Note that this is only for half of the guests; the adults have a separate sheet.

I’m hoping to have the castle content ready by Monday for further testing. I’m going to finish the runthrough with my current testers before asking anyone else to play — I want to stagger my testers so I can continue to get feedback from a fresh pair of eyes.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #32 on: November 17, 2018, 06:25:33 PM »

Signature||Move

This week I swore I would not put it off anymore. I had to get my logo commissioned.



The logo is such a big, important part of the game. It’s on the front page, it’s on every single promotional post, and I want it to be RIGHT. Rushing decisions like that isn’t going to do any favours in the long term, and honestly I’ve never really had to design a logo before.



My brother’s forte is design, so I forced him to sit down and look through my designs to give me some feedback. We ended up settling on 4–5 concepts, though they weren’t all A+ designs. I’ve entrusted the job to a design company to see what they come back with, because I want something very professional looking. The game can’t speak for itself until you actually play the thing, so the visuals are the thing potential buyers are going to be basing their decision to purchase or not off. I want to make a stellar first impression!




I collected a ton of reference images, logos I liked, didn’t like, colour schemes and fonts that I wanted, then sent off the application. I’m still waiting for them to come back with the final version, so fingers crossed we get something nice looking!



Logo aside, I’ve been intending to continue coding the party, this time doing the younger guests, but — as always — complications arose. The party is split into four windows, and during each there is a different conversation. There are movements between each of the four conversation windows, and there are around 11 characters who need to move each time. This is all well and good, but sometimes characters move as part of a conversation — for example, when you watch the argument break out between two guests, they each sulk on different sides of the castle using the convo movement script system. BUT herein lies the problem, since my current ‘timed movement’ script sets a start and end position, and the start position — as just mentioned — may vary depending on if a conversation is initiated or not.

There are a couple of solutions. I could hard-code each individual movement, and for those specific times where a character has changed position, make it update the start point. However, a simple start point is rarely enough — most movements need multiple lines of instructions to make it around corners and through doors, and it also meant if any of these positions were to change I would have to painstakingly reprogram them.

The other solution, which I feared would be the best one, was to learn pathfinding and implement it into the game. It might be overkill considering that there are perhaps only 40 ‘scheduled movements’ over the course of the game, but some of them are very complex — winding around corners, rivers, across a bridge, and through a series of teleports in a few cases.



I’ve never learnt pathfinding before, and wrapping my head around the tutorial was really tough. Once I’d figured out how the thing actually worked, it was mostly a copy/paste job to get the code running. But, of course, nothing is ever quite THAT simple. The pathfinding algorithm runs based on the distance from the start to the end nodes, but my game has teleports — and what’s more, the teleports aren’t positioned in such a way that their distances make sense.

The best way around this that I could find was to first split the game into zones. Each of these zones calculates which teleports exist within its borders, and also works out which teleports connect to which other zones. The algorithm discovers the shortest number of teleports required to reach the target zone. It then runs the pathfinding algorithm to detect the shortest walkable path from one teleport to the next. This might not technically be the shortest path in scenarios where there are multiple teleporting routes to the destination, but fortunately Ann Achronist doesn’t have a circle of teleports anywhere so that isn’t something I have to take into consideration.

All good, in theory, but in practice it’s proving exceptionally hard to code. I’m not familiar with pathfinding in the first place, so having to code a custom solution on top of an alien framework I’m finding really challenging. I’ve been beating myself up a little this week on how little I’ve managed to actually produce, but really this is going to save me a ton of time doing hand-coded pathing and also there is certainly value in me learning pathfinding for future games. It’s not quite functional yet, but I’m confident I can have it up and running in a few more days.

In the meantime, I’d love to hear your thoughts on the current logo concepts. Which are your favourites? Smiley
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #33 on: November 27, 2018, 06:48:14 AM »

Herding Pixels

The majority of this week has been dedicated to the creation and implementation of pathfinding into the game.


At first, I wondered whether it would really be necessary for my game. Pathfinding is something that I’ve never had to code before, so it would be quite the time investment to properly learn how it works and develop my own bespoke solution for Ann Achronist. I think it would have taken me around 3 days to get all of the paths custom built, corner by corner, step by step, painstakingly monitoring the path length to ensure the character arrives at the appropriate time. Of course, if any of these paths or zones get modified at any point, I run the risk of having to redo the laborious task of hand-coding the routes. There are probably around 75 custom time-sensitive paths within the game, and some of them are exceptionally long-winded. I thus decided that it would be worth the effort to code it through a pathfinding algorithm, and any extra time sunk I would just take as an investment for my own learning.

The A star pathfinding algorithm was the one I chose to implement. The playable area is split into a grid and the ‘cost’ of each grid is the sum of how long it takes to get to that grid cell and how far away the cell is from the destination. This helps the algorithm to make a good guess of the direction it has to go in. Of course, I had the problem of teleports to consider. The way my zones are laid out in the game has no bearing on its physical location within the game. How would the path know the best way to go when the distance to the destination becomes uncertain? Any extra zones outside of the overworld are laid out in a line on the left. Thus, this heuristic cost — the distance to the destination — might be incredibly inaccurate.


The way I decided to solve this problem was to slice my world into zones. Instead of trying to directly calculate a path from the start to the end, it first figures out the shortest number of teleports that the actor can take to get to the destination zone. It then calculates a series of paths between these teleports, since paths that exist within only one zone DO work properly based on heuristic costs. Unfortunately, as the algorithm takes the shortest number of teleports, it may favour a longer path that uses fewer teleports than one that would be quicker to walk in cases where there are multiple teleport routes to a particular destination . Fortunately, there is no circuiting of teleports in Ann Achronist so the solution is fine for this project. Besides, it doesn’t have to be perfect, just functional.


Of all the things I’ve coded, it’s been one of the most satisfying to get working! The reason I decided to implement this now was due to the castle content involving over a dozen guests moving at regular intervals during the birthday ball. I set up the interaction events that occur at different times throughout the party but the characters weren’t moving accordingly. It’s exceptionally difficult to test this when the characters aren’t there to pinpoint where interactions happen, so this is a necessary step before playtesting the final three endings.


It amazes me how elaborate the pathfinding can get. Adding penalties for not following designated roads, blurring those values to create a gradient, to name just two. I made my solution prevent diagonal movement; however, as the crow flies, diagonal movement is preferred and my characters retaliated by following a frantic zig-zag path to their destination, despite it not being any faster. I overcame this by adding penalties any time the unit changes direction. I didn’t want the unit to follow paths that were slower due to its hesitance to turn corners, but adding a minor penalty — whilst not eliminating unnecessary turns — makes the movement look much more natural.


The final lesson I took from this was the benefit of using gizmos in unity. They’re much easier to implement than I first thought, and it’s a great tool for spotting implementation errors right within the editor. The tutorial I followed used gizmos to show the paths to be followed. I found that it was useful to show which teleports are connected, so that’s something I kept when I transferred from the test project to the real one. If a teleport is connected one-way, it’s drawn red; if it’s two-way, it’s in yellow. I like it! Maybe I’ll add some more of those in the future for other things.


In other news, I’ve commissioned the logo for the game. I was hoping for something more vortex-y, but I can’t say I dislike the final version. It was odd — the more I looked at logos for research, the more it dawned upon me that I’d be going for something very simple. I do like it, but I was a little unhappy with the process. I’ll definitely use the logo somewhere, but I’m unsure if it’ll be one I keep for the final version. My main issue is the black background — I’m not sure it’ll read well over any image, which is very problematic for a logo. The final files will be delivered some time this week.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #34 on: December 04, 2018, 12:19:00 PM »

Doth thee has’t the wifi password?


One of the first pieces of feedback I received regarding the game once I posted it was that they expected the game to live up to its title — “Ann Achronist.” But 3–4 months ago there wasn’t an (intentional) anachronism in sight. The writer and I have combed through the script to sprinkle in some anachronisms — objects that don’t belong to the time period they’re in — to heighten the humour of the game.


There are currently around 15 spoken anachronisms and 10 physical anachronisms in the game. Whether or not each one appears is determined at random each time you travel to the past. The idea behind the anachronisms is that the ring has caused time pollution in Alderdale, so the more times you travel to the past, the more likely these anachronisms are to appear.


I spent a bit of time allowing characters to change costume. My goal is to finally implement the path towards getting into the ball — the ball content is mostly ready now, give or take a bit of bugtesting, but it wasn’t yet possible to get past the guard. The requirements for getting in are finding an invitation that was misplaced by a party guest, finding an outfit for yourself and Matt, and arriving after 7pm. The screen dims whenever an outfit change takes place. Outfits are changed as soon as the clothes are purchased or found; I mulled over how on earth the character was supposed to find somewhere to change clothes. None of the items in the game are ‘usable’ through the inventory UI — they must be used as part of the dialogue systems, and I didn’t want the dress to be the exception to this rule. I’d thought about having a specific object — a mirror, maybe, or a dressing room — where you know you can change clothes, but it’s such a specific interaction it only happens once for Ann. So now Ann just gets dressed in the streets! Bish bash bosh! Not like she has to stick around to deal with the consequences, after all.

I added some extra functionality to the pathfinding script. My next step is to see if I can allow mid-conversation movement to piggy back off the pathfinding system already in place. Currently I have to manually write out every corner, but I’m determined to find a solution. But that’s a job for next week.

It’s odd — after such a focused week last week, I feel like this week’s efforts have been more scattered. I’ve been part of a podcast called Level Edit for a few months now, and this week the writer featured as a guest for us to discuss games writing. There are some extra details about the process of building Ann Achronist in there — feel free to check it out. This week I was responsible for preparing and editing the podcast, more so than usual, so I was somewhat distracted this week.

Once editing was done, I turned my attention to the task of finding an artist. My old one was unable to continue for health reasons, so the hunt is on yet again. I’ve found a couple of promising artists for the portraits and I hope to decide some time next week. Currently, that seems like the thing that will be finished last in the whole game, so I want to get it sorted as soon as possible.

We’re also planning to commission a few more illustrations that tie up the events after the game, sort of like a prologue that explains what happens to your ancestor that you leave in the past. I think it’s going to look great.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #35 on: December 09, 2018, 07:12:25 PM »

Walkies

Most of my Friday-Tuesday of this week was taken up with Ludum Dare. The weekend-long game making competition is a nice break from working on Ann, since it can be rewarding to quickly prototype something (one of the funnest stages of development). Our team of 5 produced Ursa, a cutesy puzzle platformer about a cosmic cub searching for his mother. There is talk of us turning it into a full game so watch this space!


I’ve been working on lining up commissions for the rest of the game art. Portrait and illustrations have been sent to be created, so I’m just waiting to see what comes back before proceeding.


Code-wise, although I’d implemented pathfinding if it was input directly into Unity, I realised it would also be beneficial to allow the script to directly access the ability to pathfind. It means that if a character has two possible positions prior to the conversation, the character will still find a nice reasonable path to its destination. Another obvious advantage is that lazy old me doesn’t have to define every path, corner by corner, teleport by teleport. Most of the work for this had already been done, since I was piggybacking off the scheduled movement system that I’d already built. There was no end time, thus no speed, and sometimes directions have to lock — everything else was plain sailing. Most of the work for this was refactoring the ConvoMovement which was written over a year ago.


As unimportant as it is from a functional point of view, the writer and I did decide to add wandering characters to the overworld. The aim was to make the town feel alive, as as though it’s running like clockwork. The ulterior motive for this is getting to meet the ball characters before properly being introduced to them at the party. There are over a dozen new faces locked behind the castle doors, so this will prevent players from feeling so overwhelmed by the staggering number of new characters to learn about. It’s really nice to see the characters milling about as you get on with your business! Most interactions must be initiated by the player, so the touring characters don’t annoy the player by constantly hindering them.


As part of the side-quest with the baker, there’s a pretty, peaceful glen the player can visit — if they’ve learned about it. I hadn’t intended for this area to be a separate zone connected by a teleport, but I actually prefer the cosy aesthetic of it being a small, intimate space surrounded by black, as all other zones are. I much prefer this defined sectioning of the zones, especially for interiors.

I had to make a small fix to the way pathfinding locates the teleports. Sometimes teleports are inactive until certain moments in the game — the glen, for example, but also locked doors. Some NPCs wander through locks teleports, so this change makes sure that is always possible.

As the end of the project draws near, it’s getting increasingly difficult to prioritise what dialogue to implement next. A lot is merely garnish — wonderfully written garlish, but not vital to finishing the game. There are one or two bits that are quite important to code, but I have no idea how I’m going to make — like setting someone on fire and throwing someone in a river. All that aside, I’m ready to continue playtesting, as 8 endings are finished now. Just one ending left to code!
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #36 on: December 17, 2018, 07:47:38 PM »

test-write-fix-test-write-fix

As unimportant as they are, I took out a day this week to add a ton of miscellaneous easter egg interactions. They’re lovely to have in the game to make the world feel real and complete, but they’re by no means necessary for completing the game. These are important to have working during testing, as every interaction is a diversion from the main path towards completion.


I’ve added a very basic cinematic for the first time you enter the world. This adds a slight bit of polish to the game, and didn’t take long to achieve, thankfully.


I worked on a temporary landing page for the endings. Previously, you had to scroll through hundreds of lines as I’d provisionally shown them through the NPC dialogue system I’d already built for ease. What I have here is much closer to what I’d actually want for the real thing. I’m planning to add functionality to hide the text so you can properly enjoy the image before diving into the text. It was also recommended to split this dialogue up into ‘pages’ rather than one huge wall of text to make it easier to digest. I quite like this suggestion, so it’s on my to-do list.


After asking five different artists, I’ve finally found one to do the portrait art for me. Really looking forward to seeing what she comes up with! Below, we can see Otis Levin smiling and growling. I love how animated and expressive they look!


With those things out of the way, I wanted to playtest, playtest, playtest this week! I ran about 6 hours of playtests over the course of two days. In total, I managed to spot 6 pages worth of bugs. Most of those have since been corrected, I’m working on the final two now.


Moving forward, I plan to keep playtesting my game basically until the end of development now. Whilst I can seek out the bugs in my own playthroughs, spotting them in playtests gives me more time to focus my attention on actually spotting the bugs (instead of getting distracted from my coding task) and is much more enjoyable as I have fun watching playtests.


Now that I’m polishing, it has come to my attention that there are no controls shown in the game anywhere. I need to add explanations for movement, interaction, fast forwarding, and ending the day early. I’m also planning on adding a controls option in the menu in case players forget.

There are some small problem areas that every player hits. The entrance to the library has been missed by every single player so far, so I’m doing everything in my power to make it jump out. These are the sort of problems I could never predict without doing playtesting.


Worryingly, even veteran gamers are having some difficulties understanding the core game loop of restarting the same day over and over. I’m working to improve the on-boarding process by heavily focusing on the first three runs that the player makes in the game, and also streamlining the first timeline’s experience. I plan to shut off some content when you first enter the game to limit the game’s scope so players know how to get started, and after that the training wheels can come off.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #37 on: December 27, 2018, 09:00:23 AM »

Doing To Dos

I’ve been working through all my playtest notes, slowly condensing until they’re all gone. I have 7 large tasks left to complete before I intend to move onto any more playtesting.



As suggested to me by a tester, I’ve added a ‘cheat sheet’ of all the bonuses you get when playing in each timeline. This helps players assess how to move forward.



I tidied up the end game scene. The wall of text was fairly daunting to some, so I split the ending prose into pages instead. This fits well with the fact that some endings have a new illustration half way through the story, and a page turn is a great time to include that. You can now toggle the text on and off to get a good look at the art.



I’ve worked a great deal on polishing characters’ movements. I’ve also added a layer on my tilemap for any sprites that are supposed to cover up the player — things like pillars, tall walls, and as shown here the table that Ann is sitting at.



I’ve also been working on some miscellaneous scenes that had a lot of heavy animation work on the presentation side of things. Here’s a fairly dramatic scene from the game.

I intend to keep working through the Christmas period, hoping to finish coding the core of the game in January and then just work on improving graphics and polish.
Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #38 on: January 23, 2019, 08:40:39 AM »

January round-up ready! Hand Joystick Hand Joystick Hand Joystick

Logged

MaybeLaterGames
Level 0
**


View Profile WWW
« Reply #39 on: May 09, 2019, 03:26:58 PM »

Spring round-up ready! Hand Joystick Hand Joystick Hand Joystick


Logged

Pages: 1 [2]
Print
Jump to:  

Theme orange-lt created by panic