Slitherine

quote:

Originally posted by Les the Sarge 9-1:
Alas a few hundred bucks wont do it. A few thousand might as well be a few hundred. Last I heard a game is about a 50K project (assuming you actually wish to "make" money doing this). Assuming you are not a bored rich person this means investors. Investors are like freelance bankers. if you dont have proof you can make money you wont get their money either.

---

quote:

Originally posted by Jeffery:
why don't you try 2D view tiles before isometric? Consider a lattice, 2D tile (squares) are just lattices composed of vectors that are perpendicular. Isometric is non parallel vectors but not necessarily at right angles. It creates the illusion of depth that way. I know how to program, I'm just no very familiar with some of the UI techniques. For example, how do you create a 2D picture but program it such that when you rotate the object it scrolls the 2D pic to crate an illusion of 3D?

---

quote:

Originally posted by Paul Vebber:
The key to a successful "open source" development project is to create 3 "reference design documents" before the first line of code is written. The Interface design document describes how you wat the player to interact with the game, what controls the player uses to do that and what information will be presented where in what situations. The Data Dictionary defines teh data structures that are used to represent the entities that exist in the game and environmental factors that affect them. Every "number' the game uses should be defined here. The Software design document is the "rules" for the game, or the way in which the data elements in the data dictionary interact with each other. These three documents ensure that everybody contributing to the game understands the "design intent" for the game. ALl teh "open source" efforts I have seen to date very rapidly become excercises in making the game "all things to all people" this dooms teh project form the start. A good year (or more) devoted to the group development (and most importantly agreement on) the contents of those three docs should be done before any body starts to code anything. Its like painting a house, the prep work is the hard part and takes much longer than applying the paint, but makes the difference between a good and terrible result. I've yet to see an "open source" group put the necessary prep work in. That is why all to date have yet to yield a product.

---

quote:

Originally posted by Paul Vebber:
The key to a successful "open source" development project is to create 3 "reference design documents" before the first line of code is written. The Interface design document describes how you wat the player to interact with the game, what controls the player uses to do that and what information will be presented where in what situations. The Data Dictionary defines teh data structures that are used to represent the entities that exist in the game and environmental factors that affect them. Every "number' the game uses should be defined here. The Software design document is the "rules" for the game, or the way in which the data elements in the data dictionary interact with each other. These three documents ensure that everybody contributing to the game understands the "design intent" for the game. ALl teh "open source" efforts I have seen to date very rapidly become excercises in making the game "all things to all people" this dooms teh project form the start. A good year (or more) devoted to the group development (and most importantly agreement on) the contents of those three docs should be done before any body starts to code anything. Its like painting a house, the prep work is the hard part and takes much longer than applying the paint, but makes the difference between a good and terrible result. I've yet to see an "open source" group put the necessary prep work in. That is why all to date have yet to yield a product.

---

quote:

Originally posted by Duane:
In my "real life", I design clinical interface applications so I do know the work required in designing, planning and bringing a project to conclusion. We don't do it quite the same way but the steps listed above make sence. OK, I will get to work on some prelims.

---

quote:

Originally posted by Jeffery:
What we need first before anything else is someone skilled in software project management. I agree that with large scale software development the coordination becomes more important than the actual coding. So why don't we first see if we can work out a framework from which to develop a game (sort of like making the team before making the game) before we start doing concepts. Have a structure organized so we know what resources we have and who can do what. This way no matter what final concept we decide to work on, the project won't get bogged down in disorganization.

---

quote:

Originally posted by Duane:

I agree with Jeff's statements. I had no idea that I would get more than one person really interested. I will start...other than myself, let's first see who is interested in actively participating. Please replay here and I will generate a list. PLease include all contact info and skills/experience, etc.

---

quote:

Originally posted by Sgt Wilson:
Hi Jeffery is this what you mean when you refer to rotating\scrolling 2d graphics ? (borrowed from Eastern Front II) Or the way Close Combat does it, by physicly rotating a single 2D image? Victor, tile based game interfaces are pretty straight forward. IMHO go for books on C++ & DirectX. Add my name to the petition for an additional forum. [ October 30, 2001: Message edited by: Sgt Wilson ]

---