|OT| Indie Game Development thread

Deku

Just nothing
Oct 19, 2018
4,262
8,616
113
20XX
www.seikens.com
damn ... you're going so fast with that game! :)
Thanks again. Although I don't think I am doing this fast as you think :p
Last weekend I tried to make projectiles to go in circle motion, but totally failed. I also reworked some things to add information on each gun.
Today I added ammunition count, but that took maybe 30 minutes to add :p
 
  • Like
Reactions: lashman

lashman

Dead & Forgotten
Sep 5, 2018
30,372
85,149
113
Thanks again. Although I don't think I am doing this fast as you think :p
Last weekend I tried to make projectiles to go in circle motion, but totally failed. I also reworked some things to add information on each gun.
Today I added ammunition count, but that took maybe 30 minutes to add :p
still counts in my book! :)
 
  • Like
Reactions: Deku

Le Pertti

0.01% Game dev
Oct 10, 2018
8,279
21,203
113
45
Paris, France
lepertti.com
Been philosophising a bit about making your first game. Like everyone says go simple, which is understandable, so many go 2D but 2D art that is actually usable is so way beyond what most people can do for their first game. I actually think 3D is better for a first game, it's more complicated but getting over that initial hump makes it easier on the production pipeline. But depends on the kind of game, if you go first person, well then you again need super top-notch art but in 3D this time.
 
  • Like
Reactions: lashman

Parsnip

Riskbreaker
Sep 11, 2018
3,028
6,669
113
Finland
I always struggle with that question, whether to go 2D or 3D.

The actual answer is it doesn't matter, the actual answer is to make something with a scope you can finish regardless of the other choice.
Making a game with 2D stick figures or or 3D blocks is useful because it will make you more familiar with the tools, as well as teach you level design and such. Plus it means you can finish a thing. Actually finishing your first game is the biggest hurdle.

The saddest part is that I'm terrible at taking my own advice.
 
Last edited:

Deku

Just nothing
Oct 19, 2018
4,262
8,616
113
20XX
www.seikens.com
Godot was granted $250k by Epic Mega Grant. While it is good that they got supported by a huge sum of money. I hope there is no hidden strings attached from Epic's side because of it
 
  • Like
Reactions: BlackRainbowFT

Le Pertti

0.01% Game dev
Oct 10, 2018
8,279
21,203
113
45
Paris, France
lepertti.com
Godot was granted $250k by Epic Mega Grant. While it is good that they got supported by a huge sum of money. I hope there is no hidden strings attached from Epic's side because of it
Yeah I was about to comment on this. While it's great with the money and I don't think there are any strings, but damn Tim have to taint everything I like.XD
 
  • Like
Reactions: lashman

Le Pertti

0.01% Game dev
Oct 10, 2018
8,279
21,203
113
45
Paris, France
lepertti.com
I've always had this issues with how game development is done, especially with assets and how labor intensive it is and how it is something that will be an obstacle. Like take indie movie making as an example, they just take a camera out and film. They don't handcraft every piece of clothing, items to be used or backdrops/city. That's why there is much greater artistic expression in other mediums that are simpler to make. SO having asset packs is crucial to game development but one reason to I've never even considered using one of them, because they are all so stylised already and usually only have the assets that are the main things in a game and not less important things where assets bundles would be much greater help.
 
  • Like
Reactions: lashman

lashman

Dead & Forgotten
Sep 5, 2018
30,372
85,149
113
I've always had this issues with how game development is done, especially with assets and how labor intensive it is and how it is something that will be an obstacle. Like take indie movie making as an example, they just take a camera out and film. They don't handcraft every piece of clothing, items to be used or backdrops/city. That's why there is much greater artistic expression in other mediums that are simpler to make. SO having asset packs is crucial to game development but one reason to I've never even considered using one of them, because they are all so stylised already and usually only have the assets that are the main things in a game and not less important things where assets bundles would be much greater help.
except i wouldn't really use this particular stuff for a finished game

why? because their (Synty's) style is REALLY unique ... you can recognize their packs immediately ... and every 10th new store page added to steam uses those packs ... i've now seen like 20 or 30 games using those assets ... and they all look the same
 

Nyarlathotep

The Crawling Chaos
Apr 18, 2019
190
494
63
Most pf those packs looks like they have a bunch of useful 'background' stuff included anyway - environments, props, scenery etc, and if you're going low poly anyway there's only so many different ways you can make a stylised tree or a rock.

Maybe using the characters might be a dead giveaway, but I'm pretty sure you could do a lot of set dressing with these packs in your own project without it being obviously noticable.
Having said that, I really dislike the 'must have all new assets' mentality that has been fostered anyway.
I really could not give a shit if someone is using purchased assets in a title they make.
For literally the same reasonsI really could not give a shit if someone is modding an existing game and using the stock assets that came with it to do something new.
 

Grindwheel Games

Junior Member
Jun 6, 2019
297
804
93
Good evening!

My name is Tony Wilson, designer and developer at Grindwheel Games. On my thread (|OT| - Grindwheel Games Titles) I asked if people would be interested in hearing about the pipeline I have been using to develop my games. (Grindwheel Games - Our Games) These are Lovecraftian text adventures available on Steam and Android. As I am pretty much flying solo, I thought maybe it could help other developers who are also working on similar projects. Since people seemed interested, I am going to start posting about it when I am able.

Right now I am also working full time for Quarter Circle Games, while doing my own development in my free time. As such I will likely post chunks of the pipeline when I am able. But feel free to ping me questions if you like. :)

In brief, the method I use to design the games is as follows:

  • Concept
  • Update
  • Development
  • Initial Edit/QA
  • External Editing
  • Art and Music
  • External QA
  • Final Tests and Polish

I'll cover Concept today, as there is a lot of backstory to the project as a whole in that subject.

Concept

Core Concept


The overall design of the games came from a number of factors within the games industry. When I started looking to leave Jagex back in 2015/2016, I found that many of the companies I applied to considered the previous 11 years of development and design work to not exist or not count on various levels. For development this was pretty obvious, as Jagex uses an internal, home-brew language. So if I applied as a Unity developer they just want 'you have no published Unity experience, sorry'. When it came to design it was a little more baffling, as I had people tell me everything from 'you have no design experience because the game you worked on was launched before you started working there' to 'you have too much design experience for MMORPG's to work on our product'.

One of the other issues was that at this time a lot of companies were focused heavily on yearly releases. So to them, having 11 years working on an MMORPG was 1 game in 11 years. And they wanted people who had worked on one game per year (or as close as possible), as that was what they expected me to do when I was with them.

I started working with Carlos on plans to deal with this. In the end, between our schedules and after some experiments with larger projects, we decided that we needed something which could be developed while we both worked our regular jobs, and could preferably see one release per year as part of a series. It also needed to be developed on a tight budget because at this point my wages had been frozen for about five years, so I had balls-all money to put into the project. This meant that I was going to try and do as much as I could, barring the art and music.

We had toyed with the idea of visual novels in the past, and I had also tried to get a series of simple Runescape adventures for tablet up and running. It made the most sense to me at that stage to try and build a simple, modular engine into which I could insert a new story and artwork to ensure I hit a yearly deadline. Again, I needed to be able to show both the coding, story and system design elements to help me get work elsewhere.

Thankfully I ended up working for Sperasoft. Not only did they have a far less toxic environment than Jagex but they also paid well. This was why I was able to upgrade the art from a black and white imitation of the old Fighting Fantasy books to colour, but also speed up the editing process by hiring an external editor. Until then, editing was being done by the testers whenever they had time, so it was slow going!

This resulted in the product as it stands. Something which can be worked on alongside a regular 9-to-5 job in the games industry with a release per year, while being developed with a limited budget in mind. I should also note that it is also something I take pride in, and am very happy to have my name attached to. There have been a lot of people asset-flipping or spamming things onto Steam to pad their CV, but I and the rest of the team wouldn't budge on quality.

Further Concepts

Once the core design of the game and the engine was laid out, I worked on the stories I wanted to plug into it. Some of these were adventure ideas for pen-and-paper games I never got around to running. Pale Harbour was, for instance, going to be an introductory game to a steampunk horror campaign using the Savage Worlds system. Others sprang from projects I worked on while learning Unity. The Vile Philosophers were from a larger project initially. Specifically a text-based adventure game with elements like random dungeons, quests, multiple cities you could visit, and a plan to add new content over time.

Yet more have sprung up as a result of working on the games and trying to flesh out the world and its rules. Red Ripper, for instance, takes place in the Sunlight Alliance. I made a note in the first game that this is a theocratic society, and while working on other things fleshed out exactly what form this took. This then built into the book which will be released later this year.

Overall I generally try to make sure the story has a logical plot which goes from a start to a suitably epic climax. As will be discussed in the Development section, a lot of this is in my mind and expands as I write it all out. Side paths get added at this point too, but overall I try to keep to that core A leads to B leads to C format.

A lot of the time I start with the villains of the piece, often the final boss. From there I work out how to move the player from an initial starting point to this climax. Having run a lot of Call of Cthulhu and other RPG's, I use this experience to create a core storyline to follow where possible. For example, with Pale Harbour, I had started with the idea of the players having the face off against what at first looked like plant monsters until they were killed and bones were discovered inside. Then I started asking myself 'who put them there?' 'How did this work?'

The initial version of events had nothing to do with Externals. It was, instead, being controlled by a necromancer who was using the dead slain off the coast to build an army and enhancing them using his corrupted druid magic. However, as I worked on the concept in my head, I decided to add a scene where the player encountered villagers who had gone mad or fallen to the necromancer's power and decided to a) infect themselves with seaweed and b) offer sacrifices to the skeletons. The idea of a religious following trying to spread the plague seemed to me a stronger theme, and so I changed the sequence of events to the one in the final version.

Anyway, I hope that has been of some help and I should be able to answer questions on my games if you have any. :)
 

Grindwheel Games

Junior Member
Jun 6, 2019
297
804
93
Good evening! Here is the next part of the pipeline discussion.

Updates

The first version of the game engine was as robust and simple as I could make it. I wanted to have something which worked, but was open to iterative improvement. Making a super-fancy system was possible but would delay development outside of the year, as every day I was working on messing with the engine was a day I was not writing the story or plugging it in.

So, in the first game, everything was 'on the page' so to speak. If there was an enemy, for example, then the page script would have a boolean saying that this was the case, and fields for the name and stats of the enemy. This was obviously very clunky and meant that even if an enemy was not present the page data still had these fields. It also meant that I was limited in the number of special effects which could happen during combat, as each of these would be a boolean included on every page. That's why there is only one 'boss mechanic' in Pale Harbour.

I decided this was something which needed to be addressed first, so I split everything related to npc's off into enemy data prefabs. I kept the boolean to say that there was a fight on the page, but then just had an entry for the enemy data scrip, and created new enemies as needed. This also meant I could expand the number of unique effects in combat, as all of that was kept neatly in the enemy data prefab.

There were a number of other mechanics which I have done this with at the start of each game. Shops, for instance, were on the page, and have been moved off to prefabs. Other mechanics have been streamlined when I have had time, such as the mechanism by which choices affect the game down the line. These 'story triggers' used to be contained in the story wrapper which holds all of the game pages, and were broken up into individual blocks of ints and game object links.

For Red Ripper and Tattered Sails I have also added two new core game mechanics which I have been planning for a while. In Red Ripper you will be able to customise your hunter's equipment using the Heirloom system. This will allow you to sacrifice a slot in your inventory for a weapon, set of armour, or other item. These all come with positives and negatives, such as armour which blocks automatic damage but gives you a -1 to hit in combat. Tattered Sails does the same, but with Traits. These are bonuses which are always on, but usually only trigger under specific circumstances. For example your hunter could be a Veteran, meaning they start the game with less maximum health, but they do not take Skill penalties in combat.

One of the core things that I use to drive this is considering the new mechanics as I am writing the game. The addition of timed fights came because I thought that adding this as a mechanic to make the fight with Aunt Flay in Vile Philosophy would add some urgency to the scene. By contrast, the mechanics related to only being able to take one of a certain item in Blissful Ignorance was to allow for a very specific outcome if you tried to use them during certain points of the game.

Overall though, the core mentality behind these changes is to make the game more modular where possible. So, for example, enemies were very rigid and could not be easily modified and personalised under the old system. So I cut that chunk away, made it modular, and plugged it back in. The same went for shops, triggers, pointer adjustment, giving and taking items, stamina and skill adjustment, etc. Some things are unique to each game, such as specific boss mechanics. When these come up, I always make sure to comment them with the line 'Temp for this game' so that when I build the next title I can hunt down these entries and remove them as needed. But, where possible, if I use a mechanic once and it is simple enough, then it gets added to the core engine for use later.

So, that's today's diary! I hope people found it useful, and as always please ask me any questions. I have a lot of things to do tomorrow to make the flat a bit more tidy so I may not get a chance to discuss development, which is a pretty hefty subject, but if I don't tackle it this week I should be able to post next weekend.
 

BlackRainbowFT

Mouse Accelerated Member
Apr 17, 2019
505
1,164
93
38
Switzerland
Today I was kind of in the mood to prototype something.

I was thinking about Borderlands and how they claim to have a "bazillion" guns when in fact those differences are mostly "stat based".
One game that does weapon variety way better than Borderlands is EDF which features some really crazy stuff.

So I thought I'd come up with my own system... this is what I made this afternoon (Note: I'm hiding it since I don't want this video to be shared elsewhere):
Hidden content
You need to react to this post in order to see this content.
So currently I have:
  • Regular gun behavior: everything can be tweaked (mag size, fire rate, reload time, bullets per shot, spread, bullet velocity)
  • I can modify the trajectory of the bullets (waves and spirals)
  • I can choose to accelerate or decelerate the bullets (the one I put in the video is a really bad example... my goal is to be able to do stuff like spawning a wall made of 100 bullets that almost don't move for a few seconds and then accelerate really fast)
  • When using a weapon with bullets that spread (i.e., shotgun) I can either set it to "random" or "pattern based" (I can then draw pixel art either simultaneously or sequentially)
All of these behaviors are modular, meaning that I can have accelerating spiraling bullets that also draw a pattern.

I don't know if I'll keep working on it, but I want to implement some others things like physics-based projectiles (i.e., grenades), "heat-seeking" projectiles, geometry-building projectiles (e.g., like an ice ray that could build a wall).

But the thing I want the most is "multi-stage" projectiles... which would allow me to do ridiculous stuff like:
each projectile goes straight towards the sky > after 100 meters each projectile splits into three sub-projectiles > each sub-projectile becomes heat-seeking.

Edit: Oh yeah... I didn't know what to call my project and the first thing that came to mind is the title of the video...
 
Last edited:

Grindwheel Games

Junior Member
Jun 6, 2019
297
804
93
Ok, so I had a long day, but I will try and make a coherent post about development. :) Here goes!

Development

Pale Harbour was unique in that it was being designed and developed, as well as having the story written, all at the same time. Now the engine is in place, I just need to focus on core improvements, and plugging in a new story. The way I do that is as follows:

First, I write the core 'perfect' route. The actual perfection of this route can change as I add side missions, but ultimately a player going by this route they will arrive at the perfect ending with the least danger possible. As I do this I will leave myself various cues and hints as to what is going to be down the side routes, but usually I will stick to the main game progression. Once I hit the end of the perfect route I will add in all the deaths that could be encountered in combat, meaning that when it comes to VO and editing, the poor people will be reading a victory condition, and then 10-12 violent, gory ends!

Next, I will plug in the core path. This is so that I can more easily go through it and see where the side routes are. I also take this time to go over each page, do a basic edit if I notice a lot of repetition, errors, plot holes caused by something which came up later, etc.

With the core path done I start writing everything else. This involves starting the new build, going along the core path until I find a page which should branch, then writing out these entries (and any branches that they cause themselves). Once everything is in place, I go back in and turn to the next page. This does take a while, but ensues that I have made enough branches to keep things interesting and covered all the side points as best as I can. Usually it is at this stage I also notice if there are too many dead ends at certain points. For instance, in Pale Harbour jumping to the wooden ship caused the player to die rather than open an additional area. That meant that at that stage you were faced with three options - die, die or continue.

As the project is designed to be completed alongside regular work, the usual schedule is to create new content Monday to Friday and plug it in on the weekends. That means I don't get too far ahead of myself, and as i create the enemies, items and triggers as they appear in the book, it also means that I can test them to make sure any new mechanics work as expected. When I hit the end of the story I will plug everything that remains in, and add things like any missing deaths, 'you have already done that's and so on.

Between completing the core story and finishing the script I will also sit down and write the first draft of the unlockable content. By the time the game is written I should have a better idea of the lore I want to give the players as they progress. And, as a result, what easter eggs to put in at the end of the script. Pale Harbour is a bit of an exception, but from Vile Philosophy onward, these have followed the format of:

One of the Easy lores will change the name of an enemy in game to represent something which you now know. IE - the Harrows' Gate Beast has a more appropriate name when you know how and why it was created.

One of the Intermediate Lores will prevent an instant death situation near the end of the game. So in Blissful Ignorance you can avoid a death when dealing with a certain Infernal.

And finally, one of the Hard lores will unlock an alternate ending. This could be slightly easier, or it could simply skip a stage of combat. I won't give away one of these for those who have not found them already. ;)

With these written, the game is essentially complete. Following this formula I will have a complete script, all new mechanics covered in it have been added, all the story triggers have been implemented, and the content has been given an initial pass for errors. That means it is ready for the next step, which I will cover next weekend!
 

Grindwheel Games

Junior Member
Jun 6, 2019
297
804
93
Good evening! My machine is chewing its own head off as it tries to install an update, which was why there was no post yesterday. It is still flailing a bit at the moment, but hopefully will stay alive long enough for me to send one out. :)

Initial Edit/QA

As I mentioned during the Development post, when I put each page into the game I give it a quick check to make sure it seems fine. I also test them to make sure they seem to be pointing in the right direction, as I walk through the entries to be sure that I have covered all the planned side paths. But, once this is done, I give it a more detailed edit, as well as make absolutely sure everything goes where it need to.

I created a script which I exported as a Unity asset for this. At this stage I import it, and let it run. It takes all of the pages in the game, and outputs a text file which contains all of the information about where each page points. This includes where it will point if triggers have been applied, as well as if the player has specific items, money, etc. This does not contain the text of the pages, just all of the ways to get out of that page currently.

I print this file out, usually resulting in a hefty stack of pages! I then put a circle next to 'Entry 1' and check its links. To do this, I load up the game, and check each ribbon. If the ribbon leads me to the right page then I put a circle next to the entry as it appears in the document. So if 'Check your notes' leads to Entry 2, I find Entry 2 in the document and put the circle next to that. If a link is broken, I will go back to the master script, find where it should be pointing, and correct it. I then update the printed file to match. If a link will only work if a trigger has been activated, I will do this via the back end, as I am doing all of these checks in Unity. I then save and reload to make sure things are as they should be. The same goes for if I need to check a death. I just set my stamina to 0, reload, and try the fight again.

Once I am happy that a link is valid, I cross it out. Once all of the links under an entry have been crossed out, I go in and check the text. I do this in the editor so that I can make sure it is not overflowing the page. I should have picked up everything major when the page was entered during development, but there are always little mistakes to find! When I am satisfied that the page is ready, I put a tick into the circle next to the entry, and then go looking for the next circle in the document.

Nowadays, this should lead me through the printed file almost completely chronologically. After all, at this point page 1 points to page 2, and might also point to 200 and 201. So by the time I have made it through the perfect path, all of the entries to the side paths will have been circled. Then, by following these paths, I will end up back at entries which have already been checked. So, for example, page 1 leads to page 2 and 200. Pages 2 and 200 both point to 3. By following this method I will have checked 1, 2 and 3, and when I get to 200 I will find it has a circle, showing it can be reached, and when I check its links I go back to 3 and see that it has a ticked circle to prove it has been checked.

This does take a chunk of time, but ensures that every page in the game can be reached. If I find a page which has not been circled, then it cannot be reached in game, and that needs checking.

I would like to point out that the first time I did this I had shuffled the pages around. I make sure to keep that to later in the process, as when it came to testing things the circles were all over the place! So page 1 lead to 80, 500 and 42, for instance, and they all led to random number in turn. I had to keep going back to the start of the printouts and hunting for the circles. Waiting until after this has been done saves a lot of time.
 

Grindwheel Games

Junior Member
Jun 6, 2019
297
804
93
Good evening. Just a short one this evening, but i hope it can help anyone in a similar position. :)

External Editing

As noted previously, I will go over every entry myself twice before this point, technically three times. First, when it is written initially, second when i plug it in, and thirdly when I check the game is functioning correctly. But, there is always room for improvement. With Pale Harbour friends of mine were going through and editing the script, but this was being done whenever they had spare tome, so the process was slow. Thankfully when i moved over to Sperasoft I had the money available to pay for an external editor to do it in one go.

I went with Servicescape because they had a good reputation, and Xperteditor because she was at the top of the list, ranked by reviews. Usually the way this works is that i will send over the unlockable content first, and while she works on that, I will complete the previous step. This year, thanks to having everything already plugged in, I sent that through and started on book 5 instead. But, when the lore was sent through, I send her the main script itself and plugged the edited copy into the game.

In previous versions I was splitting this up by the paragraph to make sure it all fit in the page, even with resizing. Thanks to the addition of the text mesh pro options I was able to pit it all into Red Ripper with the justified option, and it all worked out nicely. This saved a considerable amount of time!

In any case, when the main script comes back I will go through it and check all of the changes. 99% are accepted, with just the occasional change or rejection. If, during this time, I come across another issue while reading the script, I will correct that as well. When the script has been checked I will then go through and plug all of the entries back in. I used to highlight the exact lines which had been edited and transfer those over, but then I missed a few and only caught them during the audio checks, so now I just plug in all of the pages, even if they were not changed by the editor, to be on the safe side.

Overall I would recommend using an external editor if you can afford one. When it comes to game text a writer can get very 'into' the script and not realise there are mistakes. Having someone look over it, preferably a professional, can give you valuable feedback which you would otherwise have missed.
 

Grindwheel Games

Junior Member
Jun 6, 2019
297
804
93
Hey all. Sorry for no update yesterday, but my machine is slowly chewing its one head off. I have ordered a replacement, which is long overdue, and I should have it next week or so. Until then I am trying to work around its frequent grinding.

Anyway, on with the next part!

Art and Music

The first step in this stage of the pipeline is to randomise the page numbers. This is done for the PC and tablet builds. I will have made a temporary tablet build which can step through the pages in numerical order before now, in order to see if any pages overflow the text boxes. So when the PC version has been checked and all of the page numbers updated, I will copy this across and replace all the data in the tablet build.

This then allows me to step through the pages and see if it is suitable for art. The criteria for this is:

  • It must only take up one page (obviously)
  • It should not be a page where the player can lose stamina where possible, in case that means they reach it and die without unlocking the image.
  • It cannot be a shop.
  • It probably should not be a 'you have already done that' entry.
  • It can't be a death page, or show the player directly killing an enemy. If it is an iconic enough character then it can show the creature alive, but if the page it appears on isn't available then that's tough.

As I go through the pages I make a note in a text file, saying what the possible entry is. When the whole game has been sorted I then split this list into blocks of 10 pages, and pick a suitable entry from in that block. That means that roughly one in every 10 viable entries will have a specific image. Naturally if there is a run of deaths or long paragraphs, the gap between images could be much, much bigger, but that is how I try to space them out.

All of the information about the pages is then added to a document I send to the artist. This contains all of the requested pages, the general images and front cover.

While this is going on I also contact the musician and voice actor. In the case of music Cryo Chamber have a system they use for commissioning new pieces, and we have got a pattern down now. So I will focus instead on VO.

I send my father the edited script, and he reads the entries in his home studio. This is where he records a lot of his folk music, and is pretty decent when it comes to shutting out noise. So long as the cruise ships on the Tyne are not honking away like idiots that is! In any case, he sends me these files, and I will go through and edit them. Specifically I will go through listening to the full read of a page to see if there are any issues. So, if he makes a minor error that can be corrected, or which changes the script in an inconsequential way, I will update the text and put a yellow mark on the page number. If it can't be used due to a missed line, then it gets a red label for re-do's.

I have a piece of 'silent' audio which is 1 second long. I go in and use this to break up the sentences and cover any background noise, as well as mask any pops or clicks not caught by the filters already. Once the entry is sorted, I will place it in a folder for later. At the end of the week I got through each of the entries again to make sure I have not missed anything. If they are fine, I add them to the game and move them into an 'added' folder so they are out of the way. This then continues for all of the pages, until we're done!

After the internal testing, this is naturally the longest and most demanding phase of the process. If the game has 650 pages, that is 650 audio files i will need to edit, check, and add. Short entries like 'you have already done that' are fine, but when it is a 2-page discussion about dismemberment, that can take a good chunk of time to deal with. Still, having voice over, especially done by a professional storyteller, is a great boon to the product and a great USP.
 

Grindwheel Games

Junior Member
Jun 6, 2019
297
804
93
Good evening and sorry this post is a bit late. It is also a short one, but I hope it helps! As before if you have any questions about this system, or want help developing your own, please let me know!

External QA

All of the passes done to the game so far should have caught all of the bugs which could pop up. However, I do like to make sure other people play the game before I am satisfied that everything is fine. I have a drop-box into which I put the tablet build to let them test it. In theory, unless anything has gone seriously wrong, the two builds are identical, as they both use the same story triggers, items, etc. As such, the tablet build is the smaller of the two for them to download and play, so it makes sense to go with this one. In addition, I only got my Steam account last year, so getting them testing keys before that point was impossible.

The feedback I have received from these external testers has been very valuable. For instance, in the first version of the game there was only quick combat. It was suggested that, even if the combat wasn't interactive, some people might want to see the numbers as they were generated. So, I added the expanded combat system. The character sheet previously didn't have any boxes, only numbers and a small button to press to heal. This was changed as well. In fact, the layout was originally two pages in the book rather than a sheet of paper, but this was also changed based on feedback.

Passing the game around the office at Sperasoft also led to me adding things like the quit confirm and 'escape to quit' code, which I had not considered before. Obvious system issues like this can slip by if you don't consider them! Being essentially a one-man-band means you often don't consider things someone else might think is obvious, so having someone else look over your code or game is always useful.

In terms of bugs, the testing phase for Blissful Ignorance found that, for some reason, the loop which made sure to add all of your items back into your inventory had been messed up when I added the changes from the PC version, meaning that loading your game stripped your inventory! This was literally one line of code which had somehow gotten copied over, but if it hadn't been caught that would be a hell of a problem! It also identified some errors where screen resolution was not setting properly on the first time the game was run. Obviously I didn't pick the error up as I had run the game before, and so couldn't see the bug myself.

The testing phase also led to the Rose Run achievement, as Stephanie always plays the game from the very beginning without saving. This meant that every time she died or hit a dead end she would start from the beginning. I thought this was a fun little thing to add, which is why it became a core unlock for the games. Some of the others were suggested by running ideas past the group as well, although the idea to have one achievement per monster you can kill was, naturally, dropped for being too much work.
 

Le Pertti

0.01% Game dev
Oct 10, 2018
8,279
21,203
113
45
Paris, France
lepertti.com
For dialogue stuff, the creators of 80 Days and plus have some free tools that one can use!


 
  • Like
Reactions: Deku and lashman

Grindwheel Games

Junior Member
Jun 6, 2019
297
804
93
And here is the last part of the pipeline. :)

Final Tests and Polishing

Overall, by this point the game should be about ready to go in the formats I can (currently) release in. Since I don't have an Apple tablet or Mac to test on, I am not able to currently test those builds, and therefore don't try and release on them. I hope to pick up an Ipad at some point this year to see what I can do on that front, and depending on how things go could expand to a mac as well. But until then, or until I find someone to help test on those platforms, I am holding off. Much as I would like to go for them, if I can't be sure they will work I also can't be sure I will be able to fix any bugs I come across on them.

In terms of polish I tend to play through the games one last time, specifically the core path. If I can get to the end then I know that it is going to be at least functional, and all of the major bugs should have been caught by this stage. I should have plugged in all the artwork, so I will use Unity to create a save file and run the steam build to make sure all the images appear on the correct pages. Then I will upload to Steam and Google Play to do the store pages, along with trailers and other things.

I think it is probably a good idea to discuss the number and format of things like achievements. Some of the people who tested the game suggested adding one per creature and item, which would be nice. But since I am limited to the page art for everything, unless I buy a load more icons, then I have to be sensible with this. Keeping the achievements the same between books is also not just to help make them a little more interchangeable, so they can be played in any order, but also so that I do not have to go back to re-invent the wheel with every game.

This is, ultimately the core lesson that I hope anyone following this sort of pipeline can take away with them from all this. It is totally possible to make a fun, interesting, series of games, with yearly releases, flying solo or as part of a very small team. But you HAVE to be sane with your expectations. One of the early projects which I tried was going to effectively be all of these games tied together in a huge lump - a giant open-world text based adventure with additional content being added periodically. While that was a nice plan, it would have taken me until now to get it ready, and cost far more in terms of time and art resources. One of the other projects was a full Metroidvania. Thankfully sanity (and reality) stepped in and reminded myself and Carlos that neither of us had time to make that while also working full time in our other jobs.

So I hope people have enjoyed these insights, and if you have your own games then I hope following this sort of structured pipeline will help you get to release them. Thanks again and hope you are all staying safe out there!