On Thu, Sep 8, 2011 at 9:29 PM, Lawson English <lenglish5 at cox.net> wrote:
> On 9/7/11 5:56 PM, Juan Vuletich wrote:
>>
>> Levente Uzonyi wrote: We should pick good stuff from Cuis (and Pharo)
>> instead.
>
> [...]
>>>
>>> To make the image smaller we should do two things (in parallel):
>>> - craving (make packages unloadable, remove dependencies, split packages)
>>> - building (use Spoon to rebuild the current image)
>>
>> Growing back the image with Spoon is much easier if you already start with
>> a clean image, like Cuis. Same for loading packages back: half of the work
>> is already done.
>
> For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It
> would be interesting to see if Craig can use Spoon to make it even more
> lean.
>
> At the other extreme, when Craig brags that he's gotten a minimalist Squeak
> image to run with only 1337 bytes, he's not joking. I loaded it into a
> programming text editor (BBEdit) and sure enough, it is exactly 1337 bytes.
>   Very LEET indeed.  :-)
>
>
> As far as what makes a "killer app" goes, the answer is obvious.
> Squeak/Pharo/Cuis/Spoon/Seaside are programming *tools*. This community
> doesn't have the resources to make a new killer app out of the existing
> tools (if they did, they'd be multi-millionaires already), BUT, Squeak
> running on Cog/MTCog is sufficiently fast to compete with other programming
> environments in order to create THE killer app: tools to create games for
> others to use to create games.
>
> Squeak could easily become the next Flash environment if the APIs existed to
> manipulate sprites and 3D objects properly. We already have Teatime, which
> distributes processing in ways that no other platform can even dream of (or
> even understand without some hours of explanation). Matt Fulmer has managed
> to get Open Cobalt running in a 4.2 image and play nice with the Morphic GUI
> (at the cost of some speed, you can overlap windows on top of the OpenGL
> layer seamlessly http://www.opencobalt.org/downloads).

There are lots of "low hanging fruit" that could enhance Squeak for of
game development.
Tools for managing internal and external resources/ media for example.

I would really like to see a lot of game development happening in Squeak :-)
Here are a few for fun:

http://www.hpi.uni-potsdam.de/hirschfeld/projects/olpc/index.html

Karl

>
>
>
> I've been looking at a simple, but fun, 2D game called NAEV. It uses C for
> the skeleton framework and calls external libraries (most of which Squeak
> also calls, or has bypassed to some extent) for speed, and uses Lua
> scripting to bind the game logic together. It uses SDL for its graphics
> needs -there was a Squeak project to interface with SDL 1.2, but that
> apparently died when the main programmer did, but I don't think we need SDL
> interfacing, because we have direct access to the entire OpenGL 1.4 API.
> Naev is the work of 7 programmers and my impression is that those same
> programmers using Squeak + OpenGL would have finished their project many
> months ago, instead of being only halfway through it.
>
> What we lack is a wrapper around the various libraries that Squeak already
> calls that would be attractive to game makers, both 2D and 3D. Combine that
> with squeak's ease of programming, Teatime, and a way of minimizing the
> footprint of the image using Cuis & Spoon, and you have something that could
> attract literally thousands of wannabe game writers to the platform.
>
> We have OpenCobalt and OpenQWAK. We need a similar 2D library for
> sprite-based games as well.
>
> Just a thought...
>
>
> L.
>
>
>
>
>
>