Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm currently working on a new project, and I would like to publish it as Open-Source...
The project consists in a server and a client created to emulate a famous 2d game...
There are already 2 or 3 some other projects of this type (Open-Source), but you all know in these days people have the habit to rename the work of other people and publish it under their name etc, so now there are hundreds of renamed versions of the SAME project!...
I already tought about GPL, but also the other projects where under it, and other people just renamed it published without having any problem...
So, I'm currently searching for a way to insert some "default" strings about project name, authors etc in the sources, so that stealers/rippers etc can't just rename the project and maybe sell it etc... So, i was thinking about an external dll that should contains these info and that should print them as console output when server starts, but sincerely, I don't think it's possible (to invoke some methods, in this case the console class of the summoner from the invoked object)...
But if it's possibile, any of you knows how?
And maybe, some of you know other ways to do what I said above (protect from renaming a project) in Open-Source projects?
Thanks for reading and for your answers
You can't "protect your code". By going GPL, you can have legal standing to sue anyone who infringes on the copyright licensing, but you can't do much else.
Maybe if your product was good enough, people would use your version above others. I don't quite think you understand that in true opensource, your original work is destroyed, and something better is produced. If you can't handle this, don't release your source at all.
I don't think you can do that and still be truly open source.
The open source definition dictates that
The license must allow modifications
and derived works, and must allow them
to be distributed under the same terms
as the license of the original
software.
I can't see how you can restrict modification of any aspect of the code (such as strings in the code like a name) and comply.
So you are looking for a non-open-source license. If your primary interest is to be credited, maybe look at Creative Commons Attribution?
Why not just provide the project under a license that prevents this?
That being said, project forking is one of the core, fundamental freedoms that are provided by many open source licenses. Using a license or a mechanism to try to avoid this may impact your acceptance by the community.
The GNU Free Documentation License might be able to do kind of what you're asking for here. At the very least, it requires more thorough change logging for re-distributors. You might even be able to declare the title an "invariant section", though you'd probably need to talk to a lawyer about that, since a lot of the language of the GFDL is specifically about changing the title. They certainly didn't intend for the title page to be an invariant section.
A big part of the trouble is that typically open-source licenses require people to change the title when they fork the code -- so their changes don't appear to be yours. I've never heard of anyone wanting forks to be required to keep the same title. I can't imagine why you'd want this. Even easier than improving your program, they could make changes to make it absolutely terrible, and they'd still be required to keep the same name. (And what happens if they want to re-use just part of it? How much of the original program is required, in order to keep the same name? I don't think this rabbit hole has an end...)
Even if you survive all of that, the GFDL is not designed for source code. It's not GNU GPL compatible. It may not meet the OSI Definition, and it's certainly not DFSG compliant. You'll probably piss off far more potential contributors than you will gain by preventing renaming. I can't think of any upsides to releasing source code under such a license. The restrictions are so strange that programmers wouldn't bother trying to figure it out.
So, I'm currently searching for a way to insert some "default" strings about project name, authors etc in the sources, so that stealers/rippers etc can't just rename the project and maybe sell it etc
How exactly is that different from selling it under the original name? To release something as open-source is to invite people to try to sell it. If they remove your name from the AUTHORS file or pretend that they wrote it, go after them for copyright violation, same as any other composition.
Related
I am working on a C# project and have two programmers to help me on parts of the project. The problem is that I don't trust these programmers as they are joining recently and need to protect my company's property.
I need to hide some parts of the code from the two programmers so they don't see it and they should still be able to work on their parts and run the full application to test it.
Is there such thing ? :)
Know a few things:
You Can't Hide Code Users Compile Against.
C# makes it incredibly easy to see what you're compiling against, but this is actually true for all programming languages: if they are required to compile it, compile against a dll, or they can run it, either as a DLL or as raw C#, they can get access to the logic behind it. There's no way around that. If the computer can run the program and it all resides on your PC, then the human can look it over and learn how to do it too.
HOWEVER! You can design your program in such a way that they don't need to compile against it.
Use Interfaces.
Make the code that the other employees must write a plug-in. Have them write their code as an entirely separate project to an interface that the core part of your API loads dynamically at run time.
Take a look at The Managed Extensibility Framework for a tool to do this.
Use Web or Remote Services.
Components of particular secrecy can be abstracted away so the details of how it works can be hidden and then invoked via a web call. This only works in situations where the core details you want to protect are not time sensitive. This also doesn't protect the idea behind the feature: the employee will need to understand it's purpose to be able to use it, and that alone is enough to rebuild it from scratch.
Build Trust Through Code Reviews.
If you don't currently trust your employees, you need to develop it. You will not be able to know everything that everyone does always. This is a key skill in not just programming, but life. If you feel that you can't ever trust them, then you either need to hire new employees that you can trust, or build trust in them.
One way to build trust in their capabilities is through code reviews. First, make sure you're using a version control system that allows for easy branching. If you aren't, switch immediately to Mercurial*. Have an "integration" area and individual development areas, usually through cloned branches or named branches. Before they commit code, get together with the employee and review the changes. If you're happy with them, then have them commit it. This will consume a little bit of time on each commit, but if you do quick iterations on changes, then the reviews will also be quick.
Build Trust Through Camaraderie.
If you don't trust your employees, chances are they won't trust you either. Mutual distrust will not breed loyalty. Without loyalty, you have no protection. If they have access to your repository, and you don't trust them, there's a good chance they can get at the code you want anyway with a little bit of effort.
Most people are honest most of the time. Work with them. Learn about them. If one turns out to be working for a hostile entity, they've probably already obtained what they wanted to get and you're screwed anyway. If one turns out to be a pathological liar or incompetent, replace them immediately. Neither of these issues will be saved by "protecting" your code from their eyes.
Perform Background Checks.
A further way to improve trust in your employee, from a security standpoint, is a background check. A couple hundred bucks and a few days, and you can find out all sorts of information about them. If you're ready to hide code from them, and you're the employer, you might as well do due diligence before they steal the secrets to the universe.
Your Code is Not That Important.
I hate to break it to you, but there's almost a 100% chance that your code is not special. Trying to protect it through obscurity is a waste of time and a known, poor, protection method.
Good luck!
**Why Mercurial? Just because it's one option that's easy to get started with. Feel free to use any other, like Git, if it suits your fancy. Which one you use is entirely besides the point and irrelevant to this overall discussion.*
You can't do it,
Even if you only give them a DLL with your code, they can extract the code with reflection tools, e.g. reflector.
Keep a separate backup and submit dummy placeholders to source control.
The complicated way: set up an application server with VS2010 and all the files they need, lock everything down so they cannot access any files directly and can only run VS2010 and the built application, and provide only DLLs for the protected code.
Theoretically, they would be able to work on the code they need to but would never have direct access to the DLLs, nor would they have the ability to install or use a tool such as .NET Reflector to disassemble the files... might still be some holes you'd need to look for though.
The right way: Hire trustworthy programmers. ;)
Put your code into a DLL and use Dotfuscator to obfuscate the internal workings.
The only way I can see is to give them compiled and obfuscated assemblies to reference. Because you can only obfuscate private members you may possibly need to modify your code so that public methods do not do much if anything at all. If there is any interesting code in a public method you should rearrange your code like this:
public bool ProcessSomething()
{
return this.DoProcessSomething();
}
private bool DoProcessSomething()
{
// your code
}
Even obfuscator that comes free with VS will do some job to make it non-trivial to look into your code. If you require more protection you need better obfuscator of course.
But in the long run it is impractical and sends bad signals to those developers telling that you do not trust them. There can be nothing good coming out of this. If you're not the boss (or owner of the code) I would not worry that much - after all it's not your property. You can talk to your boss to express your concerns. If you are the boss you should have not employed people you do not trust in the first place.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
A little bit of Background first:
I have been using Team Foundation Server for about few months and know pretty much how to use it. I have been using it for my project on Codeplex. They required TFS and it was in my Visual Studio Installations, so basically I never knew what all it took to get it to work as it seamlessly worked inside Visual Studio and I just had to do Check In and Check Out stuff...
But now I wanted to see what other Alternatives were available and first installed Mercurial command line (which I never used), then searched for a GUI alternative and installed TortoiseHg and followed instruction from documentation on its Website. Then it said to install a 3 way Diff tool... I searched for it and then Found TortoiseSVN; I thought it must be some plugin or something so I searched SO for questions related to my situation when I stumbled upon this SO Question and was pretty mesmerized by so many tools for different work.
Now:
Can somebody explain what all tools are for source control. Do I have to install a different tool for every different task. Isn't there any single package for all of them. And basically what are the tasks we perform in Source Controlling. I only know Check In, Check Out and checking difference from Codeplex Website. What else should I know.
Does every website like Git, BitBucket, etc use different Tortoise (xxx) for their source control.
Are Source Control and Version Control different terms
Please help..
This is a huge topic and will be impossible to provide a single all-encompassing answer. Nonetheless here are a few thoughts, assuming you are looking for more of a Software Configuration Management solution rather than a simple Revision Control System type approach:
Release Management:
In addition to concurrency control (check-in, check-out, etc.) your SCM can/should also provide history, tagging, branching, and other release management type capabilities. That is, it should always provide a single source of truth as to what source files when into which release, service packs, etc. In order to do this, your build environment needs to be well integrated into your SCM.
WIP Management:
A good SCM system will allow to you compare your work-in-progress to the latest checked in revision. It should also let you revert your WIP, shelve it temporarily, or merge another's changes on a file by file basis.
Documentation & Training
Do not underestimate how important it is to use a tool that can give you a ton of help, books, documentation, community support, and even paid support if needed. Also selecting a "popular" tool can mean that some new developers have one less thing to learn.
Continuous Integration:
Automated builds are a must for any serious organization and you should pick an SCM that can be access by your build systems (e.g. Hudson, CruiseControl, Bamboo, etc.)
Security
The SCM system should have a built in authentication system and also be able to use outside authentication providers as many organizations change over time. In addition, it should be able to support developers working outside the firewall, preferrably over http.
IDE and Build Tool Integration
To make all this stuff easier your SCM must be able to be seamlessly linked into your development system and any command line tools you use. This fact is made easier by the fact that almost all non-Microsoft IDE's support all SCM tools.
Source Browsing
Most SCM tools that I've seen have a number of very high quality, third party browsers such as Fisheye. So I discount this as a differentiating factor.
So which tool to use?
If your organization is fairly well contained within your company then pick Subversion. It is very popular, integrates with every IDE/OS/Build tool, works with ToroiseSVN, supports all platforms, supports multiple protocols, several UI, a powerful command line, a huge community, is free, and is rock solid. It also has an excellent free book.
If you have a highly distributed development group and/or expect to receive open-source contributions from many different folks, go with the distributed capabilities of Git.
Beyond these two, save yourself a ton of time and hassle and forget everything else....really. I realize I am being opinionated, but you kinda asked for an opinion.
If I was to advise something to you, it would be
Use mercurial (aka hg), and start by
learning it in the command line. That
way you will learn all basic concepts,
which could be somewhat hidden from
you when using only GUI overlay such
as TortoiseHG. All with a good
simplistic tutorial of course, perhaps
widely known hginit which covers
some simple usage scenarios.
That would be answer to "What else should I know" part, at least for a start. You can then explore by yourself, having a limited, but somewhat solid base. Or, at least, you will be able to ask more concise questions to learn more, or make more sense of the SO question you quote. Your question is somewhat broader than this, of course, but I would advise not to try to grasp everything at once. Each system has it's own quirks and specialties, but you shouldn't be worried by that fact now. Just as with programming -- you should not try to learn many languages at once, if you don't know any yet.
Ah, and as a finishing touch: Tortoise(xxx) is not exactly a revision control system, thats just a typical name for a shell-integrated Windows client to system xxx. As far as I'm concerned, the "Tortoise" part refers to "shell".
PS. the "Mercurial" advice is due to my personal taste of course, but also by the feeling that learning Hg will enable you to grasp most of the ideas from other systems quite easy (if you ever need to).
From my personal experience I would recommend looking at the new generation of 'Source Control Systems' that are called Distributed Version Control Systems. These are systems like Git (and I think Mercurial but I haven't used that.) that actaully store a full version control system locally and when you commit to the remote repository (push in git terms) you push the changes in your local version control system to the master version control system on the server.
Also Git is designed to make Branching a breeze. In systems like Subversion branching is not as easy but with Git Branching is the recommended practice of making changes. I have used Git, Subversion (SVN) and SourceSafe(the worst Source control System of the three by far!) and this is the major advantage of Git over more traditional Source Control Systems.
For Example if you are fixing a bug or adding a feature in a code base that uses SVN the standard practice would be to
Check out the branch you are going to work in.
Make any bug fixes and test them.
Checkin the changes.
With Git or Similar systems you would
Branch the master branch locally (i.e. development, producton version 1.1, etc.).
Make any bug fixes and test in your locally branched version (i.e. you made a jira-123-bugfix branch for version 1.1).
Merge the branch back into your local copy of the master branch that you created it from and make sure everything is OK.
Then push the changes you made to your local copy of the master branch to the central Git repository.
The advantage of this is that if you have to go back and revist the bug fix you still have your local copy of that branch.
See articles like A Successful Git Branching Model for more info.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've just inherited a large project previously coded by about 4-5 people. The documentation consists of comments, and is not very well written. I have to get up to date on this project. How do I start? It consists of many different source files. Do you just dig in? Are there tools that can help visualize the structure/flow?
If you have a chance, I'd try and talk to the original designers and developers. Ask them about any major design issues or shortcomings of the project. Is the project in good shape and only needs maintenance or are there major components that need to be added or reworked? What are going to be the biggest roadblocks to maintaining the project? Take one or two of them to lunch (separately) if you have a budget for it as they might be more free to talk about problems outside of the office.
Talking to the users is also important for getting a feel for the current status of the project. Quite often they have a different opinion of how things stand then the developers do. Make sure, however, that they don't start giving you a list of all the things they want added or changed - you should take a few weeks to understand the project before you can start making major changes to it.
As for visualization tools, I'd start with the database design if there is a database involved. Tools like Microsoft Visio can create a diagram from an existing database. I find knowing the design of the database helps me wrap my head around what the programmers were trying to accomplish. Visio is also good for documenting program flow with some basic flowcharts though you'll have to create them yourself - it doesn't generate them automatically as far as I know.
Good luck.
I would encourage you to buy and read this book thoroughly. It provides you a LOT of information in this regard, much more than you will find here.
Brainstorming a little for you:
Step around in the application with a debugger, use a Static Code Analysis tool for which ever language you are working with...
Talk with people - both developers AND USERS to get a feel of the application.
Review the issue tracking system to see if you can see any recurring types of problem...
Are there tools that can help
visualize the structure/flow?
The latest Visual Studio 2010 allows you to generate architecture diagrams.
http://ajdotnet.wordpress.com/2009/03/29/visual-studio-2010-architecture-edition/
Try to find the starting point of the system and start digging from there. It sort of sucks to be in that situation, and chances are the comments might not be that helpful either. If the original developers didn't bother (or didn't have the chance) to document, chances are they never kept the comments up to date with code changes.
So time to bring the shovel... but don't just dig in blindly. One thing that is important is to understand what the system does from a users' perspective.
Concurrent with your code digging, you need to meet with a user (or the users' liason) and have him walk through the system, showing you how it is supposed to be used, for what purpose and what it and its subsystems are supposed to do. Moreover, attempt to understand what are the business pre-conditions and post-conditions of each major operation performed with this system.
Then map (or do a hierarchical) chart of the main functions of the system; classify them by category, purpose or module. If the system performs some sort of work flows or business transactions, attempt to chart some sort of state/transition diagram documenting each (and cross-referencing each state/transition to the subsystem or module in the system that is in charge for it.)
Once you have that, you can dig according to function. It will be best if you dig for a specific purpose, say, there is a bug fix to implement. You locate the logical module or category pertaining to that bug fix, you have the pre-conditions and post-conditions; then you can dig precisely on (or around) that bug fix.
If you just dig in without a guide (at least a high level one), you can be digging for months without getting anywhere (I'm telling you from painful experience.)
If there is no user manual, implement a draft according to your meetings with the users/users' liason. That could serve as a guide for implementing a developer's/administrator's manual for the system you just inherited (if there is ever a chance to implement one.)
If code is not on source control, put it on it. Doesn't matter what SCS you pick (could even be CVS, yuck!) What matters is to put it under source control asap.
Those developers didn't exist in a vacuum, they must have had exchanged emails. Identify other tech liasons they work with. Attempt to identify what other systems, if any, this system interfaces to (.ie. your databases, other's peoples databases, cron jobs, etc.)
But this could come at a later time. I think you should, for starters, focus on understanding how to use the system and what it is for. Let's call it understanding its business/knowledge architecture. Then dig according to that... or better yet, according to that and with the purpose of fixing a bug.
Good luck.
Use Profiler to see main functions and events in your project (the fastest way to learn framework)
Learn business logic very well to better understand the code
Documenting every new thing you learn - setup wiki (you will be surprised how quickly things are forgotten)
You can use Visio to draw Database Model Diagrams. (keep them close to you while studying the code)
These are the things that helped me when I inherited the previous project (50+ developers, 70+ GB database, 1 GB of source code and not even a single line of comments in code (maybe few :), and everything written in foreign language )
Use the debugger to walk through the application. That will let you go both deep and wide. You'll also be able to learn about how the code handles specific scenarios.
When you're ready to change something as #Jaxidian said, Working Effectively with Legacy Code is a great resource.
I was recently in a similar situation. What helped in my case was focusing on the changes I needed to perform on the project, and in the process of making those changes I learned about how the project is structured and so on. Sure, the first few tasks took a bit longer, but look on the bright side: I got stuff done and I got familiar with the project at the same time.
I'd suggest two things that may help:
Be productivity-driven. In other words, find a change that needs doing and use this to learn how that bit of the system works. Your changes may not be the most elegant without a whole-picture understanding of the software, but you will get work done within days/weeks.
Follow things from the user-interface. I.e if a change involves things a user does on a dialog, find that dialog in the code (relatively easy) and then work backwards to see what bits of the code provide data to the dialog, how the dialog interacts with the system, etc. Trying to find "where does X happen in the code" is very hard without good documentation, but finding "where is the code relating to this dialog" is quite easy and gives you an entry-point into the code.
Whenever I start a new project, I spend 2-3 days skim reading the code and making notes. I basically go through the entire solution from top to bottom and make a map in a text editor of each (significant) class in each project and what it appears to do.
The aim in doing this is not to completely understand the entire codebase, so don't worry if you feel you are not getting your head around it completely. The aim is that you end up with an index of where to go when you need to start on your first piece of work. You should also end up with a cursory picture of the solution in the back of your brain that will get filled in over the next couple of months. I always do this on the first few days as your superiors will not expect you to be productive during this time and you may never get another opportunity where you have the time to do so.
Also, do not rely on code comments for direction. Even with the best intentions they are often unmaintained and may lead to incorrect conclusions about what a class or section of code may do: a comment may lie but the code always tells the truth.
If you already have a team, you could charge each with a part of framework, and the result of their exploration should be registered somewhere, like a wiki. After that, give to each a task similar to something which is already done in the system (from the functional point of view)
For example: if a list of products is displayed in your app, you could display a list of orders (the complexity should be approximately the same), in the same manner it's done actually in the app. Than make it more interesting: try to edit it and save into DB.
Than switch the tasks and let the questions appear and than the first person who made the same task will show & explain how things are done.
Like that you'll see how the things are done pretty easy + your team will be up to date with this knowledge.
Presuming there is a database, start with the data model. Somewhere (Mythical Man-Month?) it was written "if I have your tables, I don't need to see your code."
Regarding potential tools, you may want to look into NDepend. It is a code-analysis tool, with an emphasis on highlighting the internal organization and dependencies of the code base (see this post for typical outputs), and spotting code quality issues. I have not used it personally, but Patrick Smacchia, one of the developers of the product, has a few posts where he applies NDepend to some classic apps (here is NUnit for instance) and discusses what it means, and I found them interesting.
Go and speak to the users or, read the manual and / or if one exists, go on a training course for the system (internal training departments will sometimes have put them together if there are lots of users).
If you don't know what it's meant to be doing then the chances of you being able to work out how it does it are close to zero.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I want to design a 2D game idea with C#/XNA. Between school, project inexperience, limited resources, and other things that may cause me to bail on the project I am going to try to plan it out before I jump in:
What are some key aspects you've noticed in a successful personal project?
How did you (successfully) draw revenue the project (besides asking for donations)?
(Note: this is not the main purpose of my project but would be nice!)
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
How do you bring an abstract idea of a game and making into a real product. What tools do you use in your sketching and planning?
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
What are some key aspects you've noticed in a successful personal project?
I suppose this largely depends on your definition of success. I consider a game project successful if:
It's fun. Enough that I want to play it after I've finished.
I learn something in the process of making it.
I actually complete the project, where complete is defined as having art, audio, and any other assets adequate for the style of game that I'm making.
It works under 'field conditions', rather than simply on my own machine/hardware configuration.
In my case, every project that I've considered successful has been one that I've done some serious planning on and committed to seeing through to completion. That's the biggest step for me to get past. A casual project that is the product of a bored weekend usually won't get finished.
How did you (successfully) draw revenue the project (besides asking for donations)? (Note: this is not the main purpose of my project but would be nice!)
Heh. Haven't managed this yet. But then, that hasn't been a concern of mine enough to do the work required to support it. Someone already mentioned the potential revenue from XBLA for XNA projects, which is a very easy avenue to success if your project is the sort of thing that translates well to the console. I've looked into it, but it isn't really appropriate for my projects so far.
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
Pen. And paper. I draw a lot of screenshots as guides and I'll usually have some kind of artistic theme in mind to go along with the gameplay. Rapid prototypes help here too; everything from making mockups of menus and various screens in a drawing program to making some simple interactive stuff in a throwaway project.
Write everything down. I take lots of notes and I've been known to have a laptop with notepad open on it sitting next to my development machine, to save me the trouble of alt-tabbing away from my code to type a quick note on what I'm doing. Some great ideas come out of the process of trying to make other things work and if you don't write it down, it didn't happen.
How do you bring an abstract idea of a game and making into a real product. What tools do you use in your sketching and planning?
Work iteratively as much as possible. I hate to sound cliche, but the whole agile model works really well for games. Start with that core 'fun' idea you have that inspired you to make a game in the first place and get that working in code. Maybe it's a single mechanic that you want to build puzzles/levels around or maybe it's more of a look/feel that you can capture in a single environment/level/whatever. Either way, if you can get a single example of it working right, it becomes a good check on whether the idea is actually viable and will likely give you some ideas of the different ways it can be implemented. That might seem kind of vague, but more specific advice would depend on any number of other factors (your choice of genre, audience, the specific ideas you have in mind, etc.).
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Peter Molyneux of Lionhead has said that he used to prototype all of his games with ascii art. If they were fun with that limited level of graphics, then they were worth continuing. While you might not be able to get that simple with some genres (and an ascii 3d shooter might be novel for it's own sake...), certainly worrying about finished art, audio, or other assets is something that can be saved for much later. In the end, if the game is fun to play, then getting an artist willing to work with you becomes a lot more trivial. I have, on many occasions, used copyrighted assets during my prototyping phase when I just couldn't stand to look at my own art any longer. Just be sure that you have anything like that replaced before you start distributing your project...
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
Not sure exactly what you're thinking about here, but breaking barriers is what writing code is all about really. You're finding creative solutions to interesting problems. The web is a great resource for general knowledge, but in the end, it's your own time and perseverance that will create something interesting.
Best of luck.
What are some key aspects you've noticed in a successful personal project?
Don't worry about how it will turn out
Do it for fun
Don't plan it
Start small, don't think big
Actually code instead of procrastinating on so or other similar sites
If you want somebody else to use this game, make it non personal. Get somebody else who you can give demos to and get feedback from. Make the game very very simple. Build that first before moving onto something very simple. Then go for simple!
not sure :)
Plan with pen and paper sketches for window layouts and game flow. For look and feel, browse the web for slick looking sites you can take inspiration from.
Use notepad, and write the shortest list of things that need doing to make the simplest working demo. Only work on the things you wrote down otherwise you can get carried away on some detail and end up not producing anything useful.
Art is an important part of a game, and you can't have a finished product without it. How about searching the web for a collaborator who'd be interested in doing it for you.
If your stuck with something in your code, ask for help on StackOverflow! :)
Key aspects: Primarily, something that you are excited about. Make a game that REALLY gets you going, and you'll be motivated by your desire to share the finished product with others -- your end product's quality will probably be improved by your passion, as well.
Profitability: Well, since this is XNA and all, if you release a version on Xbox Live, you will earn 70% of the sales revenue that your game earns. Games can be priced for 200, 400, or 800 points (roughly $2.50-$10).
UI/Usability: For this, I typically go through a lot of playability testing...booting it up, seeing how things "feel," then tweaking things if they just don't feel right. I came across a lot of things that I never really thought about before (fade-ins/fade-outs for menus, repeat rates for keys, and so forth), and play-testing is one of the more effective ways that I've been able to identify issues like that. If you've got friends, you can ask them to give you feedback as well.
Planning Tools: Truthfully, I just make a list of the things that I want to include in the overall game concept, then slowly get more granular as I iron out more and more of the fine details. Certain ideas inevitably change after playtesting may reveal them to not be as fun as you had imagined they would be, of course. I haven't ever seen a huge need for any formal tools for this process, though, but I will give the disclaimer that all of my projects have been fairly small in scope and have not been professional-sized undertakings or anything.
Art: This may not always be an option for you, but I have a few friends online that are gifted with art skills -- I solicited interest, and got some volunteers. I presented the option to earn a cut of whatever royalties may come in, but most of them were happy with an attribution in the credits and a chance to see their work in a game that's playable by people all over the world. Regarding small things (icons, etc), stock/royalty-free art can do the job in certain cases, too, but I wouldn't recommend relying on it.
Breaking Barriers: Not sure what's quite meant by this question, but generally speaking if I've come up against some sort of unforeseen issue (technical/implementation challenge,
gameplay-related, or what-have-you), I'm able to either solve the problem or come up with a suitable work-around if I put my mind to it for long enough. Did you mean something else by this?
Some great thoughts given in these articles:
http://www.flatredball.com/frb/docs/index.php?title=Tips_for_Completing_an_Independent_Project
http://makeitbigingames.com/2006/06/five-realistic-steps-to-starting-a-game-development-company/
http://makeitbigingames.com/2006/02/five-foundational-steps-to-surviving-as-a-game-developer/
First of all - I know universities don't tend to teach this but you really must do it... get source control going. I would suggest installing TortoiseSvn from here: http://tortoisesvn.net/downloads
With TortoiseSvn (a subversion client) - you can create a repository on your USB Flash Drive and carry it around with you, so you always have a copy of your project files. More importantly you can have more confidence when you make changes - because it keeps a history of the changes you've made. So if you break something, you can revert to the most up to date version on your usb flash drive... or even an earlier version if you wish. It also provides ways of showing differences between file revisions, all from the explorer shell extension.
For a personal project the key thing is to keep motivated. You keep motivated by setting yourself attainable tasks. Aim for something attainable. Always make sure you can build your project. Concentrate on adding new functionality while keeping the old stuff still working rather than building up huge nicely designed framework that might end up going no where. If you write your code well, you can refactor and abstract later after you figured out what game it is you actually want to build.
I would advocate a todo list of some kind... something like the spreadsheet found here on Joels site: http://www.joelonsoftware.com/articles/fog0000000245.html
If you want to get fancy, I would suggest something like Trac: http://trac.edgewall.org/
Trac is a wiki, to-do / bug list and repository viewer all in one. If you get someone else working with you on a project, collaboration with source control and a shared wiki becomes more useful. It's also good to work with others... you can keep each other motivated.
The Wolf fire blog recently had some interesting design ideas and cited serval sources here: http://blog.wolfire.com/2009/02/design-principles-from-tufte/
As for getting money, others have already covered the community games thing.
Art assets - there are a few places to find these. Scout the forums at www.gamedev.net. Def look at this blog here for some excellent art (and game design ideas) http://lostgarden.com/
Others have suggested keeping tools simple - I would agree. The simplier and more accessible things are when it comes to project planning, prototyping and design - the more likely you are to use them. As long as you can communicate with yourself when you revisit something... or other people when collaborating, it's a good tool. Set yourself attainable goals, and get on with it :-)
What are some key aspects you've noticed in a successful personal project? Focus on something that actually works.
How did you (successfully) draw revenue the project (besides asking for donations)? Not directly. However, skills get you a job. Build skills.
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
Build the inside -- the core data model first. If the data model works, everything else is far simpler.
Build unit tests for the model to be absolutely sure it always works.
Work out "flow" and other control issues based on that model.
Build the GUI later, once you have a solid foundation.
How do you bring an abstract idea of a game and making into a real product? What tools do you use in your sketching and planning?
I do the following.
I use Argo UML for technical UML diagrams.
I write documents with my end-state in mind. What the API will be like. How it will work. As part of writing the documents, I clarify my thinking.
I write code in pieces, with unit tests, and refactor ruthlessly.
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Find an artist who wants to help.
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
Build the inside -- the core data model first.
Spike elements of the technology separately from the main development. Build separate proofs of concept for each new technology. Do not try to integrate unknown technology into the final product. (Many of my customers try this and it doesn't work.)
Having had an experience with game development in my teenage years what I can suggest is the following:
Make sure you have the story ready, or at least the basic points before you start implementing. Also make sure that you do not change the genre of the game while in dev stage. (yeah, I know, this is stupid, but could happen ;-) )
We actually drew some revenue when we managed to sell the game to a software house, however because we had already spent too much in the dev process, we just broke even (i.e. to little profit). So be careful what you spend beforehand
From what you said, you're still in school, so take advantage of that. There will surely be folk out there with artistic talent, most probably friends of yours. Make a team. That's what we did and it was all the way back in 1993! At that time it was even harder. We introduced our talented friends to 3D-Studio (v3 back then) and some even to computers in general, and believe me, before you knew it they were making brilliant art out of it!
Use pen and paper to create the story boards (even better with the friends mentioned above. Decide on the development approach. I.e. what libraries will you use etc. Read a lot about game dev. Make a plan of the project. Give it your best ;-)
Unlike us back then, you have the web to help you. For whatever problems you have with your code it is easy to look it up. StackOverflow didn't exist back then!
And of course make sure you have fun in the process otherwise it will eat you alive!
What are some key aspects you've
noticed in a successful personal
project?
Just do it!
Learning from my last question, most member names seem to get included in the Project Output.
Looking at some decompilers like 9rays, Salamander, Jungle, many obfuscating techniques seem to have been already defeated, there's this one particularly scary claim:
Automatically removes string encryptions injected by obfuscators ~ Salamander
So is manual, source-code level obfuscating more effective than post-compile / mid-compile lathered, 'superficial' obfuscation by well known (easily defeated??) obfuscating programs?
Obfuscating source-code is going to be self-defeating in terms of maintenance.
If your project is so 'secret', I guess you have two choices:
Place the 'secret' proprietry code behind a service on a server that you control
Code it in a language so not easy to decompile such as C/C++
Maybe, debatably, but you'll destroy maintainability to do so.
Is this really worth it?
Actually this just comes down to security through obscurity, i.e. it's not security at all it's just an inconvenience. you should work fromt he assumption that any party interested enough will decompile your code if they can access it. It's not worth the pain you'll inflict on yourself to make it very slightly more time consuming for the evil haxxors. Deal with the real security problems of access.
As people stated obfuscation is about raising the bar. If you obfuscate your assembly you will stop a casual developer whose just curious but you won't stop a slightly motivated person from reverse engineering.
If you want to raise the bar a little further many obfuscation tools let you use non-printable characters as member names. use reflector on itself to have a look. This will stop a lot more people, I might look at obfuscated code to understand it, but if I can't read it, I'm not going to go through the pain of dumping it to IL, and renaming all the members manually, no motiviation for me to waste that much time.
However for some people there is a motiviation so you need to go another step if your business requirements nessecitate it. But no matter what you do if the computer can read it, there will be someone out there who can read it too. The goal is to reduce the number of people who can read it or would be motivated to read it.
There are also some tricks which you can use to make reflector break (Obfuscator from PreEmptive breaks reflector in some cases but of course you can still read the IL). I had an interesting conversation once with a developer of an obfusction tool and I won't be able to do it justice but he had a way to make reflector completly break by having the code jump dynamically around. For example one moment in your function a then you'd jump to the middle of function b. Doign this cause PEVerify to raise errors so they never actually implemented it but kind of neat idea.
annakata is correct. Really all you can do is make it more difficult (and costly) for the person to reverse engineer the software.
My company identified several areas in which we wanted to make it as difficult as possible for reverse engineering. For example our files are a binary format which each object in our hierarchy responsible for saving itself and reading back the correct version. This means for a person to read our files they would have replicate our entire hierarchy in the code they create to read our files. In addition much of the information in the Job file is useful without the corresponding bit in the shop standards files. So they have to do the work twice in order to understand what the job file is saying.
Several critical areas (dongle protection, communication with our metal cutting machines) reside in Win32DLL. Which means that they would have to know assembly and how to make DLL that replicate other DLLs signatures in order to reverse engineer our software. Plus our design with our CAM software is that it is highly interactive with the cutting machine (information being exchanged all the time)
From the few time we heard about competitors trying to deal with our machines alone they wound up replacing the electronics with their own in order to finish the job. Major bucks to do this.
Part of the steps we took was based on our own experience with trying to deal with competition's machine and software. We took that experience and learned how to tweak our setup. Of course we have limits in that we are not going sacrifice reliability or maintenance just for the purpose of defeating reverse engineering.
For your case, you will have to ask yourself what part of your software would be of interest to your competitors and proceed from there. If you are a vertical market developer (machine control, specialized accounting, etc) I suggest using a USB dongle for software control.
Otherwise use a serial number system and accept that people are going to pirate your software and build that into your business model. The purpose of a serial number scheme is that is relatively unintrusive, and hinders causal copying plus give you a remote chance of tracking down where the copy came from.
The problem there is you will be sacrificing readability to do it. If your project is that sacred to protect, I believe it is safe to assume two things:
The project is large enough that the hit in readability will come back to bite you in the ass.
The people who want to reverse-engineer it will do so anyway. It will just take a slightly larger feat of intelligence to determine what things do (instead of just reading the member names).
I am alarmed that you're even considering code level obfuscation. Won't you be obfuscating the code for yourself too? How do you intend to ever work on it again? For the sake of maintainability this shouldn't be done.
But consider this: -
Suppose there was a script/app that you can run that would open your project and cleverly obfuscate every string/variable name in your project and you compiled it afterward while your original code is securely untouched in a separate location.
Now that's some idea.
Actually code level obfuscation is less secure than what the obfuscators out there can do. This is primarily because obfuscators can take advantage of strict CLI implementation details that are not permitted by language compilers. For instance, it is entirely legal for private fields to all have the same name - but there isn't a compiler out there that will let you do that.
you can use a technique like this : http://g.palem.in/SecureAssembly.html using this you write in .net but you embed into a c++ executable your .net executable ,