多執行緒的敘事方式在網文中可行嗎?

時間 2021-05-30 23:39:42

1樓:

這個問題屬於我特別想回答的問題,關注了幾天,躊躇再三,試著回答如下:

實際上,我覺得只要希望講述乙個稍微複雜的故事,多執行緒敘述不是可行不可行的問題,而幾乎是必須的方式,提供多視角、多角度,盡可能並時展開的敘述,為讀者低筒乙個複雜的故事真正的上帝視角,這是更加現代的敘事邏輯,在資訊務求充分,對事物認知務求全面的現代,這是這種敘事方式的內在驅動。

相比起來,單執行緒,單獨視角的敘事是會顯得更傳統和不合時宜,並不是說它會被淘汰,而是說傳統敘事仍然佔據了所有故事講述模式的絕對主流,從進步的角度而言,不論是作者還是讀者,都應該嘗試更多的形勢,給創作和閱讀以更多的可能性。

說多執行緒和單執行緒乙個代表現代,乙個代表傳統,也並非絕對,簡單說,許多傳統經典作品裡也區域性地採用了多執行緒敘事方式,典型如《三國演義》,不典型如「花開兩朵各表一枝」;當然,《三國演義》的並時性不顯著,花開兩朵的區域性性更強。

基本敘事採多執行緒架構的,確實更多出現在現代作品上;問題來了,前幾天知乎有個問題,網路文學敘事技法處在世界通俗文學的最前沿嗎?

是否可以說網文的敘事技法處在世界通俗文學的最前沿?

本問題的多數答案大概是直接打臉那個問題大多數回答的現場。

如果網文的多執行緒敘事佔據主流,那倒是的確可以說網文的敘事處在了通俗文學的最前沿,但本問題的絕大部分回答是勸退的,多執行緒敘事方式在網文中不可行。

因為讀者不容易接受,也因為很難寫。

這都是誠實的說法,但在修辭的角度,有點兒充分性和必要性不區分。

可行是什麼?賺大錢,還是成就一部好作品?

多數人是從賺大錢的充分性上來說的,多執行緒敘述在當前網文讀者環境中接受度肯定不好,賺不了大錢。

從成就好作品而言,多執行緒敘事的必要性是有的,這裡的必要性實質上就是可行性。這種模式既可以寫出好作品,也可以賺大錢(但不一定,具體到當前環境下,可能性很低)。

回到最前,我的想法是,多執行緒敘事是講述複雜故事(包括立體的人物塑造)的必須,在表現性上是優於單執行緒敘事的。從個人實踐而言,它也未必需要更高的技巧和經驗,沒經驗的人只要多試幾回,很容易把握其內在的規則。

2樓:律律投資客

2023年了,還有人寫網文呢?餓死了吧?還活著?

社交還OK嗎?

七大姑八大姨沒催嗎?

朋友喊你喝酒,碼字完了嗎?

就這吧,多執行緒不行,我沒空看,吹不動。

3樓:淘故事

多線敘事多用於影視作品例如《瘋狂的石頭》、《樹大招風》、《盜夢空間》等

多線敘事手法的網文多存在於懸疑推理系列文章中,其他型別的文章全程以多線敘事推進是很考驗作者的邏輯和文學素養的,這篇文章作為讀者我覺得閱讀體驗較差,看著看著就罵罵咧咧的退出了(開玩笑),故事情節交代不清晰,故事線推進的令人摸不著頭腦...

4樓:小南打人

這個的問題就在於……

你寫了一段劇情,然後咔切到另乙個劇情。

只會讓讀者產生「你到底在寫什麼啊」的感覺然後刪書。

根本等不到你最後把它們串聯起來。

5樓:

對讀者不太友好.

我曾經在作文中嘗試這樣的敘事方式,結果並不理想,說實在的,過了很長時間以後我去看自己之前寫的,確實故事線讓人讀起來有點混亂.

6樓:小透明熊熊

論知乎提問用詞的重要性。

我想說你走錯片場了,原因在於問題裡的「多執行緒」,把乙個寫作問題,活生生推上了數碼熱榜前十。是無心之失還是AI太蠢,不得而知,但你一定能收穫一堆各路大牛關於CPU,多執行緒,併發處理的深入解答。

至於寫作內容,說實話沒看完,就說我吧,平時刷刷爽文是休閒解悶來著,怎麼簡單碾壓怎麼來,你起那麼多頭,哪個能記得住啊,哎呦腦殼疼。

當然,如果你的讀者是高知人士,那麼就上多執行緒,順序倒序插敘都招呼著,執行緒之間還要量子糾纏,反正怎麼燒腦怎麼來。你要知道,諾貝爾文學獎得主在爽文領域成為小透明,被三少和西紅柿碾壓,大概率也是常態。

所以重點在於,理解受眾、受眾、眾,然後才是寫作和故事。話說結尾的第二件半價又是什麼梗。

7樓:嚴重

三天的販罪和紂臨,就是多線型敘事,成績沒有驚悚好,但在讀者的口碑卻不差。

多線型不是亂碼型,朋友,你歹是條線,再考慮多的問題。

8樓:雪山飛狐

不管是多牛的人,寫多執行緒手法,都或多或少會引起讀者的厭惡。

這是因為,人的本能就是排斥突然變化的東西。

而有的人能做到讓讀者耐心看下去,是因為其功力高深,能把每乙個故事線都寫的無比精彩。

網文裡作者都擔心的乙個問題,就是換地圖。

就乙個換地圖,還是同乙個主角,同乙個世界,只是換了乙個故事線,稍有不慎都會流失不少讀者。

何況多執行緒……

好好先生很理解你,

畢竟這幾年出了個權力的遊戲,大家一看,都覺得自己也可以寫個裝逼的東西。

文藝青年一下子有了寄託。

(就像詭秘之主之前,龍空等論壇提起克蘇魯的幾乎沒幾個一樣。)但是你們有幾個看過幾本真正的這樣的書?

多少人死在冰與火之歌第一頁了?

馬丁老頭子,幹了一輩子編劇,不知道寫了多少作品,半個身子入土的年紀,寫了本冰與火之歌,算是火爆全球了。

但那是人家花了一輩子心血的東西。

你自問有那功力嗎?

你寫了不過千把字就來提問,連上架的字數都夠不到,單執行緒故事都講不清,又何談多執行緒了。

這不是哪個故事模式的問題,

這是……態度問題。浮躁。

9樓:

親測pov視角是可以在網文中使用的,但是寫起來會比較累,我用pov視角寫了武俠(160萬字,目前因為生活原因斷更中),多線索並行的方法,缺點是節奏比較慢,這一點可以通過其他線的精彩程度來進行調節。

同時多線寫法出現在網文需要進行彙總,那就是不同的人物線要產生乙個交集。

因為是初次嘗試,所以我寫的比較一般。

《縹緲風煙錄》_虯胡山主著_武俠_起點中文網

傳統武俠成績非常差,見笑。

之所以我會使用pov視角來進行寫作,源於平時看美劇的原因,同時發現一件事情多視角展現有助於構建比較複雜及龐大的情節內容。

不同的人物對於一件事情的行動,包括他們產生的想法對比起來是非常有趣的東西。

當然主要也是試圖用這種「劇本」的方式,來讓自己突破,將來可以駕馭更難的故事。

pov視角存在了很多的優勢,劣勢也很明顯,劣勢可以通過文字情節進行改良。

改良耗費精力比較大,網文更新強度大,寫到後面難免會出現舉步維艱的情況,想保持更新和質量非常困難,加上我個人沒什麼天賦,所以做的不是太好。

另外多線存在的問題就是bug處理的麻煩事,因為如果出現了bug,有的時候bug點牽一髮而動全身,當乙個情節要進行修改,往往會導致連鎖反應,然後就必須修改大綱。

因為才智不足,大概寫到30萬字左右,我的大綱就基本已經不可用了,到五六十萬的時候,故事已經和我的初始大綱基本互不認識,後面的情節是靠無數次的逼迫自己,或者避實就虛,強行圓轉,一步一卡來完成的。

當然如果你更擅長做大綱,又不是像我這樣有的時候會捨棄大綱,更按部就班的進展,我想應該就不會出現我遇到的問題。

究其根本還是自己的大綱做的不好,不夠充分,導致bug多,不精彩,多線敘事,pov視角寫作需要比正常寫作更加強硬的大綱。

如果你能把大綱細緻到幾十萬字,一切都不是問題,當然這也是我的想法,沒有時間實踐。幾十萬字是按照比例來的,比如二三百萬字之類的。

多線索寫作,pov視角會出現許多主角化的人物,對於塑造立體人物來說,是非常巨大的優勢。

有優勢的同時也擁有劣勢,因為戲份多了,就會出現搶奪光環的情況,當然事情總有解決的辦法,就看想不想辦法,這方面的辦法我覺得應該是對劇情的掌控能力作為決定因素。

10樓:「已登出」

我們從計算機的角度來看這個問題

你理想中的讀者:

算力強大,999核處理器,可同時執行幾十個虛擬機器,記憶體9999TB,還能自動幫你打遊戲!

事實上:

人家最多倆核,算力底下,和你們家放了四五年年的電腦一樣糟糕你告訴我,你還想寫多執行緒?

11樓:你喊五十我落錘

首先你要先講明白乙個故事,你要有優秀的情節,動人的劇情,高潮起伏的推動

然後你才能去考慮文字的使用,描寫的方式,敘事的手段。

你不能因為做的菜不好吃,就換盤子,換廚具。

首先它得是乙個好故事

12樓:流浪的蛤蟆

寫的非常糟糕……

每乙個情節都沒交代清楚,就岔開去寫其他東西了,閱讀感支離破碎,非常差……

不在於能不能寫多執行緒,這種寫作手法對不對,而是……你寫作的能力非常差……

多執行緒,需要把每乙個執行緒都交代的清清楚楚,明明白白,乙個多頭並進的小故事,往往要鋪開幾十萬字去寫……沒有試圖幾千字就玩多執行緒的……

13樓:弗蘭肯的壞遊戲

瀉藥,別玩太過,對於新手來說一切花裡胡哨的東西都不是亮點而是雷點,如果你不能保證這種多線敘事能製造吸引人眼球的懸疑和扣子,否則對你積攢人氣只有壞處。

關於多執行緒程式設計和CPU多核多執行緒的關係?

佐佐浪 具體到你的例子,修改優先順序和修改時間片是無法達到這個效果的。你需要做的是把你的計算部分做成並行的。單獨乙個執行緒是達不到你要的效果的。 棒子先生 首相我們了解下為什麼需要用到4核,這是由於不能盲目的提高CPU的主頻和頻寬,這樣會產生各種實際很難處理的問題,比如溫度飆公升等。舉例來說我們需要...

關於muduo多執行緒日誌的疑惑?

陳碩 首先,muduo 日誌是 diagnostic logging,不是資料庫的 write ahead logging。如果你要求 不丟失資料 那就不要用 muduo 日誌。其實你在 core dump 裡可以找到 buffer 中的日誌訊息,FixedBuffer cookieStart 就是...

多執行緒效能比單執行緒效能差的例子

有人在唱歌 Any kind of sequential program is not a good candidate to be threaded.An example of this is a program that calculates an individual tax return.A...