I was going off this article by Mario Zechner: https://code.google.com/p/libgdx/wiki/AndroidStudio

My only point is that I primarily use libGDX, so Android Studio doesn't buy me much, and in fact I lose out on the ability to deploy to the web and as an application in addition to Android. But I might use Android Studio for Android-only projects. Not sure what your problem with those statements is.

As others have said, one of the best things about using libGDX and eclipse is the ability to develop for desktop/web/Android simultaneously. Android Studio might make developing for Android sexier, but that sorta misses the point.

That being said, I might check it out for non-game, Android-only apps in the future. But I'll still keep eclipse for desktop and EE development, which is the bulk of my work.

The $800 $700 OUYA version was for a super-early beta version of the console, as well as other perks such as extra promotion for your games. Most people paid the normal price of $100 for the standard version that's releasing now. Both versions are free to develop for. The 700 dollars was basically to get your hands on it way early, provide feedback on the still-in-development hardware (several things have already changed between then and the "real" version), as well as the extra promotion. Nothing to do with the dev kit.

For more info: http://www.engadget.com/2013/02/01/ouya-developers-sound-off/

Obligatory +1 for Static Void Games... 

PS- This is the first time I've seen the site recommended in the wild. Pretty cool moment for me!

Here's an interesting article about how and why many game developers release their games as freeware: http://indiestatik.com/2013/04/15/why-freeware/

(via iandioch)

Pretty cool: https://developers.google.com/glass/quickstart/java

A lot of this goes a bit above my head, but it's pretty exciting that we'll be able to use Java to develop for Google Glass. Does anybody have any ideas for apps or games yet?

Now if only I could get my hands on a pair!

Shameless self promotion: I offer free hosting for Java, Processing, and Android games at http://StaticVoidGames.com. It's still a work in progress, but I'm constantly working on upgrades and new features. You can even specify your own ads, so you can keep 100% of the revenue your game generates.

And I'm using Amazon web services behind the scenes, so scalability shouldn't be an issue.

My hope is to create a community of Java developers, tutorials, and (optionally) open source games, but for now it's at least an easy way to host Java games.

Yeah, it works fine. And it's extremely easy, too. Here is all the code I needed:


 
And it works fine. You just have to export it as a runnable jar (which grabs everything for you) and I believe sign the jar, and you're set!

Unless I'm misunderstanding something, you can use LwjglApplet to launch libGDX games as an applet. You can also launch them as webstarts. Here's a little game I made that uses both, if an example would help: http://staticvoidgames.com/play/?game=AvalancheRider

That would be great. I'd love to play this as an applet or webstart. Which method is best probably depends on what framework/libraries you're using. Sorry if you mentioned that already!

My two cents:

You shouldn't start creating a game by thinking "how can I make money from this?" - you should start by thinking "what would *I* want to play?". Make a game that you would love playing, then worry about monetizing it later - or don't.

This looks really great. Really important question though: will we be able to cheat by playing as the spider? 

Without looking at the code, I would guess that the tick() method is called every frame (so 60 times a second, or whatever the fps is). This allows game Objects to update themselves before being rendered.

As for your own program, you're going to have to post some code for us to comment on if you want a more specific answer.

I'm a little late to this discussion, but I do run a little website that has user-submitted open-source Java (and Processing) games available to play and download. I'm not sure if we have exactly what you're going for, but if you want to poke around some open source games, it might be worth checking out: http://StaticVoidGames.com

Thanks, that makes perfect sense.

I would personally think that getting newbies into the habit of using AWT over Swing can lead to bad practices when they branch out to gui design, which is worse in the long run than any look and feel overhead. But that's a personal preference, and I can see the other side as well.

Thanks again for taking the time to answer my dumb questions!

Can I ask how? I'm not trying to be argumentative or disagree, I just honestly can't see how Canvas is easier than JPanel or JComponent.



You can call add(JPanel) or add(JComponent) just as easily though, can't you?

I wouldn't suggest putting the ui and the game inside the same component. Instead, extend JPanel or JComponent (exactly like you do with Canvas), then override paintComponent() and you get double buffering for free. Then use a completely different JPanel for your ui (buttons, checkboxes, whatever), probably again exactly like you'd do with Canvas. This is my standard way of mocking up a game, and I don't see how Canvas makes that easier.

I feel like I'm missing something obvious, but I can't see what it is.

Thanks jonjava. I understand the difference between AWT and Swing; in fact my full-time day job is gui development in Swing. That's actually part of my confusion- The only time I see AWT actually used is in really old tutorials or in game development; everywhere else recommends Swing over AWT because of all the features, the built-in double buffering, etc.

I see your point that Swing might not be necessary for many games, which don't require "real" guis. But it still seems strange to see people recommending AWT over Swing.. it's not like you have to use the parts of Swing you don't need.

I don't mean to hijack the thread, but this is something that always itches at me.

Thanks. From that article:

So I see what you're saying with AWT being thread-safe (which I did not know, interesting), but not the automatic disposal (because Swing also does the same thing). Am I missing something?

I've seen plenty of gaming folks using Canvas and Frame/Applet instead of JPanel and JFrame/JApplet, and I've never quite understood why. Is the thread-safe thing (which is solved with Swing.invokeLater() and probably doesn't matter with most games anyway) really worth sacrificing all the other benefits of Swing? In gui development, AWT is almost never used over Swing, so I'm curious about why it's backwards in game development.

I want to ask a dumb question.. what's the advantage of using Frame and Canvas instead of, say, JFrame and JPanel or JComponent?

I'm not really sure what your question is. What have you tried so far? Where are you stuck?

Without more information, the best I can do is suggest you start with the basic tutorials: http://docs.oracle.com/javase/tutorial/

I would expect that to probably be implementation-dependent.

But of course, the best way to test this is with a benchmark. I'd be really curious to see what you find though.

I'm surprised nobody mentioned Project Euler yet: http://projecteuler.net/

That website gives you a bunch of problems to solve, and you submit programs that solve them. You compete for points by solving harder problems.

I saw the same thing despite not having an ad blocker. Firefox 18.0.2, Windows 7. It wasn't a big deal, just a little "umm..." moment. I don't see it now, and I do see the featured project and latest featured stuff on the side (although nothing in the Picture of the Day, but that might be a separate issue).

I think you're underestimating the number of people under the age of 18 in game jams, specifically Ludum Dare. You're also overestimating their competitive nature: part of their fun is the spirit of camaraderie in the community, and I'd say most people taking part in them are inexperienced programmers. I also think you're underestimating how much time the adult world takes away from you: it's not like we have exactly 8 hours of work and then the rest of the day for fun and games. Finally, you're overestimating how much of a benefit age is: sure, if you've been programming games for 10 years you're going to have an edge, but it's often harder for an older person to get started programming than it is for you young'uns.

I'm all for you guys organizing any kind of contest you want, but I also think you're looking for a problem where there might not actually be one. Up to you, but that's my two cents.

Instead of trying to come up with an entire game, try thinking of only of a single mechanic to explore instead.

The last game I made explored a mechanic of typing with one hand while keeping a rhythm with the other, and the game before that explored a Dino Run + Line Rider mechanic. My next one is going to explore synesthesia, and the one after that is going to explore a "blend in" mechanic.

Creativity is pretty hard, if not impossible, to teach, but I think it's about making connections and asking questions from other genres. A painter doesn't stare at his paint and think "well, what should I paint now" - he goes on walks, looks at people, places, and objects, learns more about them, and THEN paints something based on that mixture. The same can be true of programming. Instead of staring at your code or looking at other games, get away from the genre for a while. Go on a walk. Watch a movie. Go about your day. As you do these things, think about how anything can be turned into a game mechanic, and then you've got yourself something to program. If the mechanic works and is fun, expand that into a full game.

Thanks for playing! Yeah, it's definitely hard. The idea is that it should be easy, since all you're doing is two simple tasks, but then when you actually try it, it turns out to be harder than you expect.. exactly like rubbing your head and patting your stomach at the same time! It's definitely beatable though, and is actually easy once you get a rhythm going. I can beat it in under a minute now, but it was almost impossible for me when I first started playing with the mechanic!

The resizing thing is a good point. There isn't much to see in the window so I didn't worry too much about it, but I should have at least added a setResizable(false) in there.

Here's the link: Type Your Heart Out



Can you pat your head with one hand while rubbing your stomach with the other hand? Have you ever thought about how much work it is just to keep your heart beating while you go about your day? This game explores those ideas, as you spell words with one hand while keeping the heartbeat going with the other hand.

This game was created for GGJ13, which had a theme of the sound of a heartbeat. You can view the GGJ game page here.

The game is probably a little too difficult- I can beat it in under a minute, but people who didn't develop the game have more trouble. But for two days of work this game has a beginning, middle, and end, and explores a mechanic that I think is pretty interesting. I wonder how somebody who is ambidextrous or a drummer does with it!

Nope, all I'm using is good ol' Math.random() and some parameters (the ground changes by X between 25% and 50% of a screen, then by Y between a 50% drop and a 10% rise). I've made the source available if you don't believe me!

Penguins can't fly!

Technically the penguin responds faster to user input in the air (no friction), but it's probably hard to tell. I'll have to keep that in mind for my next game. Thanks for the input!

Thanks for playing! The weird thing is that it *is* randomly generated!