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

3D Modeling- Shrine

This month I’m working on a 3D model of a Shinto shrine.

nagoyaShrine_clipped1

Added a porch, stairs, railing, and bells.

nagoyaShrine_clipped2

I can’t wait to start on the texturing process, but there’s going to be a lot of UV working (and reworking) with this one. Then once I’m done with that I’ll make some bamboo, rocks and foliage models so I have all the ingredients I need to make a pleasant scene in Unreal.

-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

Concept Art: The Power of the Polygonal Select Tool

Sometimes the lack of technology opens new ways of doing things, as I’ve experienced lately. Unfortunately, my Wacom tablet of five years decided to give up the ghost, and now I’m researching my next drawing hardware acquisition. At the rate I’ve been going though, I may not need a tablet for awhile, and it’s largely thanks to the polygonal select tool in Photoshop.

The polygonal select tool, coupled with the different shape tools in Photoshop, can be used to create decent concept art. Here is a piece I finished recently, called One Got In, that I built using no tablet work at all.

OneGotIn
While I did not use a tablet for this piece, I did use a sketch in ink and toned grey paper for my base. After transferring the sketch photo in Photoshop, I realized that the original didn’t quite adhere to the rule of thirds, so I expanded the width of the document and moved its epicenter, the speared heart, over towards the bottom right of the grid. It’s very important in concept art to make sure that your art maintains the rule of thirds, otherwise you end up with a piece that’s sterile in composition.

ogiSketch

For a quick refresher, the rule of thirds is a compositional standard that successful artists use to determine the layout of their art. If you want to know if a piece fits the rule of thirds, divide the art of your choice into even thirds, like below. Ideally, you want the focus of your piece to fall on one of the four intersections, displayed by the orange dots. Do not put the focus of your piece in the center of the thirds, as it will create a bullseye effect.

ruleofthirds

Moving on from there, I blocked out the basic shapes from the sketch using Photoshop’s shape tools and of course, the glorious polygonal selection tool. The polygonal selection tool, if you provide enough points, allows you to make irregular shapes that you can’t make with the generic shape tools. For instance, I built the heart and spear using the polygonal selection tool and the paint bucket tool.

OneGotIn copy

In addition to making delicate shapes, the polygonal selection tool is great for getting clean, straight lines for perspective. I used this tool to make sure the sides of the pillars were in correct perspective, and that the shape of the cast light was correct. I was unsatisfied with the mood that the lighting created at this point, so I changed the location of the main light source to create a haunting atmosphere.

Progress2

There are a few catches you need to be aware of when working with the polygonal selection tool. Unless you’ve set the feathering option of the polygonal selection tool to an amount greater than 0px, you will have some very harsh lines, sometimes jagged. Make sure you have feather set to 1px, or use the Gaussian blur filter at low settings to keep your edges from looking rough. Also, be sure you are working on an empty layer when you are making shapes with the polygonal selection tool, or else you might override previous artwork. Here’s the finished piece again.

OneGotIn

Despite these minor inconveniences, I remain impressed by the power of such a simple tool. I’ve decided to use it to develop future pieces, like the new concept I’m working on, The Silence That Follows. If you have any questions regarding my techniques or want to learn more (or send me a useful tip!), please send me a message or comment below. I am more than happy to help other artists along their journey. Thanks again for reading!

TSTFprogress1

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

Announcing New Game Dev Project!

logo

I did it! I finally did it. I decided to pay the $100. Now I’m a proud owner of Game Maker Studio and I feel awesome. And also ready to make a game. For now, I’m going to call this game Fight the Darkness, because until something novel comes along, it’s the title that I have stuck in my head and I can’t get anything else to stick. The idea for this game has been stewing in my head for about three weeks. It all started after I had a strange dream about a labyrinth rendered in Pokemon Gold/Silver style graphics, and about some students trying to outrun a multi-eyed demonic spaghetti noodle.

So what is Fight the Darkness? It is a 2D, top-down roguelike in which the player uses the abilities of their four characters to track down and eliminate the Darkness, without getting eliminated themselves. These four characters include:

  • The Rock- Is able to break down obstacles and bust open locked doors, but moves slower than the other characters. If he is caught in the same room as the Darkness along with another character, the player can choose to sacrifice the Rock to save the other characters in the room.
  • The Runner– The fastest moving of all the characters. The Runner can also pick up and carry another character, but for a limited amount of time. Afterwards he will be tired for a few seconds and will need to regain his strength.
  • The Peace– Has the ability to stop time temporarily. Moves at a normal rate.
  • The Light– The only character with the ability to defeat the Darkness. The Light has a slightly larger radius of light around them as well. Moves at a normal rate.

In order to win a level, the player must have the Light occupy the same room as the Darkness. The lose condition is if the Rock, the Runner, and the Peace are absorbed by the Darkness before the Light occupies the same room as the Darkness. The Rock, the Runner, and the Peace can be absorbed by the Darkness if they are in the same room as the Darkness (without the Light present), or if any of them are in a hallway when the Darkness appears. Below is an example of the win condition, because the Light is in the same room as the Darkness.

FTDdiagram5

Levels are comprised of hallways and rooms, shrouded in black. At the start of each level, the four characters spawn in random areas, and a timer begins to count down. Each character has a radius of light around them, revealing area as the player moves them.

FTDdiagram2

The player can toggle between characters to move them appropriately. It is advantageous for the player to discover as much as the map as they can, because revealing more rooms gives the player more places to store their characters when the Darkness appears, and more opportunities to find the Darkness.

FTDdiagram6

After the Darkness appears in a room, that room is destroyed, along with any non-Light characters within it. Then the Darkness disappears, and the timer resets. This mechanic repeats until the Darkness is destroyed, or all characters are eliminated.

FTDdiagram8

When discovered, rooms display two very important types of information: a fraction and a glyph. The fraction represents how many people can fit into a room at a time. For example, a room bearing 0/1 can fit one person at a time, 0/2 two people, etc. The glyph represents the likelihood the Darkness will appear in a room. Ten glyphs represent the likelihood the Darkness will appear in a room, but it will be up to the player to pay attention to environmental hints as to what chance each glyph represents. How those environmental hints will manifest I’m not sure of yet, but it is something that I am currently mulling over.

Creating this game will be a challenge for me, especially since I have only produced games in groups, but I believe it is necessary to my advancement as a game designer. If the game becomes refined enough and I believe it has a decent amount of “fun” to it, I might consider submitting it to Steam, or the Google Play store.

Game development is a journey, and like all sojourns, it is best shared. I welcome comments and input about my projects, or if you have a Game Maker resource you’d like to share with me, by all means send me a link to it! I appreciate everyone who has been reading this blog, and I hope you all look forward to future posts about Fight the Darkness and other projects of mine. Till next time, USCF signing out.

Post commandeered by the US Claire Force

UI Design & Weapons Concept

I’m going to keep this post short and sweet, because I’m applying for jobs and have a lot coming up in the next post. I finished the weapons concept I’ve been working on, as well as a UI page for the fictional game Dragoon Chronicles.

ClaireLewoczko_DragoonChroniclesUI_2

claire_weapons

I’ve included a time lapse of my work flow for the electric sword, for your viewing pleasure.

weaponTimeLapse

Later in the week I’ll post about the new game that I’m going to develop in Game Maker, either for PC or mobile devices. Until then, stay tuned, and thanks for reading!

Post commandeered by the US Claire Force

Adventures in Portfolio Building & Learning

Hello my readers! I hope everyone’s doing well in their game development quests!

In my most recent adventures, I’ve attended several portfolio reviews and received valuable feedback. Of my current three portfolios, game design, concept art, and user interface design, I’ve learned that my game design portfolio is the strongest. Huzzah! However, I do need to beef up my skills in concept art and user interface design, so to do this I’ve started doing more work in those areas.

Currently I’m working on weapon concepts for an urbanpunk setting, either for a game or comic. Pictured left from right I have a drill axe, an electric sword, and a katar. The electric sword I’m most proud of, and if I were ever to face a horde of zombies, it’d be my go-to weapon of the three.

lewoczko_weapons Rough

Progress after importing the image to Photoshop. I’m a little odd in that I like to work right to left. I’m finished with the katar, but I’m still working on the electric sword and haven’t even started yet on the axe.

claire_weaponsWIP1

In addition to building up my concept art repertoire, I’ve been working on my user interface portfolio. Currently I primarily do just the art and design side of user interfaces, but I’m learning how to code and implement them using Scaleform. I love working in Unreal Development Kit (I find the node based system for materials to be extremely useful), and learning Scaleform will greatly increase my capabilities in the engine.

The menu below is a main menu screen for a fictional game called Dragoon Chronicles. I wanted to create a menu for a game with a dark fantasy setting, like Infinity Blade or Diablo. Currently I only have a static image, but I plan on importing individual buttons and states into Scaleform and see what all I can do with them.

ClaireLewoczko_DragoonChroniclesUI_1

It’s a bit daunting, having to learn software and languages, especially when it seems like a new one emerges every several months. It’s getting better though; I’m realizing that with both engines and programming, many concepts remain the same, despite the addition of new features and versions. In a way it keeps development from getting stale, as there’s always something new to be learned.

A couple of months ago Vinton Cerf, one of the founders of the Internet, came to give a presentation at my college. After his presentation, he allowed students to come up, shake his hand, and ask him questions. I was a bit shy, and introduced myself as “just a student”. I will never forget his reply, in which he told me

  “You are never just a student. A student is one of the most important things you can be. You should never stop being a student. You should always be learning.”

Even when formal education ends, it’s always important to be learning: learning from experiences, learning from other people, learning new ways to do things. From my experience, I’ve seen that the happiest people are those who continue to learn and grow. Those who refuse to open to new ideas become stagnant and depressed.

It makes me incredibly happy to know that I am in a field that is constantly evolving. It’s been a journey so far and as far as I can see, adventure stretches into the horizon. I have a lot to learn, but I am excited about all the discoveries that lie ahead. Stay passionate comrades, and always be willing to learn.

Until next time, US Claire Force signing out.

Post commandeered by the US Claire Force

 

Comrade Quest Final Release

It’s finally reached the end of the semester, and Comrade Quest’s development is over. It makes me sad that everyone on my team is going their separate ways, but I’m glad that I got the chance to lead a group of talented artists, programmers and designers to realize my vision. Also, I’m quite proud that one of the designers on my team will have her own game in Game Production Lab next semester.

Now that my directing days in GPL have come to a close, I’ve been reflecting on what I’ve learned in the past five months. Developing Comrade Quest has taught me a lot about game development and managing a team, but the most important thing I’ve learned can be summed up in a single statement: have confidence in your original vision. There’s a reason why most successful games don’t change their mechanics mid-development, and that’s because most creative directors have the utmost confidence in their vision.

The biggest upset in Comrade Quest’s development came when we tried replacing the melee combat system with a turn based one, similar to Paper Mario’s turn-by-turn combat. Part of reasoning behind the mechanics change was based off feedback that we got from the alpha test. Many of our testers complained that Olaf’s attacks didn’t feel like “attacks”. As they were, Olaf’s attacks felt mechanical and lacked the rewarding visceral sensation featured in published games.

Comrade Quest Shot 6

By changing the fighting mechanics to turn based, we wouldn’t have to worry about achieving that visceral quality. However, while a turn-based approach would solve our current system’s problems, it would bring unanticipated problems of its own. How would turn order be calculated? How would current attacks translate into the new system? How would we make a turn-based system cooperative? We were not adequately prepared to answer these questions.

The decision to change the combat to a turn-based system was also influenced by my own worries. I was worried that we wouldn’t be able to improve the physics and animation of the character’s attacks in time for beta release. Instead of being confident in my original plan and in my team’s capabilities, I chose what seemed like an easy way out.

Thankfully we changed back to the melee system, but we lost a week-and-a-half worth of production time. This cost us Olaf’s combo attack. If I had stuck with my original plan, the time the animators spent animating buttons for the turn-based user interface could have been used to animate Olaf’s combo. If I had stuck with my original plan, the time the programmers spent programming queues could have been appropriated to improve attacks physics. This is why it is so important to have confidence in your vision. If I had remained confident in my original plan, we would have used that week-and-a-half of production time to create a better product.

Comrade Quest Shot 5

The finished executable of Comrade Quest may not feature a combo, but overall I’m satisfied with how the game turned out. I’m glad that we were able to create an entire level and feature a boss fight at the end. I’m also very pleased with the audio and visual aesthetics of the game. Our sound designers really pulled out all the stops in creating great sound effects and an ambient track. Above all else though, I’m delighted that people find Comrade Quest fun. Almost everyone I’ve seen looks like they are enjoying their playthrough and interacting with their partner. I created Comrade Quest to foster this in-person interaction and camaraderie, and to see its players have such fun together confirms the game has achieved its original intent.

I would like to continue Comrade Quest’s productionin the future, but now that I no longer have a team, it will be difficult to do. I envision getting a team of talented individuals together to work on Comrade Quest and pitching the game to Kickstarter. I can also see going to one of the existing game companies and pitching the game directly to them. However, developing Comrade Quest further will have to wait for a while, as right now I have to build up my portfolio and find steady employment. To summarize, I haven’t given up on Comrade Quest, it will just have to float around in the “things I’d like to develop someday” pool for a while. So what will I do with this blog in the mean time? I have to build up my portfolio, so I’ll be posting concept art, UI designs, mini games made in Game Maker, and other game development portfolio pieces.

Cashtaroth Battle

Thank you all my dear readers for following Comrade Quest’s development. It’s been a pleasure blogging about its production, and I hope you all continue to read about my future projects. It’s been a fun and eye-opening journey so far, and I can’t wait to see all the places my passion for game development will take me.

If you want to play Comrade Quest, go to this link to download it. Comrade Quest Download

Post commandeered by the US Claire Force

Night of Beta

Less than eleven hours remain before beta release. I’m nervous, happy, excited, stressed and sleepless all at the same time. It’s an odd mix of feelings, but I like it. Guess I picked the right industry to get into, because from what I heard, this atmosphere of high tension is pretty common in the world of video game development.

Last weekend, Team Comrade had its all-night beta crunch/work-in party. From 9 PM on Saturday to roughly 9 AM the next day, we did nothing but work on Comrade Quest. Okay, so that’s a little bit of a lie- some whiteboard shenanigans were had, and a few brusque Russian phone calls to the local pizza company were made. Even still, a lot of work got done.

The game designers worked with the level designer and programmers to firm up combat. Players and enemies alike have better physics, improved attacks, and combat feels more inclusive to the game experience. Much progress was made on the layout of the level as well. Our alpha release was criticized because it contained a lot of empty spaces. We addressed this problem by compressing certain areas of the level that were too long, and adding challenges and collectible beets to empty areas.

screenshot beta
The smashers that gave us problems. In this photo, they have been fixed.

A lot of interesting bugs were found, like Olaf being able to moonwalk in certain areas, and an insane amount of enemies spawning in the arenas. The game designers also sorted out a collision problem with the metal smashers. When the new art asset for the smashers was imported, it messed up the smasher’s collision. Rather than killing players caught underneath it, it only pushed them into the ground. The problem was rooted in the shape of the smasher’s collision- the edges at the bottom were slightly beveled. This was to match the art asset, which featured beveled edges. By changing the beveled corners of the smasher’s collision box to 90 degree corners, we were able to get around some of the smasher’s collision problems with player.

Now, we’re half a day away from beta release and Comrade Quest is looking really good. We’ve come across more bugs since our work party, but most of them have been resolved. One of the funniest involved Olaf getting absorbed into the smashers. We also have most of the main menu working, which is great. You can see what it should look like once it’s finished here.

My biggest concern lies with the camera transitions and the way players trigger them when moving from area to area. Earlier, one player was able to move into a new area without the other player. Once in the new area, the slower player would remain off-screen, ruining the gameplay experience. This transition issue was largely fixed by adjusting the camera and implementing invisible barriers. However, there’s some camera popping and I don’t know how much it will affect player feedback in the beta.

Camera popping aside, I feel very confident about Comrade Quest’s beta release. It amazes me that six months ago, Comrade Quest was just an idea in my head. Now, that idea has materialized into a playable level with working mechanics, animation, menus and most importantly, gameplay. I’m grateful to have such a dedicated, hardworking team to bring Comrade Quest this far.

Post comandeered by US Claire Force