ID:2082161
 May 10 2016, 8:07 am
|
|
The question posed is exactly as the title says, what exactly gives a game a "professional" look? How would you determine a standout game on BYOND from a regular "simplistic" BYOND game?
| |
One word:
Interface feedback wait... Er... Two words. A game can play well without interface feedback, but in the end, if you are selling your product and the interface doesn't inform you of what's going on properly, or violates standard industry conventions, you are going to have a hard time establishing a core audience in the mainstream. If the game looks like total crap, players won't be nearly as turned off as if the interface doesn't give them proper feedback. | |
There is a billion things you can do, but some of them would be...
Making sure you have a consistent art style Having a good, well designed interface Making sure the game is polished Another thing that helps a lot is taking a bit of extra time to get all those small details in that you might normally decide you don't need (when you/an enemy get hit, having an animation for it, when you open an interface have it display some kind of animation instead of just appearing, and even something as small as having an interface element be highlighted when you hover over it, those kinds of small things) There is probably more, but those are the things that I can think of off the top of my head. | |
download mabinogi duels for the android, its a rather lame game but i absolutely love the feel of the game and the music that plays on the main menu. it does a great job of creating a very fluid, animated touch experience and the soundtrack adds to the atmosphere. if the actual game itself was more fun it'd probably be my favorite mobile game. everything is responsive and easily accessible, i hate games where i have to spend 20 minutes trying to find out how to disable music or change orientation but this game places everything conveniently and is organized. its hard to describe but basically the game its an A+ in presentation but a C in gameplay.
| |
Good stuff guys! Thanks for the replies.
@TheMagicMan: What would you consider to be a "polished" game? Could you elaborate further on this? | |
He did; what he's describing is polish - things that you would normally not give much time to in your initial development run.
| |
Magicbeast20 wrote:
Good stuff guys! Thanks for the replies. I probably used polish incorrectly in that case. What I meant was make sure the game is finished. That means it has no (obvious) bugs, all of the features it should have are fully implemented (it's not uncommon for people on BYOND to use temporary systems and just never remove them) and any features added for testing and so on are removed. | |
Good music and sound design help a lot. There's an infinite difference in using stock, monophonic sound effects and chiptunes as opposed to having quality audio assets, personalized music for your game.
While there's nothing wrong with using royalty-free sound effects and music, your game becomes far more unique and polished with well-written scores and foley effects. | |
Magicbeast20 wrote:
The question posed is exactly as the title says, what exactly gives a game a "professional" look? How would you determine a standout game on BYOND from a regular "simplistic" BYOND game? a standout game on BYOND from a regular "simplistic" BYOND game? 3 rules to achieve a standout game on byond 1. Have a game that actually works/playable 2. Have a game that doesn't take 5 seconds for a person to move 1 tile 3. Have a game that's fun. But i don't think you should focus to much on making your game standout from other games. Certainly it will help but having a game standout from other byond games isnt everything a game should be. Aetherune Tournament is a good example of a standout game sadly its not seeing to many players these days =(. Maybe there is something else you want to focus on aside from just being "Standout" =) | |
Aetherune Tournament is a good example of a standout game sadly its not seeing to many players these days Yut's games have fantastic gameplay. A lot of the problems with his games reside in two areas: failure to market, and failure to provide adequate interface feedback. That said, Epoch's looking to make that statement false. | |
If you are still wondering what I mean by interface responsiveness, what I've been working on is just one small example:
We went from this: http://i.imgur.com/7eWXUUi.png To this: http://i.imgur.com/AkTrwvx.gifv It's been about a week's worth of work, but only about 4 hours of that was spent on that UI. The other week was overhauling the multiplayer connection system and client-side saving system as well as transitioning players between single-player and multi-player in the same dreamseeker instance and building a bunch of menus I haven't even shown to Yut yet pertaining to managing a lot of stuff relating to the seamless multiplayer experience. | |
Grabbing input text like that is so much more effort than it has any right being with BYOND.
I feel the reason a lot of BYOND games are stuck using interface elements and pop up boxes to get text is just because of how difficult doing something like that is. Especially when you consider it's a minor feature in many games. | |
Speaking of UI, I've always wondered what the best (read: efficient yet nice-looking) way to make a non-obstructive on-screen UI in Dream Seeker, is there any insight on that? Is there any way to fake transparency without going into software mode, or a way to do so without transparency?
I do believe on-screen UI is a very important part in making your game feel immersive and seamless (read: one more step towards being professional), though you should focus on gameplay first and foremost before at least the alpha stage. | |
I feel the reason a lot of BYOND games are stuck using interface elements and pop up boxes to get text is just because of how difficult doing something like that is. Yep. You'll find no disagreements from me there. That input element you are looking at is actually a standard interface element. The trick? I'm calculating its anchors relative to the client viewport's relative positioning data to lock it to a specific screen location. I use about 30 lines of code to keep information on hand about the client's viewport when a resize is calculated. The input element is generated on need and configured to sit exactly on top of the background of the input element when shown. The background of the input element is actually a dynamically built HUD object that automatically constructs itself to fit the exact size that the element is specified to take up. I don't like the input element because it means that I can't directly control the input filter or the presentation to automatically reject keystrokes (say if I wanted to limit an input to numbers only, or limit it to 32 characters.), but it's way better than using maptext because it allows you to copy, paste, highlight, delete, backspace, seek, home, end, etc. Working with them is actually amazingly simple and intuitive because of the underlying structure that I've set up to handle the input elements. It shouldn't require the brute know-how and hacking at things skills I've acquired in 15 years to get something like this actually working. This is the kind of thing that BYOND should be able to do in the hands of a day 1 programmer. Speaking of UI, I've always wondered what the best (read: efficient yet nice-looking) way to make a non-obstructive on-screen UI in Dream Seeker, is there any insight on that? Were this three months ago, I'd have sworn by HTML5 browsers, but rendering speed takes a digger when you layer a semi-transparent window over the map. Transparency is definitely a major issue with anything HTML5 or skin based. These days, I'm fleshing out my private UI library a little more, which primarily uses genericized HUD objects on the server with minimal support from full-alpha input elements. Let's talk about emulating each of the screen controls via HUD objects: Buttons: Fully emulatable on the server. Really not an issue. Inputs: Problematic. Dealing with maptext overflow. Can't crop or scroll maptext to show the edit context. Can't read from the clipboard during a paste. Can't interact with maptext with the mouse to select. Can't write to the clipboard to copy. Outputs: Problematic. Can't scroll maptext. Can't deal with overflow. Can't crop maptext to deal with overlong messages. Can't highlight, copy, paste. Can't click links. can't detect hover events for tooltips. Rendering maptext is super slow if the string is very long. No way to detect occupancy of maptext when rendered. Tabs: Problematic. No way to crop content area to a renderable shape without using a plane per pane. No way to measure maptext to ensure the tabs are big enough to fit the tab titles. No control over overflow to prevent overlong tabs. Labels: Maptext. 'nuff said. Not an issue. Child controls: Same issue with tab panes lacking the ability to clip plus a lack of scrolling support. Browser elements: No way to reliably render the webpage onto the screen, only over it. Sliders/bars: Fully emulatable on the server. Menus: Fully emulatable on the server provided you don't need dynamic measuring of options. Tooltips/context menus: Fully emulatable on the server provided you don't need dynamic measuring of options. Grids: Fully emulatable on the server provided you don't need dynamic measuring of names/suffixes. Subwindows: Fully emulatable on the server, but moving/resizing them can be tricky to do efficiently because there is no way to dynamically link one atom to another as a root transform in BYOND. Basically, doing these things would be trivial if BYOND supported in-render HTML pages or maptext measurement, per-object clipping masks, atomic anchoring, and maptext clipping and maptext scrolling. Unfortunately, most of these features are immensely nontrivial because of how BYOND works as a server-directed software suite. | |
Ah, so I was going about it the right way. I should finish my HUD thing I was doing, or start a new one. I was in the middle of doing input scrolling, which was somewhat of a pain. I managed to do copy+paste, so that's pretty neat.
| |
I managed to do copy+paste, so that's pretty neat. Browser hijacking? You are actually reading in data from/to the client's clipboard, or are you only managing to copy/paste information from the game to other parts of the game? | |
Yeah, basically a lot of browser mumbo jumbo. Luckily, BYOND is pretty standardized when it comes to browsers, but even so, the method I used should work with non-IE browsers as well. Unfortunately, I can't find the tutorial for it (the non-BYOND-related part) anymore, but I still have the code, I think.
| |
execCommand()?
I did some experimentation on getting the size of maptext and clipping/cropping using getClientRects() and similar functions in IE. I was able to figure out what the user was clicking on and I was able to scroll text, but it was less than sprightly. BYOND also doesn't let you do things like cropping maptext without cutting off whole lines, so scrolling actually wound up being pretty ugly and disorienting. EDIT: Sorry to hijack the thread with hacky mumbo-jumbo. Beginning to enjoy how Kamuna thinks here. | |
And not just ingame arts, some good and cool concept arts for advertising makes the game look "professional" as some work was spent in the "first views" means alot of work was spent at the game;
Aka, make it looks professional