My advice to everyone: Unity actually kinda sucks.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
GAF Indie Game Development Thread 2: High Res Work for Low Res Pay
- Thread starter Jacksinthe
- Start date
- Status
Veritigo_X
Member
I'll check it out. My game logic shouldn't be too difficult to port over to C#, I'd just need to figure out how it all fits together in Unity. I can always come back to the old engine if I ever feel like fixing the problems.
Well damn... what don't you like about it?
Jacksinthe
Banned
It does but they all suck for different reasons. I am considering moving to UE4 before the next big project tho.
-
So I brought more of the Mega Man feel to my Strafe redesign. I dig throwing shuriken over slashing with him. There's a lot more I can do with this since he is so agile, both from level design and enemy AI.
I am considering removing melee attacks altogether.
Unity makes a lot of stuff that would take a lot of effort to do from scratch very easy. But the flipside is that it can also make stuff that would be very simple to do very difficult.
It's been a couple years since I used it regularly, but I often found myself fighting with it do something that seemed trivial on the surface. Like trying to have objects update in a specific order.
The people who make Unity don't also make games themselves. So they'll often add features without understanding how they need to be designed for actual production use. You can see Feep's struggles with Unity's animation system in the previous thread as an example.
Not that I'm saying don't use it. Just be aware you're not solving all your problems if you switch to it. You're trading one set for a – possibly easier to manage – different set.
It's been a couple years since I used it regularly, but I often found myself fighting with it do something that seemed trivial on the surface. Like trying to have objects update in a specific order.
The people who make Unity don't also make games themselves. So they'll often add features without understanding how they need to be designed for actual production use. You can see Feep's struggles with Unity's animation system in the previous thread as an example.
Not that I'm saying don't use it. Just be aware you're not solving all your problems if you switch to it. You're trading one set for a – possibly easier to manage – different set.
This exactly! This is why I went with my own engine. However, even then, I would never suggest rolling your own engine from scratch, rather do what I did and start with a completely open-source one and then modify it as you need later (and of course, also only do this if you are an experienced programmer and most definitely not for your first game!).
For example, in my case I was quite annoyed with Unity's animation system, in particular the ability to "tag" animations with extra data like playing sound effects and such, without having to jump through a bunch of hoops (especially if you wanted to update the base animation later and not lose all your extra metadata). When making my own engine, I knew exactly what I wanted out of my animation system, so of course I made being able to easily add extra meta data to frames of animation a priority.
electroflame
Member
You pretty much just described using any engine that you don't make yourself.
Essentially, using any engine amounts to:
Pros:
Some hard stuff is easy
Cons:
Some easy stuff is hard
Some hard stuff is easy
Cons:
Some easy stuff is hard
Whereas, if you roll your own engine, it amounts to:
Pros:
Some easy stuff is easy
Bragging rights -- you rolled your own engine
Cons:
All hard stuff is hard
Some easy stuff ends up being hard
No support
No community -- nobody is using your engine, so if you have a problem it's 100% on you to figure it out and solve it
Most likely end up spending lots of extra time fleshing out your engine
Some easy stuff is easy
Bragging rights -- you rolled your own engine
Cons:
All hard stuff is hard
Some easy stuff ends up being hard
No support
No community -- nobody is using your engine, so if you have a problem it's 100% on you to figure it out and solve it
Most likely end up spending lots of extra time fleshing out your engine
If there was a one-size-fits-all engine that does everything for someone without any effort, we'd have a million games released a day. As it stands, I'd rather build a framework on top of an engine, than build an engine and then a framework on top of that. Unity may or may not be that engine for everyone -- I'm using it currently, but I understand the appeal of Unreal, etc. -- different engines for different tasks (and licensing models).
This isn't actually true.
Rolling your own engine does not mean writing every single line of code yourself. If I need to load a PNG file I'm just going to use stb_image or lodepng. If I need physics there's jiglib or bullet.
Not only is it easier to make a game nowadays because of all the available cheap engines, its also easier to make an engine because of all the available cheap/free libraries and tools.
I will be responsible for integrating all those libraries together of course. Which can be a large chunk of work in itself. But All hard stuff is hard isn't true anymore.
electroflame
Member
That depends on what you specify as "hard". Certain "hard" things won't have a library for them, especially if it's specific to a certain platform or piece of hardware.
Even writing glue code for libraries can be difficult depending on other libraries you use. There may even be a point where your "engine" just amounts to various glue code between various libraries -- at which point, you might have been better off using an engine that already did the glue code for you. My point was that it's a matter of preference and convenience. Some people prefer writing glue code, just like some people would rather deal with a little inconvenience later for come extra convenience up front.
In my experience it's never as cut and dry as "you'll always be better off with your own engine" just as it's equally unrealistic to say "you'll always be better off with someone else's engine". Much like the rest of game dev (or any dev, really) there's multiple ways to skin a cat. You can build and sharpen your own knife, or learn to use someone else's -- even if that means that you may cut yourself and have to patch yourself up later.
There's some other pros to rolling your own engine besides bragging rights and knowing all things that ought to be easy will be.
For example, when something isn't behaving as expected, you know where the problem is - your code. When something isn't behaving as expected with an engine, often you are left wondering if the problem is with your code, or with the engine (its not always immediately obvious), and if it is the engine, you have to figure out a way to work around it, or wait and hope that the engine developers eventually fix the issue. With your own engine, you debug your own code, find the problem, and fix it.
One of my biggest problems with using other engines in the past is getting quite far along in my project before I discover that the engine has some weakness or flaw or even bug that stops my forward progress. So knowing that no matter where your game design takes you, you can adapt your engine to do it without having to jump through hoops or discover that what you wanted to do isn't even possible on the engine you've chosen and are now committed to, seems like a benefit to me.
Finally, let us not forget the advantages of not being dependent on a 3rd party. My engine works on the Dreamcast, for example. Why? Because a programming buddy was a Dreamcast fan and wanted to see if he could get Volgarr running on the Dreamcast (which it does, we just don't have any convenient way to sell it). Sure, that's not terribly useful, but let's say we really, really wanted to release on Dreamcast. Can Unity export to Dreamcast? What if there was some other platform you were excited about but Unity or whatever engine you are using didn't support it? With a C++ engine, it sucks that I have to go through a LOT more effort to port my game, but at least I know that I can port it to pretty much anything if I want, I'm not dependent on what some other company decides are the platforms it should support.
I also don't have to worry about the engine company making changes I disagree with, going out of business and dropping support, introducing new bugs as they fix old ones, and so on.
For example, when something isn't behaving as expected, you know where the problem is - your code. When something isn't behaving as expected with an engine, often you are left wondering if the problem is with your code, or with the engine (its not always immediately obvious), and if it is the engine, you have to figure out a way to work around it, or wait and hope that the engine developers eventually fix the issue. With your own engine, you debug your own code, find the problem, and fix it.
One of my biggest problems with using other engines in the past is getting quite far along in my project before I discover that the engine has some weakness or flaw or even bug that stops my forward progress. So knowing that no matter where your game design takes you, you can adapt your engine to do it without having to jump through hoops or discover that what you wanted to do isn't even possible on the engine you've chosen and are now committed to, seems like a benefit to me.
Finally, let us not forget the advantages of not being dependent on a 3rd party. My engine works on the Dreamcast, for example. Why? Because a programming buddy was a Dreamcast fan and wanted to see if he could get Volgarr running on the Dreamcast (which it does, we just don't have any convenient way to sell it). Sure, that's not terribly useful, but let's say we really, really wanted to release on Dreamcast. Can Unity export to Dreamcast? What if there was some other platform you were excited about but Unity or whatever engine you are using didn't support it? With a C++ engine, it sucks that I have to go through a LOT more effort to port my game, but at least I know that I can port it to pretty much anything if I want, I'm not dependent on what some other company decides are the platforms it should support.
I also don't have to worry about the engine company making changes I disagree with, going out of business and dropping support, introducing new bugs as they fix old ones, and so on.
I mean, this is pretty accurate. But if you're making a complex title, it still ends up saving a TON of time in the long run.
If you're not making a complex title, use Construct or Stencyl or XNA/MonoGame or something.
Unity can export to XBox One, PS4, PS Vita, PC, Mac, Linux, Android, and iOS. Claiming that your engine can be ported to Dreamcast is rather academic. The only relevant point missing is the 3DS.
The truth is, almost literally no one can develop their own engine *and* content-filled game on a standard indie timetable and group size. It's just incredibly difficult.
I agree that most people are better off using something off-the-shelf, but this is a massive exaggeration. The post right above yours has someone who made their own engine for their game. And most of the games that started the current indie scene – Braid, Super Meat Boy, Aquaria, Minecraft, etc... – didn't use pre-existing engines.
Maybe a bit of an overexaggeration, but these are the luminaries of the indie gaming world. I still highly discourage it.
Jacksinthe
Banned
This means absolutely fuck all to the enjoyment factor of a game.
Good thing that's not what the conversation was about.
AusRoachman
Member
I would love everyone to download and try my initial prototype build. I am reluctant to call it a game as its pretty much just a tech demo atm, but would like feedback to see if its something worth building on.
https://dl.dropboxusercontent.com/u/2022922/mirrorscube/MirrorsCube.7z
Game Idea
I am a huge fan of minecraft, not so much the game but the idea of world building/sharing, especially in recent years where i have managed to play it with my kids , who can just stay in that world doing absolutely nothing but building.
So i want to take that building/sharing idea and apply it to another game i loved. Mirrors Edge
- Build your own timetrial levels with start/end points
- Multiplayer enabled
- Leaderboards to try and race the creators (or any other players) , best times.
I was inspired by this old trailer
https://www.youtube.com/watch?v=Jo2NAQ7-DFc
Game Tech
I cant take too much credit for most of the gameplay systems here except for the minecraft style world generation/building as thats from some old prototypes i did awhile ago. Most of the credit goes to these fantastic Unity Assets
As mentioned before this is pretty much just a tech demo at this point. Run around, build stuff and parkour. But i have plans to do the following
- Tweak the world colours as its pretty much just white at this stage
- Replace acParkour model with my own more blocky variant
- Tweak day/night, maybe even remove it, it serves no gameplay function atm other then looking cool
- More blocks to add, more functionality (lights, timetrial start, timetrial finish e.t.c)
- Tweak interface. Turn on/off world building, fly mode e.t.c
- Tweak world generation, at this stage its an infinite flat plain, unsure if i will make it a world with hills/trees e.t.c
- Potential adding guns, though may just keep it a strictly parkour thing.
So yeh trying to avoid any minecraft clone similarities, despite the building e.t.c pretty much coming from that game .
I am aware of some funky animation bugs where you get stuck in ledge grab . just do it again and it will clear itself.
So yeh feel free to comment on bugs e.t.c , but im mainly interested in whether you like the idea more so then the technical stuff at this stage.
Most of the fun comes into play once you start building high walls, small gaps to slide under, wallhanging e.t.c I plan on adding more extended move sets like rolls e.t.c
https://dl.dropboxusercontent.com/u/2022922/mirrorscube/MirrorsCube.7z
Game Idea
I am a huge fan of minecraft, not so much the game but the idea of world building/sharing, especially in recent years where i have managed to play it with my kids , who can just stay in that world doing absolutely nothing but building.
So i want to take that building/sharing idea and apply it to another game i loved. Mirrors Edge
- Build your own timetrial levels with start/end points
- Multiplayer enabled
- Leaderboards to try and race the creators (or any other players) , best times.
I was inspired by this old trailer
https://www.youtube.com/watch?v=Jo2NAQ7-DFc
Game Tech
I cant take too much credit for most of the gameplay systems here except for the minecraft style world generation/building as thats from some old prototypes i did awhile ago. Most of the credit goes to these fantastic Unity Assets
- UFPS
- AcParkour
- TimeOfDay
As mentioned before this is pretty much just a tech demo at this point. Run around, build stuff and parkour. But i have plans to do the following
- Tweak the world colours as its pretty much just white at this stage
- Replace acParkour model with my own more blocky variant
- Tweak day/night, maybe even remove it, it serves no gameplay function atm other then looking cool
- More blocks to add, more functionality (lights, timetrial start, timetrial finish e.t.c)
- Tweak interface. Turn on/off world building, fly mode e.t.c
- Tweak world generation, at this stage its an infinite flat plain, unsure if i will make it a world with hills/trees e.t.c
- Potential adding guns, though may just keep it a strictly parkour thing.
So yeh trying to avoid any minecraft clone similarities, despite the building e.t.c pretty much coming from that game .
I am aware of some funky animation bugs where you get stuck in ledge grab . just do it again and it will clear itself.
So yeh feel free to comment on bugs e.t.c , but im mainly interested in whether you like the idea more so then the technical stuff at this stage.
Most of the fun comes into play once you start building high walls, small gaps to slide under, wallhanging e.t.c I plan on adding more extended move sets like rolls e.t.c
Comfort Jones
Banned
I've had this happen at least once, and I feel like more than that, working with engines. I've always worked as a programmer, so it's a horrible feeling to spend time learning a tool, then learn there's some limitation, and there is potentially NOTHING you can do to bypass it. Your only option is to potentially bug a company or developer, and if you are fortunate or important it might get corrected.
That is one thing I really like about UE4: It might take a long time and be difficult to do so, but there is at least the technical possibility for you to fix a problem yourself. Want to add a neat fix to the editor, or change some annoying behavior in the texture system? In theory, you can. Afraid Epic will break your engine with future updates? You can stick with one version and either never update, or just pull in updates piecemeal if you are brave and/or knowledgeable enough.
With UDK, I felt like I had a bad habit of trying to do things that were not especially suited for the engine. For example, a friend had an idea for me to try prototyping a game with tons of animated 3D enemies, as many as 1000-2000. If you try asking on forums or on IRC, the typical response to any sort of unorthodox thing like this that would kill performance seems to be "Well, don't do that." Or "Use another engine" or "write your own engine".
There finally was one crazy person who was like, "Well if you DO use some crazy techniques like [ancient Egyptian magic] then you might be able to do it." And I put it together and it was super simple, but I was able to do 2048 ultra simple, unlighted, animated figures with decent performance. Still, that experiment was basically a workaround, and I got lucky by finding someone who even had an idea of something like that. In some situations you might be out of luck.
Of course any major game company presumably has full source license for whatever engine they use, along with reasonably competent engine programmers, so this sort of thing is not as big of a deal.
Well, in my case after 14 years working as a programmer fixing shitty corporative systems and dealing with ridiculous demands I've learn to adapt so every time I feel a system or engine has a limitation I just try to circumvent it, to find an alternate solution, hell sometimes I discover that the thing that I'm trying to do is not even necessary or can be replaced with a better solution.
Dealing with limited systems is a reality in every industry, not everyone has the time or resources to try to make a "perfect system" and sometimes you need to be brave to recognize that you don't need one to succeed.
I'm not really a fan of platforming in first person, but this seems to mostly work pretty well. I got an animation glitch after repeatedly trying to catch onto a two-tile-high ledge, shown below.
http://zippy.gfycat.com/NegativeHealthyBeetle.webm
Again, I'm not your target demographic, but I think this could be cool for Mirror's Edge enthusiasts and simulacrum.
plagiarize
Banned
Eurgh. And the editor crashes. Time to call it a day or stay up and redo all the half an hours work I just lost.
Ori and the Blind forest video showing some foley work, which I always find entertaining. There's also apparently another playable character thus far not really shown.
https://www.youtube.com/watch?v=OA8Uzj0tyG0
https://www.youtube.com/watch?v=OA8Uzj0tyG0
Candescence
Member
Rolling your own engine has its advantages, but not everyone has the programming expertise to handle building their own engine, even if they use third-party libraries and stuff, which have their own issues, even if you can adjust the source code in those. For example, OGRE is fairly well-known, but is I hear is also fairly bloated, even if it is capable of some very nice visuals.
akachan ningen
Member
Is that being made by a gaffer?
yeah, thomasmahler (THINK that's the right spelling).
Jacksinthe
Banned
You specifically mentioned games where devs rolled their own engines as a bullet point to the discussion and now you say you didn't mean it that way? If that's not what the discussion was about then why use it as a bullet point? This is video game development - the end result is the only thing that matters. The games you listed, the "indie scene" also have nothing to do with tools discussion. None of that matters. I can only assume 99.9% of developers make games not to pat themselves on the back but to create something for others to enjoy. The means to that end means nothing to anyone but its iterators. You mentioned specific games as a "well check out what some popular games have been doing" comment - which amounts to nothing in the end because... so? Rolling your own engine or using an off-the-shelf program both have advantages and disadvantages and the games that are produced with both aren't qualifiers.
That's the point :|
^^
I disagree. The sequence was this:
Feep suggests that almost literally no one can do a certain task.
Popstar disagrees, and brings up 5 popular examples of teams that may have done exactly the task that "almost literally no one" could do. (whether those 5 examples are still "almost literally no one" may still be up for debate)
Popstar was just saying, he thought Feep was exaggerating. That was the point.
Jacksinthe
Banned
I stand corrected on the context but after rereading I still think that is beyond the scope of a the grand majority and doesn't offer much relevance to anyone, hell even most of us, who develop indie games. I can rattle off some of the top names in NHRA but that doesn't mean that status is attainable for everyone with a Mustang nor does it add insight into tricking out your car for the street, which is what a majority of us and other indie devs start with.
Unless I'm massively confused, Popstar agrees with you.
I think they were just commenting on the exaggeration, but Popstar please correct me if I am mistaken.
Jacksinthe
Banned
Unless I'm massively confused, Popstar agrees with you.
I think they were just commenting on the exaggeration, but Popstar please correct me if I am mistaken.
He stated what Feep said was an exaggeration - I disagree with this. So no, we are not in agreement. Far fewer and far between and I still say his bullet points do nothing to serve his argument or the discussion. It's a misplaced bullet point. I got the context wrong the first time because I'm dumb and don't follow along as closely as I should but the shoe still fits.
You're correct Blizzard. I was just commenting on the exaggeration.
*shrug*
I've had a game using an engine I wrote on PSN and Steam for four years (predating Greenlight!) so when you tell me it's something literally no one can do....
*shrug*
electroflame
Member
Holy moley, I guess. I didn't mean to participate in/egg-on a major disagreement.
Agree to disagree on this? I'm all for discussion, but things are getting a bit heated (not to mention that this thread should probably be about creativity and encouragement, no?).
Lets just update the OP with the new golden rule of game-dev discussion: never, ever, ever, ever, ever, ever, ever, ever, ever, bring up the talking points of using an engine/rolling your own.
The weird thing is that its not like anyone is arguing that you should always write your own engine.
The disagreement is between you should always use an engine like Unity or Construct or whatever versus you shouldalways probably use an engine like Unity or Construct or whatever.
I usually don't bring up my dislike of Unity because of stuff like this. But its honestly getting a bit dogmatic. Unity has plenty of people singing its praises. It can handle the occasional bit of negative attention.
The disagreement is between you should always use an engine like Unity or Construct or whatever versus you should
I usually don't bring up my dislike of Unity because of stuff like this. But its honestly getting a bit dogmatic. Unity has plenty of people singing its praises. It can handle the occasional bit of negative attention.
Fuck garbage collection. That's one reason I don't use that piece of shit Unity.
Jacksinthe
Banned
Shrug? You put words in my mouth and you shrug? I, nor feep, never said that literally no one can do it. Feep said "almost" and I said 99.9%
Don't twist words unless your'e looking for a job at Fox News, Popstar. You know exactly what we meant so don't play this game with me, please.
Sad to see even our own like to twist words for the sake of making themselves look better. Classy, bro.
The weird thing is that its not like anyone is arguing that you should always write your own engine.
The disagreement is between you should always use an engine like Unity or Construct or whatever versus you shouldalwaysprobably use an engine like Unity or Construct or whatever.
I usually don't bring up my dislike of Unity because of stuff like this. But its honestly getting a bit dogmatic. Unity has plenty of people singing its praises. It can handle the occasional bit of negative attention.
Fuck garbage collection. That's one reason I don't use that piece of shit Unity.
And this is one of the things I do hate about Unity, I agree.
WanderingWind
Mecklemore Is My Favorite Wrapper
So, since we're on engine talk, I'd to like to revisit my quasi question from a couple pages ago. Is RPG Maker okay to use or should I be looking at some other engine? I just want to make a 16 bit style RPG and possibly, maybe, one day, throw it up on the iOS store. I've put other apps on there, but never a game. I just don't want to put a ton of effort into something and not have the option to maybe share it with people.
OccamsBlender
Member
I'm a professional game dev trying to break away and do my own thing. My workplace has their own engine. Well, I use "engine" loosely, it's a shitty pile of unscalable, not-very-modular libraries.
Maintaining your own engine is no simple feat!
No doubt the folks at Unity are in hell trying to upgrade Unity to 64 bit but for a lot of people, doing QA on all those mobile devices, operating systems is a lot of work.
Supporting new devices, new operating systems, if you have the time and smarts to do it, hats off to you. I don't know of any small indies who do.
Maintaining your own engine is no simple feat!
No doubt the folks at Unity are in hell trying to upgrade Unity to 64 bit but for a lot of people, doing QA on all those mobile devices, operating systems is a lot of work.
Supporting new devices, new operating systems, if you have the time and smarts to do it, hats off to you. I don't know of any small indies who do.
Since the iOS store is your goal, iOS support was my first question. I'm not familiar with RPG Maker, but there appears to be some sort of middleware available that lets games be exported for iOS: http://www.siliconera.com/2014/09/23/expect-rpg-maker-games-smartphones-soon/
Perhaps someone else actually knows the details of how to test this and whether it costs extra, though.
WanderingWind
Mecklemore Is My Favorite Wrapper
That could be useful. Thanks for the link. After skimming through, it looks like most people ITT are making action games or RTSs (great pixel art, btw love the colors). Anybody ever try their hand at RPG creation?
Off the top of my head I can't remember anyone here mentioning that they use RPG Maker. That's probably why you didn't get a response.
Oh yeah. I totally forgot about the coming all apps must be 64-bit for iOS. Is there a timeline on 64-bit Unity?
I'm developing my engine. And why?
-It's fun!
-It does whatever I need
-It's free
-It's multiplatform
-It's in c++
-It's challenging
My first game developed with my engine is almost on the market. It's in beta testing.
Soon I'll post some details about it.
Here is a brief interlude from engine discussion. As always, please let me know if I'm posting too many images asking for opinions. I made a few more prototypes after thinking about the previous comments for resource/health/whatever bars.
Here are 4 slight variations with sideways bars. At least to me, there seems to be a mildly annoying optical illusion in some case(s) where the cyan looks wider than the red.
Here is a crazier variant, using a left-right division that matches where the raw numbers would appear. This allows space for the unit and tile to show through, and also might make sense for toggling back and forth between numbers and bars (or perhaps cycling through no overlay, number overlay, bar overlay).
I also tried making the backgrounds behind the numbers solid black instead of transparent, but I feel like this is a little uglier:
I think some transparency behind the numbers looks better, with the exact amount depending on what sort of final palette I end up using. Thus far I have tried to keep the background tiles dark, reserving bright colors for units and overlay information.
Any opinions on these options would be appreciated! Thanks again to those who helped earlier. The general context for a player would be, "I'm playing a turn-based strategy game, I might have some 10-20 units on a big field, and I want the field to clearly and quickly tell me the current situation."
Here are 4 slight variations with sideways bars. At least to me, there seems to be a mildly annoying optical illusion in some case(s) where the cyan looks wider than the red.
Here is a crazier variant, using a left-right division that matches where the raw numbers would appear. This allows space for the unit and tile to show through, and also might make sense for toggling back and forth between numbers and bars (or perhaps cycling through no overlay, number overlay, bar overlay).
I also tried making the backgrounds behind the numbers solid black instead of transparent, but I feel like this is a little uglier:
I think some transparency behind the numbers looks better, with the exact amount depending on what sort of final palette I end up using. Thus far I have tried to keep the background tiles dark, reserving bright colors for units and overlay information.
Any opinions on these options would be appreciated! Thanks again to those who helped earlier. The general context for a player would be, "I'm playing a turn-based strategy game, I might have some 10-20 units on a big field, and I want the field to clearly and quickly tell me the current situation."
WanderingWind
Mecklemore Is My Favorite Wrapper
Just my two cents, but those numbers are really, really hard to read. I had to enlarge the pic to see if it was an 8 or a 5. Maybe a different font choice? Those bars are slick though.
That's exactly the sort of feedback I am interested in, thanks! I neglected to post a 2x version with numbers. It would look something like this (the player can mousewheel zoom in and out at any time):
A different font is certainly an option. I am not sure I can make the numbers any bigger with this layout without blocking too much of the units or tiles. One thing I considered is that I could let the player hold a key to hover BIG numbers over all units. You could then let go of that "see big number overlay" key once you've done some quick math.
If anyone thinks that might be a more user-friendly approach, I'll throw together a quick mockup of it too.
WanderingWind
Mecklemore Is My Favorite Wrapper
Ah, if that's the normal player view that's not an issue then.
Blizzard, in regards to visibility, how many tiles big is your game screen going to be? I'm wondering how "noisy" a full screen of units with numbers might look.
Also, I'm not colour-blind myself, but having the numbers in the left corner of a unit directly next to the number in right corner of another may be a problem.
Also, I'm not colour-blind myself, but having the numbers in the left corner of a unit directly next to the number in right corner of another may be a problem.
With the programmer art in place and the map sizes I'm thinking of, I would like to make the smaller view at least playable. I am poking at number options at the moment.
The test window I'm using at the moment can do 20x10 visible tiles. I should indeed put together some sort of mass unit test scenario. I almost want more unit types before I do that, but now is probably best. Thanks.
I am trying to have at least a little horizontal visual separation between unit overlays, but I am also hoping that the red and blue choices are good even for color blind people (I think TF2 and League of Legends use red/blue for this reason). I'll make a note that I might want to make the colors configurable. Changing the color is very easy with the current rendering setup.
*edit* Here's a last picture for now, what temporarily hovering larger numbers over the entire playing area would look like:
timetokill
Banned
Blizzard, here's the issue: Are these numbers capped? What kind of granularity does your game's system have?
For instance, if I'm playing a game like Advance Wars, I want to know the pure numbers. I know X troop does 5 damage, and another does 7. I don't want a bar where I have to guess if the guy has 14 health or 15 health. I want the information quick and accessible.
Are attacks discrete? As in, is there continuous damage going on, or is each attack happening individually? If there are lots of attacks going on, bars are generally better so that you don't have number overload. But if it's one attack at a time, numbers are preferable so you have a good idea of that specific attack.
How important is leveling up weapons/defenses? Am I going to notice? It's a lot harder to see an actual difference when it's like "well this makes the bar go down this much, versus this much." But a difference between a 5 and a 4 can be huge if the number system is kept small.
Concrete numbers are going to be better for a more strategic, tactical game. It lets me know exactly how much damage or health or magic or whatever something has. It lets me make more informed decisions.
A good game designer should advocate for the player. If it's going to be easier for the player to play the game seeing the numbers, then use numbers.
As an aside, the bars are okay if you break them up into discrete elements, like you did in the top right version of this:
But that becomes unwieldy if your numbers get too high.
For instance, if I'm playing a game like Advance Wars, I want to know the pure numbers. I know X troop does 5 damage, and another does 7. I don't want a bar where I have to guess if the guy has 14 health or 15 health. I want the information quick and accessible.
Are attacks discrete? As in, is there continuous damage going on, or is each attack happening individually? If there are lots of attacks going on, bars are generally better so that you don't have number overload. But if it's one attack at a time, numbers are preferable so you have a good idea of that specific attack.
How important is leveling up weapons/defenses? Am I going to notice? It's a lot harder to see an actual difference when it's like "well this makes the bar go down this much, versus this much." But a difference between a 5 and a 4 can be huge if the number system is kept small.
Concrete numbers are going to be better for a more strategic, tactical game. It lets me know exactly how much damage or health or magic or whatever something has. It lets me make more informed decisions.
A good game designer should advocate for the player. If it's going to be easier for the player to play the game seeing the numbers, then use numbers.
As an aside, the bars are okay if you break them up into discrete elements, like you did in the top right version of this:
But that becomes unwieldy if your numbers get too high.
akachan ningen
Member
With the programmer art in place and the map sizes I'm thinking of, I would like to make the smaller view at least playable. I am poking at number options at the moment.
The test window I'm using at the moment can do 20x10 visible tiles. I should indeed put together some sort of mass unit test scenario. I almost want more unit types before I do that, but now is probably best. Thanks.
I am trying to have at least a little horizontal visual separation between unit overlays, but I am also hoping that the red and blue choices are good even for color blind people (I think TF2 and League of Legends use red/blue for this reason). I'll make a note that I might want to make the colors configurable. Changing the color is very easy with the current rendering setup.
*edit* Here's a last picture for now, what temporarily hovering larger numbers over the entire playing area would look like:
I like the bars better. But not in cyan, it just stands out so much. And maybe put one bar on top and one bar below, if you haven't already.
- Status