In response to I like C
0
101 May 03, 2003 at 09:31

Oops…maybe I should read former posts, before just posting my own opinion… B)

In response to I like C
0
101 May 03, 2003 at 09:27

as i said. you have to find out were to use what.

In response to I like C
0
101 May 03, 2003 at 08:20

Speed will always be a matter(that’s why asm is still used…)…
But today, it’s mostly much more important to have a clean, flexible code and short development times(that’s why asm is only used for single, easy to overview functions… :D )…

In response to I like C
0
101 May 02, 2003 at 22:47

baldurk : i was just making a point that things that once were useful only in enterprise applications become more important in game development, too.

In response to I love asm...
0
101 May 02, 2003 at 17:14

it’s also useful when other languages aren’t available.

In response to I like C
0
101 May 02, 2003 at 17:11

anubis: I think you may be missing the point. You don’t have to use all of C++’s features to write OO code. Simply classes and most likely inheritance. That’s all

CyraX: I don’t know why, but I find that for more complicated memory allocation commands new is easier than malloc. Just my opinion though

In response to I love asm...
0
101 May 02, 2003 at 14:55

hm, i like it too but you have to be good to beat modern compiler’s optimizations…

In response to I like C
0
101 May 02, 2003 at 13:54

i object that speed is the primary concern in games. it might have been but times have changed and clean and easy to understand code has become more and more important as games and engines grow more and more complex. one good example is the nebula device from radonlabs. the virtual filesystem they created was only possible with oop. it’s just amazing to have every object, every texture, every mesh and shader accessible through the console ( look at it if you don’t know it, it’s a great engine ).
so, c++ is my prefered language. my general aproach when designing my code is to seperate it into two catogories.

1. the code that is not speed sensitive, like loading resources, etc. here i use all the features that c++ gives me to write the cleanest code possible.
2. parts of the game/engine where speed is important, here i still use c++ but try to minimize the use of polymorphism, virtual functions, etc.

in fact i believe that if you write good c++ code the speed problem is totally irelevant 90% of the time. if you are passing down 5000 triangles in one vertex buffer that one virtual function call won’t hurt you but will gvie you an easy way to abstract the gfx api you are using.

In response to I like C
0
101 May 02, 2003 at 11:17

I like to use C++ - for organization.
I would NEVER dare to use Polymorphism - slows down the code. Inheritance - Building hte parent classes before my beloved class is instantiated.
C is more mature than C++. You need C++ ONLY for enterprise applications where speed is secondary. In gamez we have speed as the primary thing.
Anyone else feels that same?
I dont use “new” rather use malloc.
Everything that dear Bjarn Stroustrup said was for enterprises… not for us game developers :rolleyes:

In response to I like C
0
101 May 01, 2003 at 20:09

in one book of Game programming is written, that in game programming you should not ise these advanced things but keep code simple. However, I use classes and methods but I rarely use virtual ones

In response to I like C
0
101 May 01, 2003 at 17:18

that’s the only part of C++ I use - classes, for organisation. I don’t however use the more advanced OO things, like polymorphism etc. I can see how they would be useful. I definitely couldn’t write in pure C++ though unless I was being paid to

In response to I like C
0
101 Apr 30, 2003 at 19:28

I think object oriented languages are better for Game developing
I like object oriented languages more than procedural ones
Hence I like C++ more than C

In response to Actual Game Developing
0
157 Apr 30, 2003 at 18:58

fringe: yes, there’s space here. When things get busy and serious, we may have it hosted at sourceforge since they offer CVS service and some other goodies :)

In response to I like C
0
157 Apr 30, 2003 at 18:49

actually I like C++ more than C. C++ is my beloved language :)

In response to Language for new Game
0
101 Apr 30, 2003 at 13:55

Nice poll… I vote for C++

In response to Actual Game Developing
0
101 Apr 30, 2003 at 11:56

yet another idea :

why not place something like a sun ( big object with gravitation ) in the middle of the level.
this would increase the difficulty of the game a bit. and anyone who ever playe kspaceduell knows that it is also a big fun maximizer.
come to speak of kspaceduell. do we want a multiplayer mode ???

In response to Language for new Game
0
101 Apr 30, 2003 at 09:06

vinmar,

checked out the site, but no my nick was nothing to do with it. It was the first nick I used on IRC when I first cam to uni and was given to me by the person who introduced me to IRC because my short fringe sticks used to stick out ike it was made of plastic,

fringe

In response to Actual Game Developing
0
101 Apr 30, 2003 at 09:00

Thats really helpful thank you, it does look like alot of work though. I shall have a little go at something soon. Any idea where we can publish these things? Is there space here somewhere?

I had a thought and was wondering whether instead of doing a straight asteroids clone whether we shouldn’t make it a litle more exciting. The game could be made so that instead of just blasting all the rocks out of space the aim is to collect the smallest sized rocks with a tractor beam. We could even build levels where asteroids that collided would get bigger again. Anyway I don’t know what you think shout me down if you don’t like theidea,

fringe

In response to I Like D
0
101 Apr 29, 2003 at 20:17

I like it too
I’m not C/C++ programmer, I’m writting in Delphi but I like C++ and I have experience with Java. And I really like D, for wich I learned due to this forum

In response to Actual Game Developing
0
101 Apr 29, 2003 at 17:12

These are a few snippets from a research paper I wrote up for school on the subject of game documentation:

“The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise” (Ryan The Anatomy of a Design Document, Part 1). This very decorative statement hints to the many things the one game doc means to different members of a team producing a game. To the producer the document is a “bible” of sorts and must be “preached”—forced to be acknowledged by all the members of the team to have any real benefit. To the designers of the team it’s a tool to “flesh out the producer’s vision”. Finally to the programmers and artists the document is a set of instructions, goals and guidelines to obtain direction from. (Ryan The Anatomy of a Design Document, Part 1)

Tzvi Freeman, a teacher of game design and documentation at the Digipen School of Computer Gaming, offers a bullet list of 10 pointers to keep in mind when creating the design documents—hints that offer insight to creating a presentable paper. I’ll give you a brief synopsis of each bullet point: 1) Describe not just the body, but the soul: A ‘matter of fact’ approach to detailing the information of your game design won’t win over any publishers looking to buy up game titles—but a carefully, even passionately, worded document that consistently uses the opportunity to buy into the whole idea will win over publishers.
2) Make it readable: Lines and lines of unformatted cramped up text wont entice any one to read the document through and through—simple formatting can make all the difference.
· Plenty of white space
· Short text
· Direct the eye towards important material
3) Prioritize: Use keywords like important, indispensable and if possible to emphasize key material that represents the heart of your ideas.
4) Get into the details: Remember that specifics sell your idea. They also help to instruct team members in what to do.
5) Some things must be demonstrated: If a description of a complex idea gets too ambiguous, it may be helpful to construct a simple prototype to demonstrate the idea with.
6) Not just what, but how: Remember not to just document what needs to be done, but be sure to list ideas on how to do these things.
7) Provide Alternatives: There are some things that just wont be do-able, it will be important to provide other useful fill-ins that can take its place.
8) Give it a life: The design document as a whole should be an adaptable idea. There will be concepts “engraved in stone” that are crucial to game but the document should be susceptible to change with out losing its original intent.
9) Nobody should be able to say, “I did it that way because I couldn’t find any reference to it in the documentation”: This goes back to the details and specifics. Make sure its absolutely certain all areas of importance are covered in depth.
10) Deliver it in good condition: After all the hard work that’s gone into the creation of the document it would be a shame for it to not be read. It should be prepared in presentable configuration that is easy to handle and manage. (Tzvi Freeman)

The following headers should be included in the game documentation:
Introduction: Very much like a thesis that is heavily influenced by the goal to capture an audience and a secondary goal to give a –brief- idea of what you have in mind.
Background: Explanation of any reliance’s on previous products or projects conducted in the past.
Description: Explanation to the players of the game goals and game play. It should be expressed in a narrative of the player’s experience.
Key features: A list of unique ideas and plans to make the game play a fun and exciting experience.
Genre: A classification of game type, much as movies are classified by action, comedy, or drama. For games, the classifications range from puzzling action adventures to card and board games, including: Real Time Strategy, First Person Shooter, Action Adventure, Puzzle, Board, Role Playing, and Simulation games.
Platform: The medium the game will be available to. This includes computers—and their operating systems (MAC, LINUX, WINDOWS, etc.) as well as console systems (Game Boy, Playstation, XBOX, etc.)
Concept art: Little extra goods to use as prototypes to entice the reader into the game idea. (Ryan The Anatomy of a Design Document, Part 1)

Hope that helps :)

In response to Actual Game Developing
0
101 Apr 29, 2003 at 08:58

OK, this sounds like a good idea (the documentation). What should be written in such a document?

Hmm, the other thing is I am not quite sure what we are aiming for in the game, I have probably missed some posts or somethin’.
As far as I am aware we are starting with a simple game of asteroids to see if it is possible to work together and produce something for the forum. Is this correct? Are we adding any extra features to it or is it just going to be a standard asteroids clone?

fringe

In response to Actual Game Developing
0
101 Apr 29, 2003 at 08:47

SDL must be able to handle all the OS related stuff anyway.
Loading of the image formats and the Model files must be something of a better format - DLLs vis-a-vis SO.
Documentation:
I have been maintaining a list of the events and suggestions.
I guess I will start sending in the documentation etc soon.
However I would also like everyone to prepare a game requirments document of your own.

Preferred format : txt

In response to Actual Game Developing
0
101 Apr 28, 2003 at 20:36

What ever floats your boat. Im not knowledgable with nix’s yet and I know not there specifications. Im working on a plug-in interface via dll’s – hence the reason I brought it up. And your right on the complexity, you’d have to agree on a set of common standards and redo every dll version when ever a major change was made to the interface where if you use the compiler #ifdef tags changes can be made to all at once.

One last thing I’d like to recomend:
Start the game documentataion. I’ve glanced over a lot of things that have been said and some agreed upon but I cant see any official record of it. I suggest a mod Post an announcement type thread that only the mods can alter that lists everything that HAS been agreed to in a formated easy to read fashion. Don’t let this become another all talk–no walk idea.

In response to Actual Game Developing
0
101 Apr 28, 2003 at 17:13

I’m not really bothered about the image thing. Just playing devils advocate.

Amithran: actually, my opinion is that that would make things a good deal more complex. It would be simple if you can just slot dlls in and out, but remember that you can’t use dlls for anything other than windows. Although there are shared libraries (the same thing) I would have thought it would be easier just to have a common interface, and put the platform specific code in #ifndef / #endif blocks, so that it is all sorted out at compile time. eg.

// Main code:-

OSCode MyOSInterface;

// function calls, but no OS specifc data/variables/types
MyOSInterface.createwindow(foo, bar);
MyOSInterface.dostuff(blah, baz);

// declaration of OSCode (OScode.h?)

#ifdef _WIN32
class OSCode
{
// windows stuff
int createwindow(int width, int height);
}
#elif defined(_unix)
class OSCode
{
// unix/linux stuff
int createwindow(int width, int height);
}
#endif


that way the rest of the code doesn’t (need to) know or care which OSCode we’re using.

In response to Actual Game Developing
0
101 Apr 28, 2003 at 16:51

@baldurk

this isn’t a demand, but I won’t be able to help code if we are only using DX or only using windows code, so it would at least need to support OGL and SDL or whatever.

Sorry for chiming in here a little late, but I wanted to add a few thoughts on the graphics api question I noticed in pages 5 and 6.

I think the best-(not too difficult) thing to do is set up an interface for graphic and window calls. You can use .dll’s to handle the opengl, sdl, dx specific graphic calls. This would limite download size as the user could download the base .exe file and choose what graphic mode to run in and download the specific dll with the correct plugin.

ie.
glInterface.dll
dxInterface.dll
sdlInterface.dll

The windows and linux portability could be addressed using dll plugins as well in the same fasion.

The idea is every function call that would be related to a specific type of api should be wrapped up into a plugin-able interface.
The idea comes from reading the plugin tutorial on (shoot forgot website[im at school] Ill get the address later today).

functions like:
createWindow
resizeWindow
moveWindow
etc. for windows/linux platforms would be interfaced

and
pixel
drawTriangle
etc. would be interfaced with the graphical.dll’s

This would solve the whole problem of protability, as any one who contributes via coding would no longer be limited by graphical api.

Welcome to DevMaster, a community-driven game development website of posts and resources!

animation × 2
android × 2
indie × 2
royalty × 1
music × 1
licensing × 1
film × 1
glsl × 1
opengl × 1
linux × 1
ios × 1
audio × 1
gui × 1
contest × 1
native × 1
web × 1
testing × 1
hardware × 1
water × 1
webgl × 1
c# × 1