行車安全雷達

電腦輔助駕駛──有雷達感測自動剎車閃避功能(行車電腦依據感測得的360度空間狀態的突發變量緊急自動調整車的動量)的智慧車。其行車雷達不會是個體獨立的系統，而是如同無方向性的輻射波通訊一樣各個體之間需要協調。每部車有專屬的雷達波訊序列，只有收到屬於自己的回波序列才計算距離。如果回波抵達時剛好有別部車的雷達波發至，就會合成另一段波訊而使雙方的測距都失效，所以要搭配通訊機制交握令每部車的雷達波訊分於不同相位。

虛擬空間＝實際空間

是不是可以做一種網路遊戲型態， 同一個空間，有的人連線到這個城鎮空間玩Sim-City搞城市建設與經營，有的人連線到這個城鎮空間玩Sim-Building蓋建築，有的人連線到這個城鎮空間玩Sim-Emergency為城市做危機處理，有的人連線到這個城鎮空間玩Sim-Life打點市民的日常活動，有的人連線到這個城鎮空間玩第一人稱模擬遊戲。這樣應該很有趣，當有人從上空俯瞰地面玩戰略遊戲的同時，有人就在地面上玩第一人稱視角遊戲，在同一空間中兩種不同的遊戲類型也互相影響著彼此。第一人稱玩家亦可以以達成戰略玩家要求為遊戲目的，而戰略玩家可選擇將任務指派給NPC或線上第一人稱型態玩家，而兩種型態的玩家的活動都被影響與影響著同一個遊戲空間。例如Sim-City玩家指定在一塊地上蓋一家醫院，Sim-Building玩家可以去接這個case蓋這棟大樓並且維護，Sim-Hospital玩家可以來經營這家醫院服務Sim-City玩家的市民，而Sim-Doctor玩家也可以接Sim-Hospital玩家的case。戰術玩家的遊戲成果會影響戰略玩家的戰略成效，如果戰略玩家不信任線上第一人稱型態玩家可以完全將任務指派給NPC，而第一人稱型態玩家可能與戰略玩家調度指派的NPC互動。而這個城鎮空間也可以隸屬於更大的遊戲空間：島嶼、大陸、地球、太空。

更進一步，試想如果把遊戲空間中單位的內含參數選擇性地改為一個輸出入介面連接到實體單位與之同步，或把動作呼叫(function call)由更改虛擬空間中的變數選擇性地增加遠端呼叫，實體單位透過與遊戲客戶主機相同的介面接受並執行戰略玩家的指派，實體單位也就變成網路遊戲的一部份，成為虛擬空間與實體空間的橋梁。而實體單位亦把在實體空間中所感測上傳給伺服器使虛擬空間與實體空間保持一致，那麼虛擬世界的活動將等同實體世界的活動，網路虛擬實境遊戲將變成分散式擴增實境遊戲，可以把原本逼真模擬的遊戲系統轉作實際用途的指揮管理通訊勤務系統。

除了Ace Combat 6: Fire of Liberations《空戰奇兵6：邁向解放的戰火》

Tom Clancy出版的Ghost Recon Advanced Warfighter™ 《火線獵殺：先進戰士》與EndWar 《終結戰爭》《終極戰爭》

這兩款遊戲是XBOX360截至目前為止少有合我胃口對我味兒的遊戲

要跟我對戰或團戰的 上XBOX Live找我吧 (限週末)

這三款遊戲的逼真場景有一點讓我覺得有點不真實

就是戰場上竟然看不到半個平民百姓 空蕩蕩的城市只有敵我雙方的軍隊在活動

《先進戰士》裡是到處停有民車可供打靶練習但卻不見軍人以外的半個人影(除了任務要解救的人質以外)

《終極戰爭》裡甚至所有街道都空蕩蕩沒有半台民車

《空戰奇兵》空中也見不到半架民航機 地上也沒有任何民人民車

真實的戰場環境不會這麼單純

在真實戰場環境你每個動作都要考慮平民安危

《終極戰爭》裡的所有建築物都可以被打壞

《先進戰士》裡 車可以被打爆 窗可以被打破 牆上地上會留下彈孔

很想有一套遊戲能綜合包含以上3種的所有遊戲類型於一個遊戲空間

等到有一天Google Earth達到相當的精細程度 就可以直接在Google Earth上做game玩

那就更符合真實世界的狀態了

真實的戰爭可不是兩方人馬廝殺打打而已

後勤生產補給部署 與媒體應對 處理群眾問題 ...... 等等琳琳種種都可以納入戰略(謀略/策略)遊戲

每一人物的活動也可再做一項第一人稱類型戰術(技術/技巧)遊戲 甚至要搞RPG也行

所有類型的遊戲都在線上同一個虛擬空間中進行

LG GD910 touch watch phone

精簡一致化行動餐飲盒

隨身攜帶兩個，一個用來裝吃的，一個用來裝喝的，吃及喝用同一種容器符合「少樣產品多樣用途」的原則。外層是隔熱的氣凝膠材質，內層是導熱的不銹合金，導電即可加熱。直接以此容器烹飪，除了野餐外用，內用餐桌上亦用此單一種容器取代各式碗盤。蓋子與盒子的接縫是有螺紋可旋緊氣密，盒底也切割出只有隔熱氣凝膠外層的蓋子，打開蓋子就可以用火加熱盒底的導熱不銹合金內層來烹飪。

ASUS EeePad

智慧型遙控器

現代人隨身攜帶可程式手機，各種遙控器的功能都可以合到手機裡。一般遙控器的波訊序列有被隔空側錄的風險，使用可程式遙控手機可以自訂密碼列表放在遙控端與被遙控端各複製一份，每發一次訊被接收端收到就將下一次的密碼指到密碼列表的下一個的下一個，並回傳列表的下一個密碼給遙控器告知「收到」以把下一次遙控的密碼指到密碼列表的下一個的下一個，如此，就算被側錄也不會被盜控。更進階，放一道formula在遙控端與被遙控端各複製一份，當遙控時先對時，然後以time為參數輸入formula，其輸出就是雙方約定的密碼。

Distributed Window

視窗系統裡不論是網頁或各種格式的圖文件都完全是由視窗控制元件所組成，但卻是轉換成不同於記憶體中的格式(如XML)儲存，多了轉換程序當然是降低速度，為何不能直接將視窗控制物件直接map？因為基礎視窗控制物件含有指向沒有class template描述的unmanaged area的指標，無法像完全存在managed memory的objects一樣直接serialize(map data & reassign addresses)到storage，目前基礎視窗系統還未完全物件化，仍是傳統軟件。只要基礎視窗控制物件能serialize，除了免掉格式轉換程序外，視窗控制物件能在網路上直接傳輸，一個視窗就能以甭轉成以XML傳輸的方式由網路上各方的元件組成。Serializiable window直接儲存視窗物件，回載時就甭像傳統window在生成時先由base class的constructor初始化一次各屬性variable然後由sub-class(es)的constructor(s)再assign一次各屬性variable覆蓋這般多此一舉了，而是直接映射回記憶體。但如此儲存或傳輸的size會變很大，serializiable object包含sub-class與base-classes所描述的所有object fields，而XML只記載要變更的member的script，binary object field反而比textual tag script大。所以，我另外redesign了一套object機制，將object與class合併成一個sense graph，此機制使得能夠僅儲存或傳輸sub-sense，base-sense(s)僅儲存或傳輸一次而不用每遇到一個sub-sense就整個儲存或傳輸一次，如此就不會造成太多的重覆而消耗太多的資源。Serializiable window也讓distributed window成為可行，如此，以XML為基礎的Web就可以淘汰了。Distributed window目的是要取代web，免除web每換一個page就要跑一大串switch(TAG)‧‧‧ case "OOO": controls.add(new OOO())‧‧‧ switch(PARAM)‧‧‧ case "XXX": ‧‧‧ OOO.XXX = xxx‧‧‧ 拖慢速度，改以直接變更distributed controls然後才repaint，不會看到換頁時繪圖不完全的破碎殘影。Applet/Flash是將原本由本端storage載入程式機器碼改到由單一遠端伺服器載入，並不具「distributed」來自多個伺服器的特性。