Topic: 32 Liner - February 08 - Games

So the theme is: Games

A slight deviation from the usual rules: this time the maximum number or functional code rows is 32.

Games are always difficult to make so this should be a topic that tests the limits of your (everyone's) abilities.

Things that (theoretically) could be fit into and bound together by 32 lines of js code:
Graphics (2D/3D)
Sound
User interaction
Level design/UI design
Story
AI
Physics/Mechanics
etc

Ideas for games:
Puzzle, platform, shooter, strategy, sports, racing, adventure, rpg, fighting or come up with something completely new!

Above all else I'd like to see originality and fun! Originality is tough but at least try to avoid copying/cloning games that we have seen cloned many times already.

Let the most fun game win!

Sounds like fun! Remember everyone, short month this month...

luckily this year, February is a tad longer

Really don't know what kind of game I'll do. Action or reflexion ... both ? in the same game ?
Mmmh, I might have an idea. But first I want to polish Castle Wolfenstein a bit.

I'm thinking along the lines of adventure, myself.

I assume that having a big, fat, giant hash at the beginning constitutes a single line of code, right? For a challenge like this, would anybody consider it abuse to have such a hash containing relevant game content (strings, positions of objects, etc)?

Cool, yay This could open some interesting avenues!

poi: Hmm...12 lines of polish? ^_^

quote:

---

iron_wallaby said:
For a challenge like this, would anybody consider it abuse to have such a hash containing relevant game content (strings, positions of objects, etc)?

---

No. But use an array instead.

(Edited by Arthurio on 02-01-2008 20:39)

quote:

---

Arthurio said:

No. But use an array instead.

---

Why? A hash is so much more convenient... (and besides, in JS, they're the same object prototype anyway!)

+1 hash are like array, just more elegant and convenient. No need to obfuscate the code even more.

wrayal: I was thinking of keeping it within 20 lines as it was for January's contest.

no no sorry hash is fine of course ... I was thinking of something else :P

I did a few tests with canvas.drawImage()

There are enormous differences in performance between different versions of opera and Firefox.

The test drew 81 (9*9) 32*32px tiles and moved them around by drawing them again and again each frame.

FF3b and Opera 9.25 displayed acceptable performance but FF2 and Opera 9.50 were just plain dreadful.

In another test with 1024 (32*32) 8px*8px tiles Firefox 3 displayed much worse performance than Opera 9.25 while the latter still managed to perform at somewhat acceptable level. FF2 and Opera 9.50 however were pumping out whopping 1 frame every 5 seconds now.

edit: the tile set was a single .png image with some parts 100% transparent and some parts 50% transparent.

(Edited by Arthurio on 02-02-2008 23:29)

Do you mind filing a bug, or provding some links so that I file it myself ?

I'd rather have you check out the code first. I guess it's better if you file the bug as well.

edit: WARNING ... Firefox2 users don't click ... will melt your cpu
(the tile set is just something I found on the web)

(Edited by Arthurio on 02-02-2008 23:41)

Trying to run a few more performance tests...

innerHTML = 256 <img> tags

link

container.appendChild(obj) and

256x obj.setAttribute('style','...')

link

Results are just as expected: 2. one works rather well and much better than canvas but why doesn't it work in Opera? :S

edit: btw it seems that the tile/image size doesn't matter, all that matters is the number of tiles/images.

(Edited by Arthurio on 02-04-2008 15:21)

Works perfectly in 9.5. Crawls in 9.2. Have you tried to preload the image ?

Ahh ... I have 9.10 here ... and it doesn't work at all.

I don't really understand preloading. Doesn't it preload the image in the 2. one? (first loop creates the tiles)

I found something on the web that instructs to do something like that: var img = new Image(100,100); img.src="img.jpg"; ... why would I want to do that img = new Image(100,100); I mean the (100,100) bit.

Btw what editor are you guys using? I'm using PSPad right now but I'm really longing for something better. Autocomplete would be nice ... googling for every single little thing is such a pain in the butt.

Doesn't seem to preload anything.

If you don't plan to scale the sprites, you should really go for a CSS sprites solution. It doesn't cause any reflow and is really simple and compact to use.

Oh and I'm using UltraEdit.

Ok I'll try to figure out what you said...

Anyway I downloaded a JS plugin for eclipse and it looks perfect! ...

In general, if all you want is to move images around without any specific blending mode or rotation, good'ole DHTML is faster than canvas. Also DHTML does not do the sub-pixel rendering, which can be an undesired feature of canvas in some use cases.


Aptana the Web IDE ? it sure looks good, but it's huuuge and so much slower than more "oldschool" text editors.

I don't really care how much memory or cpu time a tool that I work with takes as long as it works fast enough (or the combination of tools that I need work fast enough). Besides what else do I need these resources for when I'm working? Yes Eclipse is big and takes a lot of memory and is maybe a little slower than notepad but I'd say that a decent editor/IDE such as Eclipse saves the developer lots and lots of time.

So thanks for the link.

I created those tests to acquire and share some information that may be useful (to me and to others) for coding a 32line js game. I'll run a few more tests with "CSS sprites solution" and whatnot once I figure out what that means.

quote:

---

Besides what else do I need these resources for when I'm working?

---

your browsers of course

The term CSS sprites was coined by Dave Shea in A List Apart : CSS Sprites: Image Slicing&#8217;s Kiss of Death. It's a great technique when you don't need scaling. When you do, the only sensible way is the old canvas* sprites method.


WRT toolchain, what UltraEdit or my eyes don't catch, my browsers' error console or developer tools catch. I don't feel hindered by not using an IDE for small scale web developement..


*: nothing to do with the canvas tag. It refers to the idea of framing the images strip into a "canvas" in overflow hidden, size the image in percentages and move it inside the "canvas" as to show the desired frame. I'm obviously using this technique in 3D TOMB II and Castle Wolfenstein ( line 13 ) since the sprites must be scaled.

HTH



(Edited by poi on 02-04-2008 19:25)

Btw, told you guys the different implementations of canvas vary GREATLY in quality/speed/stability, it all is very much in the earliest stages
of development.

Last month, I was toying with a 200x200 pixels buffer, which never would work according to the spec in FF2, would work somehow
in Opera when it wanted to, would slow down to a crawl in FF3... I tried a 100x100, but go code meaningful water ripples with that.

With the work flood and the stumbling blocks when using canvas, I gave up altogether (and am still holding the urge to toy around inside).
If I make time to compete this month, I'll resort to the oldest of old school trickeries... which will make poi's blood boil - again -

(which will be fun in and of itself )
(chops buster me would even go for a game called "preload-less rollovers in a table nested in a frameset" for the hell of it).

Canvas "may be" a great thing someday : for now it's a pain in the ass for some purposes, and the most interesting one definitely is
fast pixel access.

100x100 is a LOT of pixels to touch in JS anyway. The biggest stuff I made using BMP generation was around 100x50 and it was a stupid fire effect rendered as an 8bits BMP image. So the calculations were very basic. Haven't played with Canvas' ImageData, but being very new don't expect it to work well or to be correctly optimized. I doubt ImageData would perform very well anyway since you have to touched individually each component.

Well, I have this 100x100 buffer code here, fps is average 20, but it looks crippled to me - sorry to say that, but
I am getting used to my 702x240 (non-standard) resolution in java - see this water applet,
or faster, 8 bit deep buffers still in software - as used in raskasmetallia,
and of course... to the 4096x4096 pixels animated buffer I developped using C and Java for "Cosa 3D"
(am unable to test that one fully, my laptop lacks the ram required to load a full buffer at that resolution, but I tested 1920x1200 with a shiny
50 fps - in this one, the blitter is pure Java, but the filters are pure C - even with the "copy arrays back and forth" extra processing, it works a threat).

I don't see any performance difference between Css sprites and css clipping ... at least in FF2... but it works in opera 9.10 now and the code is a little simpler.

Hmm looks like the real culprit is moving those div-s around in the first place ... performance doesn't improve one bit if I remove the background-image from the equation.

poi: any ideas how to improve the performance?

Anyway I figured I'll need to move or animate up to maybe 100-150 images in various sizes and this looks achievable already.

(Edited by Arthurio on 02-05-2008 15:03)

Check this out. I don't think that most of the content there is legal but certainly an interesting resource.

As of today the maximum number sprites one can move and animate at a decent framerate seem to be around 150.

When dealing with elements having only a background color, you can go as high as a 1,000-ish.

A few months ago I started working on an arena shooter with ~350 8x8 elements ( enemies + bullets ). When things were getting crowded the framerate was dropping to 10 fps due to all the elements to animate and the game logic ( collision detection, movement logic, ... ). Alas that kind of game require a LOT of elements. I started using Canvas, but the blurring induced by drawImage() was undesired, so I moved to CSS sprites which helped but it was still a too much. I'll look into it later to see if things can be improves but I doubt there is much I can do.



(Edited by poi on 02-06-2008 21:23)

Started working on my entry today.
link press 'w' to accelerate ... handling needs some work ...

original graphics ^^ not much yet but more to come

Reminds me a bit of the Ozone gravlabs (IE only it seems, maybe Opera too).

A few updates: static enemies that rotate towards the player, shooting (hold mouse button down) and better/simpler handling.
Same address.

Need to draw a few more sprites later...

16 days to go. Good time to start working on something

edit: My bots now move and shoot the player. Been slacking off lately. Still need to draw more sprites ... only 1 (x40) atm.

Hmm ... I have to make my bots fly in formation ...

edit2: An entry doesn't have to be 32 if you feel it's too many lines. Make a 3-liner if you can

(Edited by Arthurio on 02-13-2008 14:54)

(Edited by Arthurio on 02-13-2008 15:00)

*cracks fingers, marks two hours a day in his agenda, and smiles*

Oh, and Arthurio, you talk way too much At times you remind me of that guy InI..

This post has a point ... it like totally does!

edit: minor graphics update

(Edited by Arthurio on 02-13-2008 22:05)

Neat.

The angles seem a bit off. Looks a bit like they are based on the top left corner of sprites.

Hmm ... the bullets look a little off because their tails follow the direction in which they were shot instead of the direction in which they are moving but other than that what difference does it make if all the sprites are the same size.

Ah, makes sense.

How would you rate the combat/handling right now? (enemy formation flying soon to come)
Difficulty: 1-10
Frustrating/annoying: 1-10
Too simple? Good enough?
Ideas for improvement?

10% of ideas accomplished, 65% of lines used :P

The controls feel a bit strange : AFAIU the thrust is controlled/initiated using the keyboard, but then it's affected by distance between the mouse and the ship. So you can go at crazy speed and out of the viewport.

I'd prefer something like Asteroid for the ship, and using the mouse for the aiming/firing. This might mean making the ship a composite of the ship itself and a turet. But it's not a problem.


Once you've figured out how to move, it's really easy now. Maybe 2-3 / 10.


Ideas of improvements : different enemies, waves of enemies, power ups, score, ...

Also I get some scrollbars although my brower window is 1101x602.



... I really got to find an idea for an entry

quote:

---

Difficulty: 1-10
Frustrating/annoying: 1-10
Too simple? Good enough?
Ideas for improvement?

---

These were all about combat and handling.

I'll try to figure out a way to get rid of scrollbars.

I'll explain my ideas a little bit then.

Features TODO:
The player's ship is going to stay in the center of the screen and everything else is going to move. The 'world' will be borderless.
Explosions.
Scrolling background image.
World/map generation.
Radar.
Planets/bases.
Return to home when killed.
Items. Health packs, shield packs, mission items, tradables.
Basic trading.
Upgrades. Weapons, regeneration.
Missions. Kill, assassinate, retrieve, collect.
Dialogue and story.

That's necessary for a somewhat complete game. How far I go with it is another matter.

(Edited by Arthurio on 02-14-2008 10:37)

Wipes tears of joy.
This is AWESOME (game classics vault)!

UPDATE
Added radar(incomplete), background and player's ship stays in the center of the screen now.

reduced line count to 24, added background image to radar, added round bullets

I want to make a bootsector ( 480 bytes intro in Assembler 68000 ) on Atari for Outline, and would like to make a new JS demo for the Assembly to balance a bit the flood of AS3 prods and show what's possible today using open standards, so I'm not sure I'll do much casual JS coding.

Yeah, I feel you on this one poi, it's getting hectic here too and priorities need to be set - sadly, extreme coding eats up time.
But I'd like to give the 20 liners a last "shot" for the next months, and a valuable one - I can afford some time for it.
To showcase and deliver a few new interesting "compression" tricks.

Cheers,

Anyone want to be the winner? I've been too busy to finish my game...
Bad choice of topic by me and these 12 extra lines seem to be unnecessary as well. Sorry Games are just too complex a topic on so many levels. So lets return to the 20 liners and have a really nice little topic for next month. My suggestion: "Effects".
Your opinion wanted!

Your idea was great : I think it's just the season which does not work. February, most people are busy as the commercial cycle starts over again.
My idea : keep it UP for a new month with the same topic, because I've had the same problem as you.

+1

Had a few ideas but nothing concrete, plus work ( quite stressing the last weeks/months ), trying to get some furnitures in that new flat, and the other projects I mentionned above.

I'd say it's over now. No entries, no winners.

On you you poi: please choose the next topic.

February is pretty much gone now. April's topic should be set by Magna as he came 2nd in the last contest. I contacted him and he seems ok to "run" April's N liner. Prepare for a new challenge in the forthcomming days.



(Edited by poi on 03-31-2008 18:35)