I like the render quality, look very realistic and well integrated with the plate Physics are quite fucked up in that sim, the shuttle goes trough the building as if it was air, the shuttle should get totally designated by the impact Also the full simulation seems to go in slow motion while the cars and people moves on real time The ground destruction looks cool too, and the concept is interesting
At The Amsberry Law Firm in San Antonio, we focus on helping our valued clients resolve legal concerns that have a profound impact on their lives and long-term well-being.
This article is very detailed and meticulous, I have read many articles on this topic, but for this article, you leave me a deep impression and practical application to my life. Thank you for sharing. https://templerun.co
The Rewired team gave a talk on their indie side-scroller made within 10 weeks and talked about everything from the idea and prototyping to game mechanics and challenges.
We are the Rewired team. We’re very excited to share our project with all of you and shed some light on how we approached making a game in 10 weeks. Enjoy!
So, let’s introduce ourselves. Our team consisted of three artists (Nic Belliard, Allan De Paepe, and Lukas Boonen) and two programmers (Nicole Munro and Cas De Smet). We are all soon to be graduated students from Digital Arts and Entertainment in Kortrijk, Belgium.
Most of us are in fact from Belgium, and our programmer Nicole is from South Africa. The last step in our education program is doing an internship at a game company so each of us is in a different studio spread around Europe for the moment. Our backgrounds are also a bit different, some of us already studied something creative such as music or 3D visualizations, others came from different study programs like mathematics and science. But what we all have in common is the passion to create games, this is what brought us together and made us create Rewired.
At our university, the final assignment is to create a game with a team of people, and we could decide who to work with. We knew we wanted to work as a team, as we were all friends who and had already worked together for a Game Jam.
The idea for the game itself came during some brainstorm meetings. The original story idea came from Nic as he thought of a story of the abandoned robot that needed to fight its way out of the factory that built it. Together, we kept building up the story and realized that we wanted to create an experience that would be fun and immersive for the player. We all knew the game INSIDE and that became our main inspiration. Our goal was to tell the story in a world that was captivating yet minimalistic.
Learning new things was our biggest goal, therefore we chose to make the game a side scroller with a focus on non-narrative story and some puzzle elements. These were all things we didn’t know yet how to make or how to begin with. It was a challenge, but step by step we managed to get the result we desired.
What Did Everyone Do?
We all had our own responsibilities. Nic focused mainly on the art, designing the concepts, dressing the environments, creating assets and working with lighting. Allan then focused more on logical aspects such as level layout, gameplay design, puzzles and events, UI and also asset creation. Lukas was more of a technical artist, he worked on characters, rigging, animations, documentation, music, and sounds. The programmers Nicole and Cas worked closely together. Nicole mainly focused on the in-game camera, puzzle mechanics, character mechanics, and general gameplay mechanics. And last but definitely not least, Cas worked on the AI, puzzle mechanics, main-character mechanics and also general gameplay mechanics.
These well-defined roles helped us a lot during the whole process. We all had the feeling that we had ownership of a certain part of the game and strived to make that part as good as possible.
Importance of a Good Story
We wanted to create a story-based game. This meant that the story would always come first so that if we wanted to add a mechanic it needed to have its place in the story.
Because of this, we spent a lot of time brainstorming ideas of how to bring the story to life.
Rewired tells the story of a discarded robot with a developing consciousness that needs to find its way through an old, abandoned factory. His journey starts in a big disposal section of the facility where he quickly gets confronted with the dangers of his environment. While making his way through the factory he will find other robots, some friendly and eager to help him, others not that much… His goal is to escape the facility and find the greater meaning of his creation.
We started by creating key moments of the game which would bring light to some of the backstory. We specifically left the ending open during the first half of development because we weren’t sure what we could achieve considering our time constraints. Once we decided on these ‘key moments/ rooms’ we could easily create filler rooms between them to explore our bespoke mechanics.
Defining the Art Style
The art style had to serve the project. We didn’t have a lot of time and we all wanted to make a beautiful game. Inspired by the style of INSIDE we created our assets pretty low poly and with almost no textures, focusing on shapes and silhouettes. Rewired was going to have a contrasting look, we wanted to use darkness and light in a way that kept the focus on the important parts of the game but also show the detailed environments. Because of this, we knew the shapes of the assets we created were critical.
We let ourselves be inspired but we wanted our game to be different, not a pure copy. That is why we used contrasting colors and lights. You can see our use of light throughout the whole game. Different colors had their own meaning, we needed this to make the puzzles clearer and let our story come across better.
Another important aspect of contrast was that we gave more detailed textures to our characters. We did this so the characters would pop out more and show their importance in the game.
The Process of Making Rewired Feel Alive
As the key points of the story were decided on, Allan started to work on the level layout of the whole game. These were rough blockouts of the rooms that followed the story. We defined which rooms were story-focused and which were puzzle-focused, this helped a lot in the process of creating the layout.
While the blockout was in the making, Nic started on dressing the rooms. Using all of the modular assets we created in the first two weeks he started making the empty rooms feel more alive and gave them a purpose.
If a room was fully designed and dressed we reviewed it. The designer looked mainly at the area where the player would walk to see if the gameplay works and the artist would look at the background to see if the story fits and how we could improve it.
We constantly reviewed our environments, seeing if we could improve them every time. Towards the later passes, we started adding animations. Some of them were purely esthetic such as spinning fans and working robots. Other animated objects were more focused on gameplay, creating a tense feeling and keeping the player interested. Examples of these were dropping boilers and driving cars. Lastly, we had background animations that had more of an explanatory purpose to show the player what he or she can do or what should be done. The best example of this would be the routine robots in the ‘head transfer room’. They were placed there to show the player the ability to transfer your head/consciousness in a clear way without using text or narration.
Another important part of making a game feel alive is having intuitive gameplay. This was a pretty big challenge, as none of us were schooled as game designers. Before development, we created a prototype that already displayed our core feature, the head transfer. This was our most original mechanic. The idea is that you can shoot your head off of your body. If it hits another robot body it will latch on and you’d be able to control that body. Already having the main mechanic working in the prototype was perfect. From then on we knew we could build up the game further and introduce other robots.
Each of them behaved differently and had their own unique ability. This added variety and a sense of progress to our game. The feature also worked great in scoping our project. We had way more ideas for different kind of robots than the ones that made it into the final game. As the weeks went on we could evaluate how many different robots we would be able to implement.
Combining the Best of Both Worlds
The environment design for each room always started from a game and story design perspective. We had a vision for the buildup of the story, so we knew which kind of rooms the main character would encounter along the way. The level blockouts were always created before the rooms got dressed. These blockouts focused on making the spaces playable. So by the time the actual visuals of a room had to be determined, we already knew which part of the story it held and which gameplay elements would happen in the room. Additionally, another part of the blockout stage was determining the main camera angles for each room. All this combined made it so that by the time an environment was dressed a lot of key elements were already pinned down.
The main takeaways were that good planning, being very diligent at not integrating features without story or function and clear job descriptions helped us a lot with making all the rooms interesting and meaningful.
Final Touches on an Immersive Experience
To make the world of Rewired truly feel alive we added small animations in the background and a lot of really immersive music and sounds. Music is a really important part in a non-narrative game and luckily we had the man for the job on our team. Lukas took this role onto him and really made it a masterpiece by creating almost all of the music and sound himself. He made sure the music suited the environment where our little robot would pass by. We were actually really impressed ourselves when we found out how much tension, emotion and just general atmosphere you can create with the right music at the right time.
How to Fit a Big Dream in a Small Project
Because we had a big game in mind and a very limited amount of time, we needed to cut corners. The main things we did to save time were using real-time lighting and using more complex assets off the internet, changing them to suit our needs.
We’re big fans of the look and ease of work that UE4 real-time lighting brings. Combined with volumetric fog and smoke particles it just looks amazing really easily. We decided to use that feature as much as we could. We dressed up all the environments with real-time lighting in a first pass and then went over the rooms again deliberating which lights were absolutely necessary or which lights could be baked. This was a very fluent workflow, it allowed Nic to go totally crazy with the dynamic lights and push the look of the game as much as he could. It also prevented us from having to bake lighting, which saved us a lot of time.
But of course, this led to performance issues towards the end of the project. Before we did the second pass on all the rooms, the game would run very slowly because of all the dynamic lighting and god rays. Then we had to go through each area of the game and bake the lighting where possible and limit movement of objects that could cast shadows. We also found that a lot of the 3D assets in the game had way too many polygons for what they were – so we used Unreal Engine’s LOD tool to reduce the number of polys by 50% – 90%.
This also helped with performance because shadow casting wasn’t being done on as many polys. After working hard on optimizing all these things we were able to get the performance back to a decent level.
So to summarize, this workflow is very useful for smaller projects but you have to be really careful about not killing your games performance. In the future, if we wanted to expand the game at all we would have to redo the way the lighting was initially done, just because it’s so heavy on the GPU.
Mechanics and Story
When talking about fun mechanics and story, coming up with the ideas wasn’t really the hardest part. Before the project started, we came together one night and talked about what we wanted to do. We did some brainstorming, wrote down what we came up with and tried to not say ‘no’ too much. Over the course of the project it often happened that someone would say ‘Oh boy, it would be so cool if … ‘. It’s just a part of being immersed in your project and caring about your little robot character.
The bigger problem here is choosing the right ideas to go on with. Due to the short amount of time we had, everything had to go fast. We had a huge list of things we wanted to put in the game and that list needed to get shorter.
To do this we spent the first 2 of the total 10 weeks on prototyping our mechanics. This meant testing out different robots and their features, trying different room compositions and the mechanics we needed for puzzles (buttons, doors, elevators, production lines). It also meant talking about the story and pinning down moments that were important to us. We tested out as many things as we could during these first two weeks. We had to give up on a lot of cool ideas, such as a robot that could sling form one point to another, but from the start, we all agreed that we needed to keep the list of features as short as possible because we were not going for quantity but for quality. During this period of prototyping, the programmers implemented mechanics as fast as they could. This involved dirty coding, chaotic blueprinting and bad naming conventions.
The artists then set out to design puzzle rooms. These rooms had no place in the story, but were just singular areas with the goal of ‘get to the next room’. Every time a new feature was finished, the artists could then quickly implement it in a room, to test its possibilities. As we were all technically schooled, even the artists could implement some small mechanics if they needed them fast. This meant we could test a lot of puzzles concepts really fast, practice doing game design and research decent working conventions. So if we talk about game and puzzle design, we have to emphasize the importance of this prototyping phase.
For the rest of the project we had one team member, Allan, that was dedicated to game and puzzle design. He blocked out all the environments and had final say over the layout of the game, the functions and puzzles in each room. He did a great job keeping a clear and coherent view on the puzzles and game layout.
Designing the puzzles was interesting. Knowing you had to create a puzzle that needed to be original and difficult enough for the player to enjoy solving was a challenge. The puzzles that made it into the game were actually designed during the creation of the rooms, we did not have/use any pre-designed puzzles that worked similar to the final in-game puzzles. This was because it was easier to create a challenging obstacle with the room already in front of you instead of creating a puzzle on a blank sheet.
The biggest test for Allan’s gameplay and puzzle ideas was letting other students playtest our game. We let around 20 people playtest Rewired while the team was watching them closely. We made notes from every playthrough and reviewed their experience afterward.
We soon came to the conclusion that people loved the atmosphere and the story. The puzzles were challenging enough to keep them interested and eager to solve them.
Completing the Rewired Challenge
I think our biggest challenge was containing our excitement for this game. We all wanted this to be a huge, immersive and complete game. In the beginning weeks, we were actually planning on making 5 different chapters but we quickly figured out this was going to be impossible to achieve in just 10 weeks. Because of this, we cut the story a bit but we made sure it still had a solid beginning and end. Solving our ‘excitement issue’ came down to good communication. We just had to talk to each other, see what plans would be realistic and take time to lay out those plans properly. Every week we had a checklist of things we had to get done. If something didn’t get done we would review the feature and see if it was still important for the project. By constantly evaluating our to-do list we could keep ourselves and our expectations of the game in check.
We are not sure yet what we will do with our project, for the moment Rewired is more of a playable concept rather than a game. In our opinion, Rewired has a lot of potential, but because we’ve all moved on to working in big games studios we have no further plans for the game. We would love to put the game on Steam – so that everyone could have a chance to play it an enjoy the concept and the experience we created.
We hope you enjoyed this article! This project has been an amazing experience for us all and it lies close to our hearts. But for now, we will all go our own way and see what the future holds for us in the gaming industry.
Sincerely, the Rewired team
Interview conducted by Kirill Tokarev
Amplify Impostors for Unity 3D by Amplify Creations is an optimization solution that uses next-generation Billboard Impostors*
*Impostors are camera-facing quads, or simple polygonal shapes, that replace complex geometry by rendering a fake 3D representation of the original object