Creating Myran

Myran is the name of the world our fire and ice mages live on. It's been quite an adventure translating our narrative designer, Matt's, stories and lore into artwork.

I posted my progress on the map of Myran I did last week. The map is nearly done, but now comes the tedious work. With the help of Erin, and uniSWF, each name of a place on the map will become a button that (when hovered over) will give a little description of the area.

Current progress. May need some more little details, but it is mostly finished.

You may be surprised to learn that this takes a buttload of time. For every name on the map, I have to bring it into Flash to create two states for every button (one for when it is not being hovered over, and one for when it is being hovered over) and save them out. Then we have to make sure the names are back in the correct spaces on the map so it looks good. The Flash work itself takes a couple hours. Reconfiguring the map through programming might be a little difficult.

Anyways, unfortunately, we ran into some issues with uniSWF. The in-game GUI was glitchy and would disappear if the screen was minimized. For now, we had to take it out of our build until the programmers figure out and fix what's wrong. So I'm actually creating buttons for a system that we're not 100% sure is going to work yet. Cross your fingers!

Other than that, I grabbed some models from Sibyl that she had finished and painted them so they were all set to go into Unity. 

Ooo rocks.

These are a couple of "rock piles" that are going to be reused throughout the ice level. Having these assets will help the level designers and artists work together to break up the space and define it better.

We also got some of the whiteboxed buildings and other elements into the engine. 

These images are from last week.

Believe me, when you're running around in the environment, it feels a lot different than it did when it was just boxes... Especially with the proper lighting. 

With lighting. (Also from last week.)

In other news, Spring Break is coming up! Most of us aren't going to get much of a break though. I plan on finishing the majority of the menu stuff so when I get back, I can focus on textures.

... And now that I think about it, it's not really going to be spring either. Hmmm.

Hats

This week I finally got into jumping around to different kinds of art. I'm wearing a lot of hats this semester, being the designated 2D artist on the team. I have to take care of in-game UI, menus, concepts, and as many textures as I can handle. I also have to work with pretty much everybody else on the team to make sure the art is up to par and efficient for our pipeline.

For Alex, this week, I did some in-game UI changes. Ever since we switched over to keyboard and mouse controls, we've gotten endless complaints from QA Testers that they couldn't tell what spells they had queued. I scrapped the "book" UI that displayed what secondary spells are chosen and replaced it with something a bit sleeker that displays all spells (including primaries) and which are queued to cast. 

I stole this screenshot from Chris. We also have new spell effects!

The primary spells needed "symbols," as did the two new spells we added this week. In addition to our other secondary spells, we now have:

Snare - Creates a glyph on the ground that traps enemy mages and holds them in place.

Buddy Shield - A channeled spell that mages can cast on their teammates that shields the teammate from damage.

UI always takes a lot longer than I anticipate because I forget how long it takes to save everything out. I have to save out the stationary "background" (the circles), and then all of the symbols out separately. And not only that, but I have to save a "big" version out and a "small" version of each spell. AND there is a fire and ice version of everything.

Let this blog serve as a reminder that saving UI elements out takes forever!!!

Also, to make Alex's life easier, I saved it out in such a way that everything has the same amount of space.

This is the UI all together (in Photoshop). (The checkered pattern represents transparency, by the way.)

This is what I save out for the background asset.

And then this is what one of the spell assets looks like. This way, placement of these assets does not have to be programmed in. When a programmer brings this into game and puts it all together, it automatically fits together. Had I cropped the spell assets, Alex would have needed to position the asset himself, wasting time.

I also had to do a "sample" texture this week, for my fellow artists. Inevitably, I'm not going to be the only one doing textures because of time restraints. The other artists wanted to see what we were going for in terms of textures when the time comes for them to do some. Also, it's just important for all of us to know what we're aiming for.

This is the pillar in Maya. Painted in 3D Coat.

This is the pillar in engine. (Also stolen from Chris. :D)

On Sunday, we celebrated getting the first "finished" asset into the game. (I put finished in quotes because touchups will need to be done.) We all got super excited to see more assets make it into game.

I'm going to be working closely with Erin for menu art, and I started on finalizing some things for the lobby menu today. 

We're going with a Tolkein-style map for the map-selection. Players will be able to scroll over all of the areas and a little blurb with info/lore will pop up, too.

... It's just a matter of figuring out how this uniSWF stuff works and how to save out my buttons. Cropping in Flash is already a pain, but I'm even more unsure how to do it when a button's hover/on state is bigger than its off state*.

So Erin and I are going to meet sometime and go over uniSWF together so we are both on the same page about things. Working with programmers is actually a really important thing that game artists have to learn. Especially with Flash, naming conventions** and consistency are essential. If the artist doesn't know, the programmer's gonna get pissed.

Oh and before I forget, I did some concept work and gave the mages a little makeover last week.

I did these just to get some ideas out for some customization we could do. Do you love Christmas sweater mage? Me too. He wears it because his nana knitted it for him.

Anyways, until next week, readers!

*Hover/On and Off States: A "button" is a certain kind of movieclip that you can make in Flash. Its "off state" is what the button looks like when your cursor is not on it. Its "on state" is when your cursor is over it.

** Naming Conventions: A naming convention is how you literally name something or save it out as. Something common for artists, when we're doing artwork, is to name our first save project_001; our second project_002; etc... This way they save in chronological order and it stays organized. For buttons, it is common to save them out as "BTN_play", "BTN_save", "BTN_quit", etc...

Kickin' it into High Gear

We're all very aware that we're rushing headfirst toward our deadline. Why can't time just go slower for the next couple of months? Two months is not a lot of time to get from where we are to where we want to be. But we expected this.

This Sunday was a lot of discussion. I met with the artists and let them know that we are going to have harder deadlines so we can really start to churn out assets. We also talked about methods and technical issues like modularity* and particle effects**. 

I got started on some menu concepts. I feel like menu artists and menu art are probably the least appreciated of game artists (maybe technical artists are). Even I admit that menus aren't really something you really think about until you try making one. Menus are the part of the game that are totally necessary, but aren't the game, so they're extremely overlooked.

Well I'll tell you now, menu/UI creation is hard! 

These are the bare bones concepts I've done.

The Player Customization screen, where players can customize what their ice character and fire character will look like in-game. They can also put in their username and number.

The lobby screen. Multiplayer games usually have lobbies where all players join up before the game starts. Here, the host picks the map (time limit, and number of players). Players can also see each other and talk to each other. And yes, that is a map of Middle Earth.

A lot of this was also just discussion between Alex, Chris and I about the information that needs to be provided and a lot of technical things. It's my job, basically to structure and decorate the information in such a way that makes it intuitive to the player and easy to look at (if not fun to look at).

These are some new in-game UI concepts I did just for the hell of it. I remembered getting some complaints about the current one from someone, although I can't remember who. The only thing I would change about the current one is adding in a timer, an indicator that tells the player what half the game is in, and some polish. But I did these anyway just to see what would happen.

The left one is an asymmetrical idea that reflects the architecture of the two different mage groups. The banners are inspired by environmental elements we're working on. The right one is basically what we have now, only the timer is integrated through banners that hang down. If the left banner is hanging down, it means the game is in the first half. If the right one is down, the game is in the second half. I expected players might get confused by this, but also argued that if someone brand new to football saw football on TV one day they'd have no clue what was happening. (Funfact: I'm 21 and just learned how football works this past Superbowl...)

The team liked the left one more, and also suggested that we don't need an indicator to tell players what half the game is in. I disagree for a couple reasons. 1.) I feel like all games state the obvious for one reason or another. Fighting games tell players what round their in and how many wins each player has. This is not to mention sports games, which always have an indicator of what quarter/period/half the game is in. 2.) Players just joining the game wouldn't know unless they had an indicator, asked, or just waited out the timer to see if the game went into half-time or ended.

The left one also takes up too much space. Here's what I notice when I look at game UI: UI artists make a point to save screen space. Sure, UI looks good, but it's almost always just sleek and to the point. We've looked at Team Fortress 2 before, but let's look again.

Notice how the UI is pretty much just rectangles and information? I looked at a few games, and all of them had simple shapes and numbers (pretty much). I'm all for cool-looking, fancy schmancy 2D art, but this is not the place to do that. UI is for feeding players information at a quick glance. I saved as much space as I could with the UI last semester, but I still feel like it takes up too much space. Not only that, but I have to add more information to it. I think this is where we need to sacrifice nice drawings for, well, rectangles.

This takes a lot of finagling, but you can count on me to figure it out! 

Until next time. 

P.S. We totally passed greenlight and celebrated at Longhorn Steakhouse.

* Modularity - a technique game artists use that allows assets to be reused and "fit" together. Good example of a modular set for a church: http://www.turbosquid.com/3d-models/medieval-church-modular-set-3d-ma/639363

** Particle Effects - game engines can create these animations for many different uses. http://en.wikipedia.org/wiki/Particle_effect

Greenlight

Greenlight is essentially our "stage challenge" this semester. Techincally, we are in pre-production right now, and need to pass greenlight to make it into production. We need to get to a point where our teachers trust us enough to move us into production... But honestly, it doesn't really change much. (We're going to do the work anyway.)

We're presenting our greenlight challenge on Wednesday, and our whole team has some stuff to get done before then. On the art side of things, we needed some (at least) concepts of environment artwork. Marc needs to be sure that we can decide on a direction and get assets churned out. We also need to make sure we're constantly talking to the narrative designer, to make sure we're all telling the same story with our art. We had some problems talking about the animal logos in class this last week, so we needed to sort that out.

Kyle concepted some new logos and his girlfriend mocked them up in Illustrator. 

Kyle wanted to bring that modern day sports theme to what we had come up with. I thought it was a great idea. There were some nitpicky things people pointed out that we went over today, but other than that these were great.

However, some of the designers pointed out that having the animal logos in the level and the fire and ice logos in the GUI would be confusing for players. They wouldn't necessarily draw the connection between the two. While I don't think that would be an issue, or even if it would matter that much if players didn't understand right away, I was fine with scrapping the animal logos altogether. So basically we had to pick between the animal logos or the element logos.

I thought this was kind of silly, so I brought it to the art team again. The good thing about Casey's animal logos is that they have both the animal and the fire and ice symbols. Kyle brought up that actual sports teams have multiple logos they use. The Boston Bruins of the NHL have their "B" logo, circle logo, as well as a bear logo. What we could do is break the logos into pieces if we needed. So sometimes we could just use the snowflake, or sometimes we can just use the stag. As long as the fire symbol above the phoenix's head is the same fire symbol in the GUI, it should be fine.

I also mentioned that, while these coloured versions were awesome, I do like the idea of having simplified versions. So maybe silhouettes? We also made some other nitpicky suggestions to Casey and she fixed them right up for us. 

What we have here are three-toned, two-toned and one-toned versions of our logos. These could be used on jerseys as a customizable option, and in the environments on banners, not to mention the GUI. I think these turned out great and it will be fun to see these in the level and on the characters.

As far as environments go, at this stage I just think it's wise to keep putting out as many concepts as possible. That way we can have a collage of our own work to pick and choose from. The more ideas, the better. And the more angles of the levels, the better.

I drew over Rob's whitebox of the ice map for this. I just wanted to get a feel of what we want to go for. I think the first piece of concept work is always the hardest because it's when you have to make the most decisions on the spot. Afterward, you kind of just already have a feel of what you're going for so you feel a bit more free to just do it.

I also go to working on even more goal concepts, because we were dissatisfied with just having one. 

Kyle suggested floating rocks would be really cool and magicky, and I was like, "Totally." We wanted to play with the geometry a bit too, and see what our possibilities are for embellishment or marking the goals. We want the goals to stand out, because they're pretty much the target for the players. We want the target to be easily identifiable and easy to see. Kyle played around in Maya with primitive shapes too, just for more ideas.

Everything is kind of in the "in progress" stages right now. Kyle and Sibyl are working on rock sets so we can start filling the levels in with not-whitebox art. Kyle has also started working on the goals.

I'm jumping around a lot, so I think I'm going to need to get started again on menu concepts since our programmers are ready for art for that.

I can't wait to see our art as it's being placed in the levels. The levels are interesting and fun to play now, but as we start getting art in, the game will really start to come alive.