'yeah new' should allow for choosing a game name

[QuinnWilton]

Right now, all code needs to be located under #{ROOT}/code

It would be nice if we could specify a name, which would determine the namespace used for the entry-point. i.e.

> yeah new trespass

Creates:

lib/
lib/trespass.rb
Gemfile

Where trespass.rb contains:

class Trespass < Game
  def setup
  end

  def update(elapsed)
  end
end

This would bring the yeah configuration in line with the standard for Ruby gems. Ideally, this would also involve some sort of configuration file, reminiscent of a gemspec.

P.S. I saw the framework on HN, and I really like it, nice job! I'm using it for Ludum Dare 30 this weekend, so don't be surprised if I send a flurry of issues/pull requests in over the next 48 hours :D

[aostrega]

Hello Shane Wilton,

I like where you are going with this. The current game project structure does not feel ideal, so I am definitely up for making improvements to it.

Since 0.3.4, you can actually specify a project name in yeah new - though right now it only sets the directory name. I am up for it additionally setting the Game subclass's name and filename.

We could use a gemspec-like configuration file (a yeahspec?), since it would be handy to specify things that do not belong in code, like game name (for webpage/window/app title).

I am less keen on changing the code directory to lib. The Ruby community seems to consider the lib directory a library code directory, typically for a gem. A Rails app keeps the bulk of its code in app. In light of this, it seems more idiomatic to not use lib for Yeah game code.

This is not directly related to what you suggested, though in a Rails app, app also contains assets; while in Yeah assets is kept outside of code, and it is nice that way, which is why I think the code directory should also not be changed into something like game or app.

I propose we start with an alternative conservative version of your plan:

$ yeah new jump_n_run should create a project structure like this:

assets/
code/
code/code.rb
code/jump_n_run.rb
Gemfile
jump_n_run.yeahspec

where jump_n_run.rb contains:

class JumpNRun < Game
  def setup
  end

  def update(elapsed)
  end
end

and jump_n_run.yeahspec contains something like:

Yeah::Specification do |s|
  s.name = "Jump N Run"
end

This is not final, I would much like to hear your thoughts!

---

In response to P.S.: I am happy to hear that people already want to use this to make games! Please do bring up any issues or difficulties you have - that would be awesome information since it would provide a clearer idea of how exactly to push the framework forward. I plan on making Yeah making game development as painless as possible.

[aostrega]

Today's 0.3.5 release is part of the way there. A new project's game subclass name is based on the name passed into yeah new, and code/code.rb is gone in favor of a code/game.rb entrypoint.

I still think a yeahspec is a good idea, so that is likely coming up - I also like the idea of making it possible to specify the entrypoint there.

[QuinnWilton]

Wow, props on the fast response to my suggestion!

Sorry if I sounded a little pushy in my original issue, looking back it definitely comes off that way, but I meant for the issue to be more of a discussion.

I like where you're headed with the most recent change, and agree that putting things into lib/ probably isn't the greatest solution.

I'm not entirely sure what a yeahspec should be responsible for, but there might be ideas to be garnered from other frameworks, like Love2D: https://love2d.org/wiki/Config_Files

[aostrega]

The original post did not sound pushy at all! Feedback, suggestions and opinions are great - and in my opinion, they can only help!

Thanks for linking to Love2D's configuration scheme, I was not aware of it before.

A yeahspec (or something similar) will be needed to specify things that don't belong directly in game code, similar to a gemspec. A game's name for the webpage/window/app's title would belong there, because the webpage/window/app is treated as an interchangeable wrapper, rather than an integral part of the game. Author names and game version might also be kept there, similar to gemspec. On the other hand, a Game initializes its Display at runtime and interacts with it directly, so its configuration (size) is kept within the game code. I think that's a pretty good place to draw the line, but I'm not completely sure.

As usual, please share any thoughts you have!

[aostrega]

Dedicated issue for game name specification is at #30.