Sunday, October 29, 2017

Announcing 'The Making of The Painscreek Killings' Series

As The Painscreek Killings is now on the market, we looked back and reflected on our five-year journey. Through a series of articles starting next week, we will illustrate the problems we faced, the breakthroughs we had, and how we brought an idea into a full commercial product. We hope anyone interested in or currently making a mystery solving walking simulator can benefit from our experience.

Hope to see you all next month.

Sunday, October 15, 2017

Available Now On Steam And Green Man Gaming

We are happy to announce that our first game, The Painscreek Killings, is now available for purchase on Steam and Green Man Gaming.

In this game, you play a female journalist whose job is to investigate a 4-year old murder case in a town called Painscreek. You are free to roam anywhere to proceed in your investigation. Using your camera and power of deduction, you are to find the truth about the murders that happened there. When your game ends, you will need to point out who the killer is.

Key features of the game:
  1. It's a semi-open world game. This means it's not a linear game and there's no set path to follow. You explore wherever you want, most of the time based on clues/hints you found.
  2. You can end the game anytime. If you think you know who the killer is, you can leave Painscreek and submit your findings to your editor. The results you choose will be published in tomorrow's paper.
  3. It's a traditional murder mystery. You will find yourself photographing important stuff in-game, and maybe even jot down notes outside the game for easier reference.
  4. There's no handholding and no quest markers. All the puzzles are there right from the start rather than hidden until you found a clue about it, and there's more than one way to crack some puzzles. Should you come across them early in the game and have them solved, you can quicken your investigation time.
For those who are thinking of getting it, Green Man Gaming is currently offering a 24% discount on its site.

Friday, September 15, 2017

We Have A New Trailer


We have a new trailer for The Painscreek killings. Hope you enjoy our new trailer and add our game to your wishlist.

Follow us on Twitter and Facebook.
Subscribe to our newsletter for the latest updates and news.

Wednesday, September 13, 2017

Finalizing Our Game

The past two weeks, we have been working on bugs fixing. We added or removed props and items in our game. We worked on making badges and trading cards. We changed and added some important story plots and information to improve the flow of the story. Then we submitted the game for approval.

FINDING BUGS AND PROBLEMS IN OUR GAME
Some bugs or problems were game breaking, meaning that the problem would prevent the player from continuing the game. For example, if you need a specific key to open a door and if you use the wrong key, the game might freeze and stop working. Or worse, the key disappears. Most of the bugs were found during the last two weeks of play testing. Because our game world is a semi-open world, we went everywhere to find game breaking bugs. We also cleaned up our scripts along the way.

(The books are sinking into the shelf.)

(The drawers are there but the table disappeared.)
  
KEY ITEMS TO IMPROVE THE FLOW OF THE STORY
A common but simple mistake is forgetting to add an important information in the game for the player to find. This particular problem happens when the flow of the story changes, is added or removed. Sometimes, in order to make the flow more interesting and natural, important key elements in the story need to be placed well. We needed to make sure our game is not too short for players, while at the same time not too long and confusing. To improve the game, we also added better content and made sure that each character in our game had a closure to their storyline so there won't be any cliffhangers. We hope players can find all the secrets in the game.

(An example of story flow and how everything is connected.)

STEAM BADGES AND TRADING CARDS
We have an artist who volunteered to do the artwork for our steam achievements. After some brainstorming, we decided how many Steam achievements we wanted. The next step was to implement them in steam so that it can work properly. Since we have a lot of collectibles in our game, we hope that players can follow each NPC’s storyline and unlock his/her achievement. We also included trading cards that will be randomly dropped during gameplay.

(An example of our Badges.) 

CONCLUSION
Ideally, it is best to stick to the original plan before production. In our experience, that did not happen. After fixing all the problems, we could finally submit our completed work to steam. It takes teamwork, dedication, and clear communication to pull off a successful project. We are still learning. There will always be ups and downs, but at the end of the day, we hope we have created something amazing for our fans.

Friday, July 21, 2017

How We Survived Without A Programmer In Our First 3 Years

Did we have a programmer? Truth be told, we did , eventually. However, our first three years consisted of a few CG artists who just wanted to make a game. This was what happened.

GAME'S VISION
When we decided to go full-time into game development, we needed to know if we can pull off the type of game we wanted to make. There was only one category to consider: walking simulators. Thus, we decided to focus mainly on story and puzzles. We gathered inspirations from Shiver: The Vanishing Hitchhiker, Gone Home, and to a certain extend, the first Resident Evil. We wanted the game to be more than a passive ride, and decided to make the game lean towards an investigation. Knowing that we were limited in what we can pull off, we made the game focus mainly on readable content such as diaries and newspaper, keys and items for the puzzles, and a fitting soundtrack for an immersive experience. We also decided to go for a minimalist approach so there will be no in-game mini-map, quest markers, or overhead compass. Regarding characters, we decided that the only character in the game will be the player. As for the music, we will first use copyrighted soundtrack as references, then compose our own later. Even though things did not turn out to be this simple, our vision, at that time, seemed to work. So we went for it.

(One of the village's early design.)

PREPARATIONS & TESTS
Our next step was to list what we need to pull off technically. They are categorized into the following areas: (1) 3D environment and props, (2) terrain and foliage, (3) lighting and  effects, (4) sound and music, (5) programming. Out of all five areas, our biggest concern was programming. However, since we had some experience with Unreal Development Kit's kismet, we felt confident that we could pull it off with visual scripting, thinking that the game only required simple scripts, such as door scripts, item pick up scripts, etc.. As for the other areas, we relied heavily on Unity's asset store. The plugins we purchased and tested were as follows:

Area
Plugin used
Custom shaders
Shader Forge, AQUAS water.
First-person view
UFPS
Visual scripting
uScript
Image based lighting
Skyshop
Textures
Photoshop, Bitmap 2 Material.
Menu & UI
Daikon Forge GUI.
Audio
Master Audio AAA.
Save/Load
Easy Save.
Terrain & foliage
Advanced Foliage Shader, Relief Terrain Pack.

We also studied a lot of tutorials, especially in the area of scripting. We gave ourselves about two years to develop our game. What we didn't expect were, firstly, the unforeseen challenges that crept into our development and second, our estimated 2-year project took 5 years to complete.
THE UNFORESEEN CHALLENGES The original game design had 1 location. By the end of the game development cycle, we had 13 locations. This became a problem as Unity was unable to handle all the scenes, props and effects at once, and we didn't have experience optimizing the game yet. We decided to make every location an instance. This meant whenever the player enters a building, say the hospital, the game would unload the village scene, which the player was previously at, and load up the hospital scene. This allows the game to run better.

(The village as viewed from the Unity game engine.)

We also needed an inventory system, which we didn't know how to implement in the beginning. After watching some tutorials, we ended up looking through the asset store to find a suitable one. Unfortunately, there was none that would fit into with our game's look. If we decided to forgo inventory, we could just make it such that every key being picked up will allow the player to pass through the respective locked doors automatically. However, we decided to go our original idea, which is to provide an inventory for the players.

(Initial design of the inventory system, with mockup images taken from various sources online.)

Our game also had a lot of reading materials. At the start of development, we thought that not recording whatever the players read into a journal seemed like a realistic approach, and it makes it easier for us. After all, a real-life journalist would write notes that deemed important to the investigation, right? However, when the game consists of almost a hundred reading materials, all found in a non-chronological timeline, and some notes containing hints to proceed through the game, players would be confused and frustrated when they are unable to access what they read previously.

(A journal system was eventually added to aid the player when backtracking NPCs' storylines.)

In addition to the game design's challenges listed above, we also encountered technical challenges. One in particular was the conflicts between certain plugins. Since they were created by different authors, some were not tested extensively to work well with other plugins. When problems popped up, we didn't know how to fix them. Going through the forums to find out if anyone had the same problem was like finding a needle in a haystack. On top of that, for every new version that Unity released, a number of plugins showed errors, while others broke the game. We had to wait for the plugins to be updated before we could continue working.
Another technical challenge we faced was visual scripting. Visual scripting was advertised as scripting without writing a line of code, and was targeted at artists. However, it wasn't as easy as we originally thought. At that time, Unity's assets store had PlayMaker and uScipt. PlayMaker had great reviews, but uScipt resembled UDK's kismet and seemed to be the more powerful for us, so we went with it. However, the lack of uScipt tutorials and our limited understanding of visual scripting made it difficult for us.

The final challenge was game optimization, which was the process of making the game run as smoothly as possible on mid-spec computers. Since everything in the game was loaded at once when the game runs, the more assets you have in the game would mean that the game would run slower. Once it dips below 30 frames per second, the game was deemed unplayable. For us, the game would run as low as 10 fps in our heaviest scenes, and that was running on a high-end computer.
If we had chosen to ignore these problems, we would have to sacrifice some essential game mechanics, making the game worse than we originally envisioned. After numerous discussions, we settled on the fact that we cannot ignore the problems, but can compromise between our vision and what we can pull off.

2-YEAR PROJECT THAT TOOK 5 YEARS TO MAKE
When we first started developing the game, we were naive and thought it could be done within two years. The years went by quickly and we found ourselves still fixing the story, making changes to its acts, and at the same time trying to pull off certain game mechanics inside Unity. As we passed the two year mark, we told ourselves that we will make it in the third year. However, that didn't happen. As the story expanded, so did the number of game assets that had to be made. By the end of our third year, we had a partial game with partially finished mechanics. It was a no-brainer that the game was not done.

(Using Trello to categorize readable content for easy referencing when checking the story flow.)

(The furniture list is part of the few hundreds 3D assets made for the game.)

Then we had a breakthrough. A few people joined our team to help create the 3D assets, freeing one of our core member to learn how to code. She became our one and only programmer.
It wasn't a smooth ride. She had never programmed before. She bought and studied a book on C#, took the plugins that we had and dissected them. She also researched on how to create certain custom scripts for our game. Often times, the scripts would not work, and she did not know why. It took her one year to create the scripts needed to run our game. However, she still wasn't able to implement more challenging scripts, such as a journal system for the player. It wasn't until the fifth year that she was able to pull them off. By the time our game development ended, she had created most of the game's essential scripts. The only game mechanic script we ended using from the Unity asset store was Easy Save. We still used shaders and image effect plugins from the asset store as they made our development easier. Plus, the results looked great for our game.

(Painscreek village as seen in the final version.)

CONCLUSION
Can you make a game without a programmer? The answer is both yes and no. Yes, if you know exactly what game mechanics are required, that your game engine you use has the tools that you need, and there are plugins available from the company store or marketplace that you can acquire. No, if you need help beyond the all that is listed above. Could we have made our game within three years and call it done? Maybe. However, there would not be a journal system. The game would be simpler, the game mechanics limited, and the content of a lesser quality. We would also have to work around available plugins instead of asking using custom scripts that work around our needs. If there's one thing we learned from all these, it's that although having a programmer on board is great, you should not be limited by it. As long as you understand your strengths and limitations, have the desire to make it happen, and don't quit when things get tough, you can always find ways to solve the problems.

Thursday, July 13, 2017

Why We Use Unity

To understand why Unity was chosen for our game project, The Painscreek Killings, we have to first share a bit about our background.

BACKGROUND
In 2011, we were doing freelance CG work and teaching high school students about CG. Some students wanted to learn how to make games, so we studied the UDK tutorials. Once we got comfortable with the basic tools, we initiated a UDK group project consisting of several students trying to make a first-person platform puzzle game. That went quite well. We then initiated a second group project. This time, we wanted to try out multi-player. Unfortunately, the programming part proved too difficult for the students and the project eventually halted. However, those responsible for building the assets were able to create a roamable world. That foundation turned out to be the starting point of The Painscreek Killings.


(One of the students working on their project using Unreal Development kit.)

VISION FOR OUR GAME
We had limited manpower and talent, no experience in game development, and had doubts whether we could even pull off puzzle based scripts, let alone anything beyond it. The only genres we could attempt were probably platform/puzzle games or walking simulators. So we decided to focus on what we love and possible our only strength: telling a good story. Since we also understood the importance of appealing visual and immersive atmosphere, we wanted our game to lean towards a film look rather than games.

(Using RealTimeBoard to plan out the story and puzzle flow.)

UDK Or Unity?
Unreal Development Kit (UDK) was our first introduction to the game development world. At that time, there was another game engine called Unity 4. We made a comparison between those two game engines. UDK had a 25% royalty fee while Unity was free. UDK came with pre-installed packages, making the game accessible right from the start, which seemed a good thing for newcomers. On the other hand, Unity started from a blank slate. Yet, that was actually more to our advantage because we had to understand how the engine works underneath. UDK had no marketplace for 3rd party plugins so you will need a dedicated programmer to pull things off, while Unity had an asset store which was a huge boost for beginning developers. Despite the advantages that Unity have, we were still unsure if it was the right game engine unless it could achieve the film look that we envisioned. The only thing left to do is to test it.

UNITY 4 DEMO TEST
We knew that Unity 4 was used in many 2D mobile games and not well known for 3D games. However, our game did not require many things that AAA games have. All we needed was a first-person view, a 3D world, and a decent lighting setup that can simulate a mysterious atmosphere. It turned out that Unity 4 was good enough for all that we needed. We also purchased some plugins from the asset store, such as Advanced Foliage Shader and Relief Terrain Pack, to name a few. The result was a huge boost in the visual department. We felt confident that Unity was the game engine to go for. The success of the demo test, in addition to the advantages described above, sealed the choice for us.

(Testing terrain and foliage in Unity 4.)

(Testing Advanced Foliage Shader and Relief Terrain Pack in Unity 4.)

TRANSITIONING INTO UNITY 5
One of the limitation of Unity 4 was not having bounced light. When Unity 5 was launched, it gave us hope for a more realistic lighting effect by introducing global illumination. In addition, they also revamped the way menu UI are made. On top of that, they made notable improvements to the audio department. The lighting and UI were game changing for us. However, the initial versions of Unity 5 proved to be a learning curve as we moved our project from Unity 4 to 5. Light leaks can be seen everywhere. Many light parameters were not working. Plugins that worked in Unity 4 were showing up as errors. At some point, we wondered if it was a mistake to move to Unity 5. As time went on, the problems were solved, plugins were updated (or depreciated in some cases), and we embraced the advantages that Unity 5 brought. By the time Unity 5.3.4 was released, it was stable enough for our game to run without game-breaking problems. Unity continued releasing further version, but due to the plugins that we used, some altered the way our game looked while a few of them stopped our game from running. In the end, we decided to settle on Unity 5.3.4 and used certain workarounds for the bugs that Unity could not fix in that release version. Overall, we were quite satisfied with using Unity.

PROS AND CONS OF USING UNITY 
Early versions of Unity 5 had a lot of problems, especially in the area of lighting. We struggled a lot with light leaks, unwanted bounced light, broken shadows, and lightmap problems. In addition, we relied on certain image effect plugins to achieve the film look that we need, but when newer versions of Unity 5 were released, some plugins would either be buggy or ceased to work. Troubleshooting the problems were time consuming and frustrating. However, using the Unity engine for our first game project has a few key advantages. First, the Unity Asset Store helped us tremendously, especially in the beginning stages of our game production. We were able to find at least one or more plugins in almost every area of our production. Never once did we feel stuck and hopeless to the point where we could not continue. Second, Unity uses components as its base, which meant that components can be linked or added upon. With that, we were able to create the desired results based on a few modular scripts that our programmer made. It's an extremely flexible pipeline to achieve whatever we want. Third, many changes were implemented in Unity 5 to make it a better 3D game engine. One area, in particular, was lighting. The results we could achieve in Unity 5 surpassed those in Unity 4 by a huge margin. Last but not least, using Unity 5 also meant that we can benefit from further improvements that will be implemented down the road. All in all, we were glad that we switched to Unity 5.

(Depth of field effect achieved using the SCION plug-in in Unity 5.)

(Using the Time Of Day plug-in to achieve the volumetric light effect in Unity 5.)

CONCLUSION
There is a saying that the grass is always greener on the other side. Did we think of switching to a different game engine over the course of developing our game? We did. While working on our game, Epic released Unreal Engine 4, which was really powerful and by the time of this writing, only required 5% royalty fees. Cry Engine showcased what the power of the engine and is completely free. Unity, on the other hand, decided to implement a subscription model which, quite frankly, surprised us. On top of that, many of the amazing plugins that need to be purchased to make Unity great came free with vanilla UE4. At some point, we were even considering going back to Unity 4 so we didn't have to deal with the light leak problems. But one thing is for sure. If for whatever reason we did switch to a seemingly better engine, we still have to face with the difficulties and problems that came with it. Even if Unity isn't all bells and whistles, and not be the most powerful 3D game engine on the market, we were glad to have chosen it because it gave us the opportunity to achieve our dream - making our first commercial game come true.


Monday, April 24, 2017

Going Beyond A Walking Simulator

Everybody's Gone to the Rapture, Firewatch, The Stanley Parable, and the list goes on. The Walking Simulator genre is of growing popularity; full of new ideas and innovation, in which we also want to provide something new to the front.

To be frank, we don't exactly love the term "Walking Simulator" as it sounds dull and dispirited. The term is coined now by the public though, and we must accept it. With The Painscreek Killings, we want to create something that is more than just a walking simulator. We want players to find the hidden mysteries of what took place in a little town called Painscreek, and become investigators of their own journeys. There are no set paths that a player has to follow. The more inclined a person is to explore the nooks and crannies of the town, the more hidden secrets they can uncover.

In the beginning, we weren't sure if we can even make a game. Our first tests started with the Unreal Development Kit by attempting to create a puzzle platform game. Through several trials and errors, we were able to make something playable. That's when we noticed this could be something we can seriously look into trying.

We began research on what we can challenge ourselves into creating with our limited resources. Around this time, a wildly popular title called Gone Home by The Fullbright Company was released. We noticed its formula relying mainly on narrative worked astonishingly well. It hooked us from beginning to end. Looking at our limitations, we knew the "walking simulator" genre was what we needed to start from. We knew what we lacked, so we decided to focus on our strength, which is storytelling. That set the game's direction right from the start. We also decided to lean towards a film look rather trying to push the limit of what current game engines can technically achieve.

We tried to get inspirations everywhere, especially mystery detective stories. One TV show called The Killing developed by Veena Sud, in particular, caught our attention. We knew that it wouldn't be possible to mimic the show, but we wanted the game to have a similar atmosphere and immersion. Thus, we made the game such that it encourages players to search and think what really happened in Painscreek. Finding newspapers, reading diaries and gathering clues to try and find out who really killed those townspeople became a big focus of the game. We feel the investigative aspect of the game made it go beyond just a simple walking simulator.
Over the course of development, we faced numerous struggles as any game developer would. At times, visions within our team differed. Some wanted the game to be as realistic as possible. Others think that the game should be designed from a player's viewpoint in mind. In the end, we decided upon a formula that we believe could work, one where we simplify the game enough to be understandable by the players, yet keeping it at a level where we are not hand-holding them throughout the game. After several in-house and public play tests, we are glad to see that this formula worked.

Our hope for the players is to simply enjoy a mystery solving game. We hope to deliver this and are looking forward to the day when we launch our creation into the world.

Thursday, March 23, 2017

Welcome To Our New Blog!

Hello everyone!

Welcome to our blog where we will be posting regularly about our progress, development news, feature discussion and much more. We will be posting a blog schedule in the near future but until then, keep checking back for new posts. Thank you for stopping by everyone. Have a safe and wonderful week.

Follow us on Facebook and twitter.

http://painscreekkillings.com/