Jump to content
  • Advertisement
Sign in to follow this  
  • entry
    1
  • comments
    2
  • views
    365

8 ways to avoid going crazy while developing your indie game

TheOriginalGamesta

776 views

(you can find the original article here)

You've done it. You made the jump. You've gone from "just working on a project," to identifying yourself as a real-life game designer. You've got a solid game design document, a (mostly) working prototype, and have even started to deal with the incredulous looks of bewilderment and disbelief when you tell people you're "making a game".

As you consider your wild fantasy of a design, the gravity of what you've signed yourself up for BEGINS TO DAWN ON YOU:

"What have am I doing?" "Is this even possible?" "Am I crazy?"

These are among the frantic questions that race around your mind. Every time you find yourself thinking about letting your hopes of making your game die, you remember: You are a game designer, and this game deserves to exist.

I put together this list to share how I've coped with the affliction of being a game designer. As Renaissance Man Kanye West put it, "this shit was hard to do, man!". Everyone has a unique environment, circumstance, and perspective when it comes to creating art--video games are no different.

Even though these suggestions won't work for everyone, I've tried to think of things that can apply to every indie designer, regardless of who they are and what game they are designing. You should also know that I've broken every one of these rules at some point during development myself. So, don't beat yourself up -- with these suggestions, starting late is much better than never!

1) Keep going

giphy.gif

It seems insurmountable.

First, there's thinking of a way to craft your game that doesn't feel the same as everything else in the genre. That's before coding billions of mirco-conductors to manifest the wild fantasy of you've envisioned.

After that, you have to make sure it's good--even something as simple as moving a character around a 2D plane may need dozens of iterations to be balanced properly. As a designer, you don't ship with your game. Early in the process, you have to consider if the player can actually figure out what they're doing without you hawking over their shoulder. This issue is addressed through the use of designer-player communication tools like the GUI, prompts, and message windows.

The fact is, as an indie designer there will always be a million things to do. A lot of times at least half of them are going to seem impossible. A great game design professor once told my class that the "design never ends," despite the fact that the game has to ship at some point. What defines an indie game designer is the willingness to face these odds through failure, disappointment, and ridicule.

Just remember: keep going! In my experience, indie development works great in combination with "tunnel vision," or the ability to ignore and look past distractions and other exterior actors and concentrate on the goal or task at hand. Remember why you chose to do what you do in the first place. Remember how you've already come as far as you have, and consider why the world needs your game.

2) Make lists

giphy.gif

During my university career, I was once told that "humans are monkey-minded". The notion has stuck with me. I remember the lecturer explaining how our mind naturally skips from thoughts, to memories, images, and everything in-between. A primary role of our self-conscious is in mediating and ordering this "monkey-mind" so that we can do things like have conversations and file our taxes.

Not to too get super Dalai-Lama here, but both creativity and the path to a state of peace and contentment are empowered by giving freedom to the monkey-mind. Of course, there are times where the monkey really should be paying attention, but even if you have to wrangle it in, it's only kind to be gentle, right?

lists2.jpg

 

To get to the point--lists are a great way of allowing yourself to be creative. And remember, the lists don't have to be exhaustive--you can always make another one! Make a list for your tasks for the next month, the next day, the next build, or the current character you're making.

As I stated before, there's a lot going on when you are developing games--especially on a small team or by yourself. It creates a lot of baggage -- you can be constantly trying to recall details of bugs you need to fix, or details of an art asset that needs to be changed. Committing the things you need to do to paper allows you to release those thoughts so that they don't have to take up space in your mind. That way you've got much more room for your monkey to wander and gather the fruits of creativity!

Also, give yourself the satisfaction of checking, crossing off, making a blood oath, or whatever it is you want to do to the list to communicate to yourself that a task is done. No matter how big or small of a task, use it as an opportunity to celebrate. It was on list, and now it's done. You fucking did it! You are a little bit closer to bringing your game into reality.

(Please don't actually do a blood oath, it's unsanitary.)

3) Take breaksaid44724-v4-900px-Kill-Your-Sim-in-the-Sims-2-Step-17-Version-2.jpg

Remember the "fun meter" from the Sims? It's a real thing! Respect your fun meter.

Sometimes that might mean giving yourself a night off to decompress after banging your head against a wall for hours trying to fix that collision bug--maybe by switching to something like writing blog posts or by watching "Indie Game: The Movie" or an episode of Double-Fine Adventure. Do what you can to get yourself back into the zone. If you can work in a positive state of mind, both your work and efficiency will benefit as a result!

Good games take sacrifices of relationships, money, and perhaps most importantly--your time! So make sure you are managing your energy and putting some time into maintaining your physical and mental well-being. After all, if you're unwell it's harder to make a game!

4) Use Naming Conventions

Anyone who’s been hundreds of files deep into development and managed to lose that crucial asset that they've worked on for hours will stress how important this point is.

filestructure.PNGProper use of naming conventions will save you a world of time and frustration. Your method doesn’t have to be too elaborate as far as “professional” conventions" go, but your main considerations should be consistency, clarity, and convenience. Whatever system you decide to use, make sure it’s logical and predictive for you. If someone else were to make an asset for your game using your naming conventions, you should be able to tell what kind of asset it is in your game, and where it belongs.

It can be very simple, but must be enough to make your assets distinguishable. It’s also important to carry this relationship with naming conventions across your whole project! For me, this includes art assets, scripts, and even the images I use for blogging. They might change from subject to subject, but the main thing is to make sure you know, and understand it, while finding your system efficient.

 

5) Talk to people

Developing Class Rules has been one of the most isolating experiences of my life. Making a game is itself a profession that is already at odds with society's "norms" and expectations of what constitutes wage labour and otherwise normative ways of life. Further, the actual day-to-day process of developing games is alien to the vast majority of people. Attempting to explain the minutia of "the awesome new script" you're working on, current hiccups in the coding process, or the labours of trying to balance a level often results in a glazed expression of confusion and apathy.

giphy.gif

But, it's not their fault! What did you expect? You're a game developer! How long have you listened to the minor details of what other people do during their day at work? And really, why should you care so much? There is no way to know everything, and most people will not have the tools or to communicate with you about the in-depth details of your work.

The point I'm trying to make is: don't let game development's complexity discourage you from trying to talk to people about your game. Yes, a lot times you'll get friends and loved ones putting you down, disbelief in game mechanics you think are awesome, Han Solo shaking his head, and blunt disinterest in what you dedicate much of your time to. But at the same time, you can be faced with the exact opposite: great new ideas spawned from situations and conversations , songs to listen to, movies to watch, renewed fervour and faith in your project, or in short -- creativity.

Take criticism as an opportunity to review your reasons for doing what you do the way do. Take yourself through the uncomfortable process of challenging your assumptions. Make the reasons why your target market deserves your game evident within your work.

6) Set Deadlines

Setting deadlines is huge! It's a little related to making lists, but I think it deserves some more attention. When working by/for yourself it becomes very easy to let things slide. Pressure -- even if it's completely of your own fabrication -- is a great motivator. But, be realistic when setting deadlines for your schedule. This is especially true for the pre-design and prototyping phases of the project. In my experience, development times start to become a little more predictable as you become more attuned to the specific systems of producing parts of your game.

Deadlines can be set for a lot of reasons -- contest or festival entries, grant submissions, presentations, and your aunt's wedding are all valid reasons to make a stable build for your game. This is also something you can at the end of every week or two weeks to make sure you have a current and accessible version of the game ready to go just in case.

7) Show your game

Take the opportunities that you can to show your game to your peers and public. I think the most important thing going into any environment where you will have the chance to playtest and learn about your game is to know what it is you hope to answer during the playtest. Watch how your new section plays, or how players react to the dialogue. Try to have an idea of what you want to learn and take away from the play test! That way you can optimize the structure the session to get the most out of the feedback.

giphy.gif

 

Also, be mindful about where you enter your game and make sure you're ready!

8) Make it count

Game design is an art. Your work has meaning. The power that the messages behind your game can mean for other people should not be underestimated. You have the opportunity to do something that matters for others, so do it!

I touched on the importance of making the effort to consider why your game deserves to exist earlier in this piece. Ask yourself why your game deserves to be made. Perhaps more importantly, why does it matter? As a designer, I think you should be repeatedly asking yourself these questions throughout the entire development process.

In 1809 when Napoleon led his armies to victory over the Prussians in Jena, German philosopher Georg Wilhelm Frederick Hegel claimed it was the "end of history". It ensured that the ideal "liberté, égalité, fraternité" would be pursued by all peoples of the world. The marriage between Napoleon's actions, and Hegel's thoughts are an example of a powerful dialectic representing the real political action that comes as part of some great artistic or literary works.

Videogames, as with all other forms of art, can be used as an agent of political change. If your game contributes to a message, or was designed to communicate something about a particular topic, you will have a much easier time motivating yourself to see your project through. And as indie, aren't you here to make unique games that wouldn't be considered by AAA studios anyways?  

giphy.gif


2 Comments


Recommended Comments

That was a great list. Wish I had it a week ago while I was working on my class project to make a simple game. Thank you for this!

Share this comment


Link to comment
9 hours ago, MichaelMcCarron said:

That was a great list. Wish I had it a week ago while I was working on my class project to make a simple game. Thank you for this!

Thanks, Michael! Too bad about the project, but hopefully it's just more ammo for the next project. Good luck! 

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Mapet
      Hi, I started implementing 2D board game. I have concept of how to write rules, controlls etc, but i dont want to write another all-in-app. So i decided to do it "right". I divided my code into reuseable modules - ResourceManager, Renderer, Core, Math (for now). All modules use SDL2.
      ResourceManager(RM) - loads textures, audio etc without duplicating them in memory. Resources are gathered in TextureResource, AudioResource (...) objects, handled by std::shared_ptr. For textures I have prepared Texture class that wraps SDL_Texture and I RM serves this Texture objs for Core module.
      Core - The main game module, contains game loop, gameobject / component implementation and event handling. Core requests for data from RM and sends them to right components.
      Renderer - Creates window and knows about render range (in core represented by camera). Takes info about texture, position, rotation and scale to render images (just this for now).
      Its time for my questions:
      is this architecture good? After I end this board game I want to extend renderer module for example for rendering 3D objects.  Loading resources while ingame is good idea? I mean single textures, models, sounds etc.  As I said, for handling resources I am using shared_ptr, is it good cleaning cache every (for example) 3 minutes? By cleaning i mean removing not used resources (counter =1). And the hardest thing for me right now - take a look at this flow: Core create a T1 token Component Renderer2D is connected to T1. Core requests a texture /textures/T1.png from RM. RM checks if /textures/T1.png is in map, if not, loads it. RM returns a std::shared_ptr<Texture> to Core. Core assign texture to T1 Renderer2D component.
      Now i want to pass this object to renderer. But I wont pass all gameObjects and checks which have renderer2D component (i also cant, because only Core know what is gameObject and component). So i had an idea: I can create Renderable interface (in Renderer module) and inherit from it in the renderer2D component. Renderable will contain only pointers to position data. Now i am able to pass renderer2D component pointer to Renderer and register it.

      Is this good way to handle this? Or im overcomplicating things? If point above is right I had last question - registering object in Renderer module. I dont want to iterate over all objects and check if I can render them (if they are in render range). I wanted to place them in "buckets" of - for example - screen size. Now calculating collisions should be faster - i would do this only for objects in adjacent buckets. But for 2D game i have to render objects in correct order using Z index. Objects have to be placed in correct bucket first, then sorted by Z in range of bucket. But now i have problem with unregistering objects from Renderer module.
      I think I got lost somewhere in this place... Maybe You can help me? Of course it this is correct way to handle this problem. I would love to read your comments and tips about what can I do better or how can i solve my problems.
      If i didnt mention something but You see something in my approach, write boldly, I will gladly read all Your tips :).
    • By nsmadsen
      In this episode of Madsen's Musings, I detail five things I wish I'd put in my contracts sooner.
      Wanna learn more about me or my work?  Go here: https://madsenstudios.com/
      Subscribe to my YouTube channel or follow me here on GameDev.net to see all the latest updates.
      A transcript is provided below the video.
       
      Transcript
      I mean, it's cloudy, but the weather's like 75°F up here.  It was awesome, whoo, love it.  If only Austin was like this all the time.
      Okay,
      So, we're talking about contracts today -- yay, contracts -- legal stuff.
      First off, disclaimer: I am NOT a lawyer, I do not play one on TV, I am NOT a law expert, so take what I say with a tiny grain of salt.  These are just basically my experiences -- these are basically my observations -- but if you have a specific legal issue or question, or if you need some specific legal advice I always STRONGLY recommend talking to an attorney; talking to an expert because that ain't me.  [Laugh]  Saying "well Nate said on YouTube..." is not gonna hold up in court -- I've tried it!
       
      Okay, so, let's talk real quick about what are the basic components of a contract first:
      A contract is just an outline.  It's an agreement.  It's saying that Party A is going to do something, Party B in response is gonna do something else.  It outlines the specifics of the timeline, any cost related, and it outlines how long the relationship can last between both parties.  It outlines how you can end that relationship.  It also outlines how the approval process is gonna happen, how the delivery process is gonna happen.  It's just a statement.
      Good contracts are actually supposed to try to protect both parties.  That's what negotiations are all about when you're trying to nail down the specifics of a new of a new job you want to make sure that those terms are gonna be something you feel good about.  As a freelancer, or if you're looking for an employment position you're going to negotiate the terms of what's your salary, how much PTO you're going to get off the top of the starting, any special considerations.  Contracts are just outlines.
      Okay, so we've defined what a contract is.  Let's talk about some of the things I wish I put in my contract sooner.
       
      So top of my list:  Revision clause
      Basically, this clause is just capping how many times you're gonna go back to square one and rewrite something.  In my opinion -- this is just how I do my contracts -- is if you want me to make something a little faster, bump it up by five clicks, if you want me to change the oboe to a flute, if you want me to -- hopefully there's no angry wind noise there -- if you want me to change this chord from first inversion to second inversion, if you want me to do tiny minute things then I don't consider that a rewrite.  I don't consider that a revision.
      A revision for me is "this is not working, let's go back to square one and start over".  That for me is a revision, and in my contract I say for the price I've quoted you, I'm gonna give you three included revisions.  Anything past that is an extra cost.  Now, I don't list what the actual cost is in my contract, I say that should we go beyond three revisions, what we will do, is we'll have a meeting and we'll discuss things, and we'll make a new cost for this fourth revision and it'll be a mutually agreed upon dollar amount.  So maybe it's sloppy of me to not include or quote the price for those additional revisions once you get past the first three free included revisions in that original price, but the thing is, with the exception of this one experience I've never had to use it. 
      But I had a client early on, hired me to write one song that she wanted to use as a part of the pitch to hopefully get funding to make a full Broadway musical, and I was writing music, writing music, working with this client, like I said again, very early in my career, so I gave her version after version after version, each time starting anew.  About the fifth or sixth time I asked her "hey, what's not working here, why are we going back and redoing version after version after version and starting from square one?"  Well her response kind of shocked me, she said "oh, I just wanted to see what you would do, I just wanted to see what you create", and she even said "I didn't see any kind of revision cap or revision clause in your contract so I figured I could just request as many as I want".  And she was right, she could.  At no additional costs to her, she could have me writing thousands upon thousands of iterations of this Broadway spec piece.  Just over and over again, just to see. 
      Because you have to remember, the more time you take to do something, the less you're actually getting paid per hour.  If you have a job you accept for $2,500, and you take five months to do it, you're not actually earning as much than if you have a job that you do in one week for the same $2500.  It's a simple concept, but sometimes I think people forget that, and they're talking about their rates, when they're talking about their budgets, and these contracts.
      So the top of my list would be revision cap.
       
      Second thing I wish I added to my contract sooner, is basically says that I as Madsen Studios have the ability and the right to showcase my work in my portfolio.  What I've learned, especially working with some larger companies, is in buyout situations particularly they can say "well we're never going to give you the right to put this in your portfolio".  You can of course list something on your resume, but you can't showcase it on your demo real or your video reel.  You just can't without having some kind of language in your contract that specifically states you can.
      So my contract states that once a game is made public or once the game is published, I will be able to showcase -- just for promotional reasons -- the content I provided, the content that I created for that game.  I've not had any clients object to this when I have it in my contract.  I've even had clients put it into their contracts if they're the ones providing the contract to me.  I've had "hey, I want to be able to showcase this in portfolio".  The only problems I've had is when I didn't ask for it, I didn't have it in my contract, there's nowhere mentioned and I already had signed something and I'm already working and it comes up "hey, I would love to promote myself and promote this work I did, can I put it in my demo reel?"  I've had some larger clients say "no you cannot".  That kinda sucks, so I learned to start doing that.
      Let's say a game trailer showed Level One as part of the teaser for the game, and had some of my music I put in Level One, and this is out on YouTube, this is out on the internet - this is live.  In that case, I would say "okay, Level One music has been released by that company", and of course there's always political things to consider.  I would always talk to my point of contact to say "hey, I love the trailer you guys released, it's using my music, it's out there live per the contract, and says anything that's made public, or once the game's formally released I will be able to share and promote my stuff for promotional reasons on my demo reel."  And I would talk with them and say "okay, so since that's been done, let me go ahead and do that real quick, if I want to just shoot you an email and we can talk about it real fast", well I feel like that's a useful thing to do - you don't want to piss anyone off, you don't wanna get yourself in any kind of legal liability, or something like that.  In some cases, it can be as easy as just retweeting something, or linking something that the company has already done saying "hey look, I did this", but yeah... that was a weird voice for the "hey look I did this..."  You need to have some kind of language in your contract, or in the contract the company is giving you, and you negotiate that saying "I want to be able to share this on my portfolio".  And by the way, it's very common to say portfolio: this is not gonna be for downloads, this is not gonna be commercially sold again, that sort of thing, and this mostly only applies in buyout situations.  Examples when you were keeping the rights to the music you're providing, you're basically just giving the license to a client, you don't have to worry about that so much, because you are the owner.
      You might still have to worry about the schedule of it though.  You know, perhaps the client doesn't want you to release something that's not made public yet, that's very very common so you do have to be careful about that.
       
      Number three for me would be point of contact.  Final authority.  All this does is dictates -- lays out in black and white -- who was gonna be the person to have authority over saying yes or no in a project.  The reason why this is because I've been in situations where you have a group of people and let's say they get into a disagreement and Bobby-Fred does not like the music you did for Level 7, and Judith thinks it's the greatest thing, well then you have a conflict.  You have this whole other discussion that has to happen and when you're working as a freelancer and so I will get on these Skype meetings that would be about two-three hours long each, and this was a weekly meeting.  And then they would talk about these things, and then they were getting disagreements with me right there in the Skype call.  "Well I disagree with you", "well I think this", "well I think that", and suddenly my direction is cluttered.  My scope, my target is not clear because I have different points of reference.  I have people tell me different things.  I have people telling me different direction.  
      So you want to avoid that.  In some cases you don't want to worry about this.  So if for example, you're working with the team of one person; you had your key contact, you have your final authority.  It's that dude or that gal and you just have to make them happy with your content and you're golden.  But in other cases where you have multiple people it's very useful to assign and dictate and just ask the client "all right, well I have meetings with eighty of you guys, but I need to know when the proverbial poop hits the fan, who is the person that has final authority to say yes.
      I would highly recommend if you're working with a team that has multiple people and they don't know who the final authority is that you set something up.  You set some terms in your contract saying okay well let's agree that this person will be the final authority, and then you guys can go off and have your debates and your discussion for as long as you want without me involved, and then that one person comes to me and gives me clear, concise direction. 
      Another point to number three is meetings.  Are you going to invoice your client for every single meeting that you have.  It depends - this is really your call.  My advice, my suggestion would be to really understand what type of meeting schedule the client may have in mind.  If this is a weekly meeting, then yeah you might want to invoice for that.  If it's not then don't worry about it.  I kind of take mine case by case.
      It's really tricky to change a contract once you're in it, so if you don't invoice for meetings, and suddenly find yourself in the situation with the client where you have a whole bunch of meetings all the time, and it's taking up time when you could be working, it's going to be a tricky conversation to say "hey, look...".  Nothing is impossible, it's just going to be tricky.  It's a lot easier if you just say "hey, if we're going to have this type of meeting weekly then this is my rate for it" and just get that of the way, and they agree to it on the front end versus trying to change it on the back end.  That's much much harder to do.
       
      Another thing to consider is, each state has sometimes slightly different sometimes very different laws when it comes to freelancing and business, and regulations -- all that jazz -- and if should you have a point of litigation with a client well... let's say the client is out of state, State accounts in California, you're in Texas, well which law is going to be applied here?  There's a lot of different things here, but it's just a lot more clear if you just say in the case of litigation, the laws of California will be applied to this contract, or in the case of litigation, the laws of Texas will be applied to this contract.  It can be useful to have that listed.
       
      Now the big thing I would avoid is P.O. boxes.   Do not accept P.O. boxes.  I actually don't accept P.O. boxes at all on my contract.  What I do is I list all my points of contact.  I have my name, my email, I have my cellphone, I have my physical address, and then I have a spot where the client puts theirs in, and I say alright, I need your name, your email, your phone number, and your physical address, and in the state P.O. boxes are not accepted.  
       
       
      I guess a little quick blurb.  [Joking about the ocean briefly]
      When you talk about contracts, and you start talking about people getting screwed over, it can make you nervous as a freelancer.  I've worked on 575 projects, and I've been screwed over maybe five times.  When you think about it, every time you get burned, it just eats at you, it pisses you off, it makes you really angry, you just want to scream, but when you think about five out of five hundred and seventy five, most people out there are good.  Most people are going to do the right thing.  Most of them are too busy trying to make their own content and they want to do good work and they don't want to make a bad reputation for themselves, that they're gonna treat you right, or at least treat you appropriately.  They're not gonna try to steal your work. 
      But always, always, always work with a contract.  I've learned that the hard way a couple of times.  Work with a contract, all your terms speccd out, and if you're not comfortable reading contracts then reach out to a lawyer or legal person and get some input.  Read up on it, there are sample contracts online.  There's books.  Aaron Marks, he's a friend of mine and was actually very kind to feature me in that.  Looks, it's on it's third edition now and I believe there's a whole chapter on contracting.  He provides sample contracts.  You can also find contracts online.  Legalese, contracts, the whole thing can be an uncomfortable topic, but you really need it.  You really need to have the protection of the contract.  You need to have the finality of "this is what I'm agreeing to.  This is what I'm going to do, and this is what you're going to do in response."
       
      So I hope that's helpful to you.
      Again, not a lawyer, I don't play one on TV.  I love to watch Law & Order, I love to scream "objection" randomly at home and at the workplace, but I'm not a lawyer, so if you need some actual advice how to reach out to someone who can get that to you much better than I can.
      Please like and subscribe.  If you have questions or comments, or if you have topics you would like me to cover in future videos, hit me up!  Reach out - I'd love to do that.
      Work with a contract people!  Thanks!
    • By Seer
      Currently if I was to program a game using C++ with SFML or Java with LibGDX I would render game objects by calling "object.render()" on the game object. Although this makes it easy to access the information necessary to render the game object, it also couples rendering to the game logic which is something I would like to move away from. How can rendering be implemented so that it is decoupled from the game objects?
      I wish to know how this can be done in the standard object oriented paradigm, so please don't suggest that I use an ECS. Thank you.
    • By Tristanb4
      I've been making music for about 7 years, I have hundreds of releases on soundcloud and bandcamp. Recently I have stepped up my post production game, pouring long hours into EQ and mixing. Most of my music is in a moody, "foggy" piano style with heavy experimentation through pitch shifting, overdubbing, and live recording. I use a spectrogram EQ to manually shape sounds and scoop out noise in Audacity. I am familiar with many general concepts, applying compression, reverb, high and low pass filters, and pretty much all of the effects in Audacity and many of the pitfalls and lessons of live recording for guitar and piano in my home studio. I am familiar with some other programs like ableton and fruity loops but live recording is my strong suit as opposed to composing music in a DAW. I rely heavily on improvisation, recording large amounts of audio and cutting it down and manipulating it in post as well as doing overdubs. I can put out a project of piano music in a month or so up to what I think is a high / acceptable standard that I personally am happy with.

      I am heavily inspired by Akira Yamaoka's work on the Silent Hill series as well as Angelo Badalamenti. I dream of composing music for games or short films, and feel like I'm ready to take on a project like that, as well as being willing to license my already existing music out which I think would be a perfect fit for the right type of horror game or anything with emotional elements.

      I am currently working on another project that will be released in December or on New Years. I will work for a reasonable amount and have done this out of passion for 5+ years because I love doing it. I feel that I have improved enough now to pursue doing something like this.

      Thank you so much to anyone who even bothers to click any of these links, and thank you for your time!

      Here are my links, and you can also email me directly at tristan.best@gmail.com

      www.soundcloud.com/domonemesis
      https://tristanb.bandcamp.com/
      https://www.facebook.com/TristanBMusic
      https://twitter.com/tbest253


      Other skills: I do all of my own cover art with digital photo editing and subsequently also have about 5 years of experience with that- photography and digital photo manipulation. I can work on marketing materials or art in this way. I play the Piano, Guitar, Synth / String piano etc, and I sing. I have close connections to some other musicians and visual artists. I will be honest if I don't think my music will work for your project or if I'm not sure if I can do something well enough, but I feel comfortable taking on some general audio design as well, including general sound / dialogue recording or noise reduction.
    • By Wolfebytes
      I am currently an undergrad several months from graduation. My major is in Game Programming and Development. During the course of my studies, we've had a few modeling classes and I really took to it and feel that is the direction I really want to go, specifically I would love to become a character artist. I keep hearing about your portfolio being super important, but I've really never been able to find out what kind of work is best to put into my portfolio. There's no "put 2 of these and 1 of those in," kind of tips. I get that I'll want to put some characters I've modeled in there, but I guess what I really want to know is, if I want my portfolio to be noticed and taken seriously for a character artist position, what is the best way to present it? Since most of my courses have dealt more with programming, I need to build everything for my modeling portfolio on the side, outside of class on my own time. I know there are no specific numbers like: put 3 realistic humans, 2 robots, a creature, and a stylistic character in your portfolio. But as a general rule is there some kind basic guideline or tips for what to make to get your portfolio off to a good start?
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!