Related
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.
We have been having a lot of internal debate regarding staging tables. Some are view staging tables as archaic and will prevent the ability to build re-usable services, etc. It is also being communicated that these will prohibit the business to grow and handle expanded business channels.
I am not necessarily for or against either option, but I do know that having the staged data has been a life saver in many occasions and has made it really easy to re-import orders we have had issues with.
Just wanted to see what others thought about staging data and what other methods are being used to handle scenarios similar to ours (Taking orders from external partners, Amazon, etc and importing them into our ERP system).
Thanks,
S
Some places I've worked I've used staging tables, others I've used other techniques.
Each one has its own advantages and disadvantages.
That said, don't worry about it.
If some data feed comes along that requires some method other than what you are doing, then you'll come up with a new solution.
Change is driven by requirements.
(personally, when someone comes to me and says "We have to change to X because what we do now is inefficient and bad and witches will come and eat our children", they have this image in their minds that on tuesday, we will have an opportunity to triple our client base but only if we do this new thing, but if we don't get cracking on it now, then we'll miss the opportunity because none of those potential clients is willing to wait even a minute and they'll all demand the exact same thing and we can build exactly what they want right now even though we have no idea what they want HURRY HURRY HURRY AND DON'T BREAK ANYTHING. Which, of course, isn't how anything works. A single client (or whatever) comes along and says "Hey, we want your services, can you accept our XML?" to which the response is always "Sure thing", and then you get tasked with it and can make intelligent decisions, and plan things out. As opposed to the "chicken with its head cut-off" methodology preferred by people who like technical words but hate knowing anything tehcnical)
There is no reason for a debate - you have a working system. Anyone who thinks their "re-usable services" theory can do it better should put up or shut up.
Let them build a test implementation on your development servers for a common high volume scenario, and compare it to the current system - including criteria for recovery and re-import after a failure.
I hear this all the time where I work as well (usually from managers who just read an article about SOA and XML) and in situations dealing with large amounts of data - bulk imports into staging tables can handle a much higher data volume than any type of web service.
I am starting work on my first business (application + database) type application, using c# and sql I'm completely new to this,
What tips do you have for me?
What should I look for?
What concepts should I understand?
My tip is to get started and come back when you actually have a concrete question. If it makes you feel more prepared, go read some more C# and SQL books first.
While your question is broad, here is the number one thing I 'wish I knew' when I started out with business apps, kinda specific but it's pretty universal:
Writing business apps is made considerably easier by setting up a solid DAL (Data access layer) and abstracting your data access out and away from the rest of your application. That way all of your SQL is in one place and not strewn throughout your code.
Some golden ideas to read up on in this area are 'ORM' (object-relational mapping, as you're using C#, Linq to SQL could be a nice place to start) - this maps your database access to actual classes. If you have a good database design you might even find you have very little SQL work to do at all.
Another nice practice is using the Repository pattern, which effectively encapsulates all your data access into a single class (at least in the simple case - of course in bigger apps you might have multiple). Then in order to access any data, you always go via the repository. This is typically done via an interface which defines the repository, which then allows you to implement multiple concrete implementations. For example, you might want to fetch your data directly from an SQL server, but later on or in an alternative application you might want to use a web service to fetch data instead - no need to re-write everything, just drop in a new repository class! The interface stays the same, so the rest of your application doesn't know any different :D)
This is a pretty broad overview (and a bit of a mind dump sorry), and I'm certainly no expert, but believe me, good data access practices certainly make your life easier!
Just start writing code. You're going to have to throw is away later when you figure out what going on, but that's alright.
Well, I'd say you've come to the right site if you start asking specific questions.
Some of our highest rated questions, however, will give you tons and tons of reading material, books, link to other sites, etc. Here is the URL
https://stackoverflow.com/questions?sort=votes
General tips:
Get some help from somebody who has done this before. There is no way you're going to pull this off by yourself unless you allow for plenty of time to learn on the job.
Don't get distracted by the technical details -- make sure you understand the business. If you don't know why you're building the app (or your clients don't know why they need it) no good can come from it.
As far as what you should look for or how much you need to understand, I don't know the scope of the application you are trying to build -- thus I can't give any intelligent advice. A real-time financial system used by thousands of concurrent users is different from a small retail site that gets hit by hundreds. So my only look for/understand advice is this: don't overengineer your solution.
I work as a ERP programmer, mostly with MS SQL and some kind of scripting programming language.
I also wrote some simple projects in C# (a web application for our company and a simple windows service) and I like it very much, so my next job will hopefully be in .NET environment.
Now I'm learning C# from a Wrox book and I went through all the basics chapters. This is all fine and nice, but in my opinion a better way to learn a language is through a real project. So my question is: what kind of application should I write, so that I can use all the fancy-named concepts, like inheritance, delegates, generics, reflection, LINQ,... It would be nice if it also connects to SQL Server.
I thought about personal expense management system or scheduling system. Any other ideas?
Rule number one in such projects: It must be fun thing, or something you expect to profit from it.
When I was in the same place as you (and I mean the same...C#...WROX book...) I went for an engine of text based Adventure Games.
It has everything you described above, and more important I had fun writing it and later see people play it.
So, it really isn't important what you choose, as long as you enjoy it (and it's scope is big enough).
Any well-designed application could use any or all of those concepts. Language-specific books have a tendency to focus exclusively on language details (for good reason) and generally neglect basic design principles. Another important point is that delegates, generics, reflection, etc. all have their place, but they shouldn't be implemented in an application just "because". That can cause unnecessary complexity.
All of that said, pick a project that interests you. Even better, something that you would actually like to use. Then, before even coding, think about how you should structure the application so that it is easy to modify later and add features. If you're putting all the code in the form/code-behind page, you're probably doing something wrong.
Spend some time learning design patterns. These are "best practices" of organizing code that have developed over time. No need to reinvent the wheel.
Hope this helps.
Scratch your own personal itch...
I'd go for some sort of simple CRUD application, which will exercise your database skills (and give you an opportunity to use a LINQ provider against your database), but perhaps not too simple; i.e. more than one table.
There's nothing about a given problem that will make it inherently better to learn from. It's probably a good idea to stick to a domain which you can easily design and model against, to remove that aspect from the challenge. You might look at doing something "more" than just data access operations; perhaps something involving graphing or other processing of the data which will give you an opportunity to learn some other API.
Your suggestions (expenses management, scheduler) seem reasonably good to me.
If you want to try all those "fancy concepts", better make a project that does not reflect at all anything you might do at work. E.g. write a game. If you create a small CRUD application but somehow manage to use inheritance, generics, delegates etc., chances are your program is much more complex than it should. Next time you do something similar at work, you might be tempted to do it the same way. Which would be a real bad idea. (KISS principle)
Thanks for all the answers, with your inspiration I found theme for my project :-)
It is an IS for a Brothel. We keep a list of our Clients, Hookers, Rooms, Available Services, Job histories, Prices,...
Now I created all tables in SQL (with primary, foreign keys and indexes), what is next step? Should I for every table in SQL create it's own class in C# and then add methods to it? And then continue building my Program from this base? Or should I use another approach...?
Thanks
Go for some basic CRUD app - Video Management System, Student Registration System, Pet Store Inventory System, etc...
You could always look at an open-source project that uses C#... Usually, they have a lot of the different concepts that you'd like to look into...
-JFV
You could write an engine that supports adventure-style games - nothing too fancy, but I find that it makes a good beginner project as you can end up working with lots of OO. You could also make a basic media player, although I can't see that being quite so good for getting the fundamentals of the language down. You could even get the XNA Framework and try to write a simple game!
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!