Also please check out the online Applet demo of my first J2ME game (initially for Nokia phones only) here:
http://www.pixelmachine.co.uk/play.php
Enjoy!
tafty.
Also please check out the online Applet demo of my first J2ME game (initially for Nokia phones only) here:
http://www.pixelmachine.co.uk/play.php
Enjoy!
tafty.
r u selling this game? u should see if u can get someone to publish it for u. these sort of games are loved by those people who like to buy things for their phones.
the fact that it’s simple is a plus for phone games. u could modify it to use only the 2 up and down controls like in snake. that’d make it easier to play on a phone. i think i remember this one on the old atari.
not bad.
Seems fine to me!
For a cell phone, I’m sure it will be a success. My only complaint is that I like it when you can box an area thats say 3 boxes wide by 1 high and it fills all of them. I’m not keen on the go around every single box idea.
Good work!
I’ve made it available to buy at Handango but no downloads so far I’m going to send it to some review websites and magazines here in the UK too but I was rapidly coming to the conclusion that I might be better off trying to find a publisher.
On the phone the player uses keys 2, 4, 6 & 8 to move and 5 to fire which works quite nicely.
Electroid is really just a painter style game (a kind of inverse Pacman) crossed with Jeff Minter’s classic Gridrunner, which you probably played on your Atari!
That’s a nice idea for a power-up DrAnonymous! It couldn’t be available from the start as an unlimited power though as the player would simply be able to go all the way around the outside and the level would be done They’d zip through the 63 levels in a no time!
I guess most simple games have a chore-like element to them. Imagine Pacman’s first day at work, ‘Wot? I’ve got to eat ALL the dots?! On EVERY level…’!
i absolutely hate using the numbers on my phone to play games. i like snake so much more cause of the nice big easy to find up and down buttons. if u add the up and down buttons as a turn clockwise and anticlockwise like snake, it would be so much easier for people to grasp. keep the original controls, just add those two as well.
and i do remember this game, it was on an old computer we used to have, cga fun!
The idea was that it started with big 2 by 2 grid, then went up to 3x3, 4x4 and so on getting harder and harder, there was only one bad dude thingy (as far as i remember), after a point, 16x16 i think… it just got faster instead of smaller grid.
it would make it too easy to fill in large areas all at once, the player could just cruise around the border and be done, but if you were looking at adding features, certainly maybe a easy, medium, and hard level where te squares were a diferent size.
Like the game, well suited for mobile phones.
However, I agree with dranonymous: When I started to play it, I staked out an area of 2x2 boxes and was apalled to see that they would not be filled. I expected them to be, probably through previous experience with (much older) painter games.
I understand your concern that the player could simply go round the edge. How about throwing in some obstacles on the edge? Or cutting away some of the grid lines? In this way, it would be more of a maze.
Damn I wish I’d found this forum earlier - this is quite marvellous feedback and has renewed my (slightly flagging) enthusiasm for the project.
I do understand what you mean about the simple and accessible controls for snake JuddMan but I’m just not convinced they would work for Electroid. On later levels when you’re being chased by a whole bunch of mean, green Huntoids it’s imperative that you be able to turn back on yourself. However, it’s not exactly difficult to implement so I may well give it a go anyway… incidentally I haven’t mentioned that all the Nokia Series 40 phones have a small directional pad which can also be used for movement so the player does have options available.
I think that the different sized cells for different levels idea is excellent. The game engine is set up with constants for the cell sizes already due to porting it from the 6310i so it’s easy to turn those into level dependent variables.
Cut away grid lines (and thus different grid shapes) was an idea I played with but dropped in an initial attempt to keep the game really simple (this was afterall only supposed to be an experiment to familiarise myself with J2ME). I very much like the idea though. Other options I considered were one-way grid lines and invertable ones (where if you travel over them once they’re filled they get rubbed out again). This could add a neat puzzle element to the game as well as different mazes.
I have to admit that many ideas got dropped early on because: I always try to make sure that a project is ‘complete-able’ (I hate having half completed stuff lying around plus I’ve got a family and a job!); it’s ported from a 6310i version which was necessarily simplistic; and I wasn’t aware of all the optimisation options available to me.
Dropped ideas include: various different bad guys including ‘homing bollards’ (pencilled in as Bolloids!) that would provide the obstacles you’re talking about digitprop; wrappable grids; destructable and re-spawning enemies; different weapons for the player.
Maybe a sequel is in order!
java.lang.NoClassDefFoundError: IllegalName: Electroid/ElectroidGame
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.opera.PluginPanel.run(PluginPanel.java:424)
at java.lang.Thread.run(Unknown Source)
Same old same old. Getting tired of this >:(
Cas
v. nice game, im addicted now!
Hi Cas,
I’m sorry about the error - I hope you’re not too tired to point me in the direction of how to fix it? Please could you elaborate as to what causes this since you have seen it before?
Many thanks,
Gareth.
PS thanks darkprophet I’m glad you like it ;D
It would appear to be that the the JVM doesn’t think your class name is correct for the package name. I can’t figure it out though, because it looks correct. Perhaps you could try using a lowercase package name and reuploading it?
I tried it in appletviewer on JDK1.5beta2 too - same error. Could be a foible of JDK1.5 but it’s better to know about these things before they’re released
Cas
ps. Tired of seeing “Applet Crashed” and “Invalid Bytecode”, not of this particular error
Thanks for the prompt reply Cas!
I’ll download 1.5 when I get home tonight and try your suggestion.
I have tried several flavours of browser (IE, Netscape, Mozilla, Opera and Firefox) combined with several versions of Java (1.1.8, 1.3.1, 1.4.2_04) so was a little surprised (and horrified) to see that nasty exception string!
However, I have to admit I’d only used the 1.1.8 Appletviewer during dev since I knew it was headed for a website and, ironically, I wanted to keep it as compatible as possible…I guess that’s a lesson learned too…
Thanks for the help - forewarned is indeed forearmed!
1.5 is still in beta though and anything you do for it could become horribly broken with the proper release (like what happened to borderLayout though that’s not likely).
also if you compile in 1.5 it may not run in older JVM version. (even if the code and api’s you use are)
On 1.5 I got a (intermitent) null pointer exception - and this occurred regardless of the case of the package and class names.
It looks as though I had an errant Thread. When converting from the MIDlet I’d left two lines of code in that started a new Thread when a new game begins. This is redundant for the Applet version as the game Thread starts when the Applet does.
However, I cannot reproduce the exact error that you suffered Cas. I’d be grateful, if you have the time, if you could test my newer version of the Applet here:
http://www.tafty.com/electroid/Electroid/ElectroidGame.html
And let me know if the same error occurs. I’m sorry for the ‘fingers-crossed’ approach on this…if it doesn’t, well, I may have to take the “it’s only a beta” route and be ready with a hotfix come full 1.5 release time.
Thanks JuddMan; I always use the 1.1.8 compiler because of the age old IE problem - though having had a good read of the forum now I’m sure admitting to this makes me something of a heretic round here!
java.lang.NoClassDefFoundError: IllegalName: Electroid/ElectroidGame
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.opera.PluginPanel.run(PluginPanel.java:424)
at java.lang.Thread.run(Unknown Source)
A lot of other applets work OK so something’s up…
Cas
??? This is all very strange indeed.
I’ve now done a version with lower case package and class names. Again this works fine with 1.1.8, 1.4.2 and 1.5 beta 2 with Appletviewer, IE and Opera. It can be found here:
http://www.tafty.com/electroid/electroid/electroidgame.html
I’ve checked the class declaration for electroidgame (which extends Applet) and everything is public that should be…if this doesn’t work for you then I’m genuinely flumoxed…
java.lang.NoClassDefFoundError: IllegalName: electroid/electroidgame
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.opera.PluginPanel.run(PluginPanel.java:424)
at java.lang.Thread.run(Unknown Source)
What compiler are you using?
Cas
Is that code= bit wrong? I thought the code attribute had to specify a class, not a file in a directory (that’s what codebase is for)?
(although it works for me, mozilla 1.7 + 1.4.2_05)
I’m using the 1.1.8 compiler to retain compatibility with the lowest (and most prolific) common denominator IE. I’ve had trouble with using more recent compiler versions and the “-target 1.1” tag.
I think the CODE attribute represents a package/class combo (it doesn’t need the ‘.class’ extension to work) rather than an actual file path - that might be splitting hairs tho, cuz they’re pretty much one and the same here. The HTML page was generated by Sun Studio.
Funnily enough if I edit this value to read:
codebase="." code="electroidgame.class"
It causes this familiar looking error:
java.lang.NoClassDefFoundError: electroidgame (wrong name: electroid/electroidgame)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I’ll have another look when I get home tonight…
somewhere along the line jinput got broken in exactly the same way, or i should say the new jvm rejected it with the exact same error, and they’ve since released a fixed version of jinput. someone there might know what’s going on.