FAQ Search
Memberlist Usergroups
Profile
  Forum Statistics Register
 Log in to check your private messages
Log in to check your private messages
Moonpod Homepage Starscape Information Mr. Robot Information Free Game Downloads Starscape Highscore Table
June-04: Unit Customisation
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary View previous topic :: View next topic  
 Author
Message
Moonpod Developer Diary RSS feed -RSS Feed
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Mon Jun 07, 2004 2:19 pm    Post subject: June-04: Unit Customisation Reply with quote

I've gotten a bit behind this month. I was hoping to finish the full list of equipment available for both the Hades Heavy Battle Tank and the Cerberus scout class tank, and finish off the Cerberus redesign. UV mapping is causing all the delays - so much so that I may investigate using a standalone UV mapping application if I can find something I like that's cheap enough. I suppose it's just laziness, but the thought of learning yet another 3D application fills me with dread Crying or Very sad

Despite these delays, I've gotten about 60-75% of the Hades equipment finished, and mocked up a few variations. The image below should also give you a good idea of how powerful the unit templating system will be (If I have the maths right, with the equipment I have finished so far, there are a possible 1024 variations Very Happy )

*As ever: All names are subject to change as is the final equipment list.

Other equipment to come/under consideration: front mounted weapon variants, comms upgrade, squad commander, cargo shell.

Note that the Hades is Pretty big, here's a comparison shot of it next to the old Cerberus design and a handful of troops:

Although this month I've been working almost exclusively on the Hades models and textures, I have also done some of the work towards Starscape 1.5 - mainly helping out in our big push to reduce the download size of the demo. To this end I've halved the length of all the music tracks. Don't worry though - there'll be an 'extended tracks' pack available from the customer panel - this will also allow us to use far better quality compression, so the music will also be available in higher fidelity than anyone has heard it so far. Cool


Last edited by Fost on Fri Jul 16, 2004 11:02 pm; edited 2 times in total
Back to top
View user's profile Visit poster's website
Goober
Pod Team
Pod Team


Joined: 11 Oct 2002
Posts: 449
Location: Moonpod Central



PostPosted: Mon Jun 07, 2004 2:20 pm    Post subject: Reply with quote

Sadly, most of my time this past month has been spent working on the next update of Starscape. We really wanted to get the download version size smaller than the ~37MB it currently is, so we identified the problem areas (mainly just the huge amount of sprite data) and started thinking about solutions. As it happened, Fost had encountered some talk on the web about JPEG2000. We looked into it a bit and it seemed very good, good quality, supports alpha channels, and small file sizes even compared to JPEG. So I started looking into how to implement and integrate it into Starscape.

The first problem was the poor quality of documentation for a lot of the open source libraries, so we looked at a commercial solution which, initialy, worked well. The only hassle was that it wasn't handling alpha channels properly, so we emailed the vendor to see if they could clarify the issue somewhat. We waited a little while, and waited some more, and they didn't bother replying. Thanks very much to those guys, you've been no help. At least we were still in the free trial period and hadn't laid down the hundreds of dollars licensing fee. Back to the drawing board, and back to the open source solutions. Eventually I figured out how a library called Jasper (one of the JPEG2000 reference implementations, and free for commercial use too) works and got that all working.

I ran Starscape the first time with JPEG2000 compressed sprites. Everything seemed to be working, aside from the usual problem of some objects having their color channels swapped around (I always goof this up), but it was slow. My word, it was incredibly slow. Slow to the point of being unusable. The only thing left then is to decompress everything on install or first run (I favour install-time because the user is expecting a bit of a wait while the installer does stuff). To that end I started coding up a small app, that the installer could invoke, that would take a package of JPEG2000 compressed sprites, pull them out, decompress them, and stream them out to a file that the game could load. And thankfully it seems to work ok. I'm still ironing out the last few bugs before the release, but it basically all works (finally!).

Aside from this, I've done some bug fixing (just minor issues) on the new engine code for Poo Bear to be able to carry on with Battlescape, but pretty much nothing else besides. It's safe to say it's been the most unexciting and uninspiring month in my programming career so far. Which is a good warning to any aspiring programmers out there; once you get into the real world, it's not all about writing interesting and challenging bits of code, sometimes it's plain boring. Hopefully I'll get the chance to do something a bit more interesting this month, before my brain atrophies to nothing.
Back to top
View user's profile
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Mon Jun 07, 2004 2:20 pm    Post subject: Reply with quote

This was a decisive month for the game design, there were so many cool ideas going into this game that there was a danger there would be too much to do in not enough time. We really don't want to skimp on anything or dilute features, so it was back to the design document and the schedule. The game is really split into two parts, battles and world simulation. Simulating a world, its economy, empire building and a dynamic war is a big challenge and it needs a lot of time to do it justice. It also needs to be built on top of a solid fun battle game or it would be such a waste. The solution is to split the game now and focus on the bit that logically has to come first; Battles. I really hope that the first game is so popular we can come back and do the world simulation as "episode 2".

The core of the game is the battle, that is the ultimate test of the players choice of units and their customization. That has to come first and it needs all our focus to make sure it's done right. With that in mind the design document and schedule are now redone to concentrate on the "battle" and the process of unit selection and customization. User interface design is a critical (but boring) key aspect of getting this right. Ship modification in Starscape wasn't as smooth and easy as I would have liked and you only had 3 ships! It needs to be a much more efficient interface in Battlescape considering you might have an army containing 10-15 squads of 10 units each!


Here the player can manage his army, drawing in new recruits and upgrading his regulars as they gain experience in battles.



Here the player is selecting squads from his army to form a specific detachment to take on some mission.

So what is Battlescape now? The player should end up with his time split between two jobs a) building and upgrading the ultimate army b) testing different detachments of that army in the heat of battle. Where a detachment is a specific selection of units from the army chosen to perform a specific mission. The game should contain a variety of missions designed to make the player think about how his units work together. These missions should come together in a big campaign with the game built so that hopefully we can add some more campaigns after release and really build it up into an epic game with lots of units.


The core of the design update is finished and some of the critical front end work is done to make prototypes of how the customization screens will function. Now i'm looking at the different mission types and trying to get a handle on how the AI can best be implemented. I don't just want the usual "get the best units, select them all, point them at the enemy, last man standing wins". I want missions to demand the player thinks about his role and choose appropriate units/tactics i.e. the outnumbered defensive force dug in and desperate to hold out until reinforcements arrive or the crack elite units sent in behind enemy lines to take out the generators or the outgunned stranded attacker now surrounded and desperate to punch out and escape.

Oh, and I had to stop all that to go and work on the update for Starscape, that game is so polished now I really hope people like it. Almost everything that has been mentioned has been tweaked, fixed or improved. This is something that never happens with mainstream titles and it is very refreshing to have the chance to constantly refine and improve your work.
Back to top
View user's profile Visit poster's website
Weeble
Starscape Jedi
Starscape Jedi


Joined: 25 Apr 2003
Posts: 1143
Location: Glasgow, Scotland



PostPosted: Tue Jul 06, 2004 5:36 am    Post subject: Reply with quote

I'm not sure about posting comments here, so please move this elsewhere if necessary.

To what extent do those interface screenshots represent your intended interface? After staring at the top one for ages, it looks like there is a hierarchy from the army selector radio buttons, down to the squad type radio buttons, then the squad selector radio buttons, then finally the squads list. Then, strangely, both the buttons in the squad modifier panel and the history and awards buttons seem like actions or information specifically related to individual squads. If these assumptions are at least close to correct, I would suggest that your lists need to reflect this hierarchy rather better. How are squad type and the list of squads related (and thus in the same panel) in a way that the squad selector isn't?

Okay, now I realise I'm getting a bit stuck up here, so ignore as you see fit. I would personally arrange this interface into a small "Faction" bar along the top; a tree list down the left half of the screen; and a selected squad panel on the right. The tree list would incorporate the other stuff that is currently in radio buttons, and the squad data, in a collapsable tree view just like in your favourite file manager. I'd replace the abbreviated stat names (that look like they came out of some table-top wargame) with distinctive icons that have tooltips showing the unabbreviated stat-name. That would free up the horizontal space to fit it in half the screen. The "recruit" button probably belongs at the bottom of this panel. Finally the currently selected squad panel would provide slightly more verbose details, the picture and all the actions that can be performed on that squad. Hierarchy is preserved, top to bottom, left to right, and all the buttons are obviously associated with what they act upon.

I'm not sure what the "+" and "-" buttons do, or the empty option bar below them. I realise that it's quite possible I've totally misinterpreted the interface, but I guess that's another reason it needs to be clearer. Some of my guesses are based on the fact that the "Reserves (9)" matches the sum of the values in "Squad Selector" and that the list on the right lists 2 scouts, as suggested by "Scouts (2)" in the same selector. The detachment forming screen is quite baffling, so I'm not even trying to comment on that.
Back to top
View user's profile Visit poster's website MSN Messenger
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Tue Jul 06, 2004 8:32 am    Post subject: Reply with quote

Weeble wrote:
I'm not sure about posting comments here, so please move this elsewhere if necessary.

That's fine...
Weeble wrote:
To what extent do those interface screenshots represent your intended interface?

We have two phases to building interfaces: #1: Get it all working, #2:make it so that normal people can use it.

Phase 2 is pretty dangerous, because ideally you need to leave it until very late (trying to get an interface perfect from the start is usually a bad idea: you slow yourself down, you usually end up with the same mess as if you hadn't bothered, and you won't really be able to hone it perfectly until real users start playing with it), and that means you have to work on it at the end of the project when traditionally you don't have much time and there's so much code in place it's difficult to change. A good UI system helps if it can abstract the front end from the data, but there's still lots that can be difficult.

With Starscape for instance, the R&D screen needed a lot of work from an ergonomics point of view, so we took a screengrab and moved everything about. Even then there were lots of minor touches that would have helped, but were really difficult to change (e.g. changing the crew assignments to be a ratio between Research and Development). Also, after we released, we ended up adding mouse support - a major oversight on our part (we were still in the mentality of producing console games). It works surprisingly well for the most part, but obviously certain screens like ship construct could work in a much more intuitive way.

Still, it's obviously worth taking any feedback on board at all stages and doing what you can...
Back to top
View user's profile Visit poster's website
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Tue Jul 06, 2004 10:42 am    Post subject: Reply with quote

Most things go through multiple iterations and what is posted here is production work usually, but fundamentally you are right to point out the complexity inherent in the management task being proposed. The front end will require a great deal more design work to get it to the point of true usability.

This is the process to get into a game assuming you are NOT playing a tutorial and the game isn't helping you set things up and you want a one-off game.

1. start up the game and enter your name to create a new "general", ignoring any tutorial options.

2. possibly select from a number of factions/races to identify your army.

3. review the squad types available to you and draw some into your regular army.

4. select a map set or game collection to play with.

5. review the available maps and missions available to each map.

6. select a map and a mission.

7. review the mission possibly reconfiguring some of the variables i.e. points limit, game time, etc.

8. select the type, number and difficulty level of your opponent(s).

9. select squads from your army to form a "detachment" of units that comply with the points limit and unit restrictions for the mission.

10. you may feel you don't have exactly the right squads available so you might possibly revisit the army screen and draw a few more recruits.

11. when you are ready launch the game.

I found this book (among others) very useful "About Face". The main idea being how programmers see things logically in terms of how the machinery of the code performs the task and this becomes reflected in the interface. Programmers are also hypnotized by things like hierarchical lists, file systems, exposing maximum functionality and strict error checking.

Real people are a bit different though:

1. They are only interested in reaching their perceived goals as quickly and easily as possible.

2. They are not familiar with file systems and nested hierarchies, such things make them uneasy.

3. They don't like answering obscure technical questions.

4. They don't like being presented with almost infinite choice.

5. They certainly don't want to have to read complex and lengthy instructions.

6. They don't have a lot of time available and they want to feel it is being spent profitably i.e. they must constantly feel they are moving towards their goal.

7. They don't think like programmers.

8. They don't want to feel they have done something wrong and they especially don't want to be told they have done something wrong.

9. They want to feel secure in the knowledge that the program will protect them and that they can always reverse anything they do.

10. They want enormous quantities of help but as they become more experienced that help must not get in the way of their goals i.e. keyboard shortcuts, minimum number of clicks to get the job done, etc. Don't waste time.

One of the biggest mistakes I made is in assuming people will work with the app to get to the level of proficency I am at. It is hard for the author to accept that he is competing with a million other activities for the users time. The user will only put in a certain amount of effort to reach his goals before turning the app off and never running it again. It is very difficult to put yourself into the mindset of someone who has never heard of your game, has no idea what to do, is waiting for the Simpsons to start any minute and just wants 5mins of fun.
Back to top
View user's profile Visit poster's website
Weeble
Starscape Jedi
Starscape Jedi


Joined: 25 Apr 2003
Posts: 1143
Location: Glasgow, Scotland



PostPosted: Tue Jul 06, 2004 6:04 pm    Post subject: Reply with quote

Fair enough. I think the main thing I wanted to say - but I never really did because I had been awake for far too long - is that it appears that the radio buttons cause other parts of the interface to switch in and out. (I.e. the other radio button groups and unit list will change.) This is not a behaviour generally expected of radio buttons, and may be confusing. At most you might expect parts of an interface to become enabled or disabled. I believe that tabbed panels and list boxes (and tree views, hence my first suggestion) are more commonly used for the behaviour intended here.

Of course, maybe it's only programmers who expect radio buttons to behave like I'm saying. I'm not sure. I can't suggest a good reason why they shouldn't work like this other than that it's unexpected.

The other thing to consider (and Starscape still suffers from it) is that when an interface is being driven by a joypad or keyboard, the layout is not so critical because you can force user input into the right bit of the interface. With mouse input, the user can (try to) click anywhere on the screen, and can easily become confused if trying to use the controls in a different sequence from the one you envisioned. For example, do I click on a unit, then disband, or do I click on disband and then choose the unit? Neither control appears subordinate to the other in the layout, which would be my first cue. I have no idea until I try it.

I wanted to say this now, because it's all a bit late with Starscape. I really love an elegant UI. I'm a big fan of a lot of the interfaces to N64 and Gamecube games, largely because you barely ever notice them. I think I'm like most people - I'm not all that great at designing good UIs, but I can sure spot a bad one if I'm forced to use it.
Back to top
View user's profile Visit poster's website MSN Messenger
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Tue Jul 06, 2004 7:47 pm    Post subject: Reply with quote

The important thing is that Battlescape will be designed with mouse input from the start - you can't really do an rts any other way. Although there have been console rts's that work with a pad, haven't they all been pretty rubbish?

Whilst a slick UI is always important, it's even more integral to how an rts works. UI's are always best designed in hindsight however, so I'm sure there will be one or two oversights that will be dsicovered once the game ventures out into the big wide world, like all games. I think we'll get it working quite nicely for release though, I'm pretty good at whining to Mark about any of the problems I see Wink
Back to top
View user's profile Visit poster's website
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Tue Jul 06, 2004 9:39 pm    Post subject: Reply with quote

Weeble wrote:
Fair enough. I think the main thing I wanted to say - but I never really did because I had been awake for far too long - is that it appears that the radio buttons cause other parts of the interface to switch in and out.


Yes, well spotted, as a programmer I have no problem with this but users certainly do have a problem with it and it wont be there in the finished game I hope.

When writing Windows programs you don't realise how lucky you are to have all those wonderful controls written for you. Tool bars, drop down menus, tabbed pages, list boxes, buttons, buttcons, drag and drop, the list is endless. They save screen space, develop a common standard of use, speed up implementation, allow better UI designs and ultimately they make the user feel more comfortable and empowered.

With a game you have nothing unless you write it yourself, so the temptation is to write just enough to get the job done and this can result in something that isn't intuitive unless you are very careful. But it's ok in prototypes Wink
Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group