Community Game

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • One of my goals when I have more time is to learn Perforce more, I have really been enjoying Git for my code, one thing about Perforce though is that if you look at the windows and linux P4V tools, they are almost completely identical, the Git-GUI tool is great on Linux, but somewhat dodgey on windows, being able to have an identical toolset on all platforms is nice as you don't have to learn how to use it more than once.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • Speaking of Perforce, I've been using Perforce in my professional work for years where i would pretty much work on projects on one place with constant network/internet connection and i love it. But one thing that annoys me is the manual checkout process that requires you to be connected. I say this because i find this a hindrance for my personal project where i work on it in different places where internet connection is, most of the time, not available. I know that you can just use the P4Sandbox or manually altering the read-only file then doing a reconcile later on but is there an easier or automatic way of doing this? Just like subversion where i can just edit any file i want and it just marks it as altered for submitting the file later on.
    • The problem with not having a manual check-out process is when you have to deal with binary files. You really need to have an exclusive check-out set up those files or it's possible for multiple people to modify the same file at the same time.

      -Rez
    • Just throwing my opinion into the ring as someone worked 2 years as a build engineer.

      I honestly see no reason why a user should ever submit build output files (exe, pdb, etc..) to source control. The only builds that should ever be submitted should an official bulid from a build machine.

      Why you ask? Because a) whats the point and b) it saves you some the headache mentioned above.

      Compilation is deterministic, meaning if 5 different people sync down to the same source control changelist and compile locally then each person will have an identical exe/pdb/whatever. Ideally, that should also apply to final assets, but that isn't always the case as anyone that has worked with a professional game engine will tell you.
    • I agree with what you're saying, as long as you have the infrastructure to support it.

      The reason you submit EXE's is because of code/data dependencies. If I make a data schema change that also requires new code and check that in, it means that the latest version of the game is broken until the build machine catches up. Designers and artists don't usually have visual studio and should never have to build the game. You generally don't need things like PDB's, but executables can be very important.

      If you have a more sophisticated build process where code & data are versioned and packaged up by the build machine, you can get around all of this. At Maxis, we don't check in any of the EXE's because we can guarantee that it's all packaged together. Designers always run "latest", which is the last code & data package the build machine published.

      -Rez
    • @ mrmike and rez

      It seems I replied too fast. What do you define as a binary file? I can't think of any binary file that a user would ever edit manually. I haven't played with everything but the only binary files I can think of in a game project would be

      a) exe/pdb/dlls...
      b) finalized asset data
      c) external tools used to create assets/finalized assets, such as Maya or Wwise
      d) temp data generated during the build process that doesn't need to be stored in source control

      Per my above post. In my opinion as a junior (definitely not senior) programmer with 2 years of experience; a,b should never be submitted to source control except by a build machine; c is either installed manually or since it is a 3rd party tool either never or rarely changes; d is temp data so it doesn't matter.

      .... You know, I might have just answered my own question. The rules you two are discussing are more important for raw assets such as image and sound and game non-finalized game package assets. Doh, don't know why that didn't click sooner, I guess since I'm a programmer and don't really concern myself with how content folks do their thing.
    • Nevertheless, your instincts are correct. Things that are automatically generated (including code) should never be checked in.

      -Rez
    • "Wrong" is such a negative term - how about simply "uninformed, but able to learn!"

      There are plenty of binary files that are considered source files - such as WAV files for audio, PSD files for two dimensional art, the mesh and animation files generated by Max/Maya, and of course DOC and XLS files that designers generate as a part of their preproduction.

      These binary files will likely outnumber text based source code in almost any game.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • So now that you guys have a team, it's time to figure out what you actually want to build and when you want to build it by.

      Any thoughts?

      -Rez
    • Yeah sorry guys, was finishing up my 6 month project, I think a 2D game would be cool to make as the scope would be alot lower and would be more feasible to finish, or a 3D game which is not to large, maybe we could stick to a genre that isn't to complex as well.

      Maybe a 2D platformer?
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • I am fine with 2D or 3D, why not even think about 2.5D?

      Do we want to make our own version of an existing game or create something new and simplistic?

      Maybe we need to define some general roles within the project? Artists, project lead, programmer etc.. Everyone can contribute to different parts but there needs to be someone in charge of certain areas to make sure the project stays within scope and on target.

      That's my thoughts at least.
    • Lets figure out the game idea first though, that way everyone can know what it is they can handle, especially for art as most of us here are programmers, for instance I can do 3D graphical art decently, but 2D I am not very good at.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • A relatively simple 2D game I think would be best. Also, I think we should make something new instead of recreating a game. Perhaps we should determine what genre and narrow it down from there?


      This has made me wonder how professional teams decide what to make. I would imagine someone comes up with a pitch and gets others on board, but have no idea really. Anyone have some enlightenment?
    • This has made me wonder how professional teams decide what to make

      Professional teams start from their exoperiece (teams, who good ant 3d person shooter, usually make new 3rd person shooter), from the command skills, and from game designer ideas. Correct me, if I wrong.

      I think, you should take some common genre, because in other case you will waste your time arguing what your gameplay will be.
      Also look at a good successfull games - most of it are clones of another games, but on other hand, they have some orogonal feature, or new graphics, or storyline.

      Examples: Deus Ex2, HoMM, Limbo (just another platformer, isn't it?), XCOM Enemy Uncknown, Dota and Dota 2, ...

      And there are my ideas for your project:

      1.
      Genre: TowerDefense
      Good analogs: Revenge of Titans. puppygames.net/revenge-of-the-titans/
      you could find it on youtube.

      Pros: You could make strong AI if someone passionate on that, or you could use just scripted pathes, if you don't.
      One level could be no larger than screen size.
      Graphics could be as good, as you like. In this type of games it not main feature.
      Physics relatiavely simple - only collision detection. No gravity.
      User Interface could be simple or very complex too.
      Tower defence could be played by keyboard, mouse, touchpad, joystick.

      2.
      Genre: Physics puzzle game
      Good analogs: World of Goo, Osmos, Little Inferno

      Pros:
      One level could be no larger than screen size.
      If someone like to work with physics - it's his chance.
      Graphics could not be very good.
      Could use mouse, touchpad, joystick.

      Cons
      Harder to make good storyline
      Harder to make game that use keyboard (if you need it)
      Simple or no any AI

      3.
      Genre: Platformer
      Good analogs: Braid, Limbo, Mario etc.

      Pros:
      Could use simple or complex physics.
      Graphics could not be very good.
      Could use mouse, joystick.
      Could have a great storyline

      Cons.
      Harder to use touchpad or mouse.
      Simple or no any AI.
      Big levels (commonly)

      The post was edited 2 times, last by andjey ().

    • Tower defense would be cool, I know it isn't anything new but maybe we could give an interesting take on the genre.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • Sounds like it's a Tower Defense game. :)

      Next step: Blue-sky design. Start tossing out game design ideas. Someone should probably step in as the project lead and start up a google docs page. You can refine the core design of the game and figure out who is going to do each part.

      -Rez
    • Ok.

      There is project folder LINK
      By now, every person, who has the link could edit documents in it.

      There THE TEAM. You could add short info about yourself - any info you are consider necessary.

      And there IDEAS. You could add every good or bad ideas you think fit this game.

      The post was edited 2 times, last by andjey ().