[Easy Rocket]子タスクの生成
require 'er' class SampleImage < ER::ImageTask end ER::init 640, 480, 30.0 image = SampleImage.new(:image => 'sample.bmp') image.create_sample_image(:image => 'sample.bmp', :pos => [100, 100, 0]) ER::loop do image.x += 1 image.sample_image.x += 1 image._draw end
SampleImage を image の子タスクとして生成する場合は、
image.create_sample_image
とします。これで SampleImage のインスタンスが image の子タスクとして作られます。 image に対して sample_image というアクセサも同時に定義されます。
ローカル座標とワールド座標
子タスクは親タスクのローカル座標に配置されます(上記サンプルでは (100, 100) )。つまり親タスクを移動させると子タスクも同じ量だけ同時に移動します。上のサンプルでは親タスク (image) と子タスク (image.sample_image) の両方の x を加算しているので子タスクは親タスクの2倍の速度で右へ移動することになります。
子タスクのワールド座標は wpos で取り出すことができます。
image.create_sample_image.wpos
draw と _draw
draw を毎回呼ぶことで画面への描画を行います。
またループ内で image.draw ではなく image._draw を呼び出しています。 _draw は内部で自分および子タスクの draw を実行します。
デフォルトオプション
ちなみに SampleImage のデフォルトの画像をこのように設定しておけば、
class SampleImage < ER::ImageTask image 'sample.bmp' end
次のように書くだけで同じ画像タスクを生成出来ます。
image = SampleImage.new image.create_sample_image :pos => [100, 100, 0]
[Easy Rocket]画像表示のサンプル
試行錯誤中の ER ですが、なんとなく決まってきた基本インターフェースの紹介です。
以下はウィンドウを生成して画面に sample.bmp を表示するだけのコードです。
require 'er' ER::init 640, 480, 30.0 image = ER::ImageTask.new(:image => 'sample.bmp') ER::loop do image.draw end
ER::init の引数は (screen_x, screen_y, fps) です。
ループ中にこの1行を加えれば右に移動させることができます。
image.x += 1
C 言語ユーザーが Ruby を使う
C 言語を知っていれば何となくRubyを書くことができます。 C++ の class を知っていれば Ruby の class を使ったオブジェクト思考プログラミングも可能です。
C で書いていたような書式の多くは Ruby にも通用します。(とくに)型がないぶんだけより書式がシンプルになりますが、ちょっとしたコツを覚えればすぐに Ruby で動作するプログラムを書けるようになります。
次のプログラムは C 言語の hello world です。
#include <stdio.h> int main() { printf("hello world\n"); return 0; }
これを Ruby で書くとこうなります。 Ruby では C 言語の main 関数のようなものは不要です。
puts("hello world")
puts は自動的に改行を行うメソッド(メソッドとは簡単に言えば C 言語の関数にあたるもの)です。これは次のように書く事もできます。
(追記: あとで気がつきましたが C 言語にも puts がありましたね。忘れていました(汗))
print("hello world\n")
print メソッドは改行の出力を行わないので文字列の最後に"\n"を追加してあります。また Ruby にも C 言語と同じように動作する printf があります。また通常は省略しますが文の最後にセミコロンを置くこともできます。
printf("hello world\n");
main メソッドと ruturn を書いてより C 言語ライクに記述することも可能です。
def main() printf("hello world\n"); return 0; end main();
これはあくまで上記の C 言語のサンプルに無理矢理合わせて書いただけなので 実際は Ruby の hello world には main メソッドも return もセミコロンも不要です。また main メソッドが自動的に呼び出されるわけではないので最後で明示的に main メソッドを呼び出しています。
メソッドは次のように定義します。
def メソッド名(引数) 処理 end
C 言語の関数定義には型が必要ですが Ruby のメソッド定義に型はありません。ちなみに引数はこんな風に記述します。
def main(str) print(str) end main("hello world\n")
いかがでしょうか? C 言語の知識があれば Ruby のプログラムを記述することは難しくありませんし、 Ruby の方がよりシンプルに同じ処理を記述できます。 Ruby には C 言語にはない便利な概念がたくさんありますが、さしあたってはそんなことを知らなくても Ruby の便利さを教授することはできます。
[Ruby]「オブジェクト指向スクリプト言語 Ruby リファレンスマニュアル」を読もう2
「Ruby の起動」はさしあたって興味がないので飛ばしました。本当は読んだほうがいいんでしょうけど……。
オブジェクトのページ
書いてあることがなかなか理解できません。ひとつずつじっくり見てみます。
- Ruby で扱える全ての値はオブジェクトです。
これはそのままですね。
- Ruby のオブジェクトに対して可能な操作はメソッド呼び出しのみです。
なるほど。
- あるオブジェクトが反応できるメソッドは、そのオブジェクトが所属するクラスによって一意に決定します。
あれ得意メソッドは?
- 所属するクラスはオブジェクト生成時に決まり、その後は特異クラスの導入以外、所属クラスが変わることはありません。
得意クラスってなんだろう。「特異クラスとは何ですか」を読んでわかりました。でもこれで所属クラスが変わるってどういうことだろう。
む、難しい……挫折しそうですががんばります。
[Ruby]「オブジェクト指向スクリプト言語 Ruby リファレンスマニュアル」を読もう
- ドキュメントがないとゆっている人がいるという噂
- このリファレンスマニュアルは良いらしい
この両極の話をよく聞きます。オレ自身「リファレンスマニュアル」をちゃんと読んだことはなく、すでに知っている機能の検索くらいにしか使っていません。最近は書いてあることが理解できるだけの基礎力がついてきた気がするのでちゃんと読んでみたいと思います。これは今年の目標にしたいですね。
リファレンスマニュアルの入手
まずはリファレンスマニュアルの入手から。「Windows HTML Help版」が好きなんですが、過去に自分でダウンロードしてこようとするとなかなか見つけることが出来なかった覚えがあります。最近は「Ruby の歩き方」があるので大変便利になりました(あれタイトルが「FirstStepRuby」に変わってる(追記:一時的な障害だったようです)。「Ruby の歩き方」って覚えやすくて気に入ってたのに)。
リファレンスマニュアルのデザイン
デザインの印象について述べておきます。このデザインはあまり好きではありません。はじめてみたときとても安っぽいものに見えて(そもそもリファレンスというのはプロによってしっかりデザインされるはずであると思い込んでいた。それまでOSS界隈に縁がなかったのもそういう思い込みを持つ原因だったかと。)、内容を含めたドキュメント全体が質の低いものに感じました。これは印象の問題でドキュメントの質なんて読む前だから知らないのに、とにかくそういうマイナス印象を持ったことを記憶しています。表面にとらわれずちゃんと物事の本質を見極められる人にはわからないことだと思います。Rubyistには本質の見極めがしっかりした人が多い気がするので、なはかなか理解されにくい部分かもしれません。私のように表面にとらわれやすい人に対して損をしているのではないでしょうか。
(しかし字が小さかったりコントラストが低かったりするだけでよく見えるなんてなんたることでしょう。)
はじめに
冒頭の文章(とくに「Rubyは単純で、分かりやすく」の部分)に疑問を感じますが、書いてあることの意味は全部理解できました。やっぱり私にとってはここはRubyをはじめたころ読むべきものじゃなくて今読むべきものですね。今読むと大変面白いです。私にとっての「はじめに」としては難しすぎましたが。
ちなみにクロージャを理解したのはつい昨日で、最近読み返している「ハッカーと画家 」に
def foo(n) lambda {|i| n += i } end
というコードが出てきてそれをたまたま調べていたためです。
前提として必要とされる知識が多い
ちょっと読むとすぐに感じることですがわからない単語が多いですね。
たとえば「awk の RS 変数のように働きます。」といわれてもわかりません。このリファレンスの対象者は決まっていたり明示されていたりしてるんでしょうか。
[EesyRocket]タスククラスの未実装部分
- 当たり判定
- 感性(vメソッド、aメソッド、動摩擦係数、静止摩擦整数)
衝突
ちょっと考えて思いついた当たり判定の案としては、オブジェクトとオブジェクトの関連を保持するクラス(タスクかな)を設けるとどうか。
Collision.new :gtasks => [gtask0, gtask1, gtask2]
こんな感じで2つ以上のGameTaskのインスタンスを与えて初期化とか。
衝突したときの処理を当たり判定クラスに書くべきか、衝突するタスクそのものに書くべきかは不明。
--
同じオブジェクトでも衝突する相手によって振る舞いが変わるから(敵、敵の弾、パワーアップアイテムそれぞれで違う)、衝突処理はCollisionが持つべきだ。
時機とパワーアップアイテムが接触した場合に実行しなければならないのはこの2つだ。
- 時機#powerup
- パワーアップアイテム#destroy
そうか、Collision初期化時にこのメソッドも渡せばいいんだ。
Collision.new :gtasks => [[ship, :powerup], [item, :destroy]]
とかかな。
[Easy Rocket]タスク
処理のプリミティブな単位を汎用的なタスククラスとして抽象化して、アプリケーションレベル(シーン生成とかキャラクタの生成・動作の部分)のコードを出来るだけシンプルにしようという試み。
Atsushi's Homepage 〜 タスクとはを参考に過去にも実装を試みた記録があるが、そのときはうまくいかなかったらしい。が今回はかねがねイメージしていた理想に近い形でタスクを使用したサンプルコードを書くことが出来た。
Taskの基本機能として実装したものは以下。
- 木構造
- 毎フレーム呼ばれるrunメソッドとdrawメソッド
Taskを継承したGameTaskには位置や向きの情報を持たせた。ImageTaskには2D画像イメージを描画する機能がある。
今回書いてみたアプリケーションのコードはこれ。えぐぜりにゃ〜にまだなっていないもので、キャラが武器を持っていてそれを動かせるだけ。SPACEキーで武器が伸びる。コードについてはフルスクラッチしているのでもはやえぐぜりにゃ〜の改造……なのか?(いちおうこのコードのライセンスは修正BSDということにしておきます)。
require 'er' include ER::Key class Font < ER::FontTask image 'images/font.bmp' end class Bg < ER::ImageTask image 'images/bg.bmp' transparent false end class Ring < ER::ImageTask image 'images/ring.bmp' center true end class Hand < ER::ImageTask images ['images/hand0.bmp', 'images/hand1.bmp'] center true transform true end class Weapon < ER::GameTask attr_accessor :extend def after_create @l = 0 7.times { create_ring } create_hand end def run @l += (extend ? 12 : 0) + (0 - @l) / 4 @l = 0 if @l < 0 (rings + hands).each_with_index {|e, i| e.pos.x = @l * i} end end class Ship < ER::ImageTask images ['images/ship0.bmp', 'images/ship1.bmp'] center true def after_create create_weapon :pos => [64, 0, 0] end def run angle.z += 1 weapon.extend = key.press?(SPACE) pos.x += (key.press?(LEFT) ? -8 : 0) + (key.press?(RIGHT) ? 8 : 0) pos.y += (key.press?(UP) ? -8 : 0) + (key.press?(DOWN) ? 8 : 0) end end class Scene < ER::GameTask def after_create create_bg create_ship :pos => [100, 100, 0] [ ['', [0, 0, 0]], ['', [0, 16, 0]], ['MOVE=>[CURSOR]', [0, screen.h - 48, 0]], ['SHOT=>[SPACE]', [0, screen.h - 32, 0]], ['WAIT=>[W]', [0, screen.h - 16, 0]], ].each {|str, pos| create_font :str => str, :pos => pos } end def run fonts[0].str = "WAIT=%s" % (ER::sync? ? "ON" : "OFF") fonts[1].str = "%02dFPS" % ER::real_fps end end if $0 == __FILE__ ER::do_init 640, 480, 30.0 scene = Scene.new(:screen => ER::screen) ER::do_loop do scene._run scene._draw puts ER::real_fps end end
以下でポイントだけざっと解説。
画像タスク
BgはImageTaskを継承した画像タスククラス。2つのクラスメソッドが定義されている。 image "file name" と書くとその画像タスククラスが使用するイメージファイルを指定出来る。配列を渡すと複数の画像でアニメーションを行う。transparent false で抜け色処理をOFFに。デフォルトは抜け色処理がON。
このBgクラスを使用しているのはSceneクラス。after_createメソッドの中で実行されているcreate_bgによって生成され、sceneの子タスクとして登録される。
タスクにはrunメソッドとdwawメソッドがあり、これらが毎フレーム呼ばれることになる。例えば次のように書けば毎フレーム1度ずつZ軸に対して回転する。
def run angle.z += 1 end
タスク生成と木構造
Weaponは時機が持つ武器となるクラス。武器は複数のRingと一番先にあるHandで構成する。Weapon#after_create でRingとHandを子タスクとして生成している。
7.times { create_ring } create_hand
次のように書けば、RingとHandの間接構造をタスクの階層構造で実現することができる。
pa = self 7.times { pa = pa.create_ring } pa.create_hand
scene以下全てのタスクは木構造になっているので、例えばトップレベルからWeaponのワールド座標を取得する場合は次のようになる。
scene.ship.weapon.wpos
posはローカル座標、wposは親タスクの階層をたどって計算されるワールド座標を示すVector3Dクラス。
言語内DSL
クラスメソッドとして呼び出せるimage等のデフォルトオプションの定義やcreate_task_nameによる子タスクの生成のような記述方法はRailsに影響を受けている。ActiveRecordではhas_one, has_many 等のクラスメソッドでモデル間の関連を作るが、ER::Taskではいきなりcreate_task_nameメソッドでTaskNameを子タスクとして生成し同時にアクセサも作ってしまうので、こっちの方が凶悪かも。
これまでDSLって言われてもピンと来なかったんだけど、これがまさに言語内DSLってやつかな?
er.rb の実装
Ruby/SDL でシューティングのコードを参考にしつつ Ruby/SDL を使用している(ので上のコードは擬似コードじゃなくてちゃんと実行出来る)。
そしてevalを初めて使った。evalを使っていると頭がこんがらがってくる。Rubyのスコープの仕組みとか知らないことばかりで大変だった。が大変勉強になった。もっともっとRubyを勉強しないと。
速度的にはVector3Dクラスとそれを使った演算部分がネックだと思うので、その辺りを拡張ライブラリにしてしまえば問題ないと楽観視している。
EesyRocket ver 0.0
この間の勉強会で、適当に作ったソースコードを日記に張ったりすると、いい加減なコードでもそれがその人の実力と見なされて……という話があったけどそういうのぜんぜん気にしないので張っておく。長いけど、張っておかないとこういうのすぐなくしちゃうので。張っておくと後で検索出来て便利だし。
(補足: eval("#{name}s << task") の部分と parent= で #{name}s を変更をしていない部分が手抜き)
er.rb
require "optparse" require "sdl" class Numeric def to_rad Math::PI * self / 180 end end class Array def merge_hashs inject({}) {|opt, e| e.merge(opt) } end end module ER class Vector3D < Array def x ; self[0] ; end def y ; self[1] ; end def z ; self[2] ; end def x=v ; self[0] = v ; end def y=v ; self[1] = v ; end def z=v ; self[2] = v ; end def +dpos Vector3D[self[0] + dpos[0], self[1] + dpos[1], self[2] + dpos[2]] end end class Task def self.default_options *args @default_options = args.flatten class_eval args.flatten.map {|e| <<TEXT attr_accessor :#{e} def self.#{e} v ; @default_#{e}= v ; end def self.default_#{e} ; @default_#{e} ; end def self.default_#{e}_defined? ; defined? @default_#{e} ; end TEXT }.join end def self._default_options @default_options ||= [] @default_options + (defined?(superclass._default_options) ? superclass._default_options : []) end attr_reader :tasks, :boot_counter, :parent def initialize *args @parent = nil @tasks = [] @boot_counter = 0 before_create _create *args after_create end def before_create end def after_create end def _create *args self.class::_default_options.each do |e| eval "self.#{e} = self.class.default_#{e} if self.class.default_#{e}_defined?" end args.merge_hashs.each do |key, value| self.send "#{key}=", value end end def inspect "#{self.class} #{@boot_counter}" end def parent=v @parent.tasks.delete self if @parent @parent = v end def children @tasks.map {|e| [e, e.children] } end def _run run @tasks.each {|e| e._run } @boot_counter += 1 end def _draw draw @tasks.each {|e| e._draw } end def run end def draw end def method_missing(meth_name, *args) if /^create_(\w+)\z/.match(meth_name.to_s) && name = $1 klass = Kernel.const_get(name.split('_').map {|e| e.capitalize }.join) task = klass.new(*args) task.kind_of?(Task) || raise("`#{klass}.new.kind_of?(Task) => false'") task.parent = self @tasks << task unless eval("defined? #{name}s") self.class.class_eval("def #{name}s ; @#{name}s ||= [] ; end") self.class.class_eval("attr_accessor :#{name}") eval("self.send '#{name}=', task") else self.class.class_eval %Q|def #{name} ; raise "Use `#{name}s' method!" ; end| end eval("#{name}s << task") return task end super end end class GameTask < Task default_options :pos, :angle, :scale def screen=(v); @@screen = v; end def screen; @@screen; end def self.screen=(v); @@screen = v; end def self.screen; @@screen; end def pos ; @pos ; end def pos=args ; @pos = Vector3D[*args] ; end def angle ; @angle ; end def angle=args ; @angle = Vector3D[*args] ; end def scale ; @scale ; end def scale=args ; @scale = Vector3D[*args] ; end def _create *args options = args.merge_hashs %w(screen).each do |e| next unless options.has_key? e.to_sym self::send "#{e}=", options[e.to_sym] options.delete e.to_sym end super options self.pos ||= [0,0,0] self.angle ||= [0,0,0] self.scale ||= [1,1,1] end def wpos if parent if (r = parent.wangle.z) != 0 r = r * Math::PI / 180 x = pos.x * Math.cos(r) - pos.y * Math.sin(r) y = pos.x * Math.sin(r) + pos.y * Math.cos(r) parent.wpos + [x, y, pos.z] else parent.wpos + pos end else pos end end def wangle parent ? wangle = angle + parent.wangle : angle end end class ImageTask < GameTask default_options %w(transparent transform center image images) attr_reader :w, :h def cx ; center ? w / 2 : 0 ; end def cy ; center ? h / 2 : 0 ; end def initialize *args @transparent = true @transform = false @center = false super end def load_image(fname) image = SDL::Surface.load(fname) image.set_color_key(SDL::SRCCOLORKEY, image[0,0]) if transparent image.display_format end def images=v @images = v.to_a @image = @images.first @loaded_images = v.map {|image| load_image(image) } @w, @h = @loaded_images.first.w, @loaded_images.first.h @loaded_images end def image=v ; self.images = v ; end def draw return unless @loaded_images image = @loaded_images[boot_counter / 8 % @loaded_images.size] if !transform || (r = wangle.z) == 0 && scale.x == 1 SDL.blit_surface(image, 0, 0, 0, 0, screen, wpos.x - cx, wpos.y - cy) else SDL.transform_blit(image, screen, r, scale.x, scale.y, cx, cy, wpos.x, wpos.y, 0) end end end class FontTask < GameTask default_options :str @@bm_fonts= {} def self.image v class_eval "def image ; '#{v}' ; end" end def _create *args unless @@bm_fonts.has_key?(image) @@bm_fonts[image] = SDL::BMFont.open(image, SDL::BMFont::TRANSPARENT) end @font = @@bm_fonts[image] super end def image raise end def draw return if str.empty? @font.textout(screen, str, wpos.x, wpos.y) end end module Key include SDL::Key end def self.screen; @screen; end def self.real_fps; @real_fps; end def self.sync?; @do_sync; end def self.do_init screen_w, screen_h, fps @do_full = false ARGV.options do |opt| opt.on("-f") {|v| @do_full = true } opt.parse! end SDL.init(SDL::INIT_VIDEO | SDL::INIT_AUDIO) flag = SDL::HWSURFACE | SDL::DOUBLEBUF flag |= SDL::FULLSCREEN if @do_full @screen = SDL.set_video_mode(screen_w, screen_h, 0, flag) SDL::Mixer.open(22050 * 4) @do_sync = true @real_fps = 0 @fps = fps screen end def self.do_loop count = 0 tm_start = tm1 = SDL.get_ticks while true while event = SDL::Event2.poll case event when SDL::Event2::Quit exit when SDL::Event2::KeyDown case event.sym when SDL::Key::ESCAPE exit when SDL::Key::W @do_sync = !sync? end end end screen.fillRect(0, 0, screen.w, screen.h, [0, 0, 0]) SDL::Key.scan yield screen.flip # FPSを固定 if sync? tm2 = SDL.get_ticks diff = tm1 + (1000 / @fps) - tm2 SDL.delay(diff) if diff > 0 end tm1 = SDL.get_ticks # 実際のFSPを計算 count += 1 if count >= 30 count = 0 @real_fps = 30 * 1000 / (tm1 - tm_start) tm_start = tm1 end end end class GameTask def key SDL::Key end end end
またえぐぜりにゃ〜
先日も書いたこのゲーム実は結構気になっていて、その後の動向もチェックしてたり。
面白いのはそれなりに派手なゲーム画面であるのに絵の量が少ないこと。同梱されているall.bmpを見るとわかるのだけど時機だって2パタンの絵しかない。キャラクタの向きを普通ならキャラクタ自体を回転させて表現したくなるが、それを武器の向きで表現しているのもうまい。
そして改造や再配布OKとのことなのでただいま改造中。もちろんRuby使ってます。
[Rails]さくらのレンタルサーバでRuby on Railsを動かしてみる
とりあえずDBを使う前の状態で動かしてみた。
RubyOnRails(さくらサーバ編)、 さくらのレンタルサーバにRuby on Railsを入れる手順 を参考にやったら意外にあっさりと動いた。
まず ruby 1.8.4 をインストール。
wget ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.4.tar.gz tar xzvf ruby-1.8.4.tar.gz cd ruby-1.8.4 ./configure --prefix=/home/xxx/ruby make make install
インストールした ruby にパスを通す。
手元の環境はzshなので次のようにした。ここは各シェルにあわせて。
#.zshrc PATH=/home/xxx/ruby/bin:$PATH export PATH
rubygems のインストール。
wget http://rubyforge.org/frs/download.php/5207/rubygems-0.8.11.tgz tar xzvf rubygems-0.8.11.tgz cd ../rubygems-0.8.11 ruby setup.rb gem install rails --include-dependencies
あとはさくらのレンタルサーバにRuby on Railsを入れる手順 にあるとおり。
rails プロジェクトとして例えば hoge を作成。
rails hoge
hoge/publicの.htaccessを書き換え
下の3行をコメントアウト。
AddHandler fastcgi-script .fcgi AddHandler cgi-script .cgi Options +FollowSymLinks +ExecCGI
config/environment.rbを書き換え
ファイルの先頭に下の2行を追加。
$LOAD_PATH.push("/home/xxx/ruby/lib/ruby/site_ruby/1.8") $LOAD_PATH.push("/home/xxx/ruby/lib/ruby")
hoge/publicにシンボリックリンクを張る
/home/xxx/hoge
を
/home/xxx/www/hoge
で公開する場合は次のように。
cd /home/xxx/www/ ln -s /home/xxx/hoge/public hoge
動作確認
http://xxx.sakura.ne.jp/hoge/ にアクセスしてみる。「Welcome aboard」が表示されるはず。
ドメインを使っている場合「ドメインの使用方法を選択してください」ところが「エイリアスとして使用する」になっているとダメ。「リダイレクトとして使用する」はOK。
Hello world
./script/generate controller hello
app/controllers/hello_controller.rb を編集。
class HelloController < ApplicationController def index end end
vim app/views/hello/index.rhtml を作成。
Hello world!
http://xxx.sakura.ne.jp/hoge/hello にアクセスしてみる。「Hello world!」と表示されるはず。
はてなダイアリーはじめました
<URL:http://d.hatena.ne.jp/kibidan5/>
今まではてなダイアリーを使ったことがなかった(なぜか他人のはてなダイアリーにも縁がなかった)のですが、最近増えた巡回先のはてな率がやけに高いので気になってたんです。
ブログサービスはmixiしか使ったことなかったんですが、他のブログを使うとtDiaryが客観的に見えてきて面白いですね。
いくつのも場所に日記を分散させるのは嫌なんですけど、いろんなサービスを使ってそれぞれの特徴とか違いを知ることには価値があるなと思いました。
[Ruby]private とかは最近は書きません。
Rubyをはじめたばかりの頃はそれまでC++ばかりを使っていたせいか、privateであるべきものにprivateがついていないのが気持ち悪かったんですが、なんでもpublicにするという人の話を聞いて何となくそうしているうちに違和感がなくなりました。何も考えなくなったし記述量も減ったので楽です。これまで特にはまったり不都合に感じたこともありません。あんなに神経質にprivateとかprotectedとか書いていたのに書かなくても別に不都合がないなんて不思議な話です。
Railsのコントローラークラスではhide_actionでなくてprivateを使ってますけど。
ライセンスについて
ライセンスについて迷い続けています。このRailsで実装しているMMORPGのコードのライセンスをどうするか。そもそもソースを公開すべきか非公開にすべきか。
実現しようとしているものはツールでなくてサービスです。ソースを公開しても実際にそのソースを使う人はほんのごく一部です。ひとつのサービス運営に対して多数のユーザーがつくという構造です。この構造ではオープンソースのメリットがほとんど得られないように思います。
更にソースを公開した結果複数の運営者によるサービスの乱立が起るとユーザーの分散を招くので、多くのユーザー獲得を目標とするMMORPGというサービスにはデメリットのように思います。
ソースは公開するけどそれを使ったサービス運営は禁止する、みたいなライセンスってないですかね。コードの断片を再利用されることについてはなんら問題ないし、公開することによってセキュリティーホールの発見や対策が迅速に進んだり、バグの発見やパフォーマンスの改善案が得られる可能性はあるかもしれません。
上記の話はサーバー部分に限った話で、クライアントで動作するプログラム(Webベースだとほとんどないんですが)については修正BSDライセンスでいいと思っています。
[Rails] 開発中のJewel-mmoのソースの行数を数えてみる
app ディレクトリの中のソースの行数を数えてみると、
total 2185 lines .rb 1104 .rhtml 1081
.rb の部分が1104。書き始めてからおよそ2ヶ月。思ったより少ないな。 2000行以内で公開したいところ。
ちなみにtestディレクトリは以下。テストの方が行数が多いようだ。
total 1777 lines .rb 1777
app内のソースコード別に見ると以下の通り。まだコントローラーとモデルが半分くらいしかできてないかなあ。
111 app/controllers/application.rb 24 app/controllers/area_controller.rb 2 app/controllers/cardshop_controller.rb 88 app/controllers/character_controller.rb 16 app/controllers/cron_controller.rb 34 app/controllers/doll_controller.rb 75 app/controllers/event_controller.rb 66 app/controllers/ghost_controller.rb 59 app/controllers/shop_controller.rb 45 app/controllers/user_controller.rb 55 app/controllers/world_controller.rb 30 app/controllers/party_controller.rb 59 app/controllers/battle_controller.rb 14 app/helpers/application_helper.rb 2 app/helpers/user_helper.rb 2 app/helpers/area_helper.rb 2 app/helpers/cardshop_helper.rb 2 app/helpers/character_helper.rb 2 app/helpers/cron_helper.rb 2 app/helpers/doll_helper.rb 2 app/helpers/event_helper.rb 2 app/helpers/ghost_helper.rb 2 app/helpers/shop_helper.rb 2 app/helpers/world_helper.rb 2 app/helpers/party_helper.rb 2 app/helpers/battle_helper.rb 5 app/models/area.rb 55 app/models/character.rb 123 app/models/doll.rb 50 app/models/doll_card.rb 3 app/models/doll_level.rb 4 app/models/event.rb 28 app/models/ghost.rb 6 app/models/good.rb 3 app/models/job_level.rb 4 app/models/map.rb 4 app/models/shop.rb 78 app/models/user.rb 7 app/models/user_character.rb 17 app/models/party.rb 8 app/models/battle.rb 7 app/models/battle_command.rb 1104 .rb total
行数を数えるのがなぜか好き。以前はソースの行数が多いとその分仕事をした気がして嬉しかったんだけど、今はサービス内容に対してソースの量が少ないことに喜びとか優越感を感じるようになった。
キャッチマインド(IE限定)というゲーム
数人でひとつの部屋に入り、一人がお題を絵に描いて他のプレイヤーがお題を当てるというゲーム。クイズ番組でよくあるそれを体感出来。要登録だがおすすめ。