#169107 - Synthetic - Fri Jun 19, 2009 3:47 pm
Mifheu and I have been working for a ouple of months on a new ds game, and its progressing along nicely. However, we're starting to hit a wall in development, mainly because of resource handling. So, we're looking for a coder to help us put together some of the tool set.
We're looking for a programmer who is good with python and c/c++, and has a basic understanding of 3d graphics, and a good math background. Experience with combinatorics would be nice.
There is no immediate compensation. If we're satisfied with your work, you may get game credits and a cut of the profits. Also, a lot of what you write may be open sourced afterwards with your name on it, so you get recognition and satisfaction from helping the gbadev community =).
pm me or email at tetravus13@gmail.com for more details.
#169108 - gauauu - Fri Jun 19, 2009 10:30 pm
Do you have a website or demo or screenshots or design doc or something like that about your project, where we can get an idea of what you're working on?
(I ask less for myself, and more for your sake, as people will be more interested if they can see what you're doing)
#169110 - Synthetic - Fri Jun 19, 2009 11:23 pm
Sorry, you're right. It is a 3d real-time strategy game capable of fairly large numbers of units. The design doc is still a work in progress as mifheu is very busy with the graphics, and I'm occupied with the engine work.
You can see a few screenshots of the graphics at mifheu's site, http://www.aemuse.com/ under projects/other.
#169151 - Miked0801 - Mon Jun 22, 2009 4:41 am
Um, designing your game and documenting it should be more important than potentially wasted engine/graphic work :)
#169156 - Synthetic - Mon Jun 22, 2009 6:57 am
I agree that a good design is important, but the problem we're having is its really hard to finalize the design before you're sure about the technical limitations. The DS isn't exactly a powerhouse, and I've already had to work around several major limitations, which keeps changing what we can do.
But hey, if you want to help us with the design, we'd be more than happy to take any input, just as long as you write us a python script too =D
#169158 - sgeos - Mon Jun 22, 2009 7:37 am
| Synthetic wrote: |
| but the problem we're having is its really hard to finalize the design before you're sure about the technical limitations |
Is there an open "DS Limitations for Artists" document?
Anyway, here is a not for artists document.
| Miked0801 wrote: |
| Um, designing your game and documenting it should be more important than potentially wasted engine/graphic work :) |
I know of at least one publisher that does not understand this concept...
mid project spec change == months of rework
I suppose they only wasted about a year of paid artist man hours.
This frightens me.
#169160 - Synthetic - Mon Jun 22, 2009 7:55 am
I am aware of and have been using gbatek, but that is completely useless for lots of design questions. For example, lets assume I want a unit that launches rockets: How many rockets can it launch? Do they have contrails? Do the rockets their targets or just go to a position? If I don't have enough spare polys, I can't do a barrage of rockets from every unit, and I can't do contrails, and the calculations for positioning front-facing billboards for the contrails aren't free either. All of this depends on the complete picture, what is happening in the rest of the game, and it may turn out that rockets just aren't feasable at all.
Don't get me wrong, we're not changing the central idea and game elements, certainly not the artwork, its just that its hard to write a full document when you can't pin down the details without trying a lot of things out.
Also, just to be clear, this isn't a project trying to get off the ground. We're about a thousand lines of code and a dozen or so models in. A lot of the game is finished, but its getting hard to do more without a good toolset, and that's what we could really use help with.
#169164 - sgeos - Mon Jun 22, 2009 9:14 am
Some of the grey zone considerations can be answered by the question, "How many programmer hours do you have?" and "How good is your programmer?" and "Do your really want your programmer to spend time optimizing your engine?" Some of the system limitations can be worked around, but everything takes cycles. Optimization takes time and is subject to the law of diminishing returns.
As a rule of thumb, try to keep your spec simple- it is easy to bloat a spec, but harder to deflate it later. Also, a simpler spec could translate into more units on the map.
I was actually surprised when I found out "high" poly models are next to useless on the DS. All of the hi-res stuff is turned into movies and then played back with a video codec, but the in game models tend to be really simple.
As for tools... tools are a big deal even if they are not fully polished and appropriate to send out end users (ie, idiot proof). If I were in your position, I'd write a complete spec for the tools, and then ask for help knowing that I might need to do the job myself.
As an aside, explain your "profits"? Do you plan to shop for a publisher? Is this a hobby project and if so, from where will profits materialize?
#169166 - gauauu - Mon Jun 22, 2009 3:18 pm
<Devil's Advocate>(Not sure I completely believe what I'm saying here, but worth saying anyway...)
I would argue, though, that for a hobby project, a full design doc ISN'T as important as what is being claimed. Sure, you need SOME level of initial design or else everyone will be going different directions and nothing will get done. But you can also consider:
-A small 2-man team is much more agile than a larger commercial game team. You can adapt much more quickly.
-For hobby projects, the main consideration is usually fun in development. Who cares if the decision you made just nullified hours of work? You aren't under a tight budget, generally.
-In any sized project (large or small) the design often gets changed, mucked with, etc. Why waste time filling in every little detail when you think it's likely going to be changed anyway?
Of course, a less complete design doc means that you generally either need to have very good communication between your team, or a strong leader who can tell everyone what to do. Otherwise, you'll have each member of the team going off in a random direction and never meet in the middle.
</Devil's Advocate>
#169167 - gauauu - Mon Jun 22, 2009 3:20 pm
| sgeos wrote: |
| Is this a hobby project and if so, from where will profits materialize? |
You never know -- after 3 years of work, I netted about $25 and a donated DS from Anguna ;-)
That's $8.33 and 1/3 of a DS if split 3 ways -- not too shabby, right?
#169168 - sgeos - Mon Jun 22, 2009 3:47 pm
| gauauu wrote: |
| <Devil's Advocate> *snip* |
It sounds like you are advocating the code and fix life cycle model. I think that this is the wrong model for anything that requires more than about 50 man hours to complete.
| gauauu wrote: |
| That's $8.33 and 1/3 of a DS if split 3 ways -- not too shabby, right? |
=)
#169172 - Synthetic - Mon Jun 22, 2009 5:47 pm
I'm not talking about optimization, I'm talking about design decisions that are affected by the ds. Like my previous example. If I need 95% of the poly limit to render everything on the scene, then at that point there's nothing I can optimize out, I either have to design the game for fewer units, or fewer polys per unit, so that I can have my nice looking rockets with smoke, or I can't do it. Although, it would be a safe bet to assume that the programmer thinks he's pretty good =).
This is not a hobby project, we do intend to shop for a publisher, but before we do, we'd like to have a nice demo of the full game. We're... reasonably close to that, but we want to be able to completely customize the terrain and anything on it, and plug it back into the game without having to change the code at all.
If any of you guys are interested and are willling to do python, perhaps we can talk more over im or email? I'd love to work with a senior member of gbadev; I can't tell you guys how helpful this forum has been.
#169177 - sgeos - Mon Jun 22, 2009 6:51 pm
| Synthetic wrote: |
| If I need 95% of the poly limit to render everything on the scene, then at that point there's nothing I can optimize out, I either have to design the game for fewer units, or fewer polys per unit, so that I can have my nice looking rockets with smoke, or I can't do it. |
Is it possible to cut the frame rate to get more polys per frame, similar to how the two screen 3D works?
#169178 - Synthetic - Mon Jun 22, 2009 7:00 pm
I've tried it, it takes too much vram and too much time to render. I'm already planning for a 30fps game, so we can't drop the framerate either. Unfortuantely there's no hardware way around it. But, this isn't really too much of a problem, just an example of the sort of problems we've been having when designing the game
#169179 - gauauu - Mon Jun 22, 2009 7:08 pm
| sgeos wrote: |
| gauauu wrote: | | <Devil's Advocate> *snip* |
It sounds like you are advocating the code and fix life cycle model. I think that this is the wrong model for anything that requires more than about 50 man hours to complete.
|
Well, really I was thinking of something closer to the "Evolutionary Prototyping" listed above it, but I'll stop derailing the thread with discussion about it :)
#169192 - sgeos - Tue Jun 23, 2009 3:23 am
| gauauu wrote: |
| but I'll stop derailing the thread |
Split to Life Cycle Models and Project Buy In in the OffTopic forum.
#169259 - Mifheu - Thu Jun 25, 2009 5:37 pm
Wow, some interesting discussions going on here. And we only asked for some help :)
As Synethic already mentioned, we are not working on THE GAME right now. We do a prototype to answer at least the following questions:
- can the engine handle really lots of units and what are the limitations?
- what are the limitations for the meshes to get lots of them on screen?
- what can the terrain look like, how big can it be?
- can the game look good enough with this limitations?
- can we achive a very good handling of the game with the stylus?
- what are the best sizes and aspect ratios for the buildings, terrain, units and foliage?
We try to answer as much crucial questions about our game in one prototype. We try to get a clear vision, about what we can do and if we can do, what we want to do.
Take it as some kind of parallelized prototype to get rid of some of the major risks we face right now. It wouldn't make sense to start with a game design without knowing the answers to a few questions. Especially on a limited system like the DS.
So, all the learning from this prototype will go into our game design and maybe we start another development loop then (if neccessary).
But of course we already have a very clear vision statement and there is a detailed documentation (on a private project wiki). We are not stupid ;-) And we are not wasting any time at all.
And on the other hand, we do it for fun. We do it for fun, but in a professional way. There is no time to waste, because we have no pressure from a publisher or through budget right now. As Synethic said, we are indeed looking forward to get a publisher for the game some day. I have the connections neccessary for that... Let's see what comes.
So, we'd be very happy, if somebody will join and help us getting some tools and exporters for the game. Anybody who joins will of course have access to the game wiki.
Until the just visit www.aemuse.com
Under projects/other you can see a few meshes I did. And Synethic is hard at work to get a nice little running demo done the next few weeks.
_________________
Simplicity is the most complex topic.