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.

In response to Actual Game Developing
0
101 Apr 26, 2003 at 13:00

i think davepermen is right. especially because this is an internet project. every artist that might want to support this project might be used to his own modeller, image format, etc.
sure it’s easy converting into one format but it’s just as easy supporting many file formats.

In response to Actual Game Developing
0
101 Apr 26, 2003 at 10:59

its easy enough to use devil and don’t even bother. just convert to one final format in the end. you can even encript that and all the fancy stuff if you want (i’ll use wavelet from.. mavel or something like that in the final code, but devIL before, as no one supports that mavel format in the editors yet..)

that is USEFUL. just download a freaking model from the net, with some texture in some crappy format, and you can use it.

patchwork artists are very fast at rapid prototyping, but they require that it should be possible to load anything. it just helps everyone.

(integrating devIL is easy)

0
101 Apr 26, 2003 at 10:45

touche!

In response to Actual Game Developing
0
101 Apr 26, 2003 at 10:43

well, even if the artists refuse to conform, it’s easy enough to convert jpgs, etc. into TGA.

In response to build or borrow?
0
101 Apr 26, 2003 at 07:45

vinmar: ditto :lol:

to test, i put null vote. now, it says i’ve already voted. oh well.

:yes:

In response to build or borrow?
0
101 Apr 26, 2003 at 04:01

build

0
101 Apr 26, 2003 at 00:05

baldurk : lol, depending on which part of the uk you’re from you shouldn’t be the one to complain about deformation of the own language :)

In response to Actual Game Developing
0
101 Apr 25, 2003 at 17:58

because it lets artist use existing material, just for testing purposes. they love to test existing stuff. i know that. and explaining them fileformat restrictions for simple testing if something at least looks interesting, then you’ve made something wrong. don’t stand in the way of your artists.

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

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