Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

3283 Excellent


About Luckless

  • Rank
    Finder of Random Bugs

Personal Information

  • Role
    Game Designer
    Quality Assurance
    UI/UX Designer
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Luckless

    Keyboards for Programmers

    I've never found that any one keyboard really made a noticeable difference over others for me. My main daily driver is a Logitech G105, which was chosen because it was the cheapest sane looking keyboard that I could buy locally on short notice that included a cord... For a non mechanical it is a bit on the loud side, but the keystrokes are reliably recorded, keys laid out where my fingers expect them, and really what more does one want from a keyboard? The other keyboards I commonly use include an old 13" pre-retina Macbook's keyboard, and at times an ancient EeePC netbook with its weird mini-keyboard thing.
  2. Luckless

    How not to do Alpha Testing

    My first choice in a 'no budget' setting would be to focus on establishing relationships with other local developers for testing purposes beyond what you can do yourself rather than finding random people from the web willing to 'do it for free'. A simple "Test for Test" service exchange with other small developers hold a higher chance of yielding more useful results, especially during early build cycles. If you can't build up a network of professional friends to do something like that, then my next choice would be friends/family who can be coached and guided through the process to help you identify issues you missed on your own testing.
  3. Luckless

    How not to do Alpha Testing

    Getting random people from the internet to 'test for free' is a pretty risky and frequently terrible approach to testing, especially at when you're in actual alpha builds. One of the biggest hurdles in alpha testing is being able to see beyond what is currently there, and visualize your way through the software that could eventually be there. This will also frequently include visualizing multiple options of what could be there, how different features could potentially function, and weighing these options against each other before attempting to proceed down any given road. If you are dealing with alpha build software then you need to have very close control over who is using it, how they're interacting with it, and how well they understand what is actually going on at that stage of software development. It is however a sad truth about the industry that testing stages are all too often under valued or completely overlooked during development. Testers are frequently under invested in, used as a screening or entry level position while paying as little as legally possible for it, and commonly allowing staff to 'advance up' from the 'lowly noob work' of testing rather than fostering comprehensive and talented test teams who can tell their own backside from a hole in the ground as far as testing in software development goes. Skimping on QA, especially early on in projects, is kind of a fool's economy due to the risk of bug snowballing effect - The worse the state of the code base, the harder it is to work with, and the longer bugs go on for the harder they are to fix completely. The harder it is to work with the slower the progress on future development is. The slower the progress the more stress coders come under, and the more stressed coders are, which translates into increase likelihood of burnout and turn over. Turn over then translates into even less comprehensive understanding of the project, which compounds the problem of fixing bugs and making progress, and that then risks making the cycle roll over that much faster. Over my years in the industry I have seen several multi-million dollar projects in different fields get caught in such death spirals for the want of saving an extra $60-100k a year to put towards additional testing and oversight. "Saving money" on QA is often one of the most expensive choices companies make, and I rather doubt that is going to change any time soon.
  4. Luckless

    How to avoid bugs

    A few points to share based on having worked in QA full time for the better part of a decade now: 1. Code can only ever tell you what the code Is doing - Use documentation to clearly detail what it is supposed do to, and why you want it to do that. Teams that embrace detailed understanding of the what and why of their codebase have shown a far lower bug rate and overall long running productivity levels than teams who focus purely on 'productivity' and getting more code done faster. One of the biggest things I've come across that seemed to reduce bugs during a project's lifetime: Record WHY you decided to do something, and WHY you make changes. Assume that you're an idiot who will forget things, because if you're a human then honestly you are. And if you don't think you are an idiot who can forget things as a programmer, then you probably really are an actual idiot who will contribute loads of bugs to projects over the years. If you think you are too busy to take five minutes out of your day to write out some detailed thoughts about the what and the why of the code you're working on, then think about the five hours, or days, you're likely to spend trying to unravel things and track down a bug because you've misunderstood something. 2. Code small, code carefully, code only what you actually need, and analyse how a section of code might fail to do what you intend. Poke at things from different angles, do not assume they will always function the way you expect at first glance. 3. Have other people USE your software as early as possible. - You cannot fix what you don't realize is broken. Other people will break things in fun, new, and unique ways that you never dreamed of. Embrace it, and learn to address it.
  5. Luckless

    How far are we from component detailed games?

    An important question to ask yourself when you're considering doing something in a radically new way for a game (Or for anything in life really) is: What advantage am I gaining from this? Back in university I had worked for a time on a compressible volume based character design and animation system. The technology was eventually abandoned due to not being able to mature it fast enough to be really usable for anything, but the concept was to essentially estimate all the bones and major muscles in a human body with a light approximate physics and volume system, and then apply a ray-tracing layer over top of it. If a character was to pick something up with its hand, then the arm muscles would contract and change shape while a force was applied to the hand. This in turn would automatically give a 'natural' shape and motion to the animation, without requiring complex animation work. Since that time traditional animation tools and the access to them had matured more, and that raised the bar of usefulness of my project beyond what I was willing to invest in it. My project was slow, computationally expensive on run-time, and needed far more investment into the 'shell layer' for it to be useful. In theory the project would have had the advantage of far more natural and less blocky looking animation for characters with a reduced animation design cost, but those issues were solved in a far more sensible and cost effective manner by other parts of the industry.
  6. 1 - The "Gain more land" aspect of things could be handled by way of requiring 'secure land' in order to build up. Maybe allow the player to establish some things outside the 'secured zones', but make them questionably valuable due to the risk to the people/buildings/resources from raids. Depending how how you want the game to play out, you could have some interesting options in how you allow a player to choose to develop and defend with styles like: - All-Wall Citadel build up: Everything is build up within the strong central walls of the main settlement, and you force combat into pre-defined choke points due to how much you invest into the walls. Pros: You know where the fights will be, Cons: You spend TONS of cash on the walls, and limit your growth. - Ring wall and Fall Back: Colony builds up in layers, with zones dividing into cells. Defence becomes all about limiting the speed at which the attackers can overrun an area. Pros: You can spread out more for less investment. Cons: An attack is likely to cause at least some damage, and possibly lose colonists. - Walled Outposts: Rather than centralizing things, you let the colony expand out to farther flung parts of the map to take better advantage of resource nodes or something more effectively. Pros: Best use of natural resources on map, rather than relying as heavily on scavenging missions for resources. Cons: Reinforcing against attacks becomes far harder due to greater distances. - Tower-house Outposts: Like walled outposts, but further concentrate defence resources into a smaller area that colonists retreat too when attacked. Pros: Less resources for a stronger defence (Of those who make it to the tower) Cons: Building damage is far more likely. etc. 2 - Personally I would run an early concept prototype for the project, and see how gameplay feels if you use a mechanic like "Send a group out on a mission", with a very abstract view on any out of colony activities. Consider the player as being the colony manager, not an expedition leader. Start off with just giving the player a window for who is going out to where on the world map, what their priorities are, and other settings, and then give the user a nicely formatted report on how things went. See how this feels, and if the rest of the game becomes engaging enough or not. You have lots of wiggle room for flavour text and events in this kind of system. However, if you feel it is lacking, then I would look towards procedural generation of towns/villages/points of interest: Rogue like kind of thing with a build up generation rule set you can adapt and expand over time. 3 - End goals could be any number of things, and it comes down to just how you want your game to feel when playing. Are you facing an endless horde of enemies, and attempting to hit a high score in the face of an otherwise unwinnable situation? Maybe "Survive X years" and get a high score screen. In addition to the "Find and kill the wizard", you have options like "Contact X number of survivor colonies, and achieve Y total population/power" to retake control over the area and make things safe again. Good luck with the project.
  7. Luckless

    Bad Design vs. Niche Design

    Personally I put "Bad design" down as "Things that hinder the core function or purpose of the project". Tick-Tack-Toe or Rock-Paper-Scissors don't really have any 'bad' design points, but rather are examples of beautifully simple designs. Tick-Tack-Toe's game-draw 'issue' isn't a bad design in my view, but rather a fun quirk that makes it such a great logic and learning tool. So we need to draw some lines and start to think about things like 'core purpose', how design elements relate to it, and whether a design actually improves or hinders things in that specific instance for a given project. And we also have to draw a divide between Mechanics design, and Interface design. You can have a great core mechanic of how things work, but the overarching design fails due to issues with how you interact with it, and you can have a great interaction design, but overall still fail because it doesn't really connect to any good core mechanics. - You can make the prettiest and most awesome button in the world to keep on your desk, but it isn't all that great of a project if it isn't hooked up to anything. The bit of a niche market of "Frustratingly hard platformers" typically has a design mechanic that will include easy and very common ways to die. The fact that you are running along and die often due to things like falling down a bit, hitting the wrong wall tie, etc is not, in and of itself, a 'bad design' element, but rather it makes up a fundamental aspect of the project's core purpose. They're Supposed to be frustrating, as that's kind of the point of the game - Overcoming the insanely difficult puzzle and not dying. But design elements still must be judged on a case-by-case basis. If you have a mechanic where the character may completely and totally randomly just die and you lose, regardless of any input from the user or choices they may have made, then odds are it is probably something readily filed under "Bad design". However if you break the design down that is essentially the core mechanic of slot machines and many addictive gambling related games. - You select your bets, pull the lever, and odds are you probably 'die', and you lose. But every now and then you don't lose, and that triggers all the special happy things in some people's brains. Try to imagine a slot machine that allowed you to learn the 'exact right way' to pull the handle such that every single time you pulled it you 'won', and you could sit there pulling it exactly right each and every time for hours on end, constantly winning... Those slot machine mobile apps are weird enough for me to try to understand why anyone plays them (Since they don't actually have payouts, but you can still do in-app purchases), but I struggle to think of an audience who could be entertained by being able to constantly win something like that. Then we can take sound core mechanics, and look at what happens when 'bad' UI design is applied to them. I think my most recent favourite example for this would be Subnautica and how its UI functions in its current state. Namely, the inconsistencies in backing out of menus/game states. Hit tab to open or close your PDA - Simple enough... But, if you watch live streamers try it for the first time (And I myself found this issue too), while you're on that 'menu' for the PDA/Inventory/etc screen, users naturally want to hit ESC to back out of it... But that just opens the "Game Menu/Pause Screen". This is something that you eventually can learn to get around, but it breaks a 'natural convention' in the computing world, which is why it is so common to catch new users doing it. In and of itself, it isn't a 'bad' design, but rather it is more a 'less than ideal' design. But things get worse... Soon after starting the game you get a tool that allows you to open a 'building menu', which looks and feels a lot like the PDA/Inventory menu. That's obviously closed out by hitting the TAB key, as we've been 'trained' by the game with the PDA, right? ... Well, wrong. You click off to the side of the screen to close that one... Eventually we get the Seamoth or the Prawn suit, vehicles that you can enter by clicking on them... But you exit them with the E key. And it 'gets worse' when you get the large Cyclops and use the camera mode while piloting it - You right click to back out of it, or hit ESC... So in this case ESC doesn't open the Pause Menu, but backs you out of the camera to the main piloting station view, where upon ESC will then once again open the Pause Menu when pressed. Why? Because... Reasons? Then there are bad design issues like the Seamoth, the first 'proper' sub you get training you to turn your lights on and off with a mouse button, and the game teaching you that some of the 'less than friendly creatures' you might encounter don't respond in all that positive nature to having new lights show up in their environment... But when you get to the Prawn Suit? Left click 'punches' with the left arm, right click with the right arm... And I have no idea how to turn the lights off in that thing. (But on the other hand, running around and punching/drilling the stuff that used to kill you and make you terrified of the sea does have a sort of giddy pleasure to it, so I eventually stopped caring about whether the lights were on and if I were hidden or not, and just adopted a "Bring it on motherf...." attitude.) On top of that there are the 'bad designs' with inventory items, chest mechanics, and tools and the hotbar. Some objects will 'auto add' themselves to your 5 slot tool bar if you click on them, shifting all the other slots to the right. So you'll have your stasis rifle, knife, seaglide, scanner, and build tool in slots 1, 2, 3, 4,and 5, and an accidental click on the wrong thing? Well, now instead of 'deploying' the gravity net thing in the water, you've shifted things on your toolbar by one slot and put the gravity net in slot 1... So you have to go back and rekey all your tools. Moving things between chests? Well that's a right click. But a left click will eat stuff, and it is mildly easy to accidentally eat a bunch of things early on rather than putting them in chests. Easy enough to learn around, but then you'll get the battery chargers... Which not only use left click to move things be the charger and your inventory, but unlike your inventory and storage chests the items in the chargers will STAY in their spots. If you wanted to move a bunch of batteries from a chest you would keep clicking the top-left one on the screen as the rest would move up/over to auto-compact the list. Swapping batteries in your tools? Well, some tools will clearly show their battery level on screen when you pull them out, other's won't show it but still consume battery power and force you to manually check its level. And the list of different batteries you can swap to doesn't order itself with "Highest charged first", making it easy to accidentally pop a battery you just took from one tool into another. Plus the whole having to manually double check batteries/charge cells in your inventory when putting them in the charging station. (And lets not talk about the annoyance that is the Cyclops Engine Room when it comes to installing upgrades and swapping out power cells.) Subnautica has a bunch of random different 'bad design' issues. It isn't a "Bad Game", the forty or so hours I've put into it since getting it a week or so ago would suggest that it very much isn't a bad game, but being a good and fun game doesn't exempt it from having bad designs included. Subnautica's "Bad Designs" are mostly down to inconsistencies, and 'false training' of the user compared to content that they will see later on as they play more. It isn't earth shattering-game breaking bad, but man it could be so much smoother and consistent to play if they had a little more User Experience design thought put into it.
  8. Luckless

    A Common Thread

    Kavik, who exactly is this "You" you are referring to that is insisting that table top games aren't relevant to what "We" do. I've been professionally involved with hundreds of software/app/web titles, and board games have played a pretty large part of developing many of them. Of the titles I've been involved with from the ground up, probably half started out with hand drawn pieces on card stock with. They are especially important in early planning stages for anything top down and strategy related, as a group of designers can sit around a table together and talk through ideas in an afternoon rather than spending days/weeks/months prototyping the mechanics in code. But I've seen them used for pretty near any style of game I can think of, even FPS titles. Just the more abstract from a boardgame view the final game is, the more imagination is needed by the test players to judge how the end product is going to feel. If the planning and thought process to play a game works well with a pen and paper, then odds are good it will hold up when the computer crunches all the numbers for you, but as a designer you need to watch out for issues like time-decision overloads if 'turns' are running forward in real time for the end user rather than running in 'bullet time' because you're slowly juggling all the numbers and tracking by yourself.
  9. Luckless

    A Common Thread

    We really need to be careful when comparing "One main designer" and "Design by committee" results, and compare apples to apples. If you compare the work of a skilled, experienced, and highly successful designer to that what a group of kindergartners on excessive sugar and coffee come up with, then you're not going to have a very fair time and get a rather biased outcome, much like you would if you sat a group of seasoned designers down and compared their work with that of a single sugar and caffeine pumped kid. Another important factor when gauging the skill of a designer is whether or not they've worked within the project budget - And that is not just a cash value thing, but also a skill issue. What are the overall skills of the team and what are they actually able to achieve? You can have the most graceful and flawless mechanic and visual designs ever planned, but they're not worth much if the team you're working with doesn't have the skills and resources to do everything to spec by launch day. And of course there is the wonderful issue of design complexity, and confusing it for quality: A more detailed and more complex design is not a sign of it being superior, it is a sign of it being more detailed and complex. A mechanical power transfer mechanism with a million intermeshed pieces all working together to transfer rotational energy from a motor to some manner of tool is "Extremely detailed and complex", but odds are it is vastly inferior to a handful of suitably designed gears/cogs. You can run the maths and calculate out all the gravitational forces in the entire solar system to get a "Perfectly accurate simulation" of where every grain of dust will be over the next 10 years, but if all you really wanted was "Where abouts would Mars be..." then you've wasted a lot of time and effort on details that simply didn't matter. A huge part of a game designer's job, whether we're talking about computer or board games, is distilling out the essence of the design and using the parts that are actually needed while discarding those that are merely distractions, and doing so in a way that is readily understood and enjoyed by the player. And when it comes to board games this can become an exercise in information presentation. The last version of RISK rules I read were a great example of "Close, but no cigar" design presentation. I'm specifically thinking of the reinforcement mechanic rules, which frankly were a mess. (Trying to relearn a game's rules when you have a 10 year old hopped up on sugar interrupting and insisting they 'know the rules' is a 'fun' holiday experience.) The information could have been far clearer if done in a more point form format with a small table, but instead they give some long and slightly awkward paragraphs describing the mechanic in a general sense that also ends up burying the minimum reinforcement rate somewhere. - At the very least you should start off a rule's section with what the minimum standard of what a player should expect every turn, and then expand on it from there.
  10. Luckless

    A Common Thread

    So where is a shipped title that is 'centuries' ahead of anything we are apparently doing that I can check out? I deal with QA and UX, and am always happy to check out new content doing things I may not have seen before. I for one am amused that "We" are the arrogant ones, and yet you somehow have not only learned centuries worth of knowledge, but have even managed to learn and then forget more beyond that, and there is no way any of us could possibly catch up? - Would YOU want to hire someone acting as arrogant as that to work with? Also do you have any more information on Magic Maze?
  11. Is there a "Report user Profile" functionality I missed somewhere? The ones in question had no posts or messages or anything I could find with a report button linked to it, and I'm not seeing one on their profile pages. Figured a post was the easiest way to bring it up, and the "Follow a user with zero other visible action" that seemed weird and new to me for a bot's actions. Hadn't seen that behaviour in a bot before as an opening move. On a semi-unrelated note, blog posts on bot activity on the site would be rather interesting to read if anyone on staff has the time and desire to write such things, but sadly that also sounds like the kind of info bot writers could use to fuel their creativity.
  12. Noticed a pair of rather random looking new users started following me out of the blue this week. New accounts, no posts or activity and both [FirstName][Initial][LastName] username formats, and looking a tad 'bottish' - Figured I would toss a post up on the off chance there is something more suspicious going on with the site as a whole, but could totally just be random chance and totally unrelated to anything. No idea what they might be up to if they are bots. Just seemed mildly suspicious for some reason.
  13. Luckless

    A Common Thread

    A bit confused by the purpose or goal of the thread... Of all the designers I've worked with, or have talked about with others who have worked directly with them, I can't think of ANY who didn't generally get a group discussion going to look at things from different angles and get a back and forth. Designs are hard, and feedback helps refine ideas or inspire new ones. I can't even think of a Solo developer who really does everything totally on their own for a proper released game. Friends or family or even community typically gets involved in the discussion and refinement process.
  14. An important point to remember when considering the "How" of organizing a planned economy is that it does not need to be 'perfect', it needs to be reliable, fair, and aimed towards meeting needs and desires over the long term. Maybe we'll end up splitting all production up into classes, basic needs, basic luxuries, advanced luxuries, or some more refined grouping. Basic needs include things like food, food production, and food distribution, with a focus towards "Local First" and an aim to always produce a surplus that can be stored or composted. Resources aren't released towards luxuries/entertainment production until basic food and medical needs are met. Put everything on digital ration, and issue everyone sets of points that they can spend. As you buy stuff you can go back and flag and rate the things you bought - "I will want more of this: Daily/Weekly/Monthly/Would like again in the future|very important/nice to have", "Product quality is good/bad/whatever", etc, and allow the system to build up data to work on and aid planning. If strawberries are proving exceedingly popular during a bad season, then issue a notice and raise their ration price to encourage people to choose other options, or decrease the price of something in surplus and otherwise low demand. Points for more recreational things can be on a different system, effectively its own currency with its own economy isolated from "Basic needs" - If production levels are high, then assign more points for people to spend. Chile was working towards a computer aided economy system back in the 70's with the Project Cybersyn thing, and we have the technology to go well beyond what they could back then. A system also doesn't need to be global, or even completely national. I think it is perfectly reasonable to break such a society down into very regional blocks, and have representatives from those blocks working together to see that needs and desires of the citizens are met. Does region A have manufacturing capacity to handle stuff for B? Does B have mining output to feed A's factories? What routes should expansions of transit lines be focused on? You also don't strictly need "Everyone is perfectly equal and gets the same thing", and the concept of classes is still overall viable to ensure the "Encouragement to work hard" remains that so many want to harp on about. Society would just have to build a class system that is A: Not excessively wide, and B: Reasonably mobile. If you just want to finish high school and sit around watching TV all day, then personally I say take your basic-life ration account, and enjoy a tiny quiet apartment somewhere. At any time you could decide you've had enough of sitting on your ass and access more education or training and move up to a 'better class' with more responsibilities and expectations from society.
  15. Luckless

    How to design linear forest levels in videogames?

    I would suggest a camping trip with a camera and note book if at all possible. Spend some time hiking and looking at elements of real environments, and try to pick out elements that catch your eye. But some design tricks to get a 'natural' look and feel to a narrow woodland environment can include tricks like: - Movement Resistive Vegetation: By using a 'soft edge' to your zone of increasing scrubby bushes, you can allow your player to 'step off the path' a bit, and not feel like they're being completely railroaded. As they try to get deeper, forward progress away from the trail becomes slower and slower, but if you turn back towards the trail you are quickly 'released' and can make ready headway back towards where you expect them to be. - By lowering the resistance of 'getting back out of the bush' as compared to diving into it, you will likely find players fairly naturally come back to the obvious 'trail' to the level while not feeling overly restricted. You can keep the 'centre' of the linear level only a few feet wide, but still let the user wander and try to sneak by parts, or otherwise offer a feeling of 'space' within the confined level. - Carefully manage turns and density of vegetation, and use to to manage a sense of being lost or not. Want the player to feel like they know where they are? Then be consistent with things like moss on trees, keep a clearly defined path in the middle, and a visible landmark like a mountain or noteable tree to one side, and don't take a turn sharper than 45 degrees. Want to promote a more "I'm lost" feeling? Then let the 'path' fade in the middle, scatter the 'edge brush' across a wider area, and then put in a sharp hair pin turn. You'll strip the player of their landmark of "The big mountain was to my left when I'm moving 'forward' down the trial.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!