Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

394 Neutral

About lougv22

  • Rank

Personal Information

  • Role
    Creative Director
    Game Designer
    UI/UX Designer
  • Interests
  1. lougv22

    Money or passion?

    Follow your passion. It's going to get really old at some point getting up every morning, going to a job that does not excite you and does not make you happy, while at the same time second guessing yourself and secretly wishing you were making PC games. If your purpose is to make PC games and you are not fulfilling it, there will be this cognitive dissonance, or misalignment with what you are truly supposed to be doing, in you and it will keep gnawing at you and making you feel unfulfilled. Secondly, don't follow trends. Trends don't matter and they change all the time. Mobile gaming may be the trendy thing today and tomorrow it might be something else. Just follow your passion and forget the trends. The caveat to all this, of course, is that you have pay the bills and put food on the table. If you can make money following your passion, go for it. If not, get a day job doing whatever pays the bills and follow your passion nights and weekends. This resonates with me as well and it's also almost verbatim something Hideo Kojima said in an interview a few year ago. He was asked something to the effect of "What was your thinking when you were making the original Metal Gear?" and sis answer was, "I was just making the game I wanted to play." This has been one of the tenets of my game design philosophy, if you will, for years now.
  2. I am currently an indie game developer and I am looking to get a job with a game company as a game programmer. I worked for a game studio 9 years ago, but at the time I decided to get a day job as a software developer (non-game development), while focusing (as an indie developer), during my free time, on a vision for a game I've had for some time. This was then, but i've recently found myself unsatisfied with my day job and I am now thinking of going back to the game industry. The drive to make games is just too strong in me and I can no longer justify spending my days making software I am not excited about. Which leads me to my questions about a game programmer portfolio. Before i first got a job at a game studio i had built a couple of small games, this was way back though, around the year 2006. Would those be too old to showcase on a portfolio? Second question, i'd like to make the indie game i am working on available for potential recruiters to play, but I am not sure how to do that. I tried to put it up on (kind like, but not as popular), but i ran into issues with that. It's a Unity game and the Web build i created for it was about 190 MB and it ran slowly and was very choppy on my machine, at which point i kind of gave up on the idea of putting it up online. The other option is to simply send (through email or Google drive) game companies a regular Unity build and let them play it that way. The question is, should i try to go the Web build route again and if so, any tips on making it work well this time? And also, if the Web build doesn't work again, would it be acceptable to send companies i apply for a regular build?
  3. Hi all, I would like feedback and ideas on how to improve the UX for an indie game I am working on, in Unity. First of all, I am not an artist so pardon the quality of my art assets. What I have in the UX below is a 3D character and a piece of interface that displays some stats about his limbs, such as arms and legs. The limb UX is connected to the limb it represents with a line (drawn with the Line Renderer component in Unity). The problem I am having, and what I want feedback and improvement ideas on, is that the line in question is difficult to distinguish from the background. I've tried different colors, but none seem to work well. Also, because i didn't want to make the line thick (it's current width is 0.02), i couldn't really have any significant outlining. I am open to making the line thicker though, if that would look better and make it stand out more, and also if it works well with the limb UX. The bottom line is that I want the line connecting the limb UX to the limb to stand out and be easy for the player to distinguish from the background. Also, I would like feedback on the limb UX itself, that's the shape outlined in purple. I am thinking it should probably be bigger and I am not sure that purple works well with the rest of my level. The first two images below are screenshots of the UX i want feedback on. The second two are ideas i've been bouncing around about to how to improve the UX in question, though I am not sure it would look any better. So what are some ways I can make my UX interface stand out more and look better?
  4. I would encourage you to give Adobe Fuse + Mixamo a try. Fuse lets you put together (not model from scratch, so you don't need to be an artist) 3D models from existing assets and then you can export them to Mixamo, where they are automatically rigged for you. After that you can apply animations from Mixamo's library to them. Their animations library is quite extensive, it has categories like action, combat, sports, etc. You can tweak animations, i.e. make them animate faster or slower, etc, and then export into FBX (and other formats) for Unity. I use those in my game and they have been a lifesaver. Both Fuse and Mixamo are free right now. Also, like other people mentioned, is a great resource for 2D, 3D, textures, and even sound effects. You can also make your own assets. People have already mentioned Blender for 3D models and animations. One thing I'd like to add is you can use XBox Kinnect for low cost motion capture for more realistic animations. For 2D graphics you can use GIMP 2, it's free. And finally, you can try and find an artist to work with. If there is a game development association or an IGDA chapter in your area, you can join and attend a session or two, which would be valuable learning experience and there is a high chance you can meet an artist there that would work with you.
  5. lougv22

    Game Engine Decisions

    While Unity is primarily a 3D game engine, it handles 2D quite well too. One of the latest versions (don't remember which one exactly) added support specifically for 2D development. Unity also has the advantage of having a huge community and very good support, so any questions you may have or stumbling blocks you might encounter can easily be addressed by looking up a YouTube video or checking out the Unity forums, or even the forums on this site. This (e.g. big community and good support) matters a LOT, because when you do get stuck on something, and you will (99% guaranteed), it makes all the difference in the world when you can easily find an answer in a few hours, as opposed to with the less widely used and more esoteric engines out there, where you hit a snag and you keep spinning your wheels for days and weeks, hoping somebody out there will take mercy on you and answer your question. As for having to learn C#, I highly recommend doing it, especially if you, at some point in your life, are planning on working as a software developer. If you don't want to though, Unity supports JavaScript as well.
  6. lougv22

    How can I ever have time to finish my game?

    Without having read every single reply (just the first 7-8), the answer is simple. You have to MAKE time to work on your game. I am in the same boat as many people here. I work a full time job, I have a spouse, and I try to exercise at least once a week. That still leaves me with about 13-14 hours a week to work on my indie game. With all that said, what I have found works for me well is to set a schedule and follow it. For example, pick some days that work best for you, let's say 3-4 days a week, and on those days set aside 2-4 hours (with specific start and stop times) and commit yourself to working on your game in those specific times. No excuses and no exceptions. When those days and times come, you get on your computer and work on the game. If it helps you, put it on a calendar or some kind of a scheduler, or something along those lines. It all comes down to the answer to one simple question, how bad do you want it? If you want it bad enough, you'll find a way.
  7. An interesting article and an impressive idea about a playable menu, but I couldn't help wandering to myself, they spent a lot of time on a menu, wouldn't some of that time have been better spent on adding more gameplay and content to the game?! Generally speaking, if a game is engaging and has interesting gameplay, characters, music, overall ambiance, etc., players will go through the effort of reading a tutorial or asking somebody or even looking up online how to play it. Look at some of the more popular arcade games from the 80's and 90's, for example. There was very minimal information about the controls and how to play the game, but players learned if they liked the game enough. In games like Mortal Kombat and Street Fighter, for example, there wasn't really much of anything in the game about what buttons did what. In MK, which is notorious for its fatalities, there was nothing in the game about the button inputs to perform one, but players figured it out and shared the knowledge amongst each other. I am not criticizing, per se, more like wandering about the merits of adding playable menus and how much playable to make them. It seems to me something like in Antichamber is more optimal. You still get the playable menu feel, but really the "play" part is very minimal and it only serves to teach the player the controls of the game.
  8.   That's great advice! Plus, if an input system is well designed, it shouldn't be too hard to switch from one system to another, if necessary. Good software design principles are universal, after all. Thanks for that.   @kburkhard84 It's unlikely it'd be finished soon, i.e. it'd probably take a while longer.
  9. Thank you for the detailed and informative responses, everyone. It's clear to me now that I have to support both Keyboard/Mouse and a game controller (s), at the very least. In addition, all types of input have to be configurable with ability to save input configurations, of course, and an option to reset to defaults. The next question I have is whether to use a third party input system for Unity, such as ReWired, or Unity's new input system. I have done some research into ReWired and I agree that it is superior to what Unity offers out of the box today. However, there is a new input system in the works for Unity, which sounds promising, and they should be releasing an experimental version this summer. Here is a link to their blog: In general, if Unity offers a certain feature out of the box, I prefer to use it over any alternative third party solutions, provided their functionalities are fairly similar. Any opinions on ReWired vs. this new input system?
  10. So I am an indie developer, working on a third person action adventure-like game in Unity. So far, while developing the game, I've only been playing and testing it with a keyboard. However, now I want to add support for a controller (Xbox One for example) as well. My question is, should I support inputs with a keyboard and a controller both? I personally am a console gamer and I only play games with a controller, so that is my preferred inputs scheme. In addition, supporting only one control scheme would reduce my development effort. I do realize though that, since the game in question is a PC game, I would think a lot of gamers would want to use a keyboard.   What is the prevailing design philosophy on this? Do most players on Steam, for example, prefer a keyboard? Would there be any harm in only supporting a controller?
  11. lougv22

    XPO Retrospective

      That's a good tip. Thanks. I already started doing that while playtesting in Unity, but hadn't thought to do it while in the editor.   After learning the lesson about testing in a build the hard way, I am now testing testing every new change in a development build. It doesn't take much time and the pay off is immeasurable.
  12. lougv22

    XPO Retrospective

    Long time reader, first time journal poster here. This is regarding a game convention called XPO, where I showcased publicly for the first time an indie game I've been working on for the past three years. And more specifically, it's about the lessons I learned from it. The game in question can be described as a fighting game with RPG elements and it is being developed in Unity. It's something that has been on my mind for a while, but I didn't start any real development on it until early 2013. XPO, which took place in September of this year in Tulsa, OK, was the first, and so far only, convention I've showcased the game at. Up to this point, I didn't think it was good enough to be publicly exhibited. And without further adieu, here are the most important lessons I learned from the whole experience: Lesson 1. Test the game in a build as often as possible (under different resolutions and aspect ratios). Because I had never done this until the week of the convention, there were a great number of things that did not work correctly in a build and there simply wasn't enough time to fix all of them, so I ended up demoing the game in the Unity editor, which was not optimal. It is much easier to position various UIs (user interfaces), dialogs, and other game objects where they need to be as you are developing them, when all the various conditions and parameters are still fresh in your mind, as opposed to coming back later and adjusting them. For example, now that I've learned this lesson, I am re-working big portions of the game to make sure it runs in a build. One of the biggest issues I've encountered is with the positions and sizes of my UIs. Many of them I simply hard coded to get them to work when I needed them, but as you can guess, they did not work so well in a build. In order to address that issue, I am currently re-doing all of my UIs to make use of the Canvas system in Unity, as it has built-in features for adjusting the positions and sizes of UI elements as the screen resolution changes. As you can probably guess, this is a time consuming enterprise, which would have been a lot less painful had I planned for it from the beginning. Plus, making sure the game works well in a build forces you to think about important details, such as what resolution and graphics quality your game should be playable under, where should data files be located, etc., early in development. Lesson 2. Have other people test the game as often as possible. It is a well known, and oft ignored, maxim in the professional software development world that a developer cannot, and should not, test his or her own code. They are simply too close to it and subconsciously, or rather consciously at times, "test" it in such a way that it does not break. Unit testing can do some of the work for you, but really nothing is a substitute for another human being playing your game and actively trying to find ways to break it. The reality though is that indie developers, such as myself, don't really have the resources to hire testers to playtest a game on any kind of a regular basis. We are often limited to friends and relatives, or just doing it ourselves, which is pretty much what I did, other than one playthrough done by my spouse. If your game has been tested on a regular basis and you already know everything works well, that will give you confidence in your creation, which will show through to whoever you are talking about it with. And as a very nice added bonus, it will also save you from having to frantically fix bugs in your hotel room the night before the convention. Trust me, I've been there, I know, it's a stressful experience that I don't care to repeat. It is, shall we say, unpleasant to find out the night before you are supposed to be showcasing your game, that it doesn't work in a build so you have no choice but to have people play it in the Unity editor, not to mention finding out that a major feature you introduced specifically for the convention, such as being able to restart the game, has caused hard to find bugs and you have no choice but to scrap it. It sucks! Test your game early and often to prevent all that. Lesson 3. Have the game playable on a TV. Somehow I had convinced myself that as soon as I had set up my laptop and started up the game, people would line up wanting to play and asking me all sorts of questions about it. Talk about wishful thinking. Well that was not exactly the case. People were walking by, but did not seem terribly interested in approaching my booth. I am sure the location (off to one side and facing away from the entrance) did not help things a whole lot, but I am convinced the bigger reason was that my set-up was simply not appealing enough. I had no posters or marketing materials of any sort, just a laptop screen facing towards the convention floor. In contrast, the main indie games booth hub, other than being directly in front of the entrance and thus being difficult to miss, was populated by big screen TVs at elevations high-enough to be seen from pretty much anywhere on the expo floor. It was only logical then that people would congregate around them and hardly even notice my less catchy set-up. Lesson 4. Have the game playable with a controller. Being a console gamer, perhaps I am a bit biased, but watching people play my game, hunched over the laptop and struggling with the keyboard, it dawned on me it would be so much easier if they could just pick up a controller and play. Plus, with a controller there is less opportunity for errors, i.e. only the buttons that do something in the game are available to the player. Even if they wanted to, they could not press a button, or a button combination (such as Escape or Ctrl + Alt + Delete), that could cause your game to exit or transition into some other undesirable state. Lesson 5. (Almost) always develop as if you are preparing to showcase the game at a convention. When you are in the midst of development and really want to pump out a cool new feature, it can be very tempting to "leave things for later". Or when you are faced with a looming deadline. Of course, the reality is that it is impossible to never leave anything for later, but you should try to minimize that and think really hard before you do (leave something for later, that is). In my case, I had left so many things for the proverbial later that when the time came to showcase the game at an actual convention, there simply wasn't enough time to address them all, so I had to cut features and otherwise make compromises just to have the game be playable at the expo. This also goes hand in hand with some of the other lessons, particularly #7 below, but long story short, (almost) nothing during the development life cycle of a game happens in a vacuum. All aspects of a game, especially the code, go hand in hand together and many are dependent on each other. So if you leave one thing for later and that one thing depends on, or affects, five other things, the amount of time and effort it would take to finish or fix that one thing several months later would be significantly higher because the other five have most likely changed, or they would have to, as a result of the thing you change. Lesson 6. Add a main menu screen. I noticed the guy on the table next to me, who was showing off an open world MMO with western themes, had a pretty nice main menu that was constantly looping while the game was on stand by, and it made his game look polished. By contrast, my game thrust the player directly in the first level. Now granted, you are not expected to have a finished product at a game expo, but whatever you do have should look as good as possible, and a main menu is just the sort of thing that can make your game look more like a professionally done product as opposed to a hobbyist project. Lesson 7. Emphasize (code) quality over quantity. As a software developer by education and trade, I've always tangled with the million dollar question, "How to build better software?" One conclusion I've reached is that creating good software is very much like building a brick fence. You lay down a layer of bricks and then another one on top of the first one, then yet another on top of the second one, and so on and so forth. Now, if just one of the bricks in the very first layer is a tiny bit askew, that's not a big problem, plus at this point you only have one layer so really, your fence is just as stable as if that one brick fit perfectly with all the rest. However, if you now put down a second layer on top of that first, imperfect one, your fence will be a tiny bit unstable. Still probably not a big deal, right?! You are on track to meet your deadline, so things are good, ....maybe. However, think about this now. If you wanted to fix that first layer at this point, you would have to undo the second one, fix that one brick, and then redo the second layer. Of course, things are not as clear cut in neither real life brick fence building or software development, but you get the point. To continue with my analogy above, if you leave the first layer imperfect as it was and not only that, but you also introduce a faulty brick in the second layer too (because again, you had to meet a deadline or some such) and then you erect a third layer, your fence is now starting to get a bit wobbly and the cost of fixing all that would be even greater, as you would have to undo and redo two layers. I am pretty sure you see now where I am going with this, but let's continue with our example a bit longer. Now let's say in layer #3 not one, but two bricks are off and don't quite fit very well with the rest of the bricks, partially because one of the bricks is now on top of the imperfect brick from layer #2. You still march on, however, and you construct layer #4 on top of #3. At this point, the whole thing is starting to get noticeably unstable, but the cost of fixing it grows higher and higher and you now start realizing it would take so long to fix all the issues that you would be severely over budget and behind on your deadline. So you do the thing that so many other developers do, and that seems the easiest at this point, and you keep on building on top of an increasingly unstable foundation, you keep on patching and duck taping the fence, just to keep it standing and your boss happy. The time comes, however, when the fence is so unstable that it becomes impossible to patch it up anymore and when that tipping point is reached, the whole thing simply collapses under its own weight. The only way to fix it at this phase in development is to scrap the whole thing and start over. That's the very situation we want to avoid by following software development best practices, measuring twice before cutting once, and so forth. As a side note in regards to best practices, I would highly recommend the SOLID principles of software design. So after this very long example, back to my lesson. After spending a few months preparing my game for XPO, I realized my code base had gotten big enough to the point where I could not really afford to add any more poorly designed or implemented code, or I would risk my "brick fence" going over the wobbly point of no return. From this point on, I decided, it's imperative that all new code is well designed and implemented in accordance with best practices. I suppose the whole point of this lesson then would be that "this point on" should really be the beginning of your development cycle. Lesson 8. Go and find people to play your game if you have to. For whatever reason, poor location, the small laptop screen the game was showcased on, etc., people were not coming up to my "booth". So after some time, I decided that it was up to me to convince them to try out the game. And so I did. I watched the people pass by and when I spotted what I thought was a good candidate, a young guy walking by himself, I went up to him and said, "Excuse me, do you mind playing my game? It's an indie game I am working on and I need some feedback. You can get free candy if you play". And the guy said "OK". Boy was I happy. The first stranger to play "Genosaga"! Bonus lesson: 9. Bring candy. Why not? Can't hurt. People like free food. See Lesson #8 above.
  13. For those interested, here is the solution I came up with, thanks to user JoshuaMcKenzie from the Unity forums. It's based on the Adapter software design pattern. First I have an interface representing the behavior of an image component with a texture: public interface IImageComponent { void SetTexture(Texture2D texture); } Then I have an implementation of the interface above for RawImage. This is an adapter type class whose job is to provide communication between a Unity image component, such as an Image or RawImage, and a logic class that performs operations (such as show, hide, and set the texture) on the image component: public class RawImageAdapter : MonoBehaviour, IImageComponent { public RawImage Image; public void SetTexture (Texture2D texture) { if (Image == null) { return; } if (texture == null) { throw new System.ArgumentException ("Texture reference could not be created."); } Image.texture = texture; } } And finally, there is the TextureHandler class, which doesn't know about the Image Component it's affecting, not even the RawImageAdapter (just that its referencing some class that implements IImageComponent). Because of that, it's decoupled from RawImage allowing me to swap it out with, for example, an Image + ImageAdapter class: public class TextureHandler : MonoBehaviour { // An array of textures for the level images. public Texture2D[] SmallLevelImages; private int _imageIndex = 0; public IImageComponent textureComponent; private IImageComponent TextureComponent { get { if (textureComponent == null) textureComponent = GetComponent<IImageComponent>(); return textureComponent; } } /// <summary> /// Gets or sets the index of the image. /// </summary> /// <value>The index of the image.</value> public int ImageIndex { get { return _imageIndex; } set { _imageIndex = value; } } // Use this for initialization void Start () { // There is nothing to do here. } // Update is called once per frame void Update () { TextureComponent.SetTexture(SmallLevelImages[_imageIndex]); } void OnEnable() { _imageIndex = 0; if(TextureComponent== null) return; if(_imageIndex < SmallLevelImages.Length) TextureComponent.SetTexture(SmallLevelImages[_imageIndex]); this.enabled = true; } } So we now have a solution which works for any image component. The IImageComponent interface and the TextureHandler class would stay the same for any image component. Only the adapter class would change. 
  14. I see. Funny, this is the exact same video I was watching the other day as my introduction to panels.
  15.   Kind of a late response, but I am just now learning about panels. Is the standard practice to put all UI elements in panels for better positioning and resizing, etc? What would you use panels for and when?
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!