Game Title: Metal Masters
Client: Skillshot – Schueco
Client’s Goal:
Skillshot aims to create a game for their client Schueco.
The game’s objective is to educate people (also new hires of Schueco) using the mini-games and also promoting how the metal industry developed over the course of the years and how it is more easy now compared to before promoting more applicants to the metal industry in general.
The game has 2 phase and it will include the ff:
Phase 1:
Phase 2:
The target audience for the game is working adults and also the game’s language should be German by default not English.
As a six-person team, extensive references of the machines were essential for our project, which the client provided. These references served as the basis for creating 3D models, where we optimized polygons to ensure suitability for the game environment.
Collaboration with the client involved outlining their vision for portraying the metal industry and providing models and images of the factory to be incorporated into the game.
Initially focusing on the old metal industry and ore mining, we began by creating a map and constructing a hut/house with a forge and crafting tables for phase 1. Upon receiving images of the factory, we proceeded to develop the map for phase 2.
Although prototyping would have been ideal, time constraints necessitated skipping this step. Instead, we expedited the process by immediately laying the foundation, including creating maps, models, and initial code. Recognizing the complexity of the coding required and our limited time frame, we opted to engage an experienced coder on a commission basis to expedite development in areas where we lacked expertise.
With the decision made to forego prototyping and enlist additional coding support, we were confident in meeting the project deadline, and production commenced accordingly.
After receiving all the references and docs we needed, we started mapping the timeline needed for the game.
To get to finish it in 2 months time, we didn’t create the products and jump on the production from the get-go. The good part is, client was active enough to provide us quick feedback on the models so we can change without it having much effect on the whole game.
We quickly run through the map which has the important factors a mining area and a hut/house with a forge. Mapping the map was easy, creating the models to fit the mapping was the hard part since we don’t have proto-types.
The mining of minerals going to the inventory and then going to the forge was hard so we call this an inventory system. This we will leave at the hands of the experienced coder that we will commission so it will not get in the way of use wasting time for testings stuff since we are racing against time and we do not want to compromise on quality.
The correct sequence of the game was like this.
With Roblox Studio for our map creator and main tool to create in Roblox, we started with the map creation, we develop the terrain first in Roblox Studio. Then we map out the coordinates including hut/house, carts, rail tracks, cave mine, signposts, etc.
After we mapped out the coordinates, we started modeling the all the asset in Blender 3D and textures are mostly adjusted in Photoshop and Paint3D.
Roblox Lua is the code we used so it’s fairly easy (compared to other game engine programs) to script simple movement and texts. While we were very wary on how the programming will do in the production, it went off great.
Over the past few days, several calls were made to see if the models would satisfy the client since we do not have a proto-type this is a must as changing models especially the products later would prove inefficient and can cause problems in the code.
We had a problem on understanding the process of the game, so we needed to reprogram, the one written in the pre-production phase is the correct one, initially we made it the other way around where-in player’s don’t get to click the ore and it’s automatically deposited.
Another problem was since there was no inventory system yet we’re stabbing in the dark on some textures/models, that cause the reprogram issue too. That said, all of it was not major and game breaking. It was fixed after syncing the model to the program once it was given to us.
The hardest problem we faced was the crafting table going to the final product. We misunderstood that it would only limit to the ones the client gave but they want all of every possible combination of the products. While we’re not reprogramming, that’s a very very long set of codes as there are around 100+ combinations.
This issue caused phase 1 to overlap with phase 2 which was a very big deal so we had to do overtime to compensate on this issue.
The teleporter going to phase 2 from phase 1 was also good. It was an addition late in the game creation but it was fairly easy so it was added.
Phase 2 was more easier than Phase 1 but Phase 1 production overlapped with Phase 1 pre-production so timeline wise it is much tighter. We finished the map of Phase 2 a few weeks after finishing Phase 1. The machine models were provided and we had to reduce the polygons to make it usable for the game. The polygons were way higher because I think the models are use for studying or some kind of mechanical stuff even the gears were sync. That said, since we’re gamifying it, we don’t need the a actual engine that is not visually seen in the game and it’s not also gonna be used in the code.
No real issue on reducing the polygons, it just takes a lot of time. An analogy would be, it’s like when you’re editing a picture and you can’t get that one dot, you have to zoom in and zoom out then multiply those dots into a thousand with large spaces between them and in the middle it’s something you can’t delete.
Since we don’t need proto-types because of the machines, we just needed to add metal bars, metal casing, forklifts, computers and a couple of lightings and high ceiling storages. Once client approved of the models, we go into the production phase.
Phase 1 still overlapped up to this point so schedule is still a bit tighter but no problems on the codes as it’s much more easier to code a 2D image than a 3D image. The only hard part on this one is that we keep getting a different result on the true and false system.
To explain the sequence, it goes like this:
There will be 2 scenarios on this. Either it will tell you wrong product or it will tell you the game is finish and you can restart to Level 1 or Level 2.
This is where the problem lies, we keep getting a different result on the true and false system even though the correct male and female was picked. While it’s randomize, the code was made so that we have a true and false so it would get the 2 scenarios in the forklift. To be clear, only 2 scenarios are wrong and you’ll only get that if you deliberately wronged yourself specifically if you start on the 2nd machine first and copy a tile there to create on the 2nd machine. Nonetheless, it was still not the right scenario so we had to fix it.
In the end, we needed more time to fix it. Fortunately, the event the client had was moved and we had enough time to fix it.
At the end, no game breaking bug so we just needed the time to sort and find the minimal bugs from models down to even the SFX(sounds) of the game.
In summary of the testing phase, extensive testing uncovered issue. Aside from the ones said above, the other issue which was always there was the translation. The game’s default should be German so we had to get in contact with client often to get the translation of the words.
External testers were also enlisted to provide fresh perspectives, leading to further refinement.
Following the client’s thorough testing and feedback, final adjustments were made for a seamless user experience.
Since their not aiming for monetization, the game doesn’t have a Robux income engagement, it was meant for educational purpose so marketing and promotion was not put in to mind. That said, we still set up a description for the game as a from of what the game would be. With the approval and checking of the client, it was put into action.
Once all was said and done, created a group and upload the game there. Then we made them managers of the group and we’re the developers so we could edit the game whenever they needed us to edit it.
While we are not sure if the game achieved educating people we know that the event they showed it went great and their client – Schueco liked the game.
Recently, they added Xbox controls. Aside from that, no future plans for expansion yet. They did say they want to have a “metal wars” game but no action was made yet.
It was not a smooth sailing one but we did it. With the right planning and coordination we were able to ultimately finish the task. Was it hard? Yes, it was. It was also satisfying, the 2 months we spent on the game, we learned so much stuff.
Our game’s primary appeal lies in the realism of our models, particularly the Schueco machines and the dream factory, which are meticulously designed to resemble their real-life counterparts, albeit gamified. While we may not replicate every detail, the resemblance is unmistakable upon first glance.
With a larger team, increased budget, and extended timeline, we could enhance both the quality and speed of development. The timeframe required to complete the models and map was reasonable for a three-person team. However, with a team of six individuals, each with their designated tasks, we could significantly expedite the process. In fact, with the resources of an estimated eight-person team and a substantial budget, we could achieve even greater results.
Expanding the timeline would not only allow for the addition of more team members but also the incorporation of more intricate models and potentially even real-life scale sizes, further enriching the gaming experience
Stephen, our adept 3D modeler and planner, brings a wealth of experience in crafting intricate digital landscapes and structures. With an eye for detail and a knack for strategic planning, Stephen ensures our projects are not only visually stunning but also meticulously organized from conception to execution.
Reynel, our talented script writer and programmer, is the creative force behind our interactive narratives. His expertise lies in weaving compelling storylines with intricate code, ensuring that our projects not only function seamlessly but also engage and captivate our audience on multiple levels.
Ryan, our skilled 3D modeler and map designer, possesses a remarkable ability to breathe life into virtual environments. Through his meticulous attention to detail and innovative approach to spatial design, Ryan crafts immersive worlds that transport users to extraordinary realms of imagination.
Darius, our dedicated GUI designer, is the architect of user experience within our projects. With a keen understanding of user interface principles and a passion for intuitive design, Darius creates visually stunning and user-friendly interfaces that enhance accessibility and elevate the overall user experience.
Jeremy, our visionary icon and visual designer, adds the finishing touches that elevate our projects to new heights of aesthetic excellence. With an innate sense of style and a flair for creativity, Jeremy infuses our work with captivating visuals and distinctive branding that leave a lasting impression on our audience.
Raul, our meticulous tester and bug checker, ensures the quality and functionality of our projects meet the highest standards. With a keen eye for detail and a systematic approach to problem-solving, Raul meticulously identifies and resolves any issues, ensuring that our final products are polished and flawless before they reach our audience.
Company Address
Contact Us
© 2024 Pearl Lemon Games | All rights reserved
