this is a repost of a entry i made on the dacii website available here

Hi there my names Stewart and I’m in charge of the user interface

Back during the start of the project we allocated ourselves roles, and near everyone specialized in 3d asset creation. I had initially planned to have only a visual role in the user interface creation and split half my time making textures for the 3d stuff as well.

But as the project progressed, I decided to assume more responsibility for the interface design as it was becoming less manageable the more people tried to help. The design process is very intricate and any new additions to the flow needed careful consideration and design before implementation however during group sessions everyone was quick to suggest new features without thinking about these ramifications the same way I did.

I find myself trying to reel back the group’s creativity during the brainstorming sessions, I imagine this must be how programmers feel all the time.

Anyway, back in the beginning before I was so jaded I made loads of different versions of buttons. As you can see, very influenced from the iPod’s style.

I got feedback from the rest of my group and cherry picked the best elements from each one and tried to create an omnipotent super button which would satisfy everyone.

But then I wanted to change the interfaces color scheme to reflect the change of season so these blue color schemes went out the window in favor of transparent buttons which would simply be shades of whichever color the background is.

Speaking of which, here are the 4 backgrounds in question. One for spring, summer, fall and winter

The symbols were originally intended to animate in the background to serve as an indication of which season it is to color blind players. But with the latest revision of the user interface, it always displays the season in text so this is no longer its primary function. The animated backgrounds will just be for visual flair now.

Speaking of accessibility, a driving force behind the design was to have as few sub menus as possible, the project has elements of strategy games and tower defense titles, and in those games repeat actions such as deploying units or doing common actions such as repairing structures are always quickly reached and no more than 2 sub menus.

Of course that`s delving a bit too heavily into hardcore game design and the project is more akin to a simulator/educational tool so I looked at Pokémon as a simpler influence.

In Pokémon the player is basically using the same menus for the entire game. It doesn’t become boring because there is always a high degree of feedback from the top screen and the time it takes to play out makes sure the player doesn’t become bored or frustrated with using the bottom screen constantly.  At this point in the project we have reformed the camera in the 3D section of the game so it is on rails and scripted for various events, such as if the player lays down an object the camera will zoom to its location to observe the effects. Now that we have some degree of `top screen flair` that is out of the players control, we can mimic Pokémon’s simple but successful interface design.

The actual flow of menus has been optimized quite a lot with the newest build also. Originally I wasn’t taking advantage of all the space that widescreen monitors had to offer so I could only fit about 9 buttons and a map. But with the wide version I can display 8 buttons, a wider map, a time slider (a new addition) and 4 large status icons prominently on the side. There may be one less button but the interface has been streamlined considerably. Animals are no longer a deployable object, and if you want to repair, move or erase a plant those options are self contained inside the plants menu. Same for buildings, which have now been renamed structures.

The old interface, with the camera controls and the sprite map.

The preliminary redesign.

In the old interface, if you wanted to erase or move an object you would have to go into the `manipulation` menu and then choose the object type to do so. But now the `move plant` or `erase plant` functions are self contained within the plants sub menu. There is still the same amount of menus to travel to actually choose a plant and place it within the game world, but to make up for this, the plant selection sub menu is much wider and can display twice the amount of plants on screen as before. Thanks to the widescreen and the smaller arrow icons.

All of the buttons in general have been shrunk slightly, I was paranoid about having tiny buttons for accessibility’s sake, but of course I wasn’t taking into consideration the widescreen monitor. Now that the buttons are smaller I’m keen to include reflections on the bottom of them where the text is.

As I mentioned earlier, there is a new time slider. Moving the icon along will move time forward (not sure about going backwards to undo actions, need to discuss with group) another apple influence here, the slider looks similar to the time slider in iTunes. A slider is a better fit for time manipulation as the player feels more in control then if they used buttons. Before, in the earlier version of the interface if the player wanted to change time they could only do it by jumping between seasons in a buried submenu. Time manipulation is to be a prominent feature so it`s been integrated onto the main screen at all times instead.

The map has been the hardest part to design, mainly because it`s so strongly linked with everyone else’s elements of the project and I have to take those into consideration when designing it. The map is intended to be a top down view of the entire beach and that hasn’t changed. Originally the map did have a grid but it only displayed when the player was about to edit the game in some form. Now, the grid is displayed constantly and pressing a square will move the camera to observe that location. But there is no longer any zoom, rotate and scroll functions from before. Which is good because it frees up a lot of room on screen. That and I imagine trying to code a fully interactive camera using touch screen controls would have been a major time sink. When actually making art assets for the map screen, I originally used tileable, pixel graphics to indicate the health of the dunes. But a valid point was raised that we already have a lot of different art styles (the 3D world, 2D character art and glossy interface) and I should try to tie it all together better. As of now, I’m working on semi realistic art for the dunes using high quality photoshopped assets.

Small Preview of dune flooding.click for animation.

So goals for the upcoming weeks are to create some more interface flow mock ups to show off important changes such as the time slider, streamlined plants and structures menus and map graphics.

All the while continuing to create production quality assets and work closely with the team to make sure everything from both screens are incorporated and sync up accordingly.