Since 1983.
And earning my (and my family's) living with it since '86...

Still detecting coding miracles nearly every day 

As long as source code is separated in header and source files it simply can't be good 

Looks pretty much like the Slick lighting that rose from this thread:
http://slick.javaunlimited.net/viewtopic.php?f=3&t=2769

The basic algorithm came (of course) from Kevin Glass.
I used a variation of the algorithm (added day and night behavior) in my game StarCleaner (see signature). Source code of the game is available as part of MarteEngine if you're interested.

@Nicke: your game looks cool. Is the level procedurally generated?

But as a 4k game with source code available it's also really really cool and fun to play sir!

Looks great and worked fine for me (Windows 7 32-bit, Firefox 8.0.1)!

The glowing progress bar is cool and so is the title screen. And tweening menu dialogs are also cool!

A nice tool to wrap up my game jars with all required LWJGL stuff to deploy as an "applet to go" would indeed be a great thing to have!

I think all the deployment trouble we have with Java (Webstart JNLP files, Applet signing/packing, Applications without .exe on Windows and included JRE) is one of the biggest reasons Java isn't used as much for game development as it could 

So whatever tool can help here (for example like Kappa's fat jar tool JarSplice or LWJGL's AppletLoader) is one step forward!

But you only need to scale once. As soon as you know the target resolution load the images and do the scaling and store the scaled images.

From then on you're fine using the scaled images.

Fun game! I finished the first two levels but was more than half dead. It became much more fun when the troopers ran away and turned around in between to shoot at me 

Webstart under Windows 7 worked like a charm!

You might see some more stuff as soon as your promising base code is shared  

I'm going to repeat myself: it's already done in Slick.

See here: https://bob.newdawnsoftware.com/repos/slick/trunk/Slick/src/org/newdawn/slick/state/transition/

10 transitions are already implemented and should be helpful enough to create your own ones.

Keep in mind when you use them that it might occur that your GameState.render() method is called before(!) an update() happened! Some transitions already call render() of your "target" state to create some nice transition effect. So you'll have to take care that your target GameState is able to be rendered without being updated.
Normal FadeIn/FadeOutTransitions won't require this.

Hope that helps,
Tommy

Great idea!

Don't forget Android and IPhone versions later on 

Maybe add some mechanism to receive user created levels that can be added to the game later (after human filtering happened to avoid "disturbing" level design)...

To the OP: You mention you want to use Slick. Slick already supports GameStates, where each GameState can be in fact a separate screen.
So you have one GameState subclass for the title screen, one for the game itself, one for options and so on.
Look up the GameState test case inside Slick. It's all there.

StarCleaner relies on some ResourceManager we built as part of MarteEngine. But inside it uses the standard Slick constructors like new Image("relativeResourcepath").
No magic at all except what's happening inside Slick.
All resources are part of the jar of course.

If that's the case for you, something like this should work:


Feel free to browse our MarteEngine source code, the StarCleaner source code is also part of Marte (test/it/marteEngine/game/StarCleaner).

Hope that helps a bit and cheers,
Tommy

I agree with pitbuller. Signing your own jars is not required. The LWJGL jars are signed and that's sufficient.
It must be a different problem.
My "StarCleaner" game runs as an applet and I didn't sign a single jar file. All resources (images, sheets, etc.) are inside my starcleaner.jar and it is a Slick game. And I also followed Kappa's tutorial on ninjacave to create Slick2D applets.

Sounds like a perfect powerful black screen to me 

Would you mind to release the source? I mean - that sounds like it's basically one of the best startup codes you could get for any LWJGL game, right? A commented version would be a jewel in the LWJGL wiki for example 

Then you might also want to look at this alphamap lighting example for Slick from pitbuller:

http://slick.javaunlimited.net/viewtopic.php?f=11&t=3250

Have a look at my StarCleaner game (signature). It's all done with Slick and MarteEngine (again: see signature) and not too much of OpenGL.
Complete source code is available as part of MarteEngine in the test directory tree.

Feel free to rip what you like 

Cheers,
Tommy

I have a question regarding different screen/device resolutions. What is the best approach to deal with them for TouchAPi?
I assume you have some scaling mechanism builtin. But is it smarter to code and create graphics for a higher resolution (say IPad) and scale down on Android or old IPhone OR is it better to create the game for a low resolution and let TouchAPi scale up?

Can an app using TouchAPi have different resolutions on different devices (like 1024 x 768 on desktop app and something like 480 x 320 on Android or IPhone 3)?

Confirmed. Firefox is much slower than Chrome, at least on my machine here.

Chrome can be considered "nearly playable" 

Cool progress! Definitely too slow right now (even on Windows) but I'll bet you'll work that out 

Saucer, I even wrote a tutorial (!) about a gameloop using fixed timesteps for updates and required tweening for rendering.
Unfortunately it's for BlitzMax but of course the principle works the same regardless of the programming language (and BlitzMax has most OO features you'd require).

The tutorial can be found here: http://www.rightanglegames.com/topdownshootertu/index.html. The game loop is based on stuff you'll find at Gaffer's blog.

The code can easily be converted to Java and Slick. I would suggest you create your own AppGameContainer subclass where you implement your own game loop using the mechanisms above.
I guess this would be the cleanest way to introduce a different update/render behavior into Slick.

Hope that helps,
Tommy

Saucer, your Slick2D example doesn't make much sense for the idea of Slick IMHO. Way too complicated.

Slick basically works by calling update() and render() in a loop. The time spent between the previous and the current update call is passed in milliseconds as delta. That's it. Update your positions by multiplying with a factor and the delta and you're done.

You can finetune Slick by switching on vsync, setting a target frame rate, delta smoothing, minimal and maximal update time and so on.

But basically I would start simple.

Give the games in my signature a try: they are all done with Slick, the source code to all those games is available on my website or part of MarteEngine. See if they stutter that much that you consider them unplayable or annoying (stuttering wise, not gameplay  ).
SpiderTrap is completely based on calculations using the delta value. Back to the past and StarCleaner use a target frame rate of 60.

Don't overcomplify things - try to get some games done 

Cheers,
Tommy

Where does the server stuff reside? Or at least the communication with the server? All via HTTP?

Things like login, saving games/highscores and such? I guess basically all the Google App Engine stuff 

And what about the payment interface PurchaseListener()? Is that implemented for Android and iOS only? Using their APIs? How does this work for the applet?

This IS interesting stuff, my brain's running in circles and I'm still at work 

Agreed! Still my favorite dev environment.

I would be fine with that.

I'm aware of the limitations of some platforms. But creating and monetizing flash games with Java is pretty tempting 
And having one code base for several platforms (I know that Java promises that for a long time now but we all know it's not quite true for some of the platforms you already seem to support with TouchAPI) is even more tempting!

Does that mean we have to wait longer? Starting this thread about TouchAPI is just to make us envy you? How cruel! 

What Eli says 

Have you ever thought about monetizing your tool chain? I think you could sell this to quite a bunch of developers. At least I would pay for it 

Cheers,
Tommy

PS: Legends of Yore is great and works fine on my cheap Android!

Slick does not use Display.sync() by default. You can switch it on by setting a target frame rate but it's off by default.

See method updateAndRender() in class GameContainer and method gameLoop() in class AppGameContainer.

Just be careful what example code you copy to start with 

Cheers,
Tommy

One more question because it's nagging me for years now:

The sound that plays when the player ship appears in Alien Flux always reminds me of the beginning of the extended version of The Cure's "A walk". Is that just me or was the sound borrowed/inspired by it?

Given your avatar I'd bet you have some good ol' The Cure records in your shelves 

Oh and btw: I would love to buy Alien Flux and Super Dudester nowadays cause I loved both games when I played the demos years ago (but couldn't afford them)...

- How does your "main game loop" work?
- Do you use delta timing or fixed time step (frame based)?
- Do you have different mechanisms for game logic updates and render loop?
- Do you use multithreading? If so, why? If not, why not?
- Do your games use a fixed resolution?
- How do you deal with different desktop screen resolutions, especially wide screen support or tiny screens on netbooks?


Thanks for this great thread, enjoying every post 
Tommy

That would, similar to Cas' suggestions, clearly move the game from "hardcore" or "difficult" to casual. And it would imply to add pathfinding, mouse handling, maybe even map scrolling via mouse (to point to positions that are currently not visible on the screen).

I think for a freeware version I keep it the way it is now. But who knows, maybe I can't resist and add it in a few weeks 

But I will surely add the options stuff to save settings and skip the tutorial levels. And I think I will also save last level, score and energy so that you can resume a game if you 'ESC'aped out of it.

Thanks again for playing,
Tommy

Thanks for the feedback!

Seems like I will create another version with some improved option handling (saving/loading settings and skipping tutorial levels)...I'll need such a OptionHandler class anyway - for the next game 

To nva225: Do you just want to skip tutorial levels or did you think of saving the game (current level, score, energy) and restart from last started level?

Cheers,
Tommy

Due to the feedback I received I created a version 1.1 of SpiderTrap 

What did I change?

- I added 4 tutorial levels with explaining messages what to do,
- now it is configurable for each laboratory if spiders can drop eggs and if active spiders can wake up stunned spiders,
- the time until a spider drops an egg is increased (random between 30-40 seconds),
- some levels were simplified,
- a special Webstart file for certain MacOS configurations was added,
- adding the icon on your desktop was fixed.

You might need to refresh your webstart cache to get the newest version ("javaws -uninstall SpiderTrap" or "javaws -uninstall").

Webstart
Webstart for Macs if above one does not work
SpiderTrap Development blog

Have fun,
Tommy