Here you can give your thoughts and feedback on the previous challenge, and share your ideas for the next challenge. That can be on what subject it should be (AI is a popular idea right now), but also other things. Eg. I'm curious what those who might want to participate in them would find a good running time for the contests. Should it be a small challenge that has to be completed quickly, or would a complex challenge that you have more time to solve be better?
One obvious lesson from the previous contest is that rules, topic, etc. should be better established and available before the contest is truly started. So don't bother bringing that one up XD
- A couple challenges per month from different core areas may get more involvement. Like: Graphics, UI, Physics, AI, or shoot, even who can submit the most wiki articles.
- Dynamic Sky - Changing times of day and night.
- Hemisphere Lighting With Radiosity Maps - Example
- Environmental Effects - Rain, snow, sleet, hail.
- Indoor / Outdoor - Defined partitioning and moving between the two (Portals).
- (for lack of a better name) Terrain Block Re-Calc - When terrain is deformed it is often left with longer distances between grid points which produces terrain texture 'stretch marks'; fastest algorithm for re-calc the terrain page wins.
It seems like a weak challenge but in fact the wiki is really sparse right now.
digitalntburn said:
- A couple challenges per month from different core areas may get more involvement. Like: Graphics, UI, Physics, AI, or shoot, even who can submit the most wiki articles.
- Dynamic Sky - Changing times of day and night.
- Hemisphere Lighting With Radiosity Maps - Example
- Environmental Effects - Rain, snow, sleet, hail.
- Indoor / Outdoor - Defined partitioning and moving between the two (Portals).
- (for lack of a better name) Terrain Block Re-Calc - When terrain is deformed it is often left with longer distances between grid points which produces terrain texture 'stretch marks'; fastest algorithm for re-calc the terrain page wins.
It seems like a weak challenge but in fact the wiki is really sparse right now.
well i don't think a couple of challenges per month would be a good idea. i think it's better to give developers more a bit time so they can produce something more useful for jme/community. and i think challenges shouldn't occur simultaneously. that way people can focus on one theme and don't get distracted by the anther theme. on the other side if many contest take place at the same time, renanse will have to set up a storage room for plush monkeys ;)
another point is what will happen with the produced code (if the quality/preformance is pleasing). as i mentioned in some other thread (don't remember which one), it would be nice if jme would stay lightweight. some of the proposed themes might be a bit too "genre-specific" (i'm not sure this is the correct naming) and wouldn't belong directly in the jme. jar. i know parts of jme could be excluded if you one wants to keep the jme distribution small, but it's easier to sort things apart from the beginning than afterwards :)
ok. now i'll stop my ramblings and make a suggestion (which many won't like):
- a wiki challenge: write an article/tutorial. i know this is a hard thing to do as many aren't native english speakers (like me), but grammar can be corrected in the wiki so that's not a reason for not writing such a thing. anyways, i'm not sure if such a challenge can really be done.
I don't think ehubbard has enough free time for a couple of challenges each month 
I think smaller projects with a pretty good time-frame for completion is the best way to go. Don't lose sight of the fact that the majority of people here have day jobs and work with jME in their spare time. So working on a challenge would not be just finding spare time because that time is mostly already taken up with their own jME projects, but find special time apart from that to work on another project. If we can be more understanding of that situation then I think most people will be able to contribute.
darkfrog
Maybe even small projects with a comparativly large timeframe?
that won't be easy. it depends on what we aim for. if we aim for implementing new features or improving existing ones, such small projects would be a bit too much.
but if we aim to just keep the community active and/or provide some attracting jme demos (which i'd also like to propose as a challenge theme - non-interactive demos: you know, the kind of stuff that make people say "wow!"), small projects would be just fine.
Part of what influenced my push for more challenges at one time was that we are now upwards of 700 members all of which have different areas of focus. Having challenges in two dissimilar areas may involve more people as not everyone who's into AI will be interested in tackling Graphics.
@sfera - I like the non-interactive demo idea and think the wiki challenges would help fuel them. Right now I'm updating the AlphaState article with the basics of how to use its syntax at the beginning of the article but by the end you're building a power-up and other specific objects. My thought is that the final code would be specific game objects that show off AlphaState. Judging wiki challenges may be…challenging.
Here's another idea: Displacement Map support.
One idea that has been considered was focusing on AI, the devs create a framework for a fighting arena, and provide an API for the users to be able to create their own AI implementation of the fighters then hold a tournament for the AIs to compete. Any thoughts on that?
darkfrog
yeah, core war gl! 
sounds great!
digitalntburn said:
- A couple challenges per month from different core areas may get more involvement. Like: Graphics, UI, Physics, AI, or shoot, even who can submit the most wiki articles.
It seems like a weak challenge but in fact the wiki is really sparse right now.
Wiki contest could be an ongoing contest... that would only "activate" if a certain number of people were contributing? I read/used every part of the wiki when I first started using JME, and once I finished reading... I was hungry for more.
What about javadocs? I've thought about contributing to those myself. I don't trust myself to write code for the core yet... but there are obvious out of date javadocs corrections that I (and others) could be trusted to do.
I think that time is a major obstacle for most of us.. and javadocs if done on a 'per method' or 'per class' basis... could be done in the little chunks of our lives that happen to be free from other responsabilities... course there is all the work to track/approve the changes.. but.. we're just brainstorming right now right? :)
Anyone willing to contribute code and/or JavaDocs is more than welcome to. I think all the developers would echo the sentiment that we would be happy to check those contributions in for non-developers. Feel free to simply post any updates to the forum and someone will pick them up and check them in if they are applicable changes.
darkfrog
I hesitate to endorse an AI contest simply because we don't have any AI what-so-ever currently. So, we'd be starting from scratch and most likely the framework for the contest would be a bit buggy. I'd like to see some AI comps in the future, but I think it's important to have a solid framework first. For the next few contests, I'd still like to allow the contests to benefit jME directly (i.e. improve something, create something, etc).
Also, while multiple contests seem like a good idea… it'll be hard to organize them, deal with them, and my pocket book can only handle so many ordering of t-shirts, and shipping prizes.
I agree it'd be better to start of with something simple, that could benifit jME directly.
darkfrog said:
One idea that has been considered was focusing on AI, the devs create a framework for a fighting arena, and provide an API for the users to be able to create their own AI implementation of the fighters then hold a tournament for the AIs to compete. Any thoughts on that?
darkfrog
I like AI topics..:) But given the lack of existing framework to leverage.. kinda tough to limit the contests in scope and effort. Besides.. thats what my game will eventually (slated for a 2039 release) be all about..:)
mojomonk said:
I hesitate to endorse an AI contest simply because we don't have any AI what-so-ever currently. So, we'd be starting from scratch and most likely the framework for the contest would be a bit buggy. I'd like to see some AI comps in the future, but I think it's important to have a solid framework first. For the next few contests, I'd still like to allow the contests to benefit jME directly (i.e. improve something, create something, etc).
Actually, this is why I think an AI contest is a good idea. I don't think we should introduce any AI aspects in the API we release at all. Simply make methods that can be invoked to execute actions and gather information about the world around them. It is up to the implementor to do something with that to create an AI. This, I believe, will give us a great foundation from which to derive some ideas about how we want to develop AI. After the tournament is over we can look at the code for the top AIs that were developed and get very useful information about how they went about developing their AI model and perhaps utilize that to develop some foundational AI core for jME. But ya know, I'm just a frog....often taken in by outlandish possibilities. ;)
darkfrog
darkfrog said:
Actually, this is why I think an AI contest is a good idea. I don't think we should introduce any AI aspects in the API we release at all. Simply make methods that can be invoked to execute actions and gather information about the world around them. It is up to the implementor to do something with that to create an AI. This, I believe, will give us a great foundation from which to derive some ideas about how we want to develop AI. After the tournament is over we can look at the code for the top AIs that were developed and get very useful information about how they went about developing their AI model and perhaps utilize that to develop some foundational AI core for jME. But ya know, I'm just a frog....often taken in by outlandish possibilities. ;)
darkfrog
Sooooooo many approaches to A.I. depending on how the challenge would be setup. I dunno if we'd find a set of particular APIs we could pull from it...hmm
What about what went WELL from the last contest?
I think the two sample solutions published by Mr. Coder were a great idea and if all the contestents had used them... would have saved a lot of time. For me it would have been just .. well.. huge..(since I was/am just learning JME) but I don't know if others realized how easy it would have been to layer techniques on top of the samples in a short amount of time.
So I think challenges in which we can provide a sample base implementation, (beyond a dumb solution that fails), are nice because we can employee those samples to make the contest take less time for people.
This is crazy. I don’t know why it didn’t occur to me before but we’ve already talked about this before; albeit outside a contest environment.
Finish the Flag Rush tutorials. Each challenge is specific to a point in the series. Now I know it isn’t as glamous as new features but it’s one of those aspects that needs some closure and wouldn’t take long to wrap up. Help mojomonk out.
Well, maybe if you finish flagrush Renanse will give you a monkey 
But how is it a contest?
Whoever writes the best tutorial for a series wins a prize. Not just code. Not just pictures. But a full fledged section for Flag Rush. One challenge per section.