Messages

I didn't even realize you were kidding, so my bad.

As I said, I was "kidding a little bit". I mean, I was partially serious at the same time. Also I forgot to add smiley to my post! (funny how that changes the message)

It is obvious then that the "line" people are speaking about is being pushed further all the time by people who cross it.
If we keep that in mind, the answer on the topicstarter's question will be: cross the line a little; at first people will ban you, but later your work will be a part of mainstream. (Am I kidding now? heh)

What bothers me is rather the reason, why the game is supposed to be provocative on the first place? Is it because the creator wants to get some attention, or he tries to make his ideas more expressive?

Does that answer your question in any way?

Yes, I think so.

I was kidding a little bit though 

Just of curiosity, can someone elaborate what is that "line" that should not be crossed?
Is that a line at which players start to puke right where they sit, or come to your house with pitchforks and torches?

Also, doesn't it depend on what kind of "provocation" do you want to achieve?
What if you are going to, I don't know, provoke people to start World War 3 or something; should there be any limits then?

[THE NOW OFFICIAL ENGINE ISSUE TRACKER:]

LATER EDIT: THE NOW OFFICIAL ENGINE ISSUE TRACKER:
http://www.adventuregamestudio.co.uk/yabb/index.php?project=3


Thanks for Khris for pushing me towards it (although he probably did not know about it )
Let's gather useful suggestions and problems that could be solved by adding features to the engine. Some were mentioned on forums already.

-------------------------
EDIT: I have to do this :
Let me elaborate why I started this thread. We all have some things in mind for sure. However, there are things being mentioned around forums, that could miss our attention. I suggest to gather them, if you find something interesting just give a link and some commentary.
-------------------------

My first contribution to this:
------------------------------------------------------------------
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=46344.0
Basically the guy wants his character's walking animation to have extra frames that play only once at start and never repeat (unless animation is reset).
I am thinking about "repeat from here" frame flag (or loop property). But there should also be a way to tell engine since it is walking anim, he should jump from one repeatable sequence to another if character turns into different direction without stopping.
Any thoughts on how to better design this? I mark "design" word, since it is question of one at the moment, rather than coding.

Alright, I do not quite remember that movie series, but the woman on background looks familiar, so my guess is:

Resident Evil 2

Hmm...
- what is your game resolution?
- what is your game colours number (256, 16bit, 32bit)?
- what is your monitor default resolution?
- do you set a "scaling" parameter in game setup window?
- what renderer do you set in setup window? Is it DirectDraw 5 or Direct3D 9?

Also it could be useful to know:
- what was the size of background pic you imported?

Couple of things I forgot to mention.

I recently found a "funny" thing about Microsoft Visual Studio 2008 I never thought about before. It puts compiled *.obj files into one folder before linkage, hence making it impossible to have two source (*.cpp) files of the identical name even if they are placed in different directories.
I tried to find a workaround (like make it put them in relative dirs), but failed. People on the web mention proper workaround that is available only for MSVS2010.

That's interesting. Perhaps in best interest we should avoid having similarly named files altogether...but that almost predicates a foreknowledge of every file in the project. Perhaps file names should be prepended with the directory name? Seems redundant, but it would prevent collisions like this (which might not even manifest on compiler A but might explode on compiler B).

I think that's too much for such a rare problem. I think it would be better to resolve this by finding a compromise and name them differently.

4.0 Header Files [top]

Every header file should have predefined macros to prevent multiple inclusion. The preferred naming convention for these macros is two underscores, optionally the path followed by another underscore, the file name, underscore, and a trailing capital letter 'H'.

Just FYI, when refactoring I introduced following header guard template:

Code: cpp

__AGS_EE_GUI__CSCIDIALOG_H

EE stands for EnginE and; I also used CN for CommoN lib.
GUI is "module" or "part" name, I also used AC for general stuff, AUDIO for audio code etc.
CSCIDIALOG is literally a name of file.
We may use this, or come with something else.

Finally I'd like to put a vote in for using tabs instead of spaces; spaces tend to go really messy. On the other hand spacing with tabs can be adjusted accordantly and this can even put in the convention.

Heh.
Spacing with tabs can be adjusted accordantly to insert spaces instead of tabs. The question here is not what key to press, but what characters to put into text. I personally use this all the time, I am not a psycho to manually type 4 spaces each time I need a newline (or even more if I need complex indentation).

The big lebowski when he gets drugged at the guys house?

Damn, that was easy after all? Correct.

No

And no, it is not Tron Runner, or Bladetron.

No.

I really (really) hate question marks in the answer. Admiral is correct, your turn.

Sorry! I won't do that again

Well, I never participated in this, so I'll just post some random weird pic. Don't know if this will be easy or difficult.

Isn't that "Admiral"?

I feel a bit confused about this though, how well is it may be known outside of Russia?
I mean, are there any rules on movie popularity?

5.  Empty Loops - Presumably empty loops are place holders for future code.  In this case wouldn't it be better to document why the loop is empty?" 

I know I am probably nitpicking, but empty loops may sometimes be used when loop header contains implementation on its own. Just a random example:

Code: cpp

for (int i = 0; i < ptr_array.size && ptr_array[i] != NULL; ++i) ; // no code inside

(finding the first free slot in the pointer array)

Done, VS doesn't seems to mind if I use
-> -> ->int integer_var...........= 5;

I mean using sole tabs. Combining tabs and spaces is cheating ... no, wait, what I mean - this requires using two techniques when you could use one.

Of course if I try to paste in an identation not aligned to tabs, then in that case it converts the tab to spaces, gotta be the "smart indenting".
I like tabs because one tab is one tab regardless of tab sizes. Well, yes, I may be partial to it due to being used to C# with other projects.

I am starting to think we are speaking about different things... because I am not sure I understand what you mean.
You tell that "tab is one tab" regardless of tab size. But that does not make much sense. Do you mean that, on the contrary, space is not always one space?  Or 2 (4) spaces are not always 2 or 4 spaces? I didn't get this argument.
You mentioned C#. But as far as I know, MSVS default settings for C# code actually is to insert spaces instead of tabs when you hit Tab (at least that's how things are in my Studio installation).

On a side note I don't care much about number of spaces. 2,4 - I can use any.

Regarding local variables inside loops, declaring them inside is actually faster, at least for value types. I found out while experimenting with software filters.

I am not sure how that is possible... like declaring ONE "int a" before the loop is slower than declaring ONE "int a" inside the loop?
In C++ practice, for example, if you are using array class in loop, declaring it each iteration would mean there's memory deleted and re-allocated every pass, which, depending on number of iterations and how often this code is called, may result in BIG slowdown. On other hand, if you declare array object before the loop and use only it (resetting contents) it may be faster, since the array class (if it is correctly written) won't actually delete the memory it uses, but rather reuse what it already has.

I do not agree, leading tabs are superior and won't screw up on people with different tab sizes

Quote opposite - they will screw up text on people with different tab sizes, simply because the indentation will look different and not always aligned same way in all text editors.

For example, type this in notepad using tabs as indents and alignment chars:

Code: cpp

	int integer_var_with_long_name	= 10;
	int integer_var			= 5;

Now copy this to Visual Studio and see what will happen.
After, try the same with spaces.

Some thoughts on all this.
Please keep in mind, that many points in code conventions are usually stated in sake of consistency rather than better design or optimization.
For these I'll simply mention alternative arguments.

1.3 Braces
"Curly braces", { and }, should occupy a line by themselves (trailing comments are acceptable also). They should be at one level of indentation lower than the code they contain. This helps as a vertical guide (in addition to the indentation) in finding where a particular block of code starts or ends.

I used this style for a very long time, until one day I was asked by our lead dev to put opening brace on the same line as "if" and "for".
He explaned that thus more actual code lines will fit in the screen. At first that may seem a bit ridiculous, but not after you spent months studying hungreds of thousands of lines in 10+ years-old code
On other hand, that depends on average function lengths. If we are going to stick to writing smaller functions this may be not that important.

I did not notice if you've mentioned a rule of making each "if" and "for/do/while" contents be enclosed even if they consist of one line. This is sometimes suggested for it would be harder to make a mistake and add new line, forgetting to enclose it in brackets.

1.5 Naming Conventions
...
Local variables (inside of functions) can be named using either lower camelCase or c_style_notation, but should remain consistent throughout any single file.

Personally I like c_style_notation for function parameters and local vars more for some unexplainable reason
Also, if class private data is named using "lower" camelCase, using c_style_notation for locals will help to distinguish them.
There could be an interesting case though if private member's name consists of one word; in that case it would be indistinguishable from local vars. There may be options how to solve this, for example add an extra char as either prefix or postfix.

Regarding function names. There are two main options for how to form a function name, I've seen both being suggested in the web -
a) verb first, e.g. AddTableEntry();
b) noun first, e.g. TableAddEntry().
Personally I suggest this:
- for class members it should start with verb, and should not include owning class name; for example if we have class Table, member function should be AddEntry and not AddTableEntry. (Except if the function is supposed to deal with other object, like CopyEntryToAnotherTable() or something, but I guess this is obvious)
- for global functions it should start with noun, a name of object, or type, or context it refers to; for example: TableAddEntry, or even Table_AddEntry. This will make easier to find function you need, and function declarations will look much better when grouped by context.

Also, what about class names? Should they have "C" or "T" or some other prefix? Or be named plainly?

No file names (stored in the same location) should differ from each other solely by case.

I recently found a "funny" thing about Microsoft Visual Studio 2008 I never thought about before. It puts compiled *.obj files into one folder before linkage, hence making it impossible to have two source (*.cpp) files of the identical name even if they are placed in different directories.
I tried to find a workaround (like make it put them in relative dirs), but failed. People on the web mention proper workaround that is available only for MSVS2010.

1.10 Pointers and References
For pointers and references, the preferred convention is to have the asterisk or ampersand beside the name

You mean "before the name", right?
BTW an example code may help.

2.14 Integer Types

Using integer typedefs is must do in sake of portability!
(Ask JJS about that )

3.1 Namespaces and using Directives

You MUST mention that example from Google CC that shows how to make an alias for namespaces!
To be honest, I never knew about that.

3.2 Nested Classes
...
Consider making the classes separate, or using namespaces, unless the nested class is actually part of the structure of the outer class.

This should be read as:
- if a type is to be used only internally in the other class's implementation, prefer making it nested type;
- if a type is to be used public relatively often, do not make it nested;
- special case is for types specific for number of classes. Think of STL iterators, each container has a related iterator type; and although iterators are used outside of container pretty much always, they are still made nested types simply because they have identical names (iterator, const_iterator etc).
As an additional note: remember you can always make an alias to the long name by use of typedef.
For example, intead of writing

Code: cpp

CMyClass::CNestedClass::FuthermoreNestedStruct  obj;

do this

Code: cpp

typedef CMyClass::CNestedClass::FuthermoreNestedStruct CShorterName;

CShorterName obj;

3.4 Functions
...
Use static functions where appropriate, but don't create a new class just to group static functions together (use a namespace instead).

I think this needs some elaboration. What do you call "static function"? Do you mean just a function in appropriate namespace, or do you mean non-member function declared as static?

Code: cpp

static void function() {...}

The function defined like that will be only callable from inside the object unit it was compiled in. If you try to call such function from other unit, you will get linker error.

3.5 Local Variables
...
If a variable is defined inside of a loop then it will be created and destroyed with every iteration of the loop. Particularly when working with class types this may impact performance, so it is acceptable to define the variables outside of the loop using them when it makes sense to do so.

Never ever declare an object of container or string type inside a loop!

5.3 Interfaces
...
By convention, any interface classes should be named with the suffix "Interface" (e.g., "ClassInterface" or "FooInterface").

That is perhaps a case where I would strongly disagree. Adding "Interface" looks a bit lame, and it increases name length for nothing.
What about "I"-prefix? like IFoo?




Aside from all this, I believe that error handling should be discussed at the early stages of further development. This is perhaps not directly a question of code convention, but still worth mentioning.
It isn't always an easy decision. Most basic way is to return integer error code. However, there are situations when having more data along with result code could be useful.
I can name three general options that are well known to me. They all have similar traits though and have some advantages and disadvantages.
1. Return integer error code, but at the same time store additional data in error-handling system. That data will be available for reading by explicitly calling some GetLastError() function.
2. Use plain class object instead of integer as a return value, that may be simply copied and so passed outside nested functions. The object may contain error code, some auxillary data, or even text message. Unless said not to, it may pass this information to the error-handling system on self-destruction; the system will decide if to show any message to the user, write it to the log, or keep silence.
3. Return "error handler", which is declared as a pointer to integer error code, but de facto points to an extendable struct, managed by error-handling system. That handle may be used to get simple result code or cast to struct pointer to get auxilary data.
Or we may use a combo of these.
In any case I believe that
a) error handling must be uniform so far as possible,
b) it is better to have some kind of "error-handling" system (a singleton of some type) that would manage error data and messaging; I think it would be unwise to allow each function to decide what to do with error, since that will not only increase code size and make program vulnerable to non-consistent handling methods, but also counter any attempt to set up a global behavior for error messages.

Monkey, you are a bit insane, do you know this? I still think you could make a separate document, like WyZ did with his Big Plan. I hope you will do that with final CC version.

Use the Project pages!  There are both 'Issues' (bugs) and Features listing options.  I'll set up a sub project for the refactoring, giving CW rights, if you like?

Thanks for the offer, but I must think about that first. Perhaps I should write more detailed list prior to posting anything there.

Until a majority of commenting people tells you otherwise.

Umm, yeah. Problem with that is you never sure: did they silently agree with you, or simply did not read your post yet

This is a problem the engine would run sooner or later, since it wasn't made with having portability in mind.

Unfortunately my only suggestion is rather for the future versions of the engine - to implement totally virtual controls that could be rebound from game setup, for example.

I have a question: was there anywhere a discussion or any attempt to make a list of core features AGS engine needs? I do not mean suggestions like new script function or different editor look, but more general ones?
This is too early for actual implementation, but it would be probably nice to begin composing such list for future reference. I believe that is actually important, since adding random features without having principal direction in mind would eventually clutter both engine and editor.

I would list some here to show an example of what I am talking about.

1. I'll start with something ProgZmax mentioned in other thread:

Reformatting game saves so that they continue functioning after game re-compiles, patches, and work regardless of resolution.

In fact that isn't only about savegames. Literally everything in AGS is being serialized in such a way that it would be impossible to change a data structure (like add new variable) without breaking compatibility with the game made in previous version, let alone saved game.
Thus, I believe, primary concern should be to change the way ASG writes and reads data (game data and in-game saves) and make each data struct (or at least each main data struct) to detect what is the version and/or format of data it is loading and store it appropriately, with corresponding conversion if needed.

2. Removing static limits.
AGS uses static-size arrays for many things, and there's practically no more real sense in that. I don't mean these limits aren't enough, I mean there's no need in them since we may use dynamic arrays (classes), so that no one would ever bump into such limit.

3. Class system.
This is not only about rewriting existing sets of global functions and variables into classes (Character, Room, Hotspot, etc). There could be things that are better managed by classes to provide extensibility.
Think of Speech Style class, for instance, or Room Transition class, with possibility to add corresponding items to game project tree in the editor and customize them as you wish.

4. Engine plugin interface.
Apparently plugin system is made a bit awkwardly; there is a bunch of data structs, that mimic internal engine data structs, accompanied by commentary telling not to change anything in them (otherwise game will crash). Basically when a plugin uses IAGSEngine interface to get game data, plugin system plainly reinterprets internal data address as a pointer to corresponding plugin struct. I understand CJ had certain considerations when he was writing it this way, but if we are to improve the engine, this system should be probably enhanced as well.


Please, tell your thoughts.

PS. And can anyone please explain me at last, are there any development coordinators in charge here? Speaking of plans while there's no one to approve them is like standing at the town square yelling and hoping someone will listen 

...so a radioactive zombie horror? I'm ok with that, keep it up.

Zombies are not undead. They are people who took a lot of radioactivity from TV.

For the sake of this thread, I think you should be called a Grammar KGB Agent instead of Grammar Nazi.

or Grammar Commi?