Project basics

Okay first things first we need to establish some basics to make sure everyone is on the same page.

1. We've agreed this will be a strategy game and an RTS, so I'm assuming no turn based?

2. The language will be c++ and the program will be written from scratch.

3. Will we use opengl or directx?

4. Windows or Unix?

5. We are going to need a version control system (aka CVS) for something this big or else we're bound to run into issues and rolling back becomes a pain in the ass.

6. We're going to have to agree to a universal programming standard, which would include variable/funtion/class naming conventions.

7. We will have to maintain a loose documentation of the code and classes so that we all know and agree what a certain class does.

8. To manage the project's progress we will also have to establish milestones (not date milestones) so that we know what we're striving for.

9. Lastly, who is joining in on this and for what? This is what I know so far.
- Programming: Angeleon and Thirlan
---Network: ?
---Graphics engine: ?
---Game engine: ?

- Art: ?

If we want to do this for educational purposes then we probably should keep it small and have everyone do many things but we shouldn't raise our hopes too high in that case ;). We also shouldn't spend much time with game design until we have a basic engine, because frankly it gets in the way and more importantly none of us have any experience at all. So I think it would be foolish to make master plans only to find out that getting the most basic engine up will take about 3 months.

Some of this sounds like a lot of extra work and I hear you but you'll never see this project even get close to finishing if we don't stay organized as the beast grows. Also a good rule of thumb is stay pessimistic.

I thought the conventional naming standard for variables, usually, was thisVariable, _thisProperty, ThisClass, thisFunction. And is it really necessary to start totally from scratch? I guess it's better that way, but goddamn... aren't you at least using some pre-existing class libraries?

My vote goes for OpenGL/Windows. If there's any need for a dedicated server I'd want that to be linux compatible, probably. Then again, aren't you wanting to do something with DirectX? I guess that's not a bad option either. I don't know anything about making an engine though, heh. Hell I actually don't have much experience with any of it. Maybe I should just be a cheerleader ;)

Quote:

---

I thought the conventional naming standard for variables, usually, was thisVariable, _thisProperty, ThisClass, thisFunction.

---

One of the things on working in projects is to assume nothing and discuss almost everything. People have their own unique and bizarre coding methods that will freak out other people or make peer review a nightmare.

Quote:

---

And is it really necessary to start totally from scratch? I guess it's better that way, but goddamn... aren't you at least using some pre-existing class libraries?

---

Aye I was going to write that we use some c++ pre-existing libraries but it all depends on Angeleon. We're mostly going to let this be his pet project :) and it will be his decision to determine how much we want to learn as opposed to how much we want to accomplish.

Quote:

---

My vote goes for OpenGL/Windows. Then again, aren't you wanting to do something with DirectX? I guess that's not a bad option either.

---

I'm really okay with either and I can go just fine with OpenGL.

Quote:

---

If there's any need for a dedicated server I'd want that to be linux compatible, probably.

---

Dedicated server sounds great and how big it is will depend on whether we want to make this a mini-mmorts or just make it an IP lister.

Quote:

---

I don't know anything about making an engine though, heh. Hell I actually don't have much experience with any of it. Maybe I should just be a cheerleader

---

You're in luck because none of us do 8P and this is also why we would need to take some precautions.

How does one even go about beginning to create an engine then?

Well we start by figuring out how we want to decompose this thing. But before that we need to tell Angeleon to look in this forum section heh ;P

SEED Online was created using a free engine.

I could probably design sprites, or game icons, if you ever need help in that area.

Otherwise, like VF said, I'll be cheerleading xD

Quote:

---

Originally Posted by Beric

SEED Online was created using a free engine.

---

Now wouldn't using a pre-existing engine defeat the purpose of this project? Personally I'd hate to do it that way but if Angeleon want's too we will.

Quote:

---

I could probably design sprites, or game icons, if you ever need help in that area.
Otherwise, like VF said, I'll be cheerleading xD

---

Aye if we ever get past the basic engine we might need a lot of sprite artists because the human eye can see 24 frames per second which means we will at most need 24 frames of animation for a single action such as "attack" or "walk" or "run". So that then becomes 24*3*number_of_units. so that ends up to be a lot of work graphics wise 8P

I'm like Fishbarrel on this one, I'll bring the pom-poms for us cheerleaders

In all actuality, as things start to settle down in my life, I may end up with some time that I would be able to spend on such a project, but for now I'll stay out of the way and just lurk around this thread from time to time.

I know that you're considering building the game engine yourself, but I discovered this little gem on wikipedia. Strategus looks rather promising, if you consider using another game engine.

Would those Cisco Networking classes give me the skills to do the networking?

Quote:

---

Would those Cisco Networking classes give me the skills to do the networking?

---

I don't know ^_^
Let me go check out what they teach to see.

And the answer is... I don't think so. Seems like they would train you with Cisco tools and not teach you how to develop such things with C++.

By the way Fishbarrel, you should check Angeleon's account to see if he has rights to academics because I've seen him around but he hasn't showed up if you get what I'm hinting at. Once Angeleon shows up we can start figuring things out 8P

Yay! Access at last!

Quote:

---

Originally Posted by Thirlan

Okay first things first we need to establish some basics to make sure everyone is on the same page.

1. We've agreed this will be a strategy game and an RTS, so I'm assuming no turn based?

2. The language will be c++ and the program will be written from scratch.

3. Will we use opengl or directx?

4. Windows or Unix?

5. We are going to need a version control system (aka CVS) for something this big or else we're bound to run into issues and rolling back becomes a pain in the ass.

6. We're going to have to agree to a universal programming standard, which would include variable/funtion/class naming conventions.

7. We will have to maintain a loose documentation of the code and classes so that we all know and agree what a certain class does.

8. To manage the project's progress we will also have to establish milestones (not date milestones) so that we know what we're striving for.

---

1. Correct. Not turn based. Real-Time.

2. Again Correct. However, if you've been assigned a part, it is up to you how much you want to use others parts to finish it.

3. Dosn't matter, and if we feel like it, we won't really have to choose. Basically we make a wrapper class that'll handle all the functions that we want and then we can have both. However, for starters, even if I think the wrapperclass is a smart move to start with, making it for only one is better, and then it don't matter for me.

4. Windows. Since well, it'd be fun if people actually could play it. =) If we want it portable, we should do it in Java.

5. Yeah. I think it might be good idea, but honestly I'm not sure if the overhead is worth it for only two developers. I've used a CVS-thingy before called subversion, but I can't say I've gotten the hang of it. We should probably do it though, in case it will grow later.

6. Definitly. I could type one up today. It won't be anything special and so, but at least we'll have something to start with,

7. Sounds like a good idea.

8. Definitly...

Now to the question about Art. I'll talk to some people I know that might be interested, but any and all contributions in this area is welcome and will be credited ingame.

Any dedicated server will be for unix, since well, windows isn't really reliable enough. =) However, at this point it would probably just consist of a battlenet like thing. Just a place to meet and stuff. But really not neccessay since there exists things like Hamachi.

A game engine for a RTS isn't that much work for a basic thing. It is all about decomposition and ambition.

Personally, I'd be happy if we could strive for something a little bit more ambitious when it comes to the engine, so that we can have some more advanced commands rather than just click to move and attack.

Then if we can just divide the engine into good classes we'd be able to start working on it.

Ok, decomposition and plans has been discussed and some actual code has been started. It is merely a shell at this point and a crucial decision has come up: I loathe windows. From the bottom of my heart I detest windows and that's why I am a bit divided. I have dabbled with windows before and its syntax really bothers me. How a OS with that kind of syntax can have been allowed to grow that big I'll never know.

On one hand, I want us to do this completely from scratch, utilizing windows and OpenGL together. But then, on the other hand, which might take the upper hand, I feel that it would be wrong to not utilize the existing wrapperclasses for openGL so that it not only is portable(if not platform-indepentent), but also without most of the windows syntax.

I feel that using a wrapper class such as SDL or GLUT/GLtk could be acceptable. The bonus it adds could easily be greater than the feeling of not having done it ourselves.

Any opinions on this?

I'm not the one developing your wrapper classes, so I don't care what you do with it honestly. If it's easier to use pre-made shit, then do it. Unless you feel you're losing a tremendous amount of learning from taking a short cut, then do it.

Actually, the thing that gets avoided is mostly programming with windows syntax and api and a part of me feels that it is kinda silly to use windows when you can use something that is almost platform-independent.

What I'd like is for someone to tell me is whether windows is the bullshit I think it is nor not. If knowing its syntax like the back of your hand is really important for programming as a career. I can't believe it is but I havn't had a real job yet, so for me it remains to be seen, I guess.

I have no idea if that's the case, ask Thirlan.

Well finally I'm back on to a normal sleep cycle again...

From what I've seen and dabbled in you do not have to "use" windows. You only need windows to start a windows program and manipulate the windows screen you open for the game and that's about it... but I think it is possible not to even use windows. Opengl is setup very much the same way windows is setup with it's window generating class hence we could very well make it only using OpenGL. You only want windows if you want to do things with the operating system which we would if all the mouse clicks and keyboard pushes weren't handled by OpenGL. On the other hand we do need UDP protocols and sadly... we need to work with windows for that one OR develop a special dual unix/windows class that will compile differently depending on the operating system. Doing this will be both tricky and buggy because you need to know C compile codes and other ancient tech.

As for window's syntax system I agree it looks a bit bizarre but you're only at odds with it because it's not the same as the C syntax. The way you were first exposed to something will always leave a bit of bias but in this case it isn't so underserved ;)

actually, windows sockets aren't that hard to handle, not even the UDP. It is quite possibly the only thing they've done right, as it is practically the same syntax as in *nix.

I've got a class that handles networking rather well and compiles in both windows and unix, but I can't say that I've used UDP for much. You think it is preferable to use UDP over the reliable one?

Well, then... What do you say about using GLT or GLUT instead of windows for most things? I think we would still have to use windows for threads, but by just adding a #ifdef we could still make it portable. Threads aren't that much work. But apart from that, GLT or GLUT should handle everything else (well, not networking :)

Right off the bat, I'd say GLT out of the two, since it is only relying on openGL which makes it more portable...

The answer only depends on whether or not you want to work with the game industry. I say stick with windows for everything else unless GLT or GLUT. Obscure tools will not help you on the resume ;P

Quote:

---

Originally Posted by Angeleon

actually, windows sockets aren't that hard to handle, not even the UDP. It is quite possibly the only thing they've done right, as it is practically the same syntax as in *nix.

---

That's simply because they copied it from *nix :)

hmm, my damn ISP cut my internet yesterday, so I've not been able to do much... Having to move havn't been helping either, but I've done some work at least, even if it cant' be shared yet.

I've been studying GLUT and I find it to be a rather simple wrapper. It would do just fine and I think we should use it. The feeling of not having to bother with any of windows shit is just to great =)

It is, however, a event-based programming and does quite limit the main thread a bit in my opinion. It should be able to do everything, but I think two more threads should be useful. I.E. Three threads. One for player input (keyboard, mouse), one for network input and one to actually compute stuff. Pathing and other heavy things. Then the question is how to handle the communication between the threads.

Actually, it is maybe not much of a question as there aren't much of an option, is there? I can't really remember what they are in c++ either. We've got monitors and the lock-thingy, right? But then the lockthingy tends to be risky, right? We don't want a deadlock, now do we? I honestly need to refresh my memory as it was over a year ago I even touch these things. Normally I just try to avoid using threads if it can end up in a deadlock since that is usually the safer way, but now I think it would be better with threads and we will need some kind of safety-procedure for it.

You're talking about Mutexs (mutual exclusion). Dead locks only occur with poor design. Any of the theoretical based stuff you have problems with I can handle since that's what I'm good at. I've kept many "Operating systems and Architecture" notes that dealt with locks and how to do proper lock and step thread information sharing. For starters one often creates inbuilt locking data structures; one of which I will share in below.

The engine is where all the information resides and the threads take care of certain parts, often unique aspects so there wont be much need of locking information. For starters the network protocol thread can be kept in lock by creating a queue system. You get a message, you then parse it and lastly you dump it on a queue with two pointers. The back pointer where you insert new messages and the front pointer where you pop messages. When the two pointers are at the same position you can't pop the queue since it's empty. Once you enter a new message and are done you increment the pointer. Thus we have a mutual exclusion datastructure that will keep the system in step.

Anyway try not to code too much without me Angeleon. Pair programming helps in that two people understand the code so that when one is absent the other is at least present to explain. So before you go bananas we really need a CVS server up. I'm going to explore a CVS program I know right now and I'm going to bug either Fishbarrel to install it on his server or bug whoever manages the Duchy server. If we don't get this server up we can't easily keep track of who is doing what or the new changes that were made and I know you hate to make comments so we're going to minimize the risks here without imposing on you.

That's what I'm talking about yes. =) I started to remember that stuff a little after the post and I too came to the conclusion that the one system you mentioned will probably do perfectly. Though I had nothing as concrete in my mind. =P

And yeah, I'm not doing anything advanced or so... I'm just setting up the startup functions and making simple (empty) functions so that we will have the ability to start a window and handle input through openGL. Basically doing things that one only have to use once. So don't worry, I'm basically just setting up so that I know how glut does things. If nothing else, I'll be able to do it correctly faster next time.

Ah okay... I'm just a little cautious. Last time I worked with a group and one guy suddenly started doing everything and before we knew what happened the entire engine was coded by him. Then he left for a bit and because he didn't bother to share or let anyone else do crap we spent just as much time trying to figure out his code as we would have if we created our own engine (couldn't tell that was the case at first). When he came back we had to hold the bugger down and extract information from him with a plier because only he knew how it worked and he was giving us a tough time because of his heroic attitude.

This is also a good time to tell everyone else something important... Heroics are a BAD SIGN because it implies things were allowed to get so out of hand in the first place that only monumental feats could save it. A well managed project has no opportunities for heroics. The same goes for wars and a passage from Sun Tzu neatly fits this,

"To see victory only when it is within the ken of the common herd is not the acme of excellence. Neither is it the acme of excellence if you fight and conquer and the whole Empire says, "Well done!" To lift an autumn hair is no sign of great strength; to see the sun and moon is no sign of sharp sight; to hear the noise of thunder is no sign of a quick ear. What the ancients called a clever fighter is one who not only wins, but excels in winning with ease. Hence his victories bring him neither reputation for wisdom nor credit for courage. He wins his battles by making no mistakes. Making no mistakes is what establishes the certainty of victory, for it means conquering an enemy that is already defeated. Hence the skillful fighter puts himself into a position which makes defeat impossible, and does not miss the moment for defeating the enemy. Thus it is that in war the victorious strategist only seeks battle after the victory has been won*, whereas he who is destined to defeat first fights and afterwards looks for victory."

*"He who seeks victory from battle is destined to defeat", familiar no?