HailStone/StormCloud progress update

[Feanor]

Hey all. I have been working for the last week or so on a level editor for HailStone, which I'm calling StormCloud. So far I've stuck to working on the user interface. I've got a 2D opengl view which can be zoomed in and out, scrolled, and set to different cardinal viewing angles. Units are correctly shown on the scroll view, set to the units of OpenGL. I've got the beginnings of a hierarchical object detail viewer (with no objects to show yet ;-) ) and a toolbar (which isn't attached to any functionality yet). I've followed Apple's document-based application model quite closely.

Today I am going to finally try to tackle the most important core capability: converting mouse up/down events into the generation of objects. (Right now, it just draws a hard-coded bunch of triangles.) That means setting the view to be able to track and record these events, and then submit them to the document, which will use that info plus the known tool selection to generate an object and insert it correctly into the hierarchy (based on which group is currently selected in the viewer).

I should be able to get all the basic shapes done (wedge, cone, and Platonic solids: tetrahedron, cube, octohedron, dodecahedron and icosahedron, and probably sphere) today or tomorrow. Then I will implement saving/loading. That shouldn't be very hard, especially as the GNU 3DKit already has archiving capabilities built in.

I'll post the code for inspection when I get that work (plus clean-up and additional commenting) finished. It will require downloading and installation of the GeometryKit and RenderKit, but I've got pre-compiled and ready-to-install binaries for those, so I'll package them up with the code and put it all on my iDisk (http://homepage.mac.com/brentgulanowski).

Actually I'll post the GeometryKit and RenderKit now, just so that people can have a look at my project files, which are up-to-date (the ones on the www.3dkit.org site are not). If anybody wants to see StormCloud earlier, just let me know, but I think it's better to actually have editing and saving capabilities before I release it. -- FÎanor

[Carlos Camacho]

You should touch base with Calum of MacDoomLegacy. He has written a tutorial on "Consoles" which I will post when I get a chance. His braain could be good for this project.

Cheers

[Feanor]

I don't know how to reach this person.

Honestly, though, I'm just going to keep on trucking on my own until Mark finally tells me how to make this an Inkubator project -- in fact, maybe there's overhead there that isn't necessary. I'm learning and enjoying myself, and I've had the occasional email exchange with some other folks. If people are interested, they'll contribute. I'm not going to petition for help.

What I'm finding is that people doing OpenGL and Cocoa (that is, really using Cocoa, not just a front end), are all doing their own things. My poll, to which very few responded, showed that Cocoa is not that popular for 3D, and 3D is much less popular than I thought -- at least on the Mac. -- FÎanor

[Pazolli]

Hi Feanor,

The first step to making this an Inkubator project is to get registered with SourceForge (http://sourceforge.net/) and hand me your SourceForge nick so I can place you as an adminstrator to the SourceForge Inkubator project. Once this is done you will have the ability to upload code, assign tasks, etc.

I wrote about this step in this (http://64.246.17.165/forum/showthread.php?s=&threadid=287&pagenumber=2) thread around ten days ago, but you never replied. I didn't know whether that meant you had lost enthusiasm for the project or not so I kept quiet.

Anyway its good to hear you're still eager to persue this project.

Welcome aboard,
Mark Pazolli

[Feanor]

Actually I believe that I emailed you directly via the site's email system. Alternately, I *imagined* that I emailed you directly, which is just as likely. Didn't I send you something about the nick "Bastronaut"? I could swear it was real...

Anyway, that's it. I much prefer this sort of thing be done via email, instead of cluttering up public lists. I will spend some time acquainting myself with administration aspects of SourceForge and learning my way around their system. Feel free to suggest reading material. I'm already fairly familiar with CVS. I hope to avoid the Terminal (at least, after initial setup) and just recommend that everything be done through Project Builder (it works great for Hooptie, btw). Ugh, except that means everyone involved would have to be using the same version of Project Builder to avoid updating the projects and making it impossible for some people to read them. Hmmmmmmmm.

FÎanor

[Feanor]

Just me again. I've decided to post the current build and project files for StormCloud prematurely, so that people can have a look and get familiar with the design. It's at least interactive enough to get a feel for it. iDisk (http://homepage.mac.com/brentgulanowski)

And I wouldn't mind help with a bug: the SCDrawingView is the view embedded in a scrollView. Click twice in there, and it will draw a box, which you can then look at from all sides. You have to draw in Front view (that's not the bug, that's laziness). The bug is that it accepts clicks outside of the clipped area. I tried to constrain this to the clipView bounds, but then things fail when zoomed, due to the conversion between scales (the scale is set in the -setZoomAction: method, and is required to keep the rulers set properly). I think I can just convert the clipView bounds to SCDrawingView local co-ords using my zoom variable (careful there, that one is the inverse of the actual zoom, to make view resizing easier -- I may change that).

If you didn't understand that, well, I hope you are in fact intrigued and want to no more. -- FÎanor

[Pazolli]

I never recieved that e-mail unfortunately. In future feel free to contact me directly using "quirinus AT mac DOT com" for private communication. The reason for using the forum for most communication is that it ensures total transparency in the project's administration. Everyone knows what's going on, can comment on or criticise decisions if need be and if anyone decides to take a break from the project it is easy to pick up from where they left off. While certainly there are areas which are best served by private e-mail (e.g. reminders about tasks, etc.) I think you'll find the majority of communication can be served best by using the forum.

That aside, I have now added you to our project with full privileges. With Hooptie I found that contributions weren't significant until the program had a solid base to start contributing to. There are definitely other ways to try and attract contributions at a project's beginning. But from the looks of it, you seem to be content with the former approach. So my suggestion for the time being is to work on sorting out some solid, well-structured, well-commented code to begin work on. Once that is done, notify me and I'll upload that code to the CVS and post a general announcement (via e-mail) to all our members. Then start thinking about writing task specifications for your project for posting on SourceForge.

Also take a look at all Hooptie's documentation and think about what is applicable to your project. With your already existing body of documentation try and assemble some documentation to go on to the CVS with the code.

It's 2 AM here so I'm in need of some sleep.

Keep in touch, :-)
Mark.

Additional notice for our dedicated forum readers:

Hooptie development has been going on in the last week, even though the forums have been realtively quiet. Non-developers can expect a patch soon and then we can begin the final run to Milestone III.

[Feanor]

I re-read the Inkubator coding conventions document. I have to say I agree with essentially everything in it (I waffle on whether to capitalize struct typedefs--like a class name--or not--like a data type.)

But I will have to re-organized StormCloud to obey the common header philosophy ("StormCloud.h"). In fact, I really have to sit down today and re-consider the whole design. I am very design-centric, but much of what I'm doing in the AppKit is new to me and doesn't always work as expected. In other words, so far I've been experimenting. Now that I've got a good idea how a number of things work, I can consider it from a design standpoint better.

Questions:
Shall we make StormCloud (the editor) and HailStone (the game) as two separate projects, or one project with multiple targets? I'm thinking the latter. In which case, should all custom classes have the same prefix? I've been prefixing classes that are only used by the editor (window controllers, UI classes, and the level document itself) with an "SC" prefix, all others with "HS".

How shall we handle the GNU 3D Kit relationship? I've talked to the creator of 3dkit, Philippe C.D. Robert. He seems like he's not that interested in maintaining the project any longer. It is *THE ONLY* open source 3d framework for Cocoa/GNUstep that I have found, and is essential to making HailStone about the game, not about the mathematics and theory of 3d scene graphs and rendering.

Truth be told, the only serious problem with it is that the project files weren't up to date, but I fixed them up already. What I'm thinking is that we can include the 3dkit source inside of our CVS. However this may be excessive. I will send my revised project files to Mr. Robert and ask him to put them in place of the out-dated ones in his source download. If he does so, we will simply include instructions for getting, building and installing the framework. For the distribution of HailStone/StormCloud, we can simply prepare binary, install-ready copies of the framework (I've already got some, stripped and pre-bound) with an archived version of the source, which I believe will satisfy the LGPL under which 3dkit is licensed.

In fact, we can easily build the binaries for inclusion within the application bundle, avoiding the need for install. If we're really clever, we can produce an installer which will put them in whichever location the user prefers (system frameworks folder, user frameworks folder or application bundle).

The necessity of a 3D library (regardless 3dkit or custom), means that there is overhead for those programmers who want to work on graphics. I believe that I have broken up the game design such that non-graphics code is well separated, but 3D concepts will be used almost everywhere by the game: in-game graphics, UI, physics, and A.I. simulation will all use spatial concepts and model data, which is all in 3D, and will use 3dkit classes. So I hope everyone who is interested in helping out with code downloads the OS X ready 3dkit project on my iDisk, and has a look, and asks questions about it here in the forum.

Edit: for those who missed it in the starting post: 3dkit is not my work, but I've mirrored it with an up-to-date project file as well as binaries. 3dkit is by Philippe C.D. Robert. Sorry if I made it sound like it was mine. Only the update to the PB Project are mine.

-- FÎanor

[Pazolli]

Okay my feelings on some of the things you raised.

Firstly, there is no reason why you can't customize the "Conventions.rtf" to suit your project. There is no need to conform with Hooptie's conventions. However I feel a common global header is a good idea for any multiple source file project.

Keeping the editor and game together sounds fine. If it begins to look like a bad idea we can simply separate the two into separate projects.

The binary only framework inclusion sounds like a fair idea. If we do find ourselves customizing the GNU 3D Kit we could post it as a separate module to our CVS. The LGPL would be satisified with this arrangement.

I'm familiar with working with Frameworks too. The Installer should not be too hard, for the time I suggest installing them in the binary using Project Builder. Mac users have double-click, if it doesn't work, trash it mentality. I have this mentality too. And despite the increased file size carrying the Framework with the binary would cause, I think it's worth it.

That last paragraph sounds good.

Mark.

[OneSadCookie]

For those who were put off by not being able to double-click StormCloud straight out of the download to run it, I've compiled a version with the frameworks inside the app. You can get it (binary only) from my iDisk: http://homepage.mac.com/onesadcookie . Should be simply double-clickable.

Stuffit Expander seems to do something weird when unpacking the tar/gzip file, but the application seems to work OK. If you have problems, let me know and I'll try again.

Hope you don't mind, FÎanor.

[Feanor]

OneSadCookie, I don't mind at all. Thanks, in fact.

According to apple's docs, it's easy to set up, yes? Just a couple of settings changes in the library -- did you make a separate target or just change the current target? Do the libraries then get bundled automatically in the application when you build, or is there a target setting there, too?

There's a new version of 3DKit (both frameworks) coming soon, btw.

I've added live resizing to the rectangle drawing, but it's still only mouse-action testing. Also it works from all direction choices. Still,my progress has a been a bit slow. Yesterday was a holiday (Canada Day), but I helped a friend move, so I didn't get any work done on the code to generate geometric primitives. I will hopefully get a chunk of that done today.

I also cleaned up the code a bit, added more comments and such, so I will re-post it and ask Mark to add a new CVS directory beside Hooptie.

[Pazolli]

Originally posted by Feanor
I also cleaned up the code a bit, added more comments and such, so I will re-post it and ask Mark to add a new CVS directory beside Hooptie.

Okay, bring it on. :cool:

Mark

[Feanor]

Originally posted by Pazolli


Okay, bring it on. :cool:

Mark

It's on my iDisk (http://homepage.mac.com/brentgulanowski).

Do we have a strong opinion about single project multiple targets for SC and HS, vs. multiple projects? It's probably easier to make separate projects. But for sure they will live in the same module on the CVS unless you figure there's a reason to make them separate.

I've set up the directory structure a bit more complicated than Hooptie, but since there's going to be some very distinct code modules, an integrated library, and two applications, it seems practical for keeping things organized.

I would like it if OneSadCookie can add his version of the 3DKit project (with code) to the CVS path {cvsroot}/frameworks/3DKit (where {CVSROOT} is Inkubator/HailStone). Then it will all be in one nice package. I haven't written coding conventions yet, but when I do, I'll add it to the documentation directory. In fact, I would appreciate anyone who sees any to report inconsistencies in the existing code.

FÎanor

[OneSadCookie]

The reason I haven't posted the changes I made to the HailStone & 3DKit project files is that they wouldn't have worked on anyone else's machines (absolute paths). For anyone else who wants to try:

In the two 3DKit projects, change the installation location to @executable_path/../Frameworks . Make sure the RenderKit links with the newly-build version of the GeometryKit.

In the HailStone project, change the framework references to GeometryKit & RenderKit to point to the new versions. Add a copy files build phase to the HailStone target. The destination (from the popup menu) should be "Frameworks"; drag the GeometryKit & RenderKit frameworks from the files tab to the "files" section of the new build phase.

----

Optional extras:

If you have Project Builder 2.0 (beta), you can use GCC3 instead of GCC2. In the HailStone target, add a new build setting "USE_GCC3 = YES".

The default warning flags Project Builder uses are pretty much hopeless. You can change the warning flags in the target down at the bottom of the build settings tab. They're currently set to -Wmost -Wno-four-char-constants -Wno-unused-pragmas or something; every project should use at least -Wall. My standard warning flags for:

GCC2: -Wall -W -Wno-unused -Werror
GCC3: -Wall -W -Wno-unused-parameter -Werror

Or if I'm in sole charge of the code, I might use something even stricter (this for GCC3):

-Wall -W -Wno-unused-parameter -Wfloat-equal -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Winline -Wdisabled-optimization -Werror

-Werror turns all the warnings into errors, so it's probably not appropriate for HailStone where the GeometryKit and RenderKit produce so many warnings.

[Pazolli]

Well HailStone is up and functioning well on my end. If you want I could also post the project files and source code to the frameworks (at the moment only the compiled versions are on the CVS). If we do post the frameworks' source, I'd suggest we post it to a different module named "frameworks" because some people will never want to work on the frameworks and for them it's just a waste of bandwidth. Plus keeping the development of the two separate can have other advantages.

Until later,
Mark.

[Feanor]

CVS seems fine, although I had to use pserver to log in, instead of ext. Working on very subtle task of integrating 3DKit into StormCloud is more difficult than I thought -- not because of 3DKit itself, but because of the translation between 2D interface and 3D world.

Also had some concerns over how to integrate new geometric primitive classes into the existing 3DKit heirarchy. Settled for creating a slew of new G3DAttributes akin to the G3DVtxArray/G3DIVtxArray, called G3D*Primitive (where "*" is the shape: cube, wedge, icosahedron, etc.). It was either that or a G3DIndexedArray class cluster. In fact, I'll probably convert it later.

I'm getting a much better idea of how 3DKit organizes itself, so I'm closer to being able to write a good discussion of said organization. In a nutshell, a G3DCamera maintains a frustum and a link to the world scene graph. (It should really contain a context as well, but that's another story.) The camera initiates drawing by sending the world a "renderWithMask:Frustum" message, which starts the drawing chain reaction.

A world is made up of three groups of objects: static, dynamic, and overlays. They draw in that order. A group is an array of graph nodes. Interior graph nodes maintain OpenGL state information that applies to groups of objects. Leaf nodes are the things that get drawn, notably G3DShapes. Shapes contain geometric information, which is any object that conforms to the <G3DGeometryBackend> protocol (including G3DIVtxArray, G3DVtxArray, and G3D*Primitive or G3DIndexedArray). The render messages filter down to the leaves, which draw themselves (or decline to if they are not in the frustum and culling is active).

GraphNodes also have render delegates which do things before and after each frame is drawn, but I don't know what sorts of things yet, unless it is updating. But this would mean that the update process and drawing are totally intermingled, which I don't approve of.

Updating the state of the world to cause animations and behaviour seems to be up to the rest of the application. Except for the G3DTimedGroup, which I believe cycles through a group of geometries to create frame-based animation, using an internal timer to track which frame is current.
--FÎanor

[Pazolli]

If you use anonymous pserver to work with the CVS you will not be able to submit back your changes to the CVS. You really must use the method prescribed here (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/inkubator/hooptie/obj-c/documentation/cvs_access.rtf?rev=1.8&content-type=application/rtf).

Mark.

[Feanor]

pserver normally works for write access as well as non-write access. I didn't use "anonymous", I used my proper login name and password. Funny thing is, I still didn't get write access, so apparently they aren't allowing pserver authorization for write access. But as I said, :ext: did not work for me. I'll try again.

[Pazolli]

You can't just type in the :ext: line and expect it to work. You must follow the documentation above.

Mark

[Feanor]

:) :) No worries, eventually I followed the instructions. Now I just fight with Project Builder which won't do CVS properly, so I must use Terminal.

Well, I've created the first geometric primitive verts class. Choosing "Box" in the toolbar and click-dragging will cause a new box (says "generic" -- forgot to init the name) entity to appear in the entity browser. Yay! Also attempted to improve commenting in many places. CVS update from Terminal worked fine, new files added and a bunch updated. -- Brent

I look forward to a day when I don't have to compile thirty times to properly track down all bugs.

[OneSadCookie]

Project Builder can do CVS integration through SSH quite happily -- with a little help. You need SSHPassKey:

http://www.codefab.com/unsupported/

[Feanor]

OneSadCookie, you came through again. Thanks, works like a charm. We can now make semi-permanent boxes. So I've got to add the other primitives and then make everything conform to NSCoding and then we can save and load files. Anybody who wants to help with that, which is a very well defined process, please come on board! -- FÎanor

[Kjurtyl]

Thank you, OneSadCookie, I've been wishing for something like this for a while. Makes everything that much easier to manage.

- Kjurtyl

[Feanor]

I was away for the weekend, so that along with a number of bug fixes in the way mouse drags were handled has slowed progress. But the bugs seem fixed, the entity browser updates correctly, and now you can change the names of objects that you add. Maybe today I'll actually post a set of tasks on the sourceforge page. -- F

[OneSadCookie]

I've made a couple of minor updates to the StormCloud project file (notably fixed the framework search path so it should work for everybody).

See the log message for details.

I notice that it notifies inkubator-commits _AT_ lists.sourceforge.net when I do a commit -- how can I join this list?

[Feanor]

I haven't figured that out yet! I'm sure there's info somewhere on the sourceforge page...

I notice that you turned on a lot of warnings for the project. Thanks, I think ;). No, really, you're right, it is much more useful, if surprising.

I've added the wedge class for real this time, and I am now enjoying fighting with making it orient itself nicely in various viewing directions. <sarcasm>I love linear transformation application order management </sarcasm>.

[OneSadCookie]

The only thing I turned on is -Wall, which basically means warnings which are almost certainly errors. I don't think I've ever seen -Wall generate a warning where I really meant to say what I did :)

[Kjurtyl]

You should be able to access the commits list's archives through the lists link in the keyword row on top of the inkubator sourceforge web page. Subscribing information should be found there as well. Look carefully under the lists subheading for details.

- Kjurtyl.

[OneSadCookie]

It was finding the Inkubator SourceForge page that was problematic... http://inkubator.sourceforge.net redirects to iDevGames, with no obvious links back....

Anyway, I found it:

Inkubator SourceForge page:
http://www.sourceforge.net/projects/inkubator

Commit list subscription, &c:
http://lists.sourceforge.net/lists/listinfo/inkubator-commits

[Feanor]

Lots of little changes to make things look and feel better, plus some extra features to allow me to understand G3DTransform HPR rotations a bit better. Had to individually case the mouse dragging behaviour based on viewing orientation and dragging vector, but everything behaves properly finally (I had a false confidence issue earlier).

Adding the rest of the G3DPrimitives should be a snap. I would appreciate some input on the best way to go about that. I am thinking of a class cluster, but they don't seem to offer a lot if you're not in a mutability situation. The interface is a bit nicer, sure. Might make the use of singletons easier. Comments?

A while ago (forget when), I fixed a bug in the entity browser where it wouldn't update properly. I'm going to hopefully put together a dialog window to allow numeric editing of shape transformations.

The SCLevelDocument file is getting big. I'm wondering if it could do with a re-organization, perhaps moving some things into functions, even into other files. I was also thinking of re-working the mouse drag behaviour cases into a lookup table, which might make the code cleaner, but would make the meaning of the values virtually indecipherable.

U.I. changes are pretty self-explanatory in light of comments above. Turning on test mode draws a wedge primitive at the origin so one can test how rotation combinations work on it. When we have free rotation of objects, this functionality will become redundant and be removed.

Apologies to anyone who was using an incomplete CVS commit at any time. I was flipping back and forth between PB and Terminal until I finally got sick of it and re-checkout out the whole module, so I should have my permissions right and be able to commit anything from PB now. (OneSadCookie: I was actually -moving- the viewDirection_t def from one file to another -- don't know how it managed to be in both in CVS, but I must have missed a commit. Anyway it probably belongs in SCDrawingView.h where it was, so I left your change alone.)

FÎanor

[Feanor]

No updates for a while -- my attempt to add NSCoding protocol to the HSLevelDocument and G3D*Primitive classes did not work, and I haven't been able to determine why. So I took a break from coding habitually to ponder the design of the system.

Also, Toronto is really hot right now and I don't have air conditioning. It's hard to work at anything more than reading theory papers. But I'm also trying to deal with other things (finding work, finding a room-mate). I am working on a much better design document, since I feel kind of aimless without one. This involved many hours spent fighting with Word's outline tools. It will probably be another week or two before I get back to coding, but I'm not in a hurry.

I'm going to read up on radiosity and other topics at the same time, to assess what is useful and what is too much work for HailStone.

[Feanor]

I finally figured out the design flaw which was breaking saving and loading, so now it's fixed! I wasn't allocating the space for the dynamic arrays; I had this idiotic idea that the unarchiving machinery was doing it for me. This is a psychological watershed, because now the application actually retains state between runs, which means it's a real interactive program, however crippled, not just a sham.

Now it is time to figure out why the rotation behaviour of 3DKit is backwards to what I want it to be, even though it is by all accounts coded properly. I think I can avoid my problem with concatenated rotations by applying them one at a time.

I would REALLY REALLY appreciate it if any 3D talents out there would look at the mouse-interpretation machinery for adding new primitive objects and explain why the rotation situation requires such non-intuitive code to get the expected behaviour. (I mean, its like the pitch, heading and roll are getting applied in the reverse order, so I have to use some insane combinations to get the right effect.)

I'll put that off myself while I design a bunch of new primitives and then look at how to do translations, scales and rotations to the objects in the scene. Then multiple selection and grouping functionality.

But I'm actually in the middle of reading The Emperor's New Mind, having finally acquired enough math background to really understand some of the obscure stuff, so look for new updates on Sunday maybe.

--FÎanor

[Feanor]

Hello,

I'm sure many people think I've gone and flaked out -- well, I did for most of August :-). The problem with being a perfectionist is that trying to understand the problem overwhelms the process of solving the problem. Anyway, I've been thinking a lot, in the hopes that when I sit back down to coding, I'll actually have a clear vision of what I'm doing and how to approach it.

Hailstone is actually a precursor to something bigger, so I'm spending a lot of time trying to understand and streamline my ideas of the bigger thing, so that I can pull out the pieces of that which will be used in Hailstone. Then when Hailstone is operational, I'll be able to extend it. I'm working forwards towards a coherent concept, then I'm refining it into an understanding of the components, and then I'll pull out the core HailStone components and adapt them to work in a vastly simplified design.

I've managed to break my long-range design into six distinct packages of objects: Grouped as Entity, Actor, Director, Schedule, Communication, and Venue. In Hailstone, there will be no Schedule nor Communication packages as such. The Director package will be represented by only one object. The Entity package will be significantly simpler, consisting of little more than a simple scene graph and objects in the world. But I want the functionality to be grouped in a similar way, and be modular.

I'm concentrating on how to reduce sub-classing and just make the behaviour of objects, especially Entities (the objects in the world) be more data-driven, in attributes as well as in behaviour. So far, it's looking very much as though Entities will be a lot like puppets that are positioned in the world. They will retain a lot of state information, and control access to that, as objects are supposed to, but their brains will be provided by other objects, which will be plugged in to each Entity when it gets its turn to decide what to do next. Also the behaviour delegates will be few in number, depending upon discrete behaviour objects which are referenced by the Entity class.

Each behaviour object will be activated with the particular Entity, reading state data, processing new results, and writing that back as new state data. By this means, the Entities will move around, attack, fire weapons and the like. If a desired change of state violates the range limits of the Attribute itself, the Entity will deny or clamp the change. If the change would violate some world rule (like cohabiting the same volume of space, ie: collision), the results will be discarded, and perhaps a different Attribute will be changed.

Using this method, it should be straightforward to simulate a robot bumping into a wall and then changing direction -- in other words, alternate behaviour when the primary behaviour cannot be followed through. But every Entity will follow the same model, including such things as projectiles and buildings. This will make it easier to allow explosions to damage things. Although I don't imagine I'll be simulating gravity to such an extent that buildings will fall over (I'd need to track centre of mass, and model compression forces, etc.), some will absorb damage and allow the user to form new paths around the levels.

For now, though, I'm looking at the different sets of tasks required to run the game world, determining which tasks have to run in order, and in what order, which tasks can run in parallel in separate threads, how to organize the task management, and what controller objects to handle this will look like.
-FÎanor

[Render]

Very cool stuff. Thanks for sharing these thoughts!

[Feanor]

You're welcome. I am actually planning on releasing some professional-style design and technical documentation sometime in the next 4-6 weeks, which should include a lot more of this kind of discussion, as well as an architecture specification and API specs for all of the classes. --F

[Feanor]

By third week of September the new design docs were about 1/3 finished, then school and being a best man for my friend kind of pushed everything aside. I have three midterms next week, so expect more delays.

One problem is probably that I spend too much of my free time on forums and mailing lists (I subscribe to eleven mailing lists of varying activity) instead of programming. The Apple top 5 (Cocoa, Games, OpenGL, ADC Student, and Project Builder) produce around 100-150 messages a day. I'm thinking I should drop Cocoa and Games, for my sanity. Cocoa is 90% UI -- I should be able to get answers from the archives or Student-dev. And Games is 90% Carbon. Hrm.

In addition, there is the 3DKit issue. Hailstone and StormCloud are meant to depend on the open source project called 3DKit, which is in the midst of a major overhaul. What I will have to do, when I re-organize how I spend my time, will be to simply hack together a viewing system that will allow a transition into the re-designed 3DKit as it progresses.

I think this post took over half an hour to write. I am a perfectionist, which is often bad for productivity.

--FÎanor

[codemattic]

Originally posted by Feanor
One problem is probably that I spend too much of my free time on forums and mailing lists
<snip>
I think this post took over half an hour to write. I am a perfectionist, which is often bad for productivity.


I friggen hear you. You can get lost reading and posting - and it feels like youve done all this work (hey I answered x amount of peoples questions!) - but then you look and youve got no new code today. Im waiting for that drug the military is testing that lets you go without sleep without adverse effects. Until then you have to be merciless in cutting out timesinks that divert you from your goals. Hey - wait - what am I doing writing this? Gotta go!

-Codemattic


Brother Void's "The tragedy of commitment" from http://www.salon.com/books/col/void/2002/07/12/commitment/ from his book here: http://jump.salon.com/xlink?1216

"Whoever wants something great must be able to limit himself."
-- Wolfgang von Goethe

Sometimes you are paralyzed with indecision. You can't bring yourself to choose any one future because to choose one is to forsake the promise of all others. Yet not choosing is making you crazy. In such a state, drastic action is necessary. You must choose -- and then one by one, murder all the futures you passed over. Like a faithful companion you've cherished all through your youth, you must lead each future back behind the shed, and even if it looks up at you with those big eyes, dreamy with possibility, you must put the cold muzzle to its head and pull the trigger. You must do it, again and again, for each future that competes for the attentions of your heart. Only then are you ready for commitment. Only then can you pursue the one thing that will, in time and after much mourning, become all things to you.

The future is full of possibilities that I must shoot in the head.

[Feanor]

Originally posted by codemattic
The future is full of possibilities that I must shoot in the head.
Personally I just tie them up and gag them so they can't whisper to me anymore. Then I promise to let them free in a few years. I figure if I'm lucky enough to live to be eighty or so, I can probably get really good at two or three things and at least dabble in a few more. But for now, software engineering and games all the way, baby.