Lost my Keys's Forum Posts

  • Before going on. I should point out that this is not your typical tutorial, or a tutorial in the traditional sense. It's not going to show you how to draw your UI, or how it should look or teach you anything like that. So if you're looking for artistic pointers your looking in the wrong place. This is about the theory of UI's, the thought behind them. The things you need to take into account long before you even run your favorite art package.

    So yeah, it's more, things to think about and bare in mind rather than a step by step guide that holds your hand.

    What is a UI?

    A UI (User Interface), UI (Graphical User Interface), HUD (Heads up Display), is the players window into your world. It's their feedback and their input. It's their backpack, their map, their compass, score and menu options. A game UI is and can be any or all of these things and many more, each one as individual as the game itself. Everything we use has a UI so to speak. The remote control, the controls in your car. Designers always striving to come up with better ways of allowing people to interact with other things, making them easier and more logical and ergonomic. Millions each year are spent on even the most mundane of UI's, even the trusty pen has a fortune spent on creating the perfect feel.

    So why do so many developers not really put much thought in their game UI's?

    It's all very pretty but..

    This is the problem, everyone who can draw a bit, thinks they can create the perfect UI. Unfortunately 9/10 times all they're thinking of is how it's going to look and fit on the screen. Which I admit, is important in itself, but you can have the worlds most amazing looking UI, that does nothing but infuriates your players and ultimately puts them off the game entirely. The UI is often more important than the game itself. We can forgive less than perfect graphics, or the odd hiccup here and there. But give your users RSI trying to control your game and you'll find they're not so forgiving.

    The perfect UI is like the Holy Grail, unobtainable and probably doesn't exist, but that shouldn't stop you from trying to reach such a goal. The better your UI, the happier your players will be, rather than a jarring experience they'd much rather forget.

    The layout

    Ignoring HOW your UI looks aesthetically, it needs to be functional, logical and simple. This seems like standard stuff, but you'd be surprised (or perhaps you wouldn't be?) at just how many games seem to end up with the most god awful UI's possible.

    Think about your game, the style of playing. Do you have icons on the screen used to move the player around? Try keep them together. It's a known fact that a player will try on average to move the mouse (or controller) the least distance to do what they want. Don't put often used icons far apart from each other. Group them together where they are in easy reach of the player.

    As with controllers below, the easiest (semi)cure to bad UI's, is allowing the player to customize them. But unlike customizable controls, a custom UI is much harder to setup, and it can and will break any specific layout idea's you want to use. Just how much customization should you allow? Will you provide an option to save custom layouts? (A very good idea!). How will you create your UI so that it fits your game no matter what the player does with it. Can they move parts around, resize them, remove them completely or even replace the visuals of them?

    Remember, each game will need it's own unique UI, something specific to that. As mentioned earlier, what works for one game, won't in all likelihood, work for another. A shoot-em-up's UI would be terrible for an RPG, and a beat-em-up's UI would be pointless for a puzzle game. Taylor your UI to fit the genre and your game, not just in appearance but also in function. For example, a standard shoot-em-up will generally not focus or worry about displaying the power-ups you have. The game will be fast, no time to be looking around your screen for detailed info, especially when you can see by your actions that you have this or that power-up. Instead just have a nice clear display, showing lives left and score, if required. Make it very simple to read at a glance, because often that's all the player will have time for.

    An RPG on the other hand, while still wise to keep them simple and easy to use. Can allow for more information, RPG's are deeper and you want to draw your player into the game as much as possible. So give them plenty of useful feedback, but at the same time, don't overdo it. There's been many RPG's that have gone completely overboard with stats and information, and that annoys the player just as much as too little. Try and find a balance. Take your target audience into account. If your game is going to be more strategic and have great depth, the user just might want lots of information available to them all at once. An RPG player will want lots of information, but wont require it all the time. Consider just sticking to the basics like health, magic etc. and weapon stats. Does your game require you to always have their level displayed? Is it that important or can it be placed on another UI screen? Try limit your main UI to just the things your player will need to see often...

    Which brings us onto separate UI screens. The more basic your game, the less likely you'll need them. But in the case of RPG's and other complex games, they're just as important as your main UI, but will often be used only for displaying information rather than control, and unlike the main UI, you can relax the rules somewhat. There are exceptions though... Using RPG's or games with inventories, for example Fallout 3 or Oblivion. Your character wanders along, finds something they want. It's just a key press to pick up the object (or steal it). Nice and simple and no messing about. But in either of those games, have you ever tried finding a specific item quickly, once you've got a full inventory? It's not so easy is it. Sure, you can display certain categories, to help shorten the list. But lets face it, in those two otherwise well made games. The inventories leave something to be desired. Often left to modders to attempt to improve and fix. What your player will want, is the most often done activities have to be the easiest to perform. In the case of inventories, sorting, and spring cleaning should be in the list of "things that should be simple and quick". Changing stats should be simple to use, to the point, but isn't going to be something that's done often, so can take a back burner.

    Be consistent! If one part of your UI behaves in a particular way, then every other part of it should follow the same behavior. There's nothing more frustrating than finding different parts acting differently, it's confusing and should be avoided at all costs. For example, a + icon for increasing a value by 1, should do the same wherever a matching + icon is used. Don't mix + icons on one page, with > icons on another if both do the same thing (such as increasing a value), it doesn't look quite right.

    Consider shortcuts as replacements for less important actions. For example, you increase a value using the + icon. If you press shift while clicking the icon, it increases by 10 instead. Use a little tooltip to explain this. It's simple to follow, easy to use and you save space by not having to use a different icon for both.

    Another option to consider, is do you even NEED a UI sat over your game? Be creative! Just because games often use three quarters of the screen for the game, the rest for the UI doesn't mean you have to.

    An old game on the Amiga had a familiar icon menu on the right, yet most of it's controls and options were done via the right mouse click and a brain like thing with bubbles in it for the options. Unique and.. interesting. Another, more recent game, had the players health not displayed on screen in the conventional sense, but instead appearing on the spine of the character themselves. So just because you've made a shoot-em-up. Doesn't mean you HAVE to follow the norm. But don't go crazy. Unique and interesting is all well and good, but you can go too far and simply confuse the hell out of the player.

    A good example of a standard UI used in an interesting way would be the PIP in Fallout 3. While not exactly original (many games before have used the wrist device type UI), it looks good, and works well, without filling up the entire screen or screens with lots of information when it's not required. Leaving the more important parts (health, radiation, weapon quality/ammo) displayed on screen always, where the player needs them most. The storyline also places this UI into the game, helping to bring an acceptable reason for their existence within the game.

    Press Z + V + H + up then move stick hub-wards while dancing on the spot and drinking a glass of water to continue

    Something just as important as your UI, perhaps more-so. Is your control method. There is one VERY important rule you should always follow when it comes to controls, and that is.

    Allow your players to CUSTOMIZE them!

    This is by far the most important yet most often ignored rule. Never, ever assume a key configuration or controller layout that fits your style of gaming, will be right for the next person. The most obvious example of this is the often used WASD layout vs the arrow keys. Ever tried using the WASD configuration, with a mouse, when you're a left handed person? The same goes for the arrow keys and right handed users. While it's true, a small minority don't notice, or have conditioned themselves to work with either or both. The majority will find it very uncomfortable, and in some cases quite painful too.

    Now think back to when you first used a computer, played your first game using the keyboard. Chances are you will have immediately tried the arrow keys, because, well, they're arrow keys, directions. It makes logical sense. But as the majority are right handed, it's not comfortable, therefore the WASD layout became popular. These are things you need to bare in mind. A gamer will more often than not, try the WASD layout first, while someone else will try the arrows first. Same with right vs left, though many left handers will usually expect an "awkward" layout and navigate to the customization screen before doing anything else (we're used to being forgotten, lol).

    By allowing the user to customize ALL the important controls (and all the other not so important ones as a bonus) will practically resolve this issue entirely. It'll also save you from having to spend ages deciding on the perfect layout for your game. But even though you're letting the player configure their own controls to fit their playing style and comfort. You have to still consider usability. Get friends and family to play your game. Don't give them too many clues on the controls, see how easily they figure them out for themselves. Provide basic in game help, to show what does what. Ask them to explain what they felt should have happened when they pressed this button or moved that stick. Find out if performing that action has them twisting their fingers about, or getting lost and hammering random keys to find the right one quickly. Try different configurations, test, test, test. A good control layout should be easy to use, so easy that in no time the player doesn't even have to think about it, they just do it.

    The above applies to game controllers too, however in those cases it's recommended you try and stick to the popular configurations as your default config. Take the XBox 360 controller, lots of buttons and things to use. Don't go against the grain. Consoles are, for now, taking the lead in how a controller should behave, and with so many people familiar with them, the player will automatically use the most familiar setup. Which in the 360's case, is the left stick to control, the right to look around, the triggers to fire. Make use of the start and back buttons too. That looks more professional, and it's more likely someone will want to press start to start, than left trigger, isn't it.

    But the 360 controller isn't the only one in the world, players have for a very long time used all kinds of controllers, though it wasn't until the popularity of the Playstation that they really came into their own, with many companies designing variations on a theme, trying to improve on each others design. Before that there were fewer choices and far simpler controllers (though mostly just joysticks back then). Some have lots of buttons, some will not. So what do you do about that? It might be very tempting to create your game to take full advantage of the 360 controller and all it's buttons. But what happens if (and there will be many) a player has a different controller? If you're developing for the XBox (which you wont be with construct), then you can make full use of it's controller and to hell with the rest. But you're working on the PC, which means you have to consider any possible configuration a player may have (within reason of course. If some player is using a McGyvered Colecovision controller on their brand new super fast PC and wondering why they can't do much, then that's not going to be your problem, lol).

    In time, construct will likely have plugins like the 360 one, for the most popular controllers. In that cases, be sure to include those plugins and treat each one as equally as the next. For the rest, you need to decide on a generic configuration, and always bare in mind usability across all your controls, be it mouse, keyboard or controller.

    Naturally there are more specific control devices available (such as the Nintendo Wii fixed up to the PC) which you wont be expected to support, unless your game is meant for use with it. You can't, after all, cover every single base. Just try and look after the majority while providing something for the minority, and it should take care of itself.

    A final, yet obvious mention. Allow the player to save the controls, do it automatically so they don't have to. Construct allows the use of .ini files. Store your controls in an ini file.

    Brandy Eggnog made writing this post incredibly difficult!

  • The problem is, you're comparing traditional animation techniques to game animation. Which a lot of times isn't viable.

    For every extra fraction of a second your firing animation is playing. It's another fraction of a second I, the player, have to wait before the bullet is fired. Now when you factor in player reaction time. You're risking very slow response time. Which annoys players. That's why you will often see sequences used for quick actions have less frames or simply happen very quickly. A player doesn't want to press the fire button, then wait for it to happen. Sure, that's more realistic, but it's not what a player will want. Especially if they just lost the game right at the end, because of it.

    So yeah, while more frames will look smoother. And could be fine in other situations. For actions relying on fast reaction times. It's a nono. Come to that, same could be said for anything the player does. They move to the left, they want to go left right that moment. But no matter how good their reflexes are, there is going to be a pause between their brain saying do that, to their hand performing the action, to the game responding in kind. That can take a second or more in a lot of cases. So adding more time to that is going to make the controls feel sluggish, forcing the player to fight with them more than the bad guys on screen.

    It's just something to bare in mind. Finding a happy medium between quality and response.

  • Nice one!

  • But yeah, happy hollywood ending kind of kills the message. Perhaps there's an alternate UK ending?

    LMAO!!

  • I would not recommend using automatic tweening (or morphing, which is all it is for the most part when it comes to raster images) for sprites, for tons of reasons, but mainly because it would look like Keira Knightly's cooking (hey she said it, not me!).

    Automatic tweening is fine for 3D objects, bones, IK or object/sprite world movement, things like that, because it's all down to math. But using it on pixels, with only a small number of frames, you're going to end up with smeared graphics and the time taking to get them looking halfway good, it'll have been quicker to draw them by hand or use other methods.

    Think about it, a tween is the computer being given X number of frames to turn A into B. It doesn't know how an arm or leg moves, it doesn't know the difference between the sprites shirt and it's face, all it knows is the quickest way to get from A to B. Yes you can add curves and splines to the tweening motion. But a 2 frame curve is going to be a straight line any way you look at it, and the more frames you pack into a particular animation sequence, the more unresponsive it will feel to the player. Which goes against how a good morph works.

    There are a few ways to do it by morphing sprites themselves, using weights etc. But honestly the results are never going to look all that great, so I'm going to help you by not going into detail on how to do it.

    It might seem like a handy shortcut, but it's really not. You'll get far better results doing it by hand, or doing it in a 3D package or with vectors (both of which is going to handle it better), then converting and using the output as your sprites. And yes, 3D can be used quite nicely for a 2D sprite, even if the sprite isn't going to look 3D (cartoonish ones for example). In those cases it's pretty similar to how bones work in construct, just easier and more advanced (since those programs are made for that sort of thing) only you'll have the choice of avoiding the segmented body sections by being able to use real skeletal systems within the 3D package (but then you'll also miss out on the rag doll effects Ashley suggested for a future version with constructs bone system).

  • Thanks for the reply CROS! I dunno about anyone else but I liked the sound of those answers

  • You could make a game called Crash Test Dummies as a demo/example of all the weird and wonderful things that are possible, lol.

    Ooooh, they could become the construct mascot! Sell plush versions of them, buttons, posters, bobbleheads.. *slaps self* ok getting carried away.

  • > So long as construct NEVER forces a logo or any kind of branding onto anything someone has made with the software, then as per my original vote. I'm more than happy to let everyone know what I used to make it.

    >

    Haha nice...so if we make it manditory to include a logo/brand for using our product for free that we have invested hundreds...or maybe thousands of hours into, you wont be happy Sorry I just found that kinda funny, but at the same time I know what you mean. Its like donations where you're forced to pay at least $1 for the product...doesn't feel like much of a donation if its manditory. But dont worry, we dont plan on adding a splash screen or whatever. They are annoying.

    Hehe, yeah I meant it to be tongue in cheek, glad it didn't offend anyone. Those mandatory "donations" are annoying, I agree. If I remember correctly, I think it's a loophole with earning money from something but avoiding paying tax, or along those lines. That and they know what they made isn't worth anything, but are going to try their luck anyways, lol.

    I think an official splash logo provided as a .psd or a collection of different styles, no background, background colors etc. though would be a good idea. Then users could use it in the game if they wanted, or put it on their site for linking back to this one. Once version 1 is officially ready and out there, chances are a lot of folk are going to be using it, and naturally will be wanting to show off their creations, and a legit logo/splash image will look better than something they might have thrown together in Photoshop themselves a few minutes before putting it online.

    Plus I really want to do the whole Warner Bros thing to it ; )

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • LMAO! Only a few minutes ago I was reading some crazy journal entries I'd found randomly, and folk commenting - most of them were doing the "This" reply.

    So brilliant timing and very funny, lol.

  • What is it with you and deadeye, the test caps you two post are always more entertaining than most games

    Seriously now I wanna make a circus game where you have to jump your fella from the top and dive into a cup of water below, lol.

  • Yeah, I'd say that's possible. How you do it though, well there's probably a bunch of different ways.

    If it's adding premade parts, then that would be relatively easy (each piece having a unique id number, and if you save those id numbers, then it knows what to change it to look like later.. heck even use a codeword type system or something eg: 924519281 would create a character (hey random character building! lol). You'd have your base character as the collision boxes and invisible and go from there, just attaching your custom character to it.

    If there's more going on, like allowing them to actually draw the parts themselves. Well again I don't see that being too complicated really considering it would be pixel art, so you'd basically have a small grid with each piece being on or off and the color being decided by whatever they've selected in the games UI (can reference RGB info) then I dunno, similar method to above for storing the information or even saving the parts out. Not entirely sure about that bit, I've really not looked into the whole saving and loading thing beyond seeing the loading having problems (don't know if those are fixed yet).

    I don't think the image editing object will be useful for this though.

  • <img src="http://dl.dropbox.com/u/939828/construct%20powered.png">

    heh

    Awesome!

  • So long as construct NEVER forces a logo or any kind of branding onto anything someone has made with the software, then as per my original vote. I'm more than happy to let everyone know what I used to make it.

    By having it entirely optional. I think then a special version of the logo, provided on the site as a .psd or something where everything is broken down and usable in parts would be a good idea. That will then let the more creative ones play around with it somewhat. I'm thinking along the lines of how various movies will often change the logo's of Warner Bros and Fox at the beginning of their films, or Lucasarts often did in their games with their logo. I think something like that would be good fun, and help make the logo "part of the game" rather than just stuck on the start somewhere. Eventually could even have as part of some construct awards event, a "best use of the Scirra/construct logo in a game intro" award. And then, at the same time, being optional will allow for a simple text mention in credits instead, if the person making the game so chooses. Whatever the game maker decides upon and whatever happens to work for their game (creative introductions will work in some games, but obviously not others).

    So yeah, could be an idea to keep something like that in mind with the design of the -official- logo/splashscreen.

  • Hey CROS, I have a few questions for you, since I really like the idea of something like this.

    1) Are you imposing rules on what kind of achievements a game can include? If so, why and what?

    2) Will our games be tied to some system on your site like steam or live, requiring a player to sign up just to be able to play it, or can they continue to download it from anywhere, play it, and if they choose they can later sign up for an account and play through again to get achievements?

    3) Further to the above question. What do you have in place to handle issues caused by someone either playing the game offline, playing the game without creating an account to hold achievements, or intentionally wishing to avoid signing up for whatever reason.

    Website specific question

    4) Is this a free service, or bloated with ads or are you charging game makers?

    5) What does the process involve? For example, a game maker would sign up, then create a "game account" add their achievements, and then somehow link up the plugin to those?

    6) Are the achievements shown on the site following a uniform appearance (like Steam and Live do with theirs), or are you allowing games to provide their own styles. By this I mean I know the actual icon (using the above mentioned examples) are always specific to the game and achievement, but do you still have some guidelines that need to be followed, if so what are they?

    In game specific question

    7) Will this service result in forced branding on games?

    8) How deeply does your achievement system impact a game? Does it sit quietly in the background within the game, accepting input only when required and uploading it to the site. Or will it need to be added to the game at the ground level and integrated with everything from the start?

    9) If your plugin requires very deep inclusion with the game, how well does it play with possible future achievement plugins from elsewhere? Some game makers may wish to link up to a number of sites for whatever reason (including their own perhaps), how will yours effect this or wont it cause any problems?

    10) Is your plugin tied to Game Jolt, or can it be used, like with the above example, for the creators personal site too, for example if the creator decides to have a page displaying the overall number of players who got each achievement on their own site (without requiring them to have anyone sign up, just have it updated automatically), while also using the plugin to update more specific player accounts on Game Jolt (as well as I imagine an overall page there too).

    11) Are there any limits to the achievement plugin, or does it accept variables (and thus practically anything you wish to throw at it)?

    12) Are you insisting on a specific "achievement unlocked" icon/image to be used in game, if so why, what, and what's it look like? Otherwise I take it we can have our achievement unlocked icons/borders etc. look however we want (in game)? But will you also be providing a selection of usable image files, for users who either can't or wont create their own, to at least provide a base level of quality?

    Thanks!

  • Well a collision is a collision regardless of the speed (as far as construct is concerned). So you need to do something like,

    if sprite1 speed >= 5 AND on collision then subtract 5 from sprite1's hitpoints

    else if sprite1 speed >= 10 AND on collision then subtract 20 from sprite1's hitpoints, and so no and so forth. Something like that anyways. (I know construct doesn't write it like that, but its easier to follow the logic).

    If you're using physics though it might be more complex.