寫過一些簡單遊戲的掛機指令碼，比如寶寶鬥場掛機指令碼，賺了一點小錢，不敢在這高手雲集的地方稱大蝦，僅僅是想和大家交流。
自己寫指令碼一開始很痛苦，不過寫多了以後，很多遊戲的子程式、函式都是可以借鑑的，甚至可以直接複製貼上過來使用，所以後面越寫越快。最後就是設計思路和程式設計習慣了，良好的程式設計習慣對指令碼執行的流暢程度、降低BUG發生率有很大影響。好了說說我的體會
1、多用函式，少用子程式，模組化：如果一個遊戲是頻繁的點選滑鼠操作，那麼需要建立一些函式來進行這些操作。我比較喜歡用函式而不用子程式。為什麼呢？因為函式有返回值，子程式沒有。我可以讓電腦做一項操作，但是操作的結果如何我不知道，這就需要返回值。比如找圖，找到了沒有呢？這個任務完成沒有呢？等等
2、關於找圖，每個圖用兩個以上函式判斷。因為遊戲經常會改動的，有些遊戲會經常對圖色做細微的修改，肉眼看不出來，但是找圖就找不到了，這個方法可以儘量減少出錯。
3、儘量少用死迴圈，堅決不用GOTO。我建議死迴圈只用在大的地方，如整個主執行緒，整個子執行緒。區域性儘量用for x代替或者do while。如果區域性一定要寫死迴圈，一定多加一些退出迴圈的判斷，同時加上執行迴圈的時間限制（迴圈開始前用t1=time記錄時間，然後在迴圈裡用datediff判斷迴圈消耗的時間）。
4、記錄：用ini檔案記錄發生的事件，包括任務是否完成，指令碼執行情況，是否出錯方便以後查詢修改。記錄滑鼠點選座標，因為大家喜歡用一種解析度以後不會經常調的，一次成功找圖後滑鼠點選座標會記錄下來，下次如果找不到圖了可以嘗試呼叫原來記錄的座標進行點選（不管你圖怎麼改，我還是有辦法），並且滑鼠座標周圍適當範圍予以截圖儲存，方便以後處理。
5、監控：可以讓按鍵精靈向郵箱發郵件，也可以用teamview等遠端控制軟體，有錢的話也可以考慮買ip kvm（我目前的願望，但是沒米）。
6、銷售：如果指令碼不是很完善或者遊戲更新很快，一定要勤快一點。不要對遊戲更新感到煩人，只要函式寫的好，更新遊戲只要加點圖，改幾條語句就可以了，而你的客戶需要經常依賴你，不管你收錢不收錢，他需要長期與你保持聯絡，這樣你的生意自然會越來越好。
寫過一些簡單遊戲的掛機指令碼，比如寶寶鬥場掛機指令碼，賺了一點小錢，不敢在這高手雲集的地方稱大蝦，僅僅是想和大家交流。
自己寫指令碼一開始很痛苦，不過寫多了以後，很多遊戲的子程式、函式都是可以借鑑的，甚至可以直接複製貼上過來使用，所以後面越寫越快。最後就是設計思路和程式設計習慣了，良好的程式設計習慣對指令碼執行的流暢程度、降低BUG發生率有很大影響。好了說說我的體會
1、多用函式，少用子程式，模組化：如果一個遊戲是頻繁的點選滑鼠操作，那麼需要建立一些函式來進行這些操作。我比較喜歡用函式而不用子程式。為什麼呢？因為函式有返回值，子程式沒有。我可以讓電腦做一項操作，但是操作的結果如何我不知道，這就需要返回值。比如找圖，找到了沒有呢？這個任務完成沒有呢？等等
2、關於找圖，每個圖用兩個以上函式判斷。因為遊戲經常會改動的，有些遊戲會經常對圖色做細微的修改，肉眼看不出來，但是找圖就找不到了，這個方法可以儘量減少出錯。
3、儘量少用死迴圈，堅決不用GOTO。我建議死迴圈只用在大的地方，如整個主執行緒，整個子執行緒。區域性儘量用for x代替或者do while。如果區域性一定要寫死迴圈，一定多加一些退出迴圈的判斷，同時加上執行迴圈的時間限制（迴圈開始前用t1=time記錄時間，然後在迴圈裡用datediff判斷迴圈消耗的時間）。
4、記錄：用ini檔案記錄發生的事件，包括任務是否完成，指令碼執行情況，是否出錯方便以後查詢修改。記錄滑鼠點選座標，因為大家喜歡用一種解析度以後不會經常調的，一次成功找圖後滑鼠點選座標會記錄下來，下次如果找不到圖了可以嘗試呼叫原來記錄的座標進行點選（不管你圖怎麼改，我還是有辦法），並且滑鼠座標周圍適當範圍予以截圖儲存，方便以後處理。
5、監控：可以讓按鍵精靈向郵箱發郵件，也可以用teamview等遠端控制軟體，有錢的話也可以考慮買ip kvm（我目前的願望，但是沒米）。
6、銷售：如果指令碼不是很完善或者遊戲更新很快，一定要勤快一點。不要對遊戲更新感到煩人，只要函式寫的好，更新遊戲只要加點圖，改幾條語句就可以了，而你的客戶需要經常依賴你，不管你收錢不收錢，他需要長期與你保持聯絡，這樣你的生意自然會越來越好。