Announcement

Collapse
No announcement yet.

How do I become my a modmaker?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • How do I become my a modmaker?

    I've been playing games forever, but I think its time I move on to something bigger, and after seing such a great mod as Alien Swarm I just HAVE to become a modmaker myself (the inspiration is overhelming).
    Question is, where do I start?

    What programs did/do BlackCat use for AS?
    What other programs is there that other modders use?
    What skills must I have? (C++?, Turbo Pascal?, drivers license?, etc..)
    How does a team of modders work together, how do they piece things together?

    I want to know everything there is to know about modmaking.
    I found an excellent page that explained the tools used to mod AVP 2 (http://www.planetavp.com/modmaker/index.html) but as that game is too old I rather stick to a game like UT2004 or Far Cry.

    I'll will probably not find the ultimate guide to modmaking, maybe not even find enough info to get me started, but I feel I just have to ask

    (I'm 25 years old, and I'm actually starting to feel an urge to go back to school and study computerprogramming for games )

  • #2
    Mod making and game design are a large field, with many different skills to learn, so it depends what part you want to go into. I advise that you learn useful programs and build on any existing skills you might have:

    2D Art:
    Photoshop
    Paint Shop Pro

    3D Art:
    3D Studio Max
    Maya
    Lightwave

    Coding:
    UnrealEd
    WOTGreal.
    (UEngine tools - I know very little about programming)

    Sound:
    Sound Forge (Effects)
    Cubase (Music)

    Level Design:
    UnrealEd (Ships with some Unreal engine powered games but not others. Quake uses Radiant, you can also edit Lithtech (No One Lives Forever) but AFAIK it's not particularly user friendly or well supported).

    (There are many more, but those are the prgrams I either use or know of).

    Level design is where all of the above are put together. I went into it primarily because I'd always been interested in interior design and architecture. I've been using UnreaEd for about five yers now, and it took four of those for me to improve my skills and finally find Black Cat Games, a good, professionally run mod team that I'm proud to be a part of. During those first four years I was releasing maps of doubtful merit into obscurity and had variously joined, led and left apathetic mod teams.

    Beyond the above skills is that of "good game design". Level design can give a good grounding in that if you choose to evaluate the gameplay of your maps critically, but quite honestly it seems to be a skill that comes much later - in level design you're dealing with everything from game mechanics to aesthetics and engine limitations. I daren't even attempt to define "good game design" because it's fraught with subjective difficulties.

    Perseverance is vital. My first map was a big pile of poo that had potential. My second, third, and fourth maps were also big piles of poo, with even less potential. It took me eight releases before I'd put out a map I was actually happy with, and even so I look at it now and see things I'd like to change. Each of those releases was something I toiled over for weeks or months, and behind them were also many more elaborate, experimental maps that were made solely to teach myself new things.

    A mapper named Ulukai once said somewhere that being a good level designer involves persevering with projects to completion, even when you're sick of them. It's true. Lots of people persistently release total rubbish, and it takes effort to stand out.

    Finding, tracking and fixing bugs can be very tiresome, and you will see a lot of people making substandard releases and saying "I can't be bothered to fix that". Ignorance is fine and fixable, laziness is pathetic.

    If you do make anything, release a beta version first and get people to test it and report bugs. Then release a second beta after fixing the first lot of bugs and ask for more feedback. Then another, and another, until it's so polished you can release a final. Finding good beta testers can be a challenge. Some communities will be full of people who can be critical and constructive (I found the Thievery community truly magnificent for this), whereas others are rammed full of people who will brown-nose you. Avoid the latter like plague, because they breed complacency and egotism.

    Finally, if you volunteer to be a part of a team, remember just what you are - a volunteer. Noone can really tell you what to do if you haven't promised it, and as long as you let your yes mean yes and your no mean no, people worth knowing will respect you. Some teams are full of people who promise the world and produce nothing but excuses.

    Ideas are cheap, everybody has them. Becoming too attached to them will ultimately sap your joy. Some teams are led by people who attempt to make others realise their ideas, just so. In such environments motivation usually drops and work ceases to be creative, instead becoming a tedious excercise in filling quotas. Keep it fun for yourself, and if you're working with others keep it fun for them.

    If you do want to use the Unreal Engine, the video tutorials at http://www.3dbuzz.com are a good starting point for many relevant programs.
    Last edited by Nachimir; 5 Jun 2004, 11:06 PM.

    Comment


    • #3
      I started a HL Mod that got very close to completion... unfortunatly, vital tweaking was lost as members fell out due to various reasons, and the project failed

      Here's my tips:
      1) Learn SOMETHING about editing your game: what languange it's in, how to map for it, etc. and learn as much as you can yourself. If you are the leader, you'll probably do a little of everything. Also, if you can onlt do ONE thing, people may not respect and follow you.
      2) My trick for recruiting was this- build a small part of the mod yourself. A map, some concept art (works well), and post on a FEW forums- post on too many and people who travel various forums will catch on to you. Gather a fairly diverse team of specialists and generalists. ALWAYS have at least one member who has modded before.
      3) As soon as possible, get a functional prototype. Recompile changes into the game as often as you see fit, and if the game 'breaks', fix it THEN. Every day the game isn't working, you're losing a lot more time than you think you are.
      4) Once you feel that if someone were to look over your shoulder as you were playing and say "Hey, what's that? That's kinda cool", start advertising a little. A few more forum posts, redirect people to your website and perhaps pick up another member or so.

      I should note that just like in AS, more members is not always better. Lots of people begin to get in each other's way, and coordination becomes more time-consuming than actual progress. Remember, CS was made by just one guy (in the very beginning).

      5) Keep a even, steady flow of work going. Always make sure that all members' ideals are being considered and implemented.

      OF COURSE, this is all for casual mods. More professional mods (Desert Combat, Red October) follow a much different set of rules that I know nothing about. Also remember that CS started out as a casual mod.

      *Sigh* Great, now I want to get back into modding. If anyone cares, I'm fairly fluent in Java, C++, and am unemployed so I can put a LOT of time into a project. :p

      EDIT: Ok, Nachimir beat me to it :p . As 'his' team actually produced something, I'd have to think that he knows better than I. My team got a playable beta with a resonable following for about 3 months before our player base dried up , so that's where my post is coming from.
      Last edited by Evilreaver; 5 Jun 2004, 11:18 PM.
      Grunt: How dangerous can parasites be?
      Grunt has been infested with a parasite!
      Grunt: Oh, I thought I could step on them.

      Comment


      • #4
        Cool, thanks for the great answers

        About C++ (and other "languages"), do all coders study three years at school or longer, or do some learn by books at home? (How deep have you got to go to become a programmer)
        I did study Turbo Pascal one term, witch I found to be a verry easy language *do you call it "language in" english?* to learn, but as I've seen most things are used in C++ nowadays, witch differs a bit from Pascal.

        I did make my own map to Unreal Tournament 2003, I loved the editor, but as you said, the map was total shit

        Comment


        • #5
          Programming language it is.

          I started with some "learn C++ in 30 days" book and I've had no problems since (and done some OpenGL and DirectX programming too). Learn the basics: structures, loops, encapsulation etc. and you're fine. However, studying these things in schools makes you understand why you do things the way they are taught in books and that's where it gets interesting.

          The key to programming is not knowing and memorizing all the gimmics of a language, but knowing where to look for the information you need. No-one really memorizes sorting algorithms (for example) but instead they look it up somwhere and the rest is a copy-paste job. Api documentation and Google are your friends.

          Comment


          • #6
            I don't think Pascal is used for anything but small home hobby projects. I'm afraid it's a tad outdated.

            But programming is more than just learning a language. Once you know how to program effectively in, let's say, Java, learning a similair language like C isn't that difficult. I learned Java in school, then had a brief encounter with C and learned Visual Basic myself to improve on the Access projects I had to do.

            One of the most important things is to produce clean, easy to read code with comments in it, especially in larger pieces of code. You can always look up a command if you don't know it.

            Comment


            • #7
              Originally posted by [CoFR]Jacq
              Programming language it is.
              The key to programming is not knowing and memorizing all the gimmics of a language, but knowing where to look for the information you need.
              *COUGH* MSDN

              Comment

              Working...
              X