I'm mostly asking people who are working on larger projects, but I can't stop makers of small plugs from stepping in the comment.

Basically, just whats your pace? Do you try to make X amounts of resources everyday? Do you follow some schedule? Do you just randomly pick it up and add content? Something else?

I'm not sure my base is a good one, but my amount of free time is relatively unpredictable until I actually have it. I tend to sit down and spend quite a bit of time adding a bunch of things and fixing many others in a single sitting. Its a bit erractic due to when I do this, mostly due to free time I have alone to work on it. Though I can't help but feel I'd be quicker if I could get a steady pace going...

I'm also fairly erratic. I spent December until now developing the back story, mapping out the galaxy, and outlining one of the major plotlines. Recently, I mapped the first major govt's systems in MC, and started adding spobs along with bar and landing descriptions. I have one ship implemented and three in develomental stages. I'm still writing down idea (daily or almost daily) in my planner notebook, and I'm outlining two more major plotlines.

Basically my process is to develop the background and story first, then begin implementing it all. I'm not terribly systematic in the implementation, which could be a bad thing, but it fits my thinking process.

This is rather different from how I approached my first major plugin that I began developing for EV Classic way back when - I started out by designing all sorts of ships and putting them into the plug, but I never got beyond that because I didn't have a story to tell. With the story in place first, it is able to dictate (perhaps inform would be a better word) the development of the universe, ships, etc., rather than having a bunch of cool but pointless ships sitting around distracting me. Make sense?

I don't work on plugins, but rather actual programs, but they're potentially large programs, so the same principal applies, more or less.

I set achievable goals, such that after each goal I will be visibly closer to achieving the ultimate goal. As a hypothetical example (giving real ones would involve a lot of backstory), say I were writing a Zelda clone. My first goal would be to load and display graphics on the screen. After that, I'd want to be able to move them using keyboard input. Then I'd want them to be able to collide with each other. Then I'd have one of the objects onscreen be controlled by an AI. And so on. The keys are that:

• Each goal is achievable in a reasonably short timeframe, so I don't spend a long time grinding away at something without feeling that I'm making no progress

• Each goal is useful in that it gets me closer to my final goal.

The first time I worked on a game project, I made the mistake of wanting a detailed collision-detection scheme that would detect collisions between concave polygons (which is nontrivial). I spent so long writing the collision detection code, and then debugging it, that I ultimately got disenchanted with the entire project. Now, the project itself wasn't a complete waste - the basic engine I wrote forms the basis for all of my other projects - but the collision detection code is scrap, and the original game idea isn't getting any work done.

In the context of EV plugins, I'd advise that you regularly have checkpoints where you can put the plugin in and fly around, taking a look at everything. Instead of placing the entire universe's systems in one go, then going through each system adding spobs in another, and then adding descs to each in a third, only map out a few systems, but create them fully (system, spobs, descs) so you have a little place you can fly around in. Instead of creating all the models for all ships before creating the stats for any ship, create one ship at a time, model, stats, descs, and all, so you can plug it in, fly it around, and see how it handles. And so on.

Edit: HTML markup->UBB markup

This post has been edited by Derakon : 15 March 2007 - 12:16 PM

I tend to do whatever I feel like doing on a given day. Sometimes I have the patience to do graphics; othertimes I come up with ideas for weapons, outfits, and their accompanying descriptions.

I really never have a set plan for anything I do in my life. I just play things by ear.

I do college-related stuff until about 1:30 in the morning, and then spend the next hour and a half writing descs before going to bed.

@derakon, on Mar 15 2007, 12:15 PM, said in Whats your development pace?:

<snip>

Now that you mention it, thats kinda what I do. When I sit down, I generally am thinking "Alright, I need to make X weapons to do this, X outfits that do that, etc." and usually attempt to make those. And usually after I make a few things, I immediately go and test it to make sure it works. In the case of a weapon, for example, I'll arm myself with it and shoot at stuff. Then I'll arm an A.I. ship with it only and have it shoot at me.

And I agree a great deal with the comment about making stuff flyable to mess around in. My first session with CTC was making it playable, complete with a single weapon that I could shoot at the A.I. ships who were my clone at the moment. My sessions also tend to end with me spending thirty minutes just using and abusing the stuff I just made.

And yes, I was allowing for programmers to talk about their pace too. After all, we plug-makers are not the only developers on this board making something.

I know ARPIA2 isn't a TC, so it doesn't involve the same amount of work right from the start. But here's how I proceeded anyway, because I know that storylines are the problem for the majority of plugs (don't worry, UE_R&D, I know about Retribution and its exceptionalism ).

At first, for Arpia1, I had no true story. I had the beginning, and some idea for the end, but I didn't have anything else. So I just started building upwards. I found that the exam period and holidays were a great moment of advance, because I suddenly had a few whole days where I didn't have anything planned.
Arpia1 was created in a rather erratic way, because I didn't have anything special planned for it. The weapons were just things I thought would be cool to have. Same goes for the ships.

Then came time for ARPIA2 development. Here, I already had a basis on which to build, so I had a general idea of what I needed for the way everything would happen in the other storylines too. So I mapped out the storylines, in this sort of manner:

	Regular						Shadow					Public

1					-----------	Pirate Hunt I	 ----------
(…)
14				-----------	Choose your future	----------

15	System opposite Residio				-- Pirate Raid III --
							 	  ---- Pirate Raid+Hunt misn avail ----

16	Launch exploration probe	  -- Investigate possible problem --
		(Korell)

17	Launch exploration probe	Slave-runners I			Ekrid Malrow
		(Uriall)

That way, I had the structure. And from then onwards, I usually managed to create approximately one mission per week or per two weeks (due to university).
Then came exams, and once again, development pace peaked, with sometimes two mission dëscs per day.
And I finished the storylines a couple of months later.
After that, back to sporadic creation. Until I got the last graphics from ATMOS. That's when I went in "hyper-speed" mode, having to finish touching everything up. All the pressure was on me, and pressure means more development

Derakon, your post just reminded me of something I still need to do on Clavius rEVisited. System coordinates I'll post more on it in our actual topic for the project.

Well, I'm going to join Derakon (as someone currently more involved with software than plugs). I indeed set myself an achievable goal (say, implementing a feature or fix, even little, that I can see the effect of), I read all the documentation needed to do it (if necessary), I plan everything necessary to do so in my head (not necessarily when I'm in front of my computer, sometimes I think about programming when I'm cooking) in advance, and then when I can find a moment with enough consecutive hours of free time, I write everything for the feature in one fell swoop. I think it's important to get it in a working state (even barely working) so that you don't have to come back to it later and wonder where you left things. Planning is important, so that the actual time spent writing code (for the purpose of an individual feature/improvement) is short so that you don't spend too much time writing code for no visible result.

For instance, I recently implemented the possibility to stop and resume the rotation by clicking in RLEPlugin, but I couldn't use the same method I use in ViewRLE, so I made sure I read all the pertinent docs (namely, HIView and friends) and made sure I had a good idea of what I was actually going to do, before I wrote the actual code. It didn't work the first time, but after a bit of debugging, it worked. Now I can worry about colored background. Next I'll worry about allowing the color to be chosen by the user (and of course, I made sure I left the possibility for this to happen in the previous step, without actually implementing it, for instance by not hardcoding the color, but instead putting it as a global var that could change, only it never does and the default value keeps being used as long as the UI to change it isn't implemented).

Now, with actual programs there are some points you need to write a big bunch of code before seeing anything, in this case write a few of the little details of the big thing and look what they do, to have a feeling for it, only as tests, then implement the whole thing. Well, perhaps not in a single session if it's big, but in a few close enough consecutive sessions. Think of a visible goal as a save point in a game (say SketchFighter), if you don't reach it and quit the game, you'll pretty much have to do it all over again (as you will spend as much time reunderstanding what you wrote as you spent writing it in the first place). But if you can reach the point you have a visible result, first you'll know you've done something, second you can start from what you're seeing (if there are bugs in it, if it isn't complete, etc ). I'm blessed with the ability to write a big bunch of code for some time without even making any of it run, while still being able to keep focus and not being discouraged as I'm not even building anything, and have it work right the first time, but not everyone can do that.

On important thing is, once you have something that's visible, check that it works as intended, make a few general checks that there is no problem with it (write it down if there is any), and now you can go to bed at 2 AM with a feeling of accomplishment: you've validated this, it's one less thing to worry about. It's important to do this just after you've wrote it, otherwise it's just an invitation to have it explode in your face later when you least expect it.

In fact, most of this advice has been influenced by this piece (though it is more meant to encourage to write clean code than prevent being discouraged, which is not really our point here since in plugs there is pretty much one way to do something and it's not going to be more or less of a maintenance mess, though sometimes I guess people can paint themselves in corners with NCBs; also, I'm not that much of a "hammer down everything to make it to break, and only stop when you can't" philosophy), though some of it I observed already before reading that.

Some of that can be applied to plug deving as well, though it's still not at all like programming from a technical standpoint.

Now, all of that begs the following question: when to work on something? It's important since none of us, I think, is independantly wealthy, we all have works or school or university to worry about, and of course none of us is actually living off doing plug-ins (or even software, AFAIK, at least the software we're talking about; jeff is no longer here to contradict me ;)). I've observed that it's no use to try and work on something serious if you only have, say, half an hour, by the time you're actually doing something it's already over. Use these short pieces of available time to write out ideas you may have though about that day, do some light stuff, or even do stuff unrelated to your project like doing your homework in advance or things like that. The objective is to set aside clumps of time (say, a few hours, like an afternoon or an entire evening if you can go to bed late) and do what you planned at that moment. And don't worry that the time you've set aside could be too long for what you've planned, if you complete the planned task in the timeframe you can then start the following task you've planned, it's even better as you're already hot.

This post has been edited by Zacha Pedro : 19 March 2007 - 04:33 PM