There hasn't been a lot of brain storming going on by participants - could be a factor of availabble time, could be because the idea as is, is fine and we'll see how it goes, could be because people are worried I will trash their ideas (I hope not!), could be people are waiting for the next step. Whatever the case, I guess the brain storming phase is over and we'll just go with the farm/defend FPS as has been listed, and let it evolve as need be.
I actually sat down recently and started writing a design document. I approached it two different ways.
1. An outline with each step/phase listed out and details to follow
2. As a project table, with specific tasks assigned on a time table
In both cases, I found myself drifting off to unconsciousness after typing a few words. I found the process that incredibly boring. Every time I sat down and started to hash out a few ideas, the next thing I knew I was eating a sandwich and watching the idiot box. However, it would be a very good idea to get a formal plan done.
No Time to Code, you voiced a willingness to do the mundane. How do you feel about taking a stab at a design document? This type of thing grows as the game develops. Initially, we need a general organization and lists of:
1. What is the project? It's name, it's genre, it's setting, it's general description
2. Who's on the team? What are their roles? These will get defined and change as the project develops.
3. What do we need? Editors, graphics, sounds, music etc.
4. How will code/media be exchanged? Where do we store stuff? How do we maintain it?
5. What kind of time line are we looking at?
6. What's reasonably in scope? What's out of scope? What's on the back burner for later implementation? - By scope I mean, what is the bare minimum it will take to get things up and running?
That's the generics. The howto, what to do, and division of labor comes next.
But for now, take a stab at this, if you will.
For general submission of code, we need a specific organization. Submitted code should be in the form of procedures (subroutines) and/or functions that can be run independently and easily implemented as modules or libraries.
Though a pain in the butt to maintain but very useful, we should have a document that lists the variables, the image numbers, the object numbers, the memblocks, bitmaps, etc., that are used and their purpose so that coders aren't typing over each other's toes, and we can track down resources much easier. This can later or sooner possibly be included as an appendix in the design document. This can also inlcude the model list, image list, texture lists, etc.
Remarks/Comments:
Comment everything! Though a few standards need to be set. To make a comment of multiple lines, more than 2 as a general rule, always use REMSTART and REMEND and indent the actual comments:
remstart
Here are a few lines of remarks as an example
of a multilined comment. Grouping the comments
in an indented block makes them easier to read
when there are multiple lines of text.
remend.
For single line comments, use the REM statement:
rem the following line adds two numbers
value=a+b
Do not use the inverse quote ( ` )for remarks. Only use it to comment out lines of code. This way we can tell what is problem or experimental code versus information about code.
rem I want to test the different states og value depending on the
rem mathematical operation.
`value=a+b
`value=a-b
`value=a<b
value=a*b
`value=a!b
Procedures/Functions/Variables:
Start all procedure/subroutine labels with an underscore _ . That way they are easily identified anywhere in the code. If a function name is made up of multiple words, add an underscore between the words. Try and avoid using the underscore in variable names. That will help differentiate arrays from functions.
Try and avoid using long variable names. The longer the variable name, the more likely a misspelling can occur and be almost impossible to find as a bug in thousands of lines of code.
DarkBASIC Classic is a case insensitive language. That means it treats lowercase and uppercase as the same:
BIG=10 is the same as big=10
FOR a=1 TO 20 is the same as for A=1 to 20
It can get very confusing if there are varying cases in the code; especially for keywords. I personally can't stand typing in uppercase unless I have to. It's just an extra key to press or not to press. Consistancy here would make the code neater, but people have habits - so I'm not sure if it should be a mandate or not to use caps and/or no caps.
Code Format:
All code should use block indentation format. That means when you start a code block with
IF
ELSE
FOR
SELECT
CASE
WHILE
REPEAT
DO
OPEN FILE
FUNCTION
the next line that follows, if part of the code block, should be indented. Indentation/tab size should be 3 spaces.
if value = 10
a=-10
b=0
endif
Avoid multiple commands on one line. It can make debugging a nightmare and it looks sloppy. A few short commands make sense, but a string of commands on 1 line makes no sense:
if value = 10 then a=-10:b=0 while b=0:b=value/((object position x(1))*a):inc a:x#=:y#=5:z#=5:endwhile:yrotate object 1,90
There's no reason for the above nonsense. And there is something wrong with the line. Can you find it quickly? Now image it's lodged between 100 other similar lines.
@Caleb1994
Quote: "Couldn't we just start working on a basic engine to walk around on a matrix. if we are going to use a matrix as the ground, but i have heard they are slow. we also could just make a large plane for the ground. either way create the basic player controls and stuff that way when we get the map we can just plug it in and there we go!"
Sure. Why not? Though it's not the matrix's speed I worry about. It's the texturing. A matrix loses 1 pixel in between tiles and for any kind of repeating texture, except perhaps a solid color, you can always see the seams of the tiles. For functionality and eas of use, a matrix is great. For the look of the environment, I have never been impressed with a matrix. But that's not to say don't use it as a testing environment to try out different engine methods. Go ahead and build a movement engine. As I perceive the project I would say keep this in mind:
1. There will be an actual animated player character that will walk around and raise, lower, shoot, and reload it's weapon.
2. You'll need to be able to put the camera at the player's eye level and be able to see and aim the gun as well as move both player and camera around.
3. You'll need a testing mode and/or a 3rd person mode where the camera can be anywhere and independent of the character so that we can objserve the player's interaction with environment (to make sure they aren't walking through a wall or something and are at the correct height in the environment and their animation is playing correctly.
I have been designing a house and I based the interior height on 8 feet (2.44 m) or 8 3d units. However, this will be scaled up about 10 times so it will be 80 3d units high. Therefore, eye level for the character should be about 54 to 57 units. But the scaling may change depending on how things look. Anyway, with those preliminary figures in mind, you can set up the camera view and the movement speed. You can use primatives as place holders for the real character.
@Robert The Robot
TheComet is working long hours and may not finish designing the environment, or his waypoint system. I have in mind a waypoint system that shouldn't be too difficult to implment.
Based on the X and Z dimensions of a 3d environment, a 2d X Y bitmap, scaled to any size, perhaps 256 x 256 , is created on which one can use the mouse to draw a line from a start point to an end point. The line's x and y values are stored in an array along with it's path value. The distance between recorded points can adjusted to be ultra fine and precise, or with large gaps to be general - this can be applied to how the line is drawn.
The goal would be to draw multiple paths that can lead to various entry points of the house. There are maybe 10 entry points, There could be say 5 to 10 different waypoint paths that lead to an individual entry point making possibly 100 paths. Each enemy would be randomly assigned a path.
Perhaps you'd like to have a go at this? I can help if you get stuck.
@Obese87
We need a path finding system to track the enemy to the player when the enemy and the player are inside of the house and then when the player is outside of the house. The enemies will use a waypoint system to find the windows to try and get in. luke810, Nanogamez Guy and Alien all have dabbled in this for DBC. Alien's is super fast, but only implemented in 2d. Perhaps you could loook into any of these methods and see if you can adapt them so the can be used in our project. We would need the enemy to figure out the fastest route to get to the player while avoiding obstacles. Also the enemy needs to go up stairs if the player is up stairs. Care to tackle this? Here are the links to those path finding systems:
Alien 001
Nano A*
Luke810 A*
And I've read on the forum that there are DBC A* path finding systems in the code base, but I haven't looked there yet.
@All
I don't know if we should post code/media here or not. What does anyone think?
Enjoy your day.
