Please Focus on Code Quality

[LaughingEddy]

Hello,

While there have been some very welcome changes in recent releases (load sharing between repair bays, for example), there has been as marked downturn in the overall quality of the code.

Speaking as a professional developer (non game) and an experienced gamer (over 20 years), I would like to take this opportunity to remind the developers that, no matter how balanced, innovative or engaging the gameplay, no game will be fun if it is constantly crashing, slows down after extended play etc, etc.

I would encourage the developers to make code quality their main priority for the next major release. Having a well-structured, robust code base will empower them to develop the the gameplay without distractions.

Code quality does not just encompass just crashing, but directly affect elements of gameplay. As examples, I have these specific concerns about gameplay that I feel fit in to this philosophy of code quality:

1. AA weapons blocked by walls, not by LoS (for example, can't put AA on a cliff, overlooking walls).
2. Units change their repair orders(!). This is unbelievably annoying and a major breakage of gamplay.
3. Air units do not consider buildings when doing route finding, often flying directly into them.
4. LoS calculations inconsistent.
5. 'Stand Ground' order is ignored.
6. Unit-passing-unit navigation is very poor (as-is, it would be better for one unit to just stop, while the other negotiates around it).
7. SAM missiles have unlimited range, fly through anything etc.

[Zarel]

Yeah, gosh, devs, go focus on code quality more!

More seriously, I'm planning on fixing #2 soon, I can try to fix #1 as well, and some rebalancing should make #7 irrelevant. I thought I fixed all the situations where #5 appeared in 2.2.2 - see r7926 - if there are any specific situations where they still occur, please provide details.

That leaves #3, #4, and #6, which I've been annoyed by as well, but not really my kind of thing to fix. As always, we accept patches.

[Ilr]

Those thing strike me as very difficult to fix (considering how Pumpkin knew about them 10 years ago and couldn't fix them all).

So I wouldn't link them directly to "code quality". When I think of code quality, I'd expect the avoidance of writing Spaghetti Code to be the only absolute expectation of any community that is donating its time and resources...

[cybersphinx]

there has been as marked downturn in the overall quality of the code.

Have you compared the released code to what we have now, or is this just based on observing the behaviour of the game?

This was said about the code shortly after it was released:

The source code is often referred to a ball of yarn that has been ripped up and then attempted to be repaired with duct tape. Unfortunately, many programmers agree that it is in even worse condition that that.

Not Quake-like quality, unfortunately...

[lav_coyote25]

actually - even the pumpkins themselves left little notes in the original release of the source code - stuff they left in when they GPL'd it. some of it was truly interesting - such as the little tidbit about gnarly c warts and all... plus other little gems about not fixing something - because if they did it would break the whole game and he wasnt sure if they would be able to fix it back... so yeah...the dev's have come a long ways with all of that... and as was pointed out - if your willing to submit patches pick a piece of code and have at it. thanks xD

[psychopompos]

That leaves #3, #4, and #6, which I've been annoyed by as well, but not really my kind of thing to fix. As always, we accept patches.

and #7!!
second only to #6 in that both look silly, but beyond the other issues, get tenured units killed more frequently.

[A4tech]

I think - better code quality equal to more time to spend on it. Unfortunetaly WZ coders have no time to spend on hardcore coding. Why? Because they have theyr own life's, job's, wife's, kid's and problem's... In my eyes there is one solution - community have to donate this project. And we will see the progress, no doubt.

Personaly, i will donate a little...

[Zarel]

and #7!!
second only to #6 in that both look silly, but beyond the other issues, get tenured units killed more frequently.

I already said I would fix #7, weren't you paying attention? >_>

[Tenoh]

I thought this problems were hardcoded in the game engine it self and cant be fixed!

[Per]

there has been as marked downturn in the overall quality of the code.

Really? That would be sad. However...

As examples, I have these specific concerns about gameplay

These examples are all except one problems that have been there since the beginning.

So while I cannot prove you wrong, your examples to the contrary are not exactly compelling.

Of course, if you have any good suggestions as to how we can improve code quality, I'm all ears. Especially if you are willing to help out with it

[psychopompos]

I already said I would fix #7, weren't you paying attention? >_>

my bad, sorry bout that.
was close to 4 am when i was posting.

[new paradigm leader]

hell i love the game at present but then i have the psx game and have crashed it so many times its unreal i like the flexibility of this over the psx version

[-Kosh-]

Hello,

While there have been some very welcome changes in recent releases (load sharing between repair bays, for example), there has been as marked downturn in the overall quality of the code.

Speaking as a professional developer (non game) and an experienced gamer (over 20 years), I would like to take this opportunity to remind the developers that, no matter how balanced, innovative or engaging the gameplay, no game will be fun if it is constantly crashing, slows down after extended play etc, etc.

I would encourage the developers to make code quality their main priority for the next major release. Having a well-structured, robust code base will empower them to develop the the gameplay without distractions.

With someone with 20 years experience you should know that if you are given a project that you know nothing about, have no design documentation, were not in on the planning meetings, and not in touch with the original crew that created this program, then you can't really complain about the state of the code, unless you can bring up specific examples of bad code that these guys created.

We all want to see a better product, but without a massive influx of talent, then this project will continue to hobble along.

Look at the timeline, looks like they only have 1 person active, then a few others names pop up from time to time.

[Zarel]

Look at the timeline, looks like they only have 1 person active, then a few others names pop up from time to time.

Which timeline are you looking at? o_O

Per (sendai), cybersphinx, and i-NoD have all been pretty active lately. Giel (muggenhor) looks to be active again. Buginator and I also go through periods of activity.

See: http://developer.wz2100.net/timeline?fr ... ate=Update

[-Kosh-]

Which timeline are you looking at? o_O

Per (sendai), cybersphinx, and i-NoD have all been pretty active lately. Giel (muggenhor) looks to be active again. Buginator and I also go through periods of activity.

See: http://developer.wz2100.net/timeline?fr ... ate=Update

The keyword there is lately.
I meant the overall scope for the past 3-4 months, there can be no denial that there has been one active person holding up the ship, with a supporting cast.
Do not get me wrong, I know how a open source project works, and this is typical, but your definition of active is apparently different than mine.