What I mean by this is such: Whenever I get into a project, I always have a good idea of how it's supposed to look, and I have a general idea of what needs to be programmed, as well as objects (datums) that need to be created. However, whenever I get knee-deep into a project, I have so many objects and files already created that I tend to lose my place, and I often dread opening the project again because I know it's still a mess.
So what I have come to a small but valuable conclusion is that I don't need to work on so many things at once, even though I feel like I should. Instead of trying to wrap up as many things as I can at once, I can spend the time to perfect a certain aspect of a project before even beginning to touch something else.
there are some exceptions to this rule, though. Objects which are derived from other objects must have some basic definitions in place in order to keep the compiler from complaining. One such example is an /actor object, which would be derived from an /entity object. If I wanted to work on actors, I would need to make sure some basic groundwork in entities is established first.
Secondly, it seems I am forgetting an important thing about developing. I am biting off more than I can chew. It's no wonder I give up halfway every time. But this is just something I do out of habit, as my mind tends to race and wander about everything. My scatterbrained nature causes me to explore every avenue of a project, and I usually want to create objects in my programming as a minder so I don't forget.
But at the end of the day I get this huge thing of hardly finished files, and of course the project is completely worthless with all of these objects which do nothing. I'll try and train myself to just focus on one thing at a time to make sure that the object is working in good order before making a shift to another object.
Sorry for the weird rant. I'm currently not in the best of moods. I'm more aggravated at myself than anything.
ID:1419215
 Nov 11 2013, 12:15 am
|
|
Sounds like you're trying to do some sort of breadth-all-at-once approach, and/or deepest-first.
I would suggest a different strategy. If you know what you want your end result to look like, step back and look at ways to implement very tiny pieces of it as you go along. For instance, look at this 'milestone' map I wrote up. This is for a single-player game that hasn't even really hit "game" status yet (I've only just started working on milestone 3). It's probably worth noting that I'm only just barely touching on the HUD, and player stats (health, move speed, etc) are literally only just getting looked at. It'll probably be Milestones 4 or 5 before this even approaches 'alpha' stage as far as showing it off goes. As you can see, different 'check points' are more or less vague, and different items are more or less work. Makes it easy to match up a task to the amount of time I have in order to accomplish it. Roadmap Although I'm expecting a ridiculous amount of work left to go, splitting it into over half a dozen "milestones" makes for very easy chunks of development that I can pick up and sprint with, then finish up and drop the project for a day or two. It also makes picking up the project easily, since the roadmap doubles as a nice checklist of progress - I can look at it and in an instant know where I am with the code, what's done, and what's left to do. By enforcing a rule that I don't touch one milestone until the previous milestone has been fully completed, I'm able to ensure I don't get "too deep" into the code if I'm not ready to. Splitting up the project into many, many files has also helped, since I can look at a file and it's a clean, organized code section that only touches on a single class or block of logic. | |
I do the same with my code in regards to files. Each object (datum) is contained in its own folder in "/objects/theobject/theobject.dm". The reason why I do this is because there may be appendages to the object, or sections of code that bloat the file. Separating the object's procs or variables into their own files helps break the object down into useful, organized structures.
My biggest problem is trying to do a million things at once. Maybe I think I'm capable of holding so much information in my brain, when in reality, it only confuses me and makes me want to restart the project. So instead, I chose this time to work on one object at a time, or one aspect of the game at a time. Sometimes I really really hate programming because there are parts of it that are so tedious and boring. But they need to get done. | |
What sort of stuff do you have that it makes the file 'bloat'? That could be part of your problem.
| |
By bloat I mean lots of code lines. I don't like having to scroll through so many, so I'll break the object up by vars, procs, and specific methods like New() and Update().
| |
Topkasa's touched on this in his previous post, but basically I think an iterative approach to your development would be better for you.
http://en.wikipedia.org/wiki/ Iterative_and_incremental_development Basically pick a small area of functionality, decide to what degree you'd want to complete it, then do that bit, test it, "release" it. This incidentally does mean you don't need to entirely complete a feature on one go, just do it to some defined useful degree. As a for-instance, you may have some plans for attacks, conditions, spells, and scrolls, in some RPG game, that all constitutes the mechanic of your combat in the game. You can, by iterations, do something like this: Iteration 1: Implement basic attacking, test and prove basic attacks take health off something. Iteration 2: Implement spells, which perform "an action" on "a target" at the cost of mana. In order to test, implement two spells, a basic attack and a basic heal. Iteration 3: Implement the idea of being affected by a condition, every X time-period "an action" happens. As a test of this, implement a spell that poisons the target for 30 seconds, taking health off every 2 seconds. ... So on and so on. The trick with this is you don't really consider the future iterations too much in the present ones, you just refactor your code in the iteration which needs it. So iteration 1 doesn't have to concern itself with the fact that maybe we'll have conditions which adjust our damage output ... yet. Iteration 3 (or more likely, much later than 3) will add this, and re-work the code necessary to do so. This does a few things for you: 1. You test often, see a tangible improvement in your game's functionality often, keep better motivated in that sense. 2. You avoid being mentally grid-locked with considering 40+ features at once when you're programming. The other 39 features are in other iterations, it's not your problem right now. 3. You refactor and rework code often, and usually quite early on. As you basically improve a design by experience and better understanding of what you want in the game, refactoring as you go works much better than planning a load of structures up front, when your understanding of what you /actually/ need is relatively poor. Similarly, it demonstrates to you that nothing in your codebase is "too painful" to re-work or adjust. | |
You avoid being mentally grid-locked with considering 40+ features at once when you're programming. The other 39 features are in other iterations, it's not your problem right now. That's been my problem I believe. You refactor and rework code often, and usually quite early on. As you basically improve a design by experience and better understanding of what you want in the game, refactoring as you go works much better than planning a load of structures up front, when your understanding of what you /actually/ need is relatively poor. Similarly, it demonstrates to you that nothing in your codebase is "too painful" to re-work or adjust. Sadly there's been times when I would need to rewrite entire sections of code because there was a conflict later on that required me to do so, or that I found a much more efficient way. With a more strict iterative approach, I probably won't have much of a problem with that. I guess the iterative approach is something I had always done, but perhaps it hadn't occurred to me that I shouldn't be working on so much at once. | |
Rewriting entire sections of code does happen, sometimes. As it goes, having smaller (but still functional, useful, testable) iterative tasks helps make this less likely, as you refactor in small increments, often.
Part of it though, is just experience, as it goes. Learning the value of composition versus inheritance is of course also quite important, and rare around these parts: http://www.artima.com/designtechniques/compoinh.html | |
I'll echo that ckmposition is good to learn, but I don't think that article is the right one to demonstrate the importance of the concept.
It uses a really bad (imo) example of a situation where composition can be used (an apple is a fruit, it isn't composed of one), and some of the points in the conclusion don't make much sense at all, especially the employee one (Either it's a role assignment and therefore is a state, not a class, or you're only dealing with employees therefore non-employees are irrelevant.) Edit: Phone grammar. Apparently apples DO "composed of" fruit. Thanks, Android! | |
Well, in most realistic scenarios, a role carries a whole raft of other data associated, so usually is composed. A luck man you are, if role distinction in your system is purely a one value visual thing, that could be modelled as a state enum or similar.
| |
A better example would be an automobile; while there are different kinds (cars, trucks, minivans, etc) which would be inherited from a "Automobile" superclass, they are all composed of parts such as an engine, wheels, a fuel tank, and more. There might be different kinds of engines, and different tank sizes, but every automobile will have each.
| |
Yup, a fair example also.
| |
I think it wasn't until recently that I decided to lessen the inheritance model on my programs and sort of go half and half with both inheritance and also composition. There are instances where inheritance makes more sense (which in most cases means that I would want to override some of the methods of the class). However in other cases, I don't want to make a new subtype for every god damned item in the game. It's a solid idea if you want (hypothetically) "/obj/item/sword1" and "/obj/item/sword2" and "/obj/item/sword3", but most times I would really like to just refer to them all as "/item" objects even if subtypes can still be considered /item objects all the same. The only reason why such specific subtypes wold exist is to override their initial values.
But of course there's other ways to do this. What I am currently doing in my project is designing a proc that loads each item into the game on startup using softcode. I'm pretty sure that it will take longer for the game to boot when this gets bigger, but to me this feels more natural than the former. An example: proc/_LoadItems() the variables "item_type" and "power" would of course be in each /item object, though null. the "power" variable is a generic term which could be used for a number of different applications, and not just for determining the damage of a sword. It could also be the healing factor of a potion. Thus, if item_type is something else, like ITEM_POTION, the game will check it and perform a different kind of action. | |
Stephen001 wrote:
Basically pick a small area of functionality, decide to what degree you'd want to complete it, then do that bit, test it, "release" it. This is basically how I (try) to work, although as you said it takes experience to start to figure out ways to avoid re-writing too much. You may not want to design rigid structures early on that become problematic later, but then again you should be thinking a little bit about the future iterations and whether there is a way to set yourself up for easy expansion. I've been slowly learning how to make the program do the work for me, by making it "smart." Like for example, say you want an equipment system where holding or wearing items can change your stats (like most rpgs). One way to accomplish that would be to include a bunch of variables for each item like "strength_bonus" and "agility_bonus" and so on, which will be used to modify the player's stats. A better way is to create a versatile associative list: obj/item That way, you can create an item that changes ANY of the mob's vars, just by writing out a simple list. If you add new vars to the mob later on, you don't need to change the Equip() code at all. Now of course this is a very simple example but it took me quite a while to start figuring out ways to employ this kind of strategy :) | |
I'm actually making solid progress. I'm talking about Magus Aora Legends, actually. I've rewritten that thing a million times. This iteration is looking good.