• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Nicholas Kong

Using a Notepad in Industry to keep track of modified code

22 posts in this topic

Is that common to have a programmer have a notepad in front of him/her keep track of code that was modified (ie: list before and after code comparison, line location from the IDE)?

 

I figure if someone modifies something, there might be a chance something else might break in a different area of the program. So this would be a good way to revert the issue.

 

I never worked in the industry. I am still a CS undergraduate but I was curious about whether or not this is actually how it works in industry.

1

Share this post


Link to post
Share on other sites

Yeah use software to track changes (also called source control). I'm surprised they don't teach you about that in uni. SVN and SourceSafe are 2 I have used in the past (Git has been mentioned too, not used it).

 

I'm a firm believer in notepads though, notepads don't crash and lose your data. Best notepads are hardbound and you can't rip pages out. Always keep your old notepads. It's also best to date each entry. (Not "sexy time" date, calendar date).

 

EDIT: Biggest problem with notepads is illegible writing ;)

Edited by Paradigm Shifter
0

Share this post


Link to post
Share on other sites

There's a whole set of software tools known as version control (or "revision control") which solve this problem far more powerfully than doing it by hand.

Interesting.

0

Share this post


Link to post
Share on other sites

Yeah use software to track changes (also called source control). I'm surprised they don't teach you about that in uni. SVN and SourceSafe are 2 I have used in the past (Git has been mentioned too, not used it).

 

I'm a firm believer in notepads though, notepads don't crash and lose your data. Best notepads are hardbound and you can't rip pages out. Always keep your old notepads. It's also best to date each entry. (Not "sexy time" date, calendar date).

 

EDIT: Biggest problem with notepads is illegible writing ;)

What course do they teach about source control? I'm a CS undergraduate and I am taking 2 CS Classes this semester: Computer Architecture and Discrete Structures.

0

Share this post


Link to post
Share on other sites

 

Yeah use software to track changes (also called source control). I'm surprised they don't teach you about that in uni. SVN and SourceSafe are 2 I have used in the past (Git has been mentioned too, not used it).

 

I'm a firm believer in notepads though, notepads don't crash and lose your data. Best notepads are hardbound and you can't rip pages out. Always keep your old notepads. It's also best to date each entry. (Not "sexy time" date, calendar date).

 

EDIT: Biggest problem with notepads is illegible writing ;)

What course do they teach about source control? I'm a CS undergraduate and I am taking 2 CS Classes this semester: Computer Architecture and Discrete Structures.

 

there are usually no courses directly related to source control, however it will often be used in larger practical excercises.

 

In any case, beside git and svn you could also check out (vcs pun, yay!) perforce, which is quite commonly used in industry and free for up to 20(?) users.

0

Share this post


Link to post
Share on other sites

I'm a firm believer in notepads though, notepads don't crash and lose your data.

 

Then there's something [i]seriously[/i] wrong with the version control software you're using.

0

Share this post


Link to post
Share on other sites

 

I'm a firm believer in notepads though, notepads don't crash and lose your data.

 

Then there's something seriously wrong with the version control software you're using.

 

 

Or there is a lack of redundancy.

0

Share this post


Link to post
Share on other sites

As a solo programmer, I've found git far more useful than svn. Once you understand how it works, it's extremely easy to set up, branch off modifications, compare those changes, and merge them together. I would never dream of doing this by hand.

1

Share this post


Link to post
Share on other sites
What about Mercurial?

 

...And it begins.

 

Git vs. Mercurial: Please Relax (Git is MacGyver and Mercurial is James Bond)

The Differences Between Mercurial and Git

Git is Wesley Snipes, Mercurial is Denzel Washington

 

My honest opinion on Mercurial: To me it feels like Mercurial is just unnecessary. It does everything git does, only slower, and it's missing a few features. Plus the name "Mercurial" is unfortunate. Not catchy and doesn't "feel" good. That's just my opinion. I'm not denying Mercurial is a good VCS; quite the contrary, it does what it's designed to do and it does it well.

 

If you tell me to use Mercurial over Git, though, the reason I wouldn't switch is not because I prefer git, but because the time it would take to learn how to use Mercurial would outweigh the supposed benefit you claim it has.

 

I'll quote the first article. The bottom line is:

 

  1. Evaluate your workflow and decide which tool suits you best.
  2. Learn how to use your chosen tool as well as you possibly can.
  3. Help newbies to make the transition.
  4. Shut up about the tools you use and write some code.

 

 

Edited by TheComet
1

Share this post


Link to post
Share on other sites

Mercurial is not slow. I switched from Mercurial (also called hg if you find that more catchy) to using git, but only because there are a few corner cases where it is more flexible. The downside is git got obscure commands you need to type in with ambiguities, 2 commands for same thing and 1 command doing 3 things.

hg you can learn in a day with easy commands you can even shorten when you type them in and rarely needs extra switches. Command names also have similar meaning as in SVN if you switch from it. Turtoise hg is also nice, I think they programmed it from scratch for hg only using the pictures of Turtoise SVN.

git you need to study and google for commands and dozens of switches per command for years to come. If you used SVN first, google every command, because all got intentionally renamed and do something else if you type in the original command. Turtoise git you better not use, I think that got into live as an awkward mutation of Turtoise SVN and did not fit git well.

 

The good thing of both compared to SVN is you can easily setup a repository, have everything locally on your computer without needing constant access to a server, you can easily setup a repository on an USB stick and push from your HDD to it to have a local backup in case the HDD or the server blows up and merging (and you can additionally rebase) is so much easier.

Edited by wintertime
0

Share this post


Link to post
Share on other sites

From my college experience, maybe one or two professors touched on source control for a total of five minutes. There wasn’t a specific class for it nor was it mandated in any class to be used (or encouraged to be used at all really). It was one of those things that I learned on my own and used on my own, and mandated for the team projects that I was a part of.

 

As far as I can tell, that’s more or less the common story. You wouldn’t believe how often we get soon-to-be-new graduates coming in for interviews and they only have “vaguely” heard of source control.

 

As for notepads, I like those big yellow legal pads myself. Always have a stack of them in my drawer, and always one open beside me while working. Very useful for notes during debugging or sketching out new ideas or designs. That may range from literally diagramming something in 2D or fleshing out an algorithm in pseudo code. It’s a good habit in my opinion.

Edited by Starnick
0

Share this post


Link to post
Share on other sites

Yes, I do it all the time.  Perforce or Git don't really track that or the relationships between different files or calls.  It's easy to forget or have a hard time finding what you're looking for in perforce because it can be hard to forsee future needs.

 

I also write general notes on the files I'm working on or of interest to me, function and line numbers I'm interested in, reminders, TODO lists, math, call graphs, etc.

 

In general if you find a habit of yours is proving useful, keep doing it :)

0

Share this post


Link to post
Share on other sites

Yeah, I sometimes do write down basic class/function relations on paper, too. But often its changing fast and you could never write down all of it even for a single time.

I wish there was a tool you could feed a whole source tree in, which would then automagically generate a nice, easily customizable diagram of all classes, member and global variables, methods, functions, including different lines for inheritance, calls and bad use of public variable read/write. That is, it should go exactly backwards from the commonly told way of sinking much time into creating an UML diagram (which seem to get too coarse grained to be useful and dont include methods), then implementing it, then some changes get made and the diagram is useless.

What I saw from doxygen class diagrams feels not really useful enough to me, because I can just look at 1 to 3 header files and see the same.

0

Share this post


Link to post
Share on other sites

AFAIK, warnexus is using Java. So, based from that...

 

Eclipse has plugins for handling version control for git (EGit), Mercurial (MercurialEclipse), and so on (Subversion, CVS, etc).

 

The things you need is a: A repository (it can be local but preferably in some website, BitBucket supports Git and Mercurial, GitHub supports Git only I think), and b: The plugin. Once you have both, you can follow some tutorial to set up your repository.

 

I use Mercurial, started to use it because I wanted to have my code somewhere so I don't have to copy it back and forth between my desktop/netbook. That's a big plus, besides that you get the opportunity of commenting each commit individually, having the whole history of each file you modify, and watching your progress in a handy commit history page smile.png

Thanks for the info! rolleyes.gif Thumbs up!

0

Share this post


Link to post
Share on other sites
What course do they teach about source control?

Unfortunately many college and university courses still completely skip any lessons on important tools such as source control (for tracking changes to code as discussed in this topic), profilers (for tracking down performance issues) and debuggers (for diagnosing and fixing problems with code) or only really cover it in passing during course-work rather than formally teaching it, so there's unfortunately a good chance that you simply won't be taught about any of these things in your course.

 

I'd strongly recommend taking some time to teach yourself the basics of all of these tools to see how they can fit into and improve your development process.  Most people learn about all of these things once they're employed, but you might give yourself a leg-up in getting hired if you can learn about these things by yourself beforehand, and you'll likely find you can improve your workflow in your personal projects as well; in particular, you can save yourself a lot of time and effort by learning to properly use a debugger.

1

Share this post


Link to post
Share on other sites


I'd strongly recommend taking some time to teach yourself the basics of all of these tools to see how they can fit into and improve your development process. Most people learn about all of these things once they're employed, but you might give yourself a leg-up in getting hired if you can learn about these things by yourself beforehand, and you'll likely find you can improve your workflow in your personal projects as well; in particular, you can save yourself a lot of time and effort by learning to properly use a debugger.

 

Nice points!

0

Share this post


Link to post
Share on other sites


but you might give yourself a leg-up in getting hired if you can learn about these things by yourself beforehand

Depending on where you want to be hired, it may not make any difference.

 

The "big 10" companies seem to focus a lot more on straight CS: recursion, algorithms, data structures, object-oriented design. Things like build systems and source control vary immensely by company and team, so they expect a fairly significant ramp-up time anyway.

1

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0