Lost my Keys's Recent Forum Activity

  • Unfortunately, there's no object that handles microphone input. Somebody would have to write a new plugin for that functionality. I was looking into it earlier, but I couldn't find much information on getting input from a microphone.

    I dunno if it helps but you could look into how video chatting setups work, webcam/mic systems, the way programs like Skype, MSN, so on and so forth deal with the microphones. Or even open source methods used for realtime chatting in games (there's bound to be open source variations on how to do that), the latter will probably have way more info about it.

  • LOL! I totally passed by this thread at first, thinking it was the other one. Didn't realize it's a new version haha awesome fixes too! YAY for canvas love!! Downloading now.

  • I really don't understand questions like these. It's like being handed a box of crayons, and the first thing you say is "Hmm... nice crayons and all, but could I draw a cat with these crayons? Because I seriously doubt someone could draw a cat with these crayons."

    It's like you're trying to trip us up. "Oh, hehe... cats, you say? Oh my, how embarrassing! No, I'm sorry, you couldn't possibly draw a cat with these crayons. A fire truck, maybe, but definitely no cats."

    A cat has nothing to do with crayons, and "spells and teleporting" have nothing to do with programming a game. You can use the crayons to draw whatever you want, and you can use Construct to make whatever you want. If you couldn't draw cats, they wouldn't be very good crayons, would they?

    A better question would be "Can these crayons draw with infrared light?" And the answer is YES THEY CAN! THEY ARE MAGIC CRAYONS!

    And guess what? Construct can draw with infrared light, too... someone wrote a WiiMote plugin. But no, there is no way to export your game to XBOX360.

    The easier a program is to use, the more you're going to get questions like these. Why? Because it attracts people who aren't programmers (nobody who uses programs like these, are programmers, there's no programming involved and you're not a programmer by using them, it's like a modder calling himself a developer, or a college student with no real world experience, claiming they know better, it's a bit of a joke, haha) The guys who wrote construct, they're programmers. At the same time, the easier a program is to use, the more limitations appear, simply because the creators can't think of everything or prepare for everything, and all software has limitations. Therefore it's a perfectly valid post to make, asking if this or that can be done. Especially when people run around claiming construct can do everything, when the reality of it is, it can't.

    So it might piss people off to hear "oh oh can you make spells n shit with it?" but if you think about it, it's a completely normal question for someone who's never used it before to ask. They aren't programmers, that's why they're here using something like this, and not on a C++ forum. We're talking people off the street, the average joe, probably with little or no experience, sees something that says you can make games with no programming, what do you expect from them? They're attracted by the appeal of making games, but may or may not know what's involved. So to them, a regular user with no programming experience or developer experience, a characters "spell" is a spell, not a collection of events and variables. Yes I admit, reading instructions, wiki pages, manuals would answer a lot of the questions that get asked. But really, you can ask people to do that all you want, it's a known FACT that most simply wont. It's "so much easier and quicker" to ask on a forum.. supposedly, lol. It's been that way for years, and it wont change for a long time.

    Not to mention the fact that a complicated programming type answer is utterly useless to someone with no programming knowledge, when all they wanted to know is "can it do that?", they can go into details and learn how later. They just want a readable understandable answer for now.

    Seriously, there is a very real problem with newbie hate and elitism on these forums and it's unwarranted and happening a lot.

    Programmers (e.g. Ashley, David and the plugin creators)

    Developers (people with real commercial experience)

    Modders (people who mod game engines or create TC's)

    Game Makers <-- this is where construct and other apps like it are, along with us, the users.

    We all use construct, we're all in the same boat, we're all here for the same reason, to make games without the need to program, and the majority aren't going to be crack coders or immediately familiar with the event system "scripting" that exists in the application OR what construct is capable of, that's why many are here, to make games without having to learn a programming language to do it, that's the whole point of an application like this, to make it easier, to appeal to the masses where the prospect of using C/C++/C# etc. is too daunting or beyond the grasp of the user. This appeals to both the guy off the street looking for an easy way to make games just for the fun of it, or those with years of real experience in commercial game development (as is the case with myself and at least one other user I'm aware of on the forum) who either can't program or don't have the time/interest, or have worked with enough programmers to know how infuriating they are to work with closely on a project and wish to avoid them as much as possible. There's going to be a mix of all kinds of users on here, which means a mix of all level of questions and queries, and not everyone is going to be a mathematical genius.

    If the user is from the modding community (which is going to be very common), then expect lots of "can it do this and that" questions because that's what they're used to. DaviX is likely a modder, probably played around with modding Source or the Crytek engines, or maybe dabbled with UDK. All those are setup to begin with for a particular kind of game and the only real part of them seen by many, is building maps and making events (can you see the confusion here now?) make a map, add a player start, add a few objects to do this or that, bit of scripting for creating events, and then compile and run, simples. If that's a users only real experience, then they're going to assume construct is the same.

    As for his "can you make games for the Xbox360" question. No, I don't think you should look down on that either, for the above reasons, to someone off the street, that's a perfectly valid question too (yes it could be answered easily with research but again, the "it's quicker to ask on forums" syndrome comes into play, blame the internet and the I want it now generation, lol). But not everyone will know automatically if something can or can't be done, after all, Xbox IS practically a PC, and there are other apps out there capable of it in some way (legality aside), there are many cases of homebrew games being made for consoles, and while doing so is not easy, fans of that will always be looking for an easier way to do it.

    Doesn't construct have a FAQ somewhere? Which can be linked to when someone first posts, which will cover all the common questions people ask, and give decent answers to them, both advanced and basic. So they don't have to ask on here and be made to feel unwanted or thick, just because they didn't know. I think that would be more beneficial than getting angry with people.

  • So... in my ship game you can zoom out. And each ship don't has a label (Ship name, position, etc.) but you zoom out and the text is unreadably small. Any ideas for a fix?

    Place ship name, position etc. in something else and don't let zoom effect it.

  • Hey guys, thanks for the info. Do you think you can give me a short direction of where to start these operations you've described? I'm still new to this program so I'm not familiar yet with where everything is.

    All I see right now that even resembles where to start, would be the project folder that says "global variables" but beyond that I'm not sure what to do. So, just a small point-to to get me jumpstarted would be appreciated.

    Create an event, for example a Start of Layout event. Then use a system action, then set value under global variables, and create the global variable from there, it can be either numerical or a string.

    You should probably get more familiar with the program and where things are before attempting to make anything but simple tests. The wiki has some info on what each part does and the majority of options and features.

  • Off the top of my head, you could try drawing a line from point A to point B, and use a triangle shaped sprite (the arrow head) and tell it to sit on the end of point B, with an angle facing the mouse. That "might" work?

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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

Lost my Keys's avatar

Lost my Keys

Member since 29 Nov, 2009

None one is following Lost my Keys yet!

Trophy Case

  • 15-Year Club

Progress

15/44
How to earn trophies