Shrine: UV Unwrapping

This week I’ve been working on the least fun part of the 3D modeling, UV unwrapping. Thankfully Maya has a good set of tools to speed up the process slightly.

nagoyaShrine3

Whoever developed the planar map tool at Autodesk has my deepest regards. SO MUCH TIME SAVED.

nagoyaShrine4

Now obviously I’m nowhere near done yet, but I like to test my work incrementally to make sure the UV work I am doing in Maya looks good in other environments. I’ll go ahead and make a quick test FBX export of this model and plop it in Marmoset Toolbag.

Marmoset Toolbag 2 (Three is out but I have not purchase it yet) is a nifty piece of software that creates high quality renders. It’s also a great tool for pre-flighting models before importing them into a game engine.

Once I’ve imported the model into Toolbag, I’ll apply a texture with a visible grain, such as Marmoset’s preset rust texture, to see if I need to do additional tweaking to the areas I’ve already UV’d.

nagoyaShrine5

Good news! The areas I’ve UV’d, such as the stairs, floor, and foundation, all applied the selected texture evenly and without warping. The areas that are circled in red show areas that I have not UV’d yet. You can see the obvious warping on the roof, and some of the supporting pillars that hold the roof up. The front panel of the building isn’t exactly stretched, but the resolution isn’t matching that of the UV’d portions. Now you understand why Toolbag can be a valuable pre-flight tool.

-Post commandeered by the US Claire Force

Anti-Drone Gun Modeling #2

UPDATE 4-21-17: I finished the model around August last year, but never got around to posting it. Here she is!

We now resume the blog post.

cyberpunkAntiDroneGun_USCF_small

I’ve made significant progress on the anti-drone gun model. Today I got all the texture work done for the stock of the gun- diffuse, occlusion, normal, height, and specularity. A few years ago I used Crazybump to build maps, but since then I’ve found cheaper and better software like xNormal and MindTex. xNormal is free, but from my experience the maps produced by MindTex are higher quality than those produced by xNormal. I brought the finished model of the gun stock and the maps into Marmoset for rendering.

antidronegun7

I’m delighted that the stock turned out so well. I might go back and change the orange and yellow lights on the stock however. In contrast to the rest of the model, they look flat and cartoonish. By adding a subtle gradient to the edges of the lights, I think I’ll be able to make it mesh better with its surroundings.  I’ll count this as a small victory, but I still have a lot of work ahead of me. In addition to making these changes, I have to finish tweaking the geometry of the gun’s body and texturing the rest of the model. I’ll see if I can finish this within two weeks.

Post commandeered by the US Claire Force

Fix a Bug and More Will Appear

Hello my readers! It’s been another exciting week in FTD development. Those collision problems I had last week? No more. Those weird issues I had with the character’s movement? Vanquished! I’m happy to say that most of the problems I struggled with last week are gone, but as is always true in game development more have emerged. However, before I delve into what problems I’m running into currently, I’m going to cover how I ended up fixing previous issues.

Last week, I struggled with two issues: one, collision with the Light character and the walls, and two, the Light character continuing to move, despite the player releasing the movement key. I realized that the Light wasn’t colliding with the walls because only the wall object had instructions for colliding with the Light. For collision between a character and a hard surface to work in Game Maker Studio both objects, the surface and the player, must feature collision events referencing each other. By defining collision with the wall in the Light object, I was able to fix the first problem.

lightObject001

The second issue, the character’s continual movement, was fixed by assigning a key release event to the movement buttons. After a key is released, the character stops moving, until a key is pressed again.

lightObject002

Now that I have those issues out of the way, I have several other problems I must tackle. Bugs aside, there were two things I wanted to get done last week. I wanted to implement all four characters into the game and set up the mechanic for the Darkness appearing randomly in rooms. I was successful in getting the four characters into the game, but I do not have their abilities functional (except for the Runner). I also don’t have the ability to control one character at a time and switch between them on the fly. Currently, the player is in control of all four players at once. When one moves, they all move in the same direction, and I don’t want that.

While I have a few ideas about how to go about fixing the character control issue, I’m not entirely sure how I’ll get the Darkness to appear randomly in the rooms. In my own pseudocode, this is what I think needs to happen.

  • Create a global timer object (timer1)
  • Create another global timer object (timer2)
  • Create Darkness object and sprite
  • Set time1 object to count down from 60
  • Create a room object and sprite
  • Create multiple instance of the room object, but assign them different names, ie Room1, Room2, Room3 etc.
  • Link room object to timer1
  • Assign randomize function to room object
  • Assign replace sprite function to room object
  • When timer1 reaches zero, replace room sprite with Darkness object and sprite
  • Have timer2 go off so that timer1 is repeated

I think this approach is the best way to get the random Darkness appearance function to work. At this point I’m not going to code the Darkness to kill anything or destroy rooms, I just need to make sure that I got the random mechanic working. I need to get the random mechanic working perfectly, because later I’ll be implementing the glyphs, which determine the chance that the Darkness will appear in a certain room.

Problems aside, I ended up getting a little sidetracked and started messing with some of the basic HUD elements of the game. Below is a mock-up of what the HUD might look like.

gameplayHUDmockUp

As useful as HUDs are, even the best designed ones get in the way sometimes. One of the functions I want the player to have is the ability to toggle the HUD on and off. I went ahead and created one of the HUD elements to test out the toggle feature, in this case the game’s timer.

lightObject003

Now I know once I work on the HUD in the future, I can give the players the ability to toggle the HUD on and off at their own whim. So what’s on the FTD development menu for this week? I have three items I want to have implemented by next Sunday.

  1. Get the randomized Darkness appearance mechanic working.
  2. Limit player’s control to one character at a time
  3. Get some of the other character’s abilities implemented.

Well, that about wraps things up for this week. There are a few official Game Maker tutorials that I think will help with the development of FTD, but I am open to suggestions and tutorials on Youtube/Vimeo/etc. If you see a tutorial that you think will help, by all means, send it my way! It will be appreciated. USCF over and out.

Post commandeered by the US Claire Force

Comrade Quest Checkpoint Animations

I’ve been working more on the menus, and animations for the different objects in the level. Here are the assets for the checkpoints- the banner says контрольная точка (kontrol’naya tochka), or checkpoint. I’m going off of what one of my Russian-speaking friends said, hopefully it doesn’t mean “capitalism for life” or “Donald Trump is awesome”

This one is just the “floating” checkpoint, used for when players haven’t yet reached a location.

Comrade Quest Checkpoint
Floating checkpoint for Comrade Quest’s levels.

This is the animation for the activated checkpoint, for when a player dies and respawns. Both animations are much higher quality in the game, these are just pixelated because GIFs are lossy.

activated checkpoint
Triggers when a player respawns.

Comrade Quest Alpha and Feedback

The Tuesday before spring break, we had alpha playtests in GPL. We received valuable feedback from developers from the Fissure, Shroud, Solar Rim and Cross Stone teams, as well as some of the ATEC professors.

From the anonymous polls we gathered from the playtests

• The co-op element and co-op puzzles are the strongest features of the game
• Art style is likeable, player character animations look great
• Combat is not satisfying and feels out of place
• Most of the level’s layout is good, but there are a lot of empty spaces

Points made by professors participating in the playtests

• Strongest elements of the game are the co-op puzzles and co-op element
• Combat is very disjointed: unsure of combat’s place within the level
• Combat is not a co-op experience- too isolated between players
• The game is a puzzle game, creative director just isn’t aware of it yet
• The level design has improved significantly since the first milestone playthrough, but there are still empty areas where player interest lags
• Attack animations are designed the wrong way. Currently, physics feel like they are designed for the animations. It needs to be the other way around, with the animations being designed for the physics.

One of the professors suggested that combat should be de-emphasized, polished in time for beta, or taken out entirely. I’ve never realized before just how difficult it is to get real time combat feeling right. Not only do the characters attack animations have to reflect the velocity and movement of their attacks, but the collision and feedback of the attack have to match as well.

Furthermore, our entire approach to coding and creating attack animations is wrong. Animations need to be designed for physics, not the other way around. Currently, we design physics for animations, which is the wrong approach. While the animations themselves look great, the physics behind them don’t quite match up- keeping combat from obtaining that visceral element it needs to be satisfying.

Over spring break, I came up with a plan of action to improve on our alpha shortcomings, most notably the combat physics, the cooperative elements of combat, and empty spaces within the level. The plan of action involved setting up mini-playtest dates to test enhanced physics and achieve the right amount of realism in combat, as well as making modifications to the existing animations to match the physics.

Despite this plan of action, I worried that it wouldn’t be enough to get Comrade Quest to the level it needed to be at for beta. With a little over three weeks till beta, I feared that we wouldn’t get the physics honed in time. There was also the matter of getting the sounds properly synced with the attacks, and having enough time to modify the old animations, as well as create new ones.

After spring break, the Comrade Quest team met for GPL on Tuesday. I asked my team mates if they had read the action plan at all over the break. They had, and mirroring the gut feeling I had in my stomach, they didn’t believe that the action plan would be enough to get the game at a polished enough level for beta.

However CQ’s level designer had the brilliant idea of replacing real time combat with a turn-based RPG system, similar to the one utilized in the Paper Mario games. She proposed a simple system, with just attack, defend, and Communist summon commands. I thought the idea was brilliant- it sidestepped all the problems aimed at making the combat visceral. She also proposed that each player would select commands for their own character, but players would have to select the same commands if they wanted to summon a Communist leader- this would make the combat a cooperative experience.

Post commandeered by the US Claire Force