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.
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)?
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)?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
posted 02-01-2008 15:24
Aptana the Web IDE
