Hard surface 3D model references

For my final assessment in my 3D class I have to create a hard surface 3D asset. Below are some ideas and links to pinterest boards with reference images I'd use to create the model.

Idea 1 - Steampunk Airship

I've always been a fan of the steampunk genre. Most of the steampunk images and media I've seen have been containing super fancy airships. These have been similar to boats, with sails and hot air balloons. Below you can find the link to my pinterest board with some nice reference photos of airships I'd be interested in making. You will also find the VASA ship, a Swedish royal ship, known for carrying so much adornments and cannons that it didn't even make it out of the harbor on its maiden voyage. I put it there because it'd be fun to try and make something similar as an airship.

https://www.pinterest.com.au/victorweidar/airships/

Idea 2 - Junkyard Rocket Launch Station

At the start of our course in 3D modelling we were told it was OK to create assets for our own game. Because of that, I wanted to create a rocket launch station as that is the main point of interest in my newest side project. It is also set in a junkyard so i want it to be constructed out of different scrapped materials and roughly bolted together.

https://www.pinterest.com.au/victorweidar/junkyard-rocket-launch-station/

Idea 3 - Steampunk Rifle

As I mentioned I am a big fan of the steampunk genre. I think there is a lot of potential to detail when it comes to 3D modelling and there is a lot of interesting fun part to model. As a dungeon master for a D&D group, I tend to create worlds and stories. Recently I have created a massive world that I keep building on and make games take place in as part of a massive world-building project. In this world, there is a city famous for it's production of weapons. These weapons are steampunk weapons and with that I will place the mark of that organization on the rifle.

https://www.pinterest.com.au/victorweidar/steampunk-rifle/

Idea 4 - Crystalline Sword and Shield

In my D&D campaign I introduced an item that was essentially a sword and a shield combined, made completely out of a slightly transparent, purple crystal. This asset would essentially be that weapon.

https://www.pinterest.com.au/victorweidar/crystal-swordshield/

Idea 5 - Golem

Golems are usually massive hulking humanoid creatures created out of various materials. Because of my interest in robotics, steampunk and fantasy, I decided to pick Iron golems for this final pick. Much like steampunk, there is a whole lot of interesting details and styles you can put in a golem.

https://www.pinterest.com.au/victorweidar/golems/

 

 

Modeling/Animation Production Pipeline

This post will outline the production pipeline for animation and 3D modeling, as part of my elective module for university. I will cover 9 different topics, from pre-production to compositing, and explain what they are and give examples of what they look like.

Pre-Production

Starting off with pre-production, or as many also may call concepting. Concepting can be anything from collecting a set of reference images on pinterest, sketching something on a piece of paper, or taking a photo as a reference. It’s important to have visual aid with you every time you are about to sit down and model so that you can keep a consistent idea of what the final model is going to look like. These reference photos can be placed inside most 3D modeling programs to model after, which also allows you to get accurate measurements of what you are trying to create.

World of Warcraft Weapon Concept Art

3D Modelling

So when you have your reference photos all set up it’s time to start modeling. 3D modelling is essentially like modeling with clay (there are several products that act exactly like clay) but digitally and with polygons. For example, a cube is made out of 6 sides, and therefore has 6 polygons. A good way to think of them is sheets of hard paper that you stitch together into models. Where these polygons connect, there is always a vertex. These vertices are dots that when interacted with move all edges attached to it. Edges are essentially that, edges or lines. Below are some examples of this. The highlighted areas are the ones mentioned above.

Texturing & Shading

Texturing

Texturing is the process of applying images or paint to a 3D object. It is a very complicated process that requires a few procedures, one of which being UV mapping. In order to paint on a 3D surface you need to flatten it out to a single 2D image. This is what UV mapping is. Once you have a UV map image you can hop into any drawing program that you like and start drawing on it. This is then brought back into the modeling program and applied to a model.

Shading

Shading (in 3D modeling terms), is telling your application what material the object is made out of, for example iron or brass. This is an alternative to texturing where the detail might be more in the model itself than on the texture. For example, for the robot model above, instead of using a painted red for the body, I could have used red metal shading, at the cost of the detail.

Rigging & Animation

Rigging

If you want to make a model you have move and animate, you first have to start of with the rigging. Rigging is the concept of placing a skeleton inside your model, with control points that are then used to move the skeleton around so that you can animate it. Usually, the control points sit in all the joints of your model, so that you can rotate them as well as move them at the same time. Then you have to bind the model’s skin to the bones, so that it moves and bends naturally. This can be done using a method called Vertex painting, where you decide how much each bone influences each vertex by painting them in a “colour”. White represents 1, which is fully influenced, and black represents 0 which is no influence.

Animation

It’s time to make the character move. To do this we have to get used with the terms “frame” and “keyframe”. A frame is a part of a second and on each frame the position, rotation and scale can be recorded. If that happens, it becomes a keyframe. There are 24 frames in a second, and if you’ve recorded the position of an object all 24 frames of a second, the 3D program you are using will create an animation out of the keyframes.

Lighting

Lighting in 3D animation is pretty straight forward. It is used to light up a scene in the final render. However, much like in any type of media, the lighting is used to set the mood in your scene. It might depend on the angle the light is coming from, how many lights you use in your scene, or what colour you are using for the light. There are also different types of light, and I will list the most common ones here. There are spotlights, that project light in a cone. There are Point lights or omni lights, that project lights in all directions originating from a specific point. There are directional lights, that most people tend to use as the sun. Directional lights light up the whole scene from a certain direction, still casting shadows. There is an alternative to this called skylight, which illuminates an entire scene but doesn’t cast shadows. It creates a sort of natural light. Finally, there is area light, which creates a softer light from an area. Sort of as if you were to have a light the size of a window and aimed it at an object.

Rendering

Rendering is technically the final stage of 3D modelling, where everything in your scene is placed into a single image that the application, with assistance from your computer's settings, creates for you. It all boils down to the press of a button, but there is a lot of tweaks and settings you can use to either render more efficiently, or to alter the way it renders with the help of filters and so on. In an animation for example, rendering would take a very long time since a video is consisting of several images that each has to be rendered with the effects.

Wherever you go to watch 3D modelling work, you’re most likely to stumble upon renders. It is the best way to get light and other visual effects into an image that looks fantastic. Above this you can see a picture of a blacksmiths station. That image is the final render of a scene that has used many of the techniques that I’ve talked about above.

Compositing

Compositing is combining visual elements together into one single media. For example, If I were to make an animation of a robot, and with the help of shading and lighting make it look realistic, and then finally place it in a video, that would be compositing. Using a green screen is a type of compositing, but also using photoshop to combine different elements.

There are different ways of doing this. Part of the compositing progress can be rendering the image in layers. For example, first doing a reflection render that only renders the shiny-ness of an object. Then on top of that doing a highlight pass for edges and a beauty pass for the textures itself. These can then be put together for a final image render that is also part of the composition process.

Bibliography

Birn, J. (2014). 3D Compositing at 3dRender.com. Retrieved from http://www.3drender.com/light/compositing/index.html

Hunt, A. (2015). Introduction to 3D. Retrieved from http://www.cgstudentawards.com/magazine/entry/introduction-to-3d

Slick, J. (2018). Get a Brief Overview of the Complex Process of Rendering. Retrieved from https://www.lifewire.com/what-is-rendering-1954

Scrapbot Dev Diary #1 - Level Design and Early Choices

Hello and welcome to the first non-forced blog in quite a while! This one is all about a personal project of mine, that I have been working on to and from for a few weeks now (trying to relax on a break and still work is a bit hard for me still). In this blog I will be discussing the main idea, then talk a bit about some design choices i’ve made, and then finally talk a bunch about the level design, as that has been the main focus these last few weeks.

So let’s start talking about the idea itself. What I wanted to go for when making the game was a Mario 64 or Banjo Kazooie feel. Kind of an open world platformer where you collect items in order to progress. I wanted to make something that didn’t use many difficult programming elements, as I had decided to make the game in Unreal Engine 4, rather than Unity which I am used to working in. My game had two characters. Two different robots that the player could switch between in order to complete puzzles and challenges. The original idea was that the player could collect three different types of currencies that would be used to construct different tools (like launch-pads) to assist the player further. The main goal of the game was to help a third robot (NPC) to go to space in a massive rocket that is located in the middle of the map. As for the map itself, it was split up into four different areas that I would lock off and release over time as I developed this project. This was the original Idea for the game, however below I will talk about some design choices and issues I encountered that changed the game slightly.

First off is my choice to remove character swapping and two characters. In a game world as “open” as mine, it would be tedious to only move one character at a time to move across the map. It is probably countered through the level design itself by moving the characters in small increments, but it didn’t correspond with what I wanted for the game.

First iteration on level. one part of several massive quadrants that would progressively be released after game release by me.

The second issue was the map size. I liked the thought of having different zones, but I eventually realized that I probably won’t want to work on this for another few months to fill out all areas with unique ideas and content, so I removed the zones and decreased the overall map size. Because of that I also had to decide what activities I wanted to include in the game. I started off with trying to come up with four different activities, one for each quadrant. However I ended up changing it to four jumping puzzles instead, as I wanted to focus on the level design and platforming aspects of the game, rather than amount of mechanics. So the final decision became four jumping puzzles starting in or being located in, the different quadrants.

New iteration on the level design. This iteration features a significantly smaller level with objectives all around.

Upper Left Quadrant of the new level. Here I have mapped out a jumping puzzle and all it's possible paths as well as locations of bolts.

Next up was some smaller changes that I had implemented, but then decided to remove completely. One of them being the three currencies. I had nuts, bolts and springs that all were made for the player to collect. However, none of them had any specific purpose at all, so I removed two of them, keeping the bolts. The reason for keeping the bolts was partially because I feel like bolts do more good than nuts, but also because the internet has ruined me and I didn’t want to keep writing nuts in my documentation. The second issue I had was the mechanic to carry items. Originally in a very early idea I wanted the player to be able to have to place boxes on pressure plates to move through puzzles, but since this became a jumping puzzle based game instead, I decided to remove the functionality completely.

Since I have one of the quadrants ready for grey-boxing, I wanted to dive in to unreal engine and start mapping out the area and test the size of the level, as well as get used to exporting from maya to UE4. The first step was to create a cylinder that would cover the size of the level. Since I had made the level smaller from the start, I decided to make the radius of the level 50 metres, rather than 80. This however, was incredibly far, and it could take me as much as 3 minutes to reach the end of the level, which was way too far. I tried changing it over and over again, and eventually ended up at 15 meters. It's around this point that I figured out that since 1 unreal unit is equal to 1 centimeter, that means that 10 unreal units is 1 meter, meaning that my "50" meters actually were around 500 meters. So my 15 meter radius made more sense as a 150 meter radius. This 150 meter radius was a pretty good size since it didn't feel too long nor too short. I played around as well with the size of the crater the map is in, and the size of the rocket in the middle. I wanted the rocket to be a very clear center-point so I needed it to be visible from everywhere.

Level design test, with final size iteration of 150 meter radius

Previously in my degree one of my weaknesses was to ask “why” questions. Why do I implement X, what purpose does it have? Does it add to the game experience? If the questions were no, then there is no reason to have it in the game. For this project I think I have evolved in that field significantly, and I believe my game will turn out better for that.

Darkness Dwells - Metrics and Research

During earlier blogs I have talked a bit about promotion and social media and I have talked a bunch about research, but I haven’t really concluded how it worked out for us or what we did with feedback that was provided to us. That is the purpose of this blog.  

On social media we very early on made a twitter and Facebook account that most members shared with their followers. On these social medias we kept posting pictures and teasers for the game, but most importantly, we used twitter polls. This allowed us to sort of gauge out what our audience enjoyed at the same time we were developing the game. It also allowed us to be more in contact with our audience and show them that we were interested in their opinions in order to make our game better.  

What we found out through the social media and out of assumption testing was that most people that enjoyed horror games enjoyed challenge with it. Making it a struggle for survival and getting the adrenaline pumping even harder. We decided to take this into consideration when making our game, hence why we added the radio and the use of the bed monster. The bed monster originally wasn’t supposed to be a threat during the entire game, but upon testing the game and having it feel to easy, we made it so that the player has to try and balance the bed monster with everything else happening in the game. On top of this, we added the radio, which makes all the monsters appear faster unless the player turns it off, adding a new layer of urgency and challenge.  

It is not a surprise that streamers and youtubers enjoy horror games, for the main purpose of overreacting to them. Somehow, it seems to attract a lot of views. views that we can guide to our page. The game was originally made with youtubers in mind, which is the whole reason why the game is based around jumpscares. Due to research made by a teammate of the project, we managed to find out that generally people do not care if there is a lot of jumpscares in a short amount of time. Naturally we used this to our advantage and based our game around this as part of our core mechanic.

I believe it is due to our research and interaction with the audience, that darkness dwells at this point is number 3 on most popular game on itch.io, and have been featured on the front page. Thank you for reading this short blog discussion.

Darkness Dwells Post Mortem

What Did We Do?

Darkness Dwells was a continuation on the game developed by Scott Anastasi the trimester before this. In that game, you played a child seeing monsters appear and finding comfort in your parents presence. For this project, we took that game and built it into a horror game where you have to try and keep the monsters out, only using your flashlight. The player had to try and stop three monsters, Longtooth (in the closet), The Gremlin (on the rocking horse) and UnderBed (take a wild guess). Each monster required a different tactic to handle. But there was another factor. There is also a radio that speeds up the rate of which the monsters appear that the player had to turn off.

What Went Well?

During this project our team performed really well in all fields. We communicated often and clearly about what we were working on and when. We discussed changes with each other and made sure we compromised if not all agreed. As project manager I tried to make sure that everyone had something to do at all times, and often tried to tie that into the specialization that that person wanted to use.

As a team we worked closely together with two animators that made the main character models for us. We treated them well and made sure to give them proper feedback and the praise they required. There was large amounts of trust between the game developers and the collaborators, and I think that the trust we had for work to get done was a crucial part for the games completion. We could not have been where we are today without their splendid work.

We used project management tools such as Hack’N’Plan and development schedules with excellency in order to get work done on time, with great success. We scoped when necessary and managed to pivot and change upon feedback with ease.

In my opinion the teams marketing was fantastically executed. We made up a plan, and acted upon it. At the point I am writing this, the game page on itch.io has 1278 views and 342 downloads, as well as being the number 3 most popular game on itch.io. We have had several people play the game and upload the video to youtube where it has received high praise.

What Didn’t Go Well?

This game has been my second game as a project manager, and there was a lot that went wrong with it. I enjoy being project manager, but I believe that some of the things that went wrong was that a) no one really wanted to be project manager from the start, so I stepped in just because we needed one, and b) I didn’t feel super engaged with the project for a while, so I found it difficult to do much work for it.

Nevertheless, I pushed through my feelings and tried to do my best, and it started off pretty good in my opinion. However, I as a person am very passive, and I don’t make a lot of noise when things go against my preference, so when team members started going off the schedule or started giving orders to other members, I didn’t really speak up, making it feel like I wasn’t actually the project manager.

In order to better myself for future projects, I need to speak up more. I need to start taking a stand if roles or schedules are strafed away from, and make sure we end up where we want to be. I need to try and be more inspiring and helpful, while making sure everyone does the work they’re supposed to do.

What Did I Learn?

Working on Darkness Dwells made me learn a whole heap about what being a generalist means. I got to take care of Localization, UI, Options, and many other things I haven’t touched as much before (except for UI). It was a very enriching experience and helped me accept that I am a game designer as well as generalist, instead of trying to find a specialisation.

This project taught me a whole bunch of useful information about marketing that I had no experience with before. I now know how to find a market and make a game that panders to that market, as well as creating a brand/identity and promote all of that on social media. I learned about price points and about making assumptions and researching those assumptions for the selected market.

Darkness Dwells Marketing and Branding

In the brief for Darkness Dwells we were told that marketing was going to be a big part of the development. In fact, it was the entire reason that the game was created from the start. To take an existing game, research the market for it and then start creating a brand and promoting our work online to gain an audience before the game was released.

Marketing & Promotion

For the marketing itself, we really enjoyed the thought of having the fan base try to decipher the story or the origin of the characters. To do this we planned to post images and Gifs as much as possible to attract audiences early on. The whole point of this was to make them curious and start sharing ideas and theories about the game and its story.

When we sat down to talk about the market for our game we decided that twitter would be our main platform, as it is easy to share posts with your followers there, but also using Facebook to try and reach that audience as well. We did a bunch of research into horror games and what their price points were, as well as what type of content you got for what price and what the users thought about it. We also made some difficulty assumptions, which was based on an assumption that horror game players enjoyed challenge in their horror games. Fortunately, our assumption was proven correct and it allowed us to shape our game to be more difficult. Our market for darkness dwells were mostly YouTubers and horror game players. The main reason for us using YouTubers were because they tend to fake being scared and therefore gain more viewers. More viewers for them would hopefully translate over to more downloads for our game.

In order to reach a larger audience we were given the tip that we should use localization, meaning we add language options in order to reach other countries as well. One of the main languages (that also is a big portion of the games market) is simplified chinese. It shocked me to find out how much the percentage of purchases used simplified chinese as a language.

Branding

For the branding of Darkness Dwells we early on noticed that we really enjoyed Longtooth, and because of that he became the main monster for our game, much like Freddy in the Five Nights at Freddy’s franchise. Because of this we decided to use him for a ton of promotional material including banners, logos etc. We thought it would be important to have a distinct character that would give our game a recognizable face.

Above are some of the marketing material used to promote the game and to create a brand out of the character Longtooth.

The results of this plan will be posted in the post mortem for the project, which is being posted in a few days, so keep your eyes peeled for that.

Thanks for reading

Fullmetal Barber Testing Process and Design Choices

During Fullmetal Barber , We went through several pivots and changes, and most of the changes were made while testing our game. At the start of the project, we sat down to create a testing plan, and we all agreed that testing constantly during development would be the best course of action, while then using the Synergy exhibition as a final playtest with people that hadn’t seen the project before. We managed to act upon this fairly well and because of this we managed to root out issues and fix these rather quickly.

Our process of testing was as follows. We decided what we needed to test, and what we wanted to find out from the test (E.g. does is the game too accurate). We then consider whether it is something we want to test ourselves or have someone else test for us. Whoever was testing, we took notes on their feedback or behaviours that happened in the game or in the minigun itself. We then sat down to discuss the feedback, and after that went on to take action against it. Whether it be scrap the feedback or implement it, we made sure to listen to it and consider if it was something we could have use for in our game.

One piece of feedback we made sure to listen closely for and made sure to shape most design decisions after, was the weight and accuracy. We did not want it to be light, nor too heavy, and we wanted the player to have trouble aiming because who the hell can make precise movements with such a bulky weapon? Once we had settled on the drill engine, it was definitely heavy enough to act as the full weight of the minigun, and it did add some inaccuracy to the game. Of course, we managed to enhance this inaccuracy using violent screenshake while firing the button of the minigun.

Every now and then we had a classmate or lecturer over to test for us, giving us feedback on the construction or the weight of the item. When we let our lecturer playtest the minigun for the first time, we got the feedback that the barrels would become to heavy, and that we needed to use another material for them. We constantly looked around for materials and eventually found very light, thinner plastic tubes we ended up using for the minigun.

One example would be the choice to switch from using the Arduino Leonardo as a mouse rather than using the wiimote. We noticed that the wiimote combined with a program called GLOVE_PIE was very buggy and the connection was very unreliable. We started looking for alternatives, and found out that you can use a gyroscope/accelerator connected to an Arduino Leonardo, and it will work as a mouse. Thanks to us testing it, we managed to switch it out and make it work before any major showcase happened.

Thank you for reading this blog on the design choices and playtesting of Fullmetal Barber. Now that the project is coming to a close it is very interesting to reflect on the process of our creation and where we started off, as well as looking back on the choices we made.

Darkness Dwells Project Management

During this trimester I have worked with a bunch of different types of project management, as well as had the opportunity to be the project manager for our commercialisation project. For this blog I will write about my experience with project management during Darkness Dwells.

After researching around, most industry people (like Heather, and her article) seem to enjoy using WBS (Work Breakdown Software), such as Trello or Hack’N’Plan. Luckily we’ve been using Hack’N’Plan as well as spreadsheets to manage our work during Darkness Dwells, which is something I will discuss below.

The first thing I made sure we did for darkness dwells, as soon as I took the reigns as project manager, was decide to have weekly meetings. I wanted to make sure I knew what was going on with the project at all times. I also made sure that we used source control and Hack’N’Plan, as mentioned above, to plan out our work.

Spreadsheet

One method I tried out for the first time was week to week planning. I am aware that HNP does this, but I really wanted to be able to look at it in a spreadsheet, along with everyone's responsibilities for that particular week. I think this worked really well because it helped me keep track of what we had to do in the time we had left. This was also updated with time, as we pivoted at a certain point in the development.

Hack’N’Plan

Although half of the team were against using it, I enjoy using  HNP a lot. It helps me track time and is very useful to keep on top of things and make sure you know what to do. What I encountered as a difficulty during this project, as the project manager, was to motivate my team to continue updating HNP, and unfortunately it reached the point where we stopped using it. But up until the point where that happened, it worked well for us.

Slack/Discord

In order to keep in contact with everyone we decided to use Discord. However we were told that we had to use Slack for the project, so we sort of altered between the two. The reason for this was because everyone of us was used to using Discord for schoolwork, as it is a very flexible program for chat rooms. We ended up having to remind each other to use Slack, and therefore hopped between the two. In the end, we used Discord to talk to each other and Slack to talk to contributors.

Project management

This is one of the few projects I have been project manager for, and unfortunately I have had a better experience in the past. I think it all came down to the fact that I wasn’t engaged enough to take the reigns, and also because no one really wanted to be project manager so I offered to do it. I still have a lot to learn when it comes to controlling a team,  but hey, the game is out there and ready to play so I think it went well. I think it would be easier if I was more into the game.

Thank you for reading this rather short blog. My brain is pretty mushy at the end of trimester, so I'm happy I managed to get something about our process in here.


 

Robin B. Goode Goes Robin B. Bad

During week 11 we had a playtest for the final project of our cohort. The capstone project of our time here at SAE. During that, we learned a whole bunch about our game that we didn't know before, but we also learned that sometimes a heavy pivot is necessary for the sake of the project and the sanity of the team. For those that do not know, Beat Burglar was a rhythm stealth game where the player had to move to the beat in order to stay hidden.

There were three main issues we encountered, and I will discuss all of them in this post, as well as talk about our solution.

Issue #1 - Mushy Movement

The first issue was that the movement wasn't crisp enough. We were going heavily for a "Crypt of the Necrodancer (CoTN)" type of movement. We even read the blog post that the developers wrote in order to get as close as possible. Unfortunately we wanted the game to be more punishing when missing the beat, and this caused the game to not feel well. What CoTN did was shape the beat around how the player was moving, making it a tailored experience for whomever was playing the game.

One of our solutions to try and fix this was to implement "snake-like" movement. That is, the player moves forward automatically and the player steers left and right. This would have the player constantly be on their guard, observing where their character is heading and assess the situations to try and make the best of it.

Issue #2 - No Urgency

The second issue was urgency. In CoTN (which was our greatest inspiration) all enemies come for you, and if the song ends the level ends and the player get's sent to a small room with tonnes of enemies. It works as a kind of punishment, but if you complete the extra challenge you get loot and can continue to play the next level. In our game, guards didn't move towards you, they patrolled. When the song ended, it looped instead of kick you into a challenge.

For this issue, the snake movement would have been useful as well. The urgency of assessing the situations ahead of you and planning on the go would have possibly solved the issue of non-existent urgency. We even had counter-measures for the player actively trying to walk into walls to stand still (bump them off in the opposite direction).

Issue #3 - Tediousness

The third and final issue, Tediousness. We gave the player no direction on what to do and where to go. The levels were massive and empty and the movement was too sluggish to enjoy moving through the levels. 

I believe that snake movement would only have made it worse. Sure, you don't have to press every single beat, but given how empty the levels were you'd be able to press the turn-button once and then wait for a few seconds until pressing again.

Possible solutions include a more proper tutorial, carefully explaining to the player what they need to do. The stills are beautiful, but it leaves the player hanging where they might need to know the most. Other than that, Decreasing level size or Increasing guard population may need plausible solutions here.

Solution

I've mentioned at least one solution to all these issues, but there is one I haven't mentioned yet. Today, we pitched these solutions to our cohort and lecturers, and we were given the greenlight (kind of) again on this solution.

In order to increase interactivity, increase the overall feel-good of the game and to give the player a chance to experience all our environments close up, we decided to switch this top-down rhythm stealth game to a third-person beat 'em up game. The thought is that the player can create combos while fighting off guards, and the higher the combo the more of the main music layers on, creating an amazing feeling of being powerful.

From the start of this project, all we wanted was a game that met everyone's needs and felt amazing to play. Thanks to us sitting down and pondering on the feedback we were given, we were able to pivot this idea to something that we all want to work on, for real this time.

We will have to change the narrative slightly, as we decided to fully switch over to EDM music instead of the original choice of electro-swing, mainly because it's our audio students main choice of music and they make amazing EDM music.

Thank you very much for reading this blog post, expect to see more updates both here and on twitter.

Fullmetal Building - Material Design Dev Diary #2

This dev diary will cover how we made our weapon and the game for Full Metal Barber. It will cover materials, technology and software we used in order to get everything to work.

Product

The game in its current state is a toy, where you have to cut a persons hair using a minigun. The minigun is a controller you hold and aim with, in order to fire at a screen where you'll see the crosshair.  Originally the game featured a shotgun, but we switched to a minigun after thinking about the experience. 

The experience we are looking for, is a controller that feels good to use. We want a fair bit of heaviness to the weapon along with screenshake when firing in order to purposefully make the weapon imprecise to use. What we want from this game is for people to be able to cut weird hairstyles, and then upload an image of the hair on twitter.

Creating The Game

The Shooting

First of all we needed to make the shooting mechanic work, before working on everything else. While my teammates were off planning the build of the minigun itself, I sat down to create the game. First of all, I used a mix of scripts I already had and google to create a simple script that shoots using Raycasts. Raycasts are essentially invisible rays that can detect where they hit and provide a ton of information and uses doing so. Once this was ready, I had to make sure that when you fired the script would only react if you hit hair. This was done using Unity tags, and tagging a test object with the tag "Hair". 

As you can see in the GIF above, there isn't a particle effect firing when I click anything else than the red ball. This was the basis for how we made the hair in the game.

Michael

We knew we needed a model to hold all the hair we wanted, and there was only really one place we knew where to get it. The Makehuman application. Makehuman is a program that let's you get a realistic looking human model for games or animations, fully rigged and entirely customizable. We made a simple, bald character in that program and imported him into Unity, where we started working on the hair to place on his scalp.

Hair

We weren't sure how we wanted the hair to work. We had long been brainstorming different ideas of using either shaders or a terrain hidden beneath his head, using grass as the actual hair and coding some sort of brush that would remove the grass in real time. We also had an idea for using a model of hair and looking into removing one vertex at a time. What we eventually settled for is having a small prefab (made from a sphere) that was called hair. 

Whenever hair was hit by the raycast, it would burst into a particle effect, and fly off the head. This was created using the Rigidbody component on the hair prefab. When the prefab got hit, we immediately disable the kinematic option and enable gravity, as well as giving it a force push in the up direction of he object itself.

When it comes to placement of the hair we had multiple methods. The first one was to hand place each ball of hair (which in the picture below, you can see that it would take some time). Finally, our lecturer suggested using Polybrush. Polybrush is an addon to Unity that allows you to paint on models. The special thing with this is that you can paint prefabs onto models, as if you were paining trees onto a terrain. This worked fantastically for us since we only had to draw a hair and beard onto him, cutting time massively.

JUICE

We then decided to add some juice/polish to the game by implementing screenshake and particles. The main effect of the screenshake is both to make it feel like your actually firing a minigun and trying to aim with it. We also decided to make hair fly everywhere to really emphasize that you're shooting off hair. 

The Minigun

Planning

For planning we used the program TinkerCAD in order to create an idea of what the materials were and what it would look like. Granted, it looked nothing like it in the end but it was good for us to start thinking about materials early on.

Material Gathering

When it came to material gathering, my Teammate Paul found a place called "Reverse Garbage" here in Brisbane, where you can find a ton of stuff for a low price. We decided to take a daytrip there, and see what we could find

We ended up finding almost everything we needed for our build here, and it only cost us a total of $10. We found some plastic pipes for the barrel, some pool filter, a box with a really nice handle that could hold the arduino board and an old vacuum cleaner handle for... the handle.

The Build Part 1

As soon as we got home from Reverse Garbage, we started to put it all together. First of all, we laid everything out on the ground so that we could sort of see how to assemble everything.

First of all we decided to work on the barrel of the gun. We weren't entirely sure how to attach the barrels to the filter, but we decided to just duct tape it for this first iteration of it.

We also very crudely taped the vacuum cleaner to the main component box, as well as moving its handle so that you could hold it. At this point we were very pleased with how it was looking and how it felt. Our only problem at this stage was connecting the heavy barrel to the very light component box.

The Build Part 2

After assessing our materials and what we had, we decided to remake the body of the minigun. We had access to an empty speaker, which looked really good and also could fit some sliding door rollers so that we could have the barrel spin inside it.

All we really needed at this point was a motor. We had been experimenting with an arduino board and a small motor, but we needed to transfer it to a bigger one and build it all into the gun for it all to work properly. Thanks to Paul spending many hours with the barrel, we managed to put it together and make it more sturdy.

After having tested with a few small motors, we managed to find the motor from a drill, which was quite powerful and heavy enough to provide some weight to the minigun. Below you can see the current state of the minigun after most parts have been attached.

So let me explain how it is all hooked up. the handle is screwed to the body of the minigun. Inside the handle are two alligator clips attached to the arcade button that acts as a mouse click. Inside the body is the Arduino Leonardo. This is also connected to the drill motor and the MPU6050 (Gyroscope/accelerator) that acts as the mouse movement. What isn't pictured above is the new barrel's that we are in the process of attaching. We are currently attaching lighter plastic barrels to make it easier on the motor to spin.

That is all for now! we will showcase this game at events in the future, so keep a close look at my twitter for more information. Two of them are Synergy at SAE Brisbane next wednesday, and Squiggly River Artscade at Netherworld in the near future.

Take care, and thanks for reading!

Creating the Flybot!

Hey there! 

I do realize it's been a while since I've written anything, but I've been very busy with Uni work these past weeks, and just haven't found the time nor the energy to work on any side projects what so ever. That is, until tonight.

I'm currently writing this blog at 1:35 am, because I was just too worried that I might forget all this new information that I've discovered today if I slept, so I'm going to put it all here both as a reminder to myself and both as an update to what I am currently working on. So let's get right to it.

The Scrapbot

About 2 nights ago (yes nights, I can't work during days apparently) I started working on a robot model. I consider myself to be adequate with Autodesk Maya, but if there is anything I still struggle with, it is skin. The way it stretches along with weight painting is just too difficult for me, and something I will have to tackle another day. Therefore, robots and mechanical parts are way easier because you can use a method where you simply target all the vertices that you want, and tie them to a bone. No stretching involved. Because of all this, combined with a sudden inspiration surge to do some personal projects, I started to work on the robot I was about to call "The Scrapbot". I called it that because it feels like I can get away with not being a fully trained animator/3D artist by making scrappy stuff.

Either way, I immediately got to work, and I did feel like I made heaps of progress on it. In fact, after the second night had past I was completely done with both model, skeleton and animation. I was also fully aware I had completely skipped some of the key guidelines for modeling. One of them for example, is to combine every part of your robot so that they're not separate pieces. Even though I knew all this, I continued working (for some reason) possibly to experiment with what would happen.

I went from this, in Maya: 

To this in Unreal Engine 4:

Needless to say, something went horribly bad in the export. I already knew the skin stuff based on the amount of errors I got when exporting, however I was still very confused about the slow-mo running (more on this later). This had me drained of work energy so I went to sleep. Next day (today) I was determined to keep working on this model, however once I had the free time it just didn't click for me. I didn't want to start over with the rough animation and the rig. I decided that I had to make something even simpler, for the sake of time. Enter "The Flybot".

The Flybot

The flybot was my attempt at making something smaller that barely needed animating or skeleton. The first idea for the flybot was a little head on two legs that was running around. Then I went on to brainstorm a head with a propeller and a grappling arm. It ended up just being a head with a jaw and a propeller on top for simplicity's sake. I did everything all over again, even the things I missed last time like texturing and combining. I was ready to export. The first good sign was the error box, which turned out empty. I had my hopes up. I then hopped into Unreal Engine to start working, and behold there it was in all it's glory. No error messages, fully intact and textured, the flybot.

Now the fun part was about to start. I placed the animation inside the scene to have a look at my masterpiece and.... disappointment. The animation worked, sure, but it ran at 1/30th of it's original speed. Now, some of you might already have realized what is wrong. The key is in the number 30. Apparently (after some online research) Unreal needs Maya to have a playback speed of 30 fps instead of "Default" (which apparently is each frame). This also lead to me having to move keyframes spread out over 600 frames, down to about 90. It was a bit tricky, but hey it worked!

Some other things I learned in the process of Importing from Maya to UE4 was that UE4 requires your Maya scale settings to be set to centimeters instead of meters, unlike Unity which requires the opposite. Now my model was arguably a bit too big still, which I am currently working on solving.

Finally, I learned a helpful little trick that I might be able to use in the future. When making animations, you can make the run, jump and death animation in the same file, and when you import it into UE4 they will give you the option to import different frames separately. Important to note though is that only the first animation has to be imported with the mesh. The other animations are fine if you import the bones only.

That's all for now! The reason I didn't say what the game is yet is because I am still figuring it out and testing. I need it to be really simple because I just want it out there really. This whole modeling project I've been doing is partially just to prove to myself that I can do it, and so far it has worked, but the game is the final piece.

Anyways, thanks for reading! Until next time.

Material Design Research Process

This post will go over how I have been going about my research when creating a custom controller. This is more specifically tied to studio 3 and the brief that we've been following for that class. The specific tasks on which this post is based on, was that we had to come up with a small game that used a custom controller.

Research

First of all I had to look for inspiration. I had no specific idea so I decided to look online on different electronics retailers for different types of fun stuff. Problem was I wasn't exactly sure what I wanted, so I decided to search for "Sensors" and see what comes up. After some browsing I found a flame sensor and a proximity sensor, that I started to spawn some ideas for.

Brainstorming

Once I found the sensor I started to come up with different ideas for these sensors. The flame sensor idea was that you had to light a persons cigarette perfectly by moving the lighter closer or further away from the sensor. The player would know if they did good or bad by the eyes of a giant mannequin (that would hold the sensor in a fake cigarette) that would light up if you did well.

The idea from the proximity sensor was that you would have a parallel parking simulator where the controller would be a cardboard car, with the proximity sensor attached to the back part. With it you would have a game which would have a car that would drive forward and backwards depending on the proximity of your hand to the sensor. You would also have two arcade buttons on the car roof in order to be able to turn right and left in the game. All you have to do is manage to park between the two cars in the game.

Materials

For the final step I had to consider materials. Of course a cardboard head would start to burn so I would have to use some form of thin metal sheet for the cigarette game, and a casing for the sensor. For the parallel parking game I wanted to use a cardboard car, as I felt like it would feel really good to both create and use. Cardboard has a kind of "crafty" feeling to it which I really like.

And that is practically it! Research what you can use, brainstorm and make sketches of your ideas and then find out what materials to use in order to get the cool controller you want. 

That is all for now, thanks for reading

Beat Burglar Pitching Process - Post Mortem

What Did We Do?

Final project part one consists of roughly 6 weeks of pitching and polishing an idea for a project, where the rest of the project is creating a prototype to get all the work ready for next trimester. During these past 6 weeks, we have worked as a team to get an idea and presentation ready to start working on the game. We had meetings regularly both within the team and within the game designers to try and get as good of a product as possible. 

What Went Well?

Communication

During our process of pitching and presenting, We have all been very transparent and honest in our communication. We have raised issues and discussed them with each other, and we have had meetings regularly to make sure that everyone is on the same page. We have had meetings discussing feedback we've received and what changes to make, and we have had meetings to rehearse the pitch and go through the presentation to make sure everyone knows what to say. 

Pitching

Our pitching in front of class were very structured and clear. We spoke loud and made sure to detail as much as we could, highlighting all key features and levels. Everyone talked about a specific point of the project, making sure that everyone sounds engaged.

Why Did It Go Well?

Communication

When working in such a big team as we are, it is important to make sure you know exactly what everyone is doing and that it will be done on time. A big part of why I think we succeeded so well on this point, is partially because we had a lot of trust in each other that we can finish our work and make something great. It was also because we made sure to pick an idea that everyone would be happy working on, and in that we find everyone being enthusiastic about showing up to the meetings and discussing what we've done and can do. 

Pitching

After we had pitched twice, we noticed that our way of pitching sounded very improvised and unstructured. Because of this, we decided to have a script that we read off of. This also allowed us to rehearse every day before class to make sure everyone knew and could agree on what was being said. 

How To Make Sure It Happens Again

Communication

For a project like this, where you've worked together with the majority of the people in your cohort, you know which ones to trust in doing the work that is required. Part of why our team in general was so successful was because we had all worked together in one project or another before, and we know each others strengths. You can trust each other to show up on meetings and get work done. It is also easier to communicate with people you know well.

However, for projects where this isn't the case, having a strong project manager that makes sure that things get done, that frequently looks through all work that we've done and checks what is remaining to be done helps a lot. It is important to keep the morale of all teammates as high as possible and include everyone so that no one is left out.

Having set dates for meetings is also a good idea, in that case everyone can make time for the meeting and make sure to show up on time.

Pitching

If you want your pitch to do well, it is important to ask for feedback. Especially if you're pitching several times after one another, as this was the case here. The script writing was also very useful as it allowed us to review each others lines and comment on them before the actual pitch.

What Went Bad?

When trying to come up with an idea for our game it was very difficult for us to try and find out how to come up with an idea everyone would get something out of. Graphic design and audio was simple, but for the game designers it was tougher. We also had trouble finding a time for meetings where everyone was available.

Why Did It Go Bad?

Mainly our team size made it difficult for us to come up with ideas and meetings. When having 4 game designers trying to figure an idea out that everyone gets something out of, a lot of ideas that 3/4 designers like get tossed away. This is also why meetings was an issue. You have to find a time on a day where no one has work or an activity, and we had to do this approximately 3 times a week because of all the meetings we had.

How To Make Sure It Doesn't Happen Again

I would say pick a team with less teammates, but that is not always the case. The main reason that our team has managed to get meetings together is because we've all been participating in trying to find a time for meetings. We assisted in taking the burden off of the project manager's back and called for our own meetings where we all look through documents and iterate on feedback.

As for the difficulty of coming up with ideas, it's always important that you try to make everyone feel included, however that will not always work. Working with friends often makes the roles of project manager and creative lead sort of fade off a bit, as everyone discuss the ideas as friends and no one holds real authority over the others, and that can cause ideas to become harder to decide as no one really goes "No. We're doing this". I'm not saying that you should completely ignore the requests of your teammates, especially not in a smaller indie team, but it's important that someone takes the wheel and decides in benefit for everyone.

Summary

The pitching process has been a joy to work on. I am in a great team that all are capable of working and showing progress, as well as turn up to meetings and raise issues or questions. We always were confident in our ability to do the presentation and we never doubted that we could create a great product together. Although we've had our troubles because of our team size, we make up for it in enthusiasm and interest.

Thank you for reading this post mortem. Stay tuned for more posts regarding Beat Burglar.

Chris Shadforth - Business Design Concepts

During last Thursday's class, we were visited by a friend to my lecturer by the name of Chris Shadforth. He visited to talk to us about business design concepts and marketing. I personally found this to be a very useful talk, as it filled in a lot of cracks of questions I've had previously about marketing. In short, the presentations purpose was to reduce the possibility of failure and to build a model of customers. To do this, our main primary rule was "don't bullshit yourself", Something I as non-English speaker learned meant "don't lie to yourself".

The first crack to fill was "what is marketing". I've sort of had an understanding with it during the classes, but never really had a sentence to explain it. But thankfully, Chris's presentation did. The way it was explained was "A process for creating, communicating, delivering and exhanging offerings that have value for customers, clients etc.". This was not the full explanation but unfortunately that's all my notes said. 

The main section of the presentation was all about the 4 P's of marketing. Price, Place, Promotion and Product. I'll go through each of these and talk about what I learned and what it means for my profession.

Price

There was a lot of good stuff to learn about this, considering I haven't charged money for any of my games. The first thing we talked about was "what do competitors charge?" which was interesting to me as often when making a game I don't really see other games as competitors. I make my thing and they make theirs. Of course, when it comes to pricing you really just want to check what they are charging, and then match your game with theirs and see if you can charge the same amount, which is really interesting. I'll try to do this moving forward with the games that I'm making.

Another thing that I learned to keep in mind is expectations at different price points. What people expect at different price points helps you as a content creator to place a price on your product depending on quality and content. For my own practices, I would most likely always place my price slightly below the price of the competitor, unless I am 100% sure that my game is better in some way. 

Other than that, we learnt about common price conventions, bulk discounts and price drops. Common price conventions meaning that most companies make a $5 product $4.99 instead as our brains interpret that as cheaper.

Place

Place was something that we didn't need to talk a lot about as we as game developers know where to sell our products. Mainly itch.io, but there's always Gamejolt and Steam.

Promotion

For promotion we learned some things we already knew and some new things. The first thing is that promotion is not the whole of marketing, however, in my personal opinion it's a big part of it. Of course, marketing is a lot about scoping out your audience and figuring out what they like. 

We were told that visual designers and writers are good to have, and even better if you know some personally, but access to the right audience is better. For example if you know an academic that can write reviews of your games and so on (hinting at the one academic we used to have as a lecturer, Brendan Keogh). We were taught there three different types of promotion. Paid, owned and earned. Paid being of course a service you pay to do promotion, owned being a friend or colleague that does it for you, and earned being the kind of promotion you get from getting a lot of downloads or views on YouTube. While doing promotion it is always important to keep track of trends.

The 4th P of marketing, Product, will return later in this post.

Brand

Next up we were taught about brand, which has two definitions. The unofficial one, is the mental model of your business/product/you.  For example, my brand is the viking themes I keep in my work. I use runes and stone, Nordic mythology and etc. for websites and games. The official definition tend to be limited to symbols of identification. There are personal brands (which is the one i'm using), team brands and product brands.

Risk

We talked a bit about risk management as well, which was a very useful thing to touch on. We should always avoid mental risk, and only take risks where failure would improve us. Through our degree we have been thought that burnout and crunching is never worth it. Crunching being the concept of working to the point where you barely sleep in order to meet a deadline. With risks you also need to minimize leaps of faith, and always look to win over the long run. 

As a game developer I feel like I have been taught risk management in a proper way. Of course, sometimes crunching is unintentional and unavoidable. Research and preparations are also good ways of avoiding leap of faiths, and just taking risks over all.

Observation

Observation in this case means observing your audience in order to find out what types of features they like in your product. The first advice was "go where your audience is", which in our case would be forums like Reddit or social media like YouTube. Then take notes. Take a lot of notes, as opinions are different in different parts of the internet.

It is also important to approach these observations as a stranger, and not as a game developer, and always be careful of participation in discussions and the like. You don't want to have influences or cause influences that may skew your findings.

The Exercise

The rest of the talk that Chris held was tied to a certain exercise that was carried out afterwards. It was a useful exercise that had us dive deep into what customers gains and pains, and what we as developers could do to create those gains or relieve the pains.

Conclusion

This talk was very eye-opening into all the different procedures and processess that go into marketing. It closed a lot of gaps for me in what we have learned so far, and I will take many of the things I learned from the talk into account when moving forward in my career as an indie game developer.

Definitely the main take-away for me was the part about pricing, as I've never put a price on any game I've made ever. If possible I've always had donations or ad-revenue as the main income, and Chris talk taught be a lot about what I can do in order to put the right price on my game that it deserves.

That is all for now! thanks for reading this rather lengthy blog. Until next time, take care

To Connect a Wiimote - Material Design Dev Diary #1

The other 1/3 of Studio 3 is material design. That is creating some type of controller for a game that is custom, or used in an unconventional way, or doesn't use any digital products what so ever. It's pretty fun and I must say it really makes me feel smart to sit and toy with electrical parts and making stuff light up and so on.

For the material design project, me, Paul Frame, and Nicholas Duxbury are working on a game called... FULL METAL BARBER. You are a barber that uses a shotgun in order to cut peoples hair. Sounds awesome right?

Well, in order to get this working we had to decide how we wanted the game to work. We quickly came up with the idea of making some form of light-gun that you aim at a mannequin in order to make things happen in the game. Paul had the idea of using a Wiimote as the main "pointer" for the weapon. He also built an amazing cardboard-scissor-gun that we could place the wiimote and nunchuck inside.

Here comes all the challenges we had to go through in order to get it to work. First of all, connecting a Wiimote was easier than we thought, even though it was hard. All we had to do was connect the wiimote through bluetooth and that's it. The only issue we encountered with this was where we connected it (apparently there's two different places to connect bluetooth devices).

Next issue was that the Wiimote didn't react to movement or button presses at all. Of course, we had to have some form of App to recognize the Wiimote as a form of valid input device. We figured that since we were only going to make the game in Unity, that we use some form of API for the wiimote. Luckily, there is one, made by Flafla. All we had to do was press a button, and the button input was being shown!

There was however, no reaction of the actual movement of the controller. So it couldn't be used for what we wanted it to be used for. However, after some conferring with our lecturers, we came to the obvious conclusion that we needed IR lights in order to sense the position. Luckily, one of our lecturers had a spare one for PC lying around in his office that we were allowed to use for this test, and voila, there was movement recognition. 

And now we get to the issue that plagues us to this day. The API. Flafla is amazing for having created this API, but as a user with no advanced experience in coding, I would have prefered some form of manual on how to use aspects of the code. Something as simple as "How to make shit happen on button presses" or "how to get the position of the pointer in world space and not in canvas space" would've been extremely helpful. This is still to be figured out, but it seems like Paul has a solution to it, so it remains to be seen what works and what doesn't.

Until that update comes out, take care and thanks for reading this post.

Darkness Dwells 2 - Studio 3

A big part of studio 3 has been and is the marketing. Which is understandable, as marketing is so incredibly important to get your product out into the world. The long-term assessment for the marketing side of studio 3 is that we gather all previously created games, pick some that are suitable for marketing, and then carry out marketing processes for that game along with adding/removing features that makes it more/less marketable.

The team I am a part of (team name yet to be determined), consists of me, Paul Frame, Nicholas Duxbury, and the game's owner himself, Scott "Penguin" Anastasi. As I mentioned, Penguin is the owner of the game Darkness Dwells, and we are setting out to make the sequel, Darkness Dwells 2.

A little information about the game before we dive into the marketing side of things. Darkness Dwells was a first person game where you play as a child, laying in a bed trying to sleep while monsters and horrible beings apparate all around you. If you wait long enough, you will hear your parents comforting voice through the walls talk to each other and you'll finally be able to rest, free from monsters.

What we noticed in horror games, is that jumpscares always sells. Especially in the streaming/youtuber market, as it gives both the game and the youtuber views. Youtubers gained a lot of views (and money) from sitting and screaming at jumpscares coming at them (that may or may not be scary). We wanted to try and reach that goal of having a very youtuber friendly game. So what we mainly are looking to changing/adding to the game is the following:

• Walking
• Monsters with purpose
• Blanket Mechanic

 

Walking

What previously wasn't possible in Darkness Dwells was walking. We wanted the player to have more input on where they go and what to do, so we added a purpose. You wake up in the middle of the night, and have to try and find your parents room before the monsters catch you. Because the game is set within a house, there will be short play sessions, which are optimal for youtubers and streamers as they can play a quick game or a couple of games per streaming session.

Monsters With Purpose

A lot of horror games (nearly all of them) have at least one distinguishable threat that is recognizable for that game. Examples are the Five Nights at Freddy's (FNAF) animatronics or the good old classic Slender man. We want the player to know what Is chasing them, so that the face of the monster can be tied to the game, in order to spread. For example you might see a monster you recognize, but you're not sure where it is from so you look it up. That's how they find Darkness Dwells 2.

What we mean with purpose as well is that they all have a purpose for haunting the character. However it can be debatable why. Slender man for example kidnaps children while the FNAF characters seek revenge for their unfair deaths (also debatable). A lot of the characters have stories that you read between the lines to figure out, and that appeals to us, and to youtubers as well. It also allows a type of audience participation that is very intriguing.

The character we chose for Darkness Dwells 2 is Longtooth. We have some early concept arts of the character, and so far no backstory has been written. But I figured that the image itself can haunt you until a purpose is fully made.

Blanket Mechanic

A lot of horror games have at least one mechanic that let's them avoid the threat haunting them. Sometimes at the cost of something else. This would for example be the golden mask in the FNAF franchise. We added a blanket mechanic to Darkness Dwells 2. This means that the player walks around constantly wrapped in a blanket that they can hide in for a certain amount of time. We are also discussing ways of making this a curse, much like the blinking mechanic of SCP containment breach or the weeping angels from doctor who.

We strongly believe that all the above mentioned mechanics will allow for a strong game that can be played within 10 minutes and give the player a good scare. The game will be suitable to youtubers mainly for the short game time and plentiful of varied jumpscares that the player can try and avoid. Only time will tell what gets added and removed.

Thanks for reading this first blog post on my new website, I appreciate it!

Until next time, take care.