team threads

By which I mean the compiled mess that I had to order off the wiki begins. We've already been working on the Game Design Document steadily whilst already starting art and programming. I expected, given the amount of designers we started with, to have a lot of design by committee, but in the end there were really only two contributors to this being Jarrod and myself.

Death Metale GDD - Version 1.0

Apologies in advance if it's not descriptive enough in some areas, I rely upon lots of hyperlinks on the wiki we're using, so I've had to remove all that. Also, no version history since, once again, it's on a wiki. Sometimes I feel like the wiki is a bit empty, but I'm happy after seeing it compile into 31 pages when I know I've still got edits and entries to make.

Feel free to put any comments & criticism here. Cheers.

Well, time to show some progress on the UI side of things...

I´ve been posting my progress on the UI on my website, so here is the link

All comments and suggestions are most welcome :P

Here is the progress of the player ship design(Occlusion Render). It starting to take shape and weapons and details are slowly being added and updated.

Feel free to make any C&C on it.

Front View
http://www.postimage.org/gxW3JDJ.jpg

Perspective View
http://www.postimage.org/gxW3M7S.jpg

Rear View 1
http://www.postimage.org/gxW3R79.jpg

Rear View 2
http://www.postimage.org/gxW3YBA.jpg

Rear View 3
http://www.postimage.org/gxW42AS.jpg

Top View
http://www.postimage.org/gxW4550.jpg

Its good to see a totaled list of all participants on the project, but who of these are still showing interest?

These forums have been rather dead as of the last 2 weeks. No one has replied to the design changes and we still don't know about the engine licenses. I understand that they make take time and I'm fine with that. I'm more worried that the project is losing momentum and beginning to stagnant.

Currently we need a few things done before we can make any progress. The licenses need to get purchased, and this will happen soon. I'm waiting on sponsorship dollars, and as soon as I get that, the programmers will get their licenses. This may take another week or two, but it's definitely coming. In the meantime, they can research and prepare for the time being.

The concept art needs to be finalised and given to the 3D artists to model and texture. I'm pretty much happy with John's work so far, and if anyone wants to chime in on anything regarding the design, feel free to provide some input, otherwise, he can get onto some front/side art for the artists.

We'll delegate the job to the artists, if they're not around, I'll just message them each to let them know.

I know you're refining some of the design related stuff, and doing a mockup in flash for things - I will be using that for referencing when doing the UI and menus etc.. I've been hunting around for some tutorials on making awesome gaseous nebulae, but the ones I've found so far are pretty lame. I remember bookmarking an incredible planet surface texturing tutorial yonks ago, but I will have to hunt for it again. It was a pretty damn cool tutorial on creating some really unique looking planets. If anyone has some tutorials handy, free to post it.

I guess we can nudge OverActive-Imagination for the sound effects and ambient music etc once we have a basic demo..

If I may make a suggestion. :)

You should do a headcount of people still interested. And in order to do that you should get all team members e-mails and directly notify them to respond to your e-mail to vest continued interest in the project.

People can sometimes forget to visit site and it's forums for months at a time. :) You need to contact your team-members in a more directed fashion.

Cheers.

I've been checking in periodically. Unfortunately I recently hit crisis point on the work front, as in I have none, so fixing that has taken priority. I'm hoping to get a better balance on the work front soon and should be back on board with regular updates then.

In the mean time any/all feedback or ideas on game themes and visuals would be helpful, especially over-arcing themes... actually I'll go and post in the concept art thread to encourage some responses and ideas there.

I've been lurking around waiting to see if i have to spring into action. i could probably warm up my pencil arm and contribute some concept sketches of my own if that would help push the arty side of things forward.

Hey Guys, sorry i haven't showed up in the last couple of weeks since I was busy with the VFX submission thing. So I guess we already have some concept drawings and stuff. I am free to work on it if you guys need any help with modeling or 3D animatic. Send me an email and i will reply within 24 hrs. Cheers!

I'm still around and interested. Been checking forum from time to time.

We have the funds to purchase two engine licenses for Roger and Suggo, and we are ready to roll in that department.

Concerning the licenses costs, since this is coming out of my pocket, the agreement is that what ever money we make out of this game, the costs of the licenses will have to be paid back first. I can't cover a third license for mulletd, unfortunately, so if he is purchasing a license out of his own pocket for one, then that also will need to be paid back with the proceeds made from the game.

Currently, we're looking to the new refined concept art from JohnN for the artists to work from.

At this time, we will ask our 3D artists to volunteer which specific area of work they want to do. I would imagine they could be split up into spaceship and craft modelling/texturing, planet/nebular texturing and special effects, and miscellaneous.

Mulletdulla to work on some really simple flash prototypes to show off some of the gui and ideas (nothing too fancy).

I would like to volunteer in modelling/texturing spaceship. I ‘ve been busy at work, and working on my animation reel - will focus more on this project than on my animation reel. I can start modelling anytime.

I'm fine with any modeling tasks. So, spaceship and craft modelling/texturing would be my task i guess. Email me if u need immediate start, will get back to u in 24 hrs. Thanks!

Aaah this is really exciting! We get to start really digging our teeth into this project.

I will probably end up getting my own license so I can gt stuck into the work of this project.

I'd love to hear from Roger and Suggo when they have their engines up and running so we can discuss what they have for us so far, where to begin and what priorities need to be made to get this behemoth on a roll.

I still owe you some gui prototypes but unfortunately I dont have a working flash license on this computer. I will storyboard the major elements in photo shop however and get a doc rolling out with that over the coming week.

I also added to the design brief a reference doc to Sins of a Solar Empire. It outlines a lot of the major elements of that game I think are important for ours. Its more to do with the functionality and user interface both 2d and 3d rather than straight GUI. But when I story board up our interface I will reference aspects from both defcon and sins.

The programmers have the funds for their licenses, so you should be hearing about the engine stuff real soon. They can start implementing things straight away, and will have to put in primitives as placements for the ships etc while the concept art is getting sorted out then modelled.

The gui stuff - some pictures would suffice if you don't flash. Just some diagrams on the menus and ingame gui etc.

Yes it is getting exciting. Hopefully I will be purchasing my license when I get home from work today. I'll let you know when I'm up and running.

Just thought I would let you all know I have the engine running and I'm in the process of looking at how it all works.

Nice Suggo

How are you finding it? Let us know when you are ready to rumble with it. Any word from Roger on his license? I haven't seen him post in a while.

Thanks for keeping us updated. You will have to correspond with Roger to see what part of development you both will be working on. Please use place holders for the art for the time being while the concept art and models get worked on.

Cool, Placeholders for the art is no problem. I'm still doing some learning at the moment looking at the demos etc. I've been a bit slack this week but hopefully the long weekend will give me some time to get my hands dirty.

Also, I would like to try and put together some sort of technical design document outlining the exact structure of the code for our game. It will detail how different classes in the engine need to be used and/or extended and a general overview of how it all works together. This way Roger and I will be on the same page.

Roger, if you have any ideas let us know or put them in a document. Hopefully I can get a good start on it this weekend and we can compare notes and come up with a solid structure.

So, it comes at no surprise that without any communication, projects appear to stay at a stand still. We could get some response from Roger on how the engine work is progressing? We really need to get some concept art finalised to get the artists to work on something as well.

Hey guys,

I've been on a bit of a hiatus sorry. Last weekend I took a trip to sydney and I just got back yesterday. Now next week I am moving to Melbourne for a 3 month contract with Studio Moshi. Unfortunately this will chew a lot of my free time but I am still committed to this project. It just may be another week or so till you see some more big posts from me.

I still havent seen any feedback on my interface design yet souri? any questions for it from you or chris?

for anyone in sydney there are some teaching sessions for game dev with Unity. I know its not the engine we are using but it could be very useful

http://aftrs.edu.au/courses/industryshortcourses/findacourse/creatingga…

$390 for 4 nights

I have been a little busy with other things lately and haven't found time to get a good move on but I'm still checking out the examples and documentation. not much to report.

Has anyone heard from Roger? He seems to have gone missing....

Haven't heard from him, I've been a little lazy and if he has done any planning it would be great to hear about it. I'm a little lacking in motivation at the moment because I have been very busy at work.

Hi Peeps. Sorry for posting this here, but its hard to figure out where all the participation is happening with these indie projects.

Basically I'm interested in doing an indie project with a good group of committed people. I can see that there are a couple of people that post/communicate regularly, but it appears that most of the projects have come to a stand still.

I'm a software team lead in my day job, free lance at night with some personal indie projects of my own. I've got about 11 years experience in the game/graphics industry. I have already licensed Unity 3D Pro and iPhone so would be keen to work on a project utilising that engine. Some of the artwork I have seen here I especially like, but I would prefer to work on a smaller project that has a quick time to completion. Talking Beta version in months not years.

Is this a suitable place for me to be hanging out? :)

Cheers.

Ok, it looks like we will making a shift in engine choice to Unity 3D, and it would be great to get the programmers who have shown interest in this project to discuss what part of the game they'd want to tackle.

So far, the programmers we have interested are:

Suggo
fuedone
vordu

Let me know which area of the game you want to be responsible for, thanks.

Hi Vordu,
If you are interested in taking on smaller projects, you should consider joining Team B. The current project is at a stand still, but I'm keen on getting another small scaled game going. I have made some suggestions on the type of game we could do, but feel free to provide input there.

i dont know how quick i can afford unity indie license, i suppose i can just re-use the 30 day trial for a 2 months, i am saving up to go to freeplay first lol.

after that ill probably save up for unity indie license and basic iphone license.

i don't really mind which section, i have done a bit of everything before..

edit: just downloaded unity, its pretty awesome and simple to use lol

http://i144.photobucket.com/albums/r178/fuedone/unity.jpg

I'll get my copy of unity some time in the next week. As for areas to work on i'm not picky although my weakest areas are probably networking and AI.
I think we should use the design document to break the game up into parts and look at how we are going to structure the game, I have been making some notes about the game objects involved, I will try and get it into a post when I get home tonight.

i've done networking plus i work as a server admin/programmer at work so i do know how half of that stuff works, but i dont find it all that intresting :p

ai is probably one of my weaker points, but i can still handle it

ah sweet,

sounds like we got some momentum back. I'm still MIA a tad, I don't have internet in my apartment yet but that should be resolved quickly.

It'll be good to see some of your notes Suggo as well as any techincal designs you can write out in terms of using unity and deliverying to a PC platform as well as possibly the iphone

Porting to iphone is definately an area to explore, it may be something we can look into now as well if it is the desired platform. However there remains the issue there of the added costs for the iphone liscence and publishing.

Taking a look at the objectives of the Game Design Document is certainly the the next step in our production. We will need to outline a first pass priority list of what needs to be developed to get the ball rolling. I'll start taking a look at this over the next week now that I am settled in and hopefully deliver some notes into next weekend.

Its also good to have you on board fuedone!

~ Mulletdulla

Ok, this project is sort of at a stand still, and there are many areas where we can still move forward.

I think if Squashed Bug, if you could provide us with some screen resolution specs so we can get an idea on what the artists are working with for background art, menus and gui etc

The artists - we will most likely need the latest game design document which describes the break-down on how many backgrounds we need for each level/country, and also maybe a simple flow chart describing the GUI and menus and which buttons lead where so I can mock up some screens for that.

Team Roll Call ...

Is Charcoal still on board? We don't need a completed design doc, just a draft with only the high level sections filled in, allowing the rest of the team to review and help complete the missing sections. We really all need to be on the same page and having the whole team contributing to a single document. Since we are all working over the internet the best format for the design doc might be a Wiki page, I'm sure Souri could set us up with a page on the Tsumea Wiki which we can all edit.

It would be helpful if all team members could confirm if they still want to be involved. We may also need some new members to fill in resource gaps.

You're right, we need to get things moving. If you could give me the screen dimensions, that would help with the menu and the backdrops for the levels.

I will post an art style thread which I have mentioned before later tonight, but we can pretty much get the artists working on the assets now (modelling cooking, kitchen related objects, and various store scenes from different countries etc).

In the meantime, a roll call is definitely needed.

Ready and waiting!

I've sent an email to Plusie and CAD to see if they are still interested. Charcoal is still missing in action. We'll give it a few days for Plusie and CAD to respond to see where they're at.

So, at the moment we're down a fair few players.

We're basically at Squashed_bug, myself, and Raymondl. Not good.

Potion Motion (Canceled Project) from Flashbang Studios on Vimeo.

I have a few other ideas for some other types of games which I had planned to work on entirely myself, but if it may need be, we can steer Team B into doing that instead and postpone this, because at the moment, this project has hit a stand still.

Ok folks, obviously, things need to get a moving, and I'll be here to do some prodding and to gather some ideas.

The idea for Team B was to work on small projects, and I think from Team C's experience, these projects need to have as little bottlenecks as possible. I was thinking of a few games we could work on where each artist works on their own contained level while the programmer(s) can work on refining the game mechanics. This probably means that the types of games made are restricted in that sense, but it means everyone can start on working on something, and besides I'm sure we can still be creative.

So, the obvious kinds of games I had in mind that would suit that format would be - pinball, racing (has anyone seen the dl content for Wipeout Pure?), mini golf etc. If anyone else has any other idea, let us know. We could even work on something smaller just to get something interesting complete.

I'd prefer we'd all use Unity 3D for this, btw.

Trying to get this team moving. I'm making a call for programmers who are interested in using Unity 3D and doing some small projects for this team so we can assemble interested parties and get some simple projects happening. Please post your interest here.

G'day,

This is definitely something I'd love to be a part of!

I'm a games dev student, my background is I completed an Advanced Diploma in Multimedia, and I'm now in my 2nd year studying Computer Science in Games Technology at La Trobe University

I'd love to contribute as a programmer to small projects for the team, unfortunately though I can only offer approx 5 hours per week due to study and work commitments.

If 5 hours a week is enough to help the project, and you are happy to have me please let me know :)

cheers

hobbi

ok, created an account.

Feel free to shoot me an email if this project is still live and looking for programmers :)

cheers

hobbi

We're gonna have to need a reboot and start these two teams fresh again, and working on something more simpler and more achievable next time round.

Hey, that's great :) I had fun playing it!

With the ideas mentioned earlier about filling out orders and opening up stores, I can see some real potential with this game.

Awesome work.

The campaign map and the other things you listed is probably what I should come up with considering it's a ui design issue. The concept art of the ship models, fighters, carriers, satellites etc is what JohnN would be tackling. If you're reading, John, can you read through the design doc and come up with some concepts?

just for some ideas for the art style - I would love to see a lot of gothic influence into the fleets, ships and structure designs.

For an example:

http://stevencnelson.com/resources/_wsb_696x520_40k+003.jpg
http://kennettix.streamlinetrial.co.uk/BFG/cobra.jpg

I've read the doc already Souri, I'll re-read and build up a list of assets that need concepts and will attempt to make it into an organised brief that people can comment on before I head down a unpopular path.

Should i also add to the list general styling/feel/ambience for the game? I expect it will naturally develop as the ships etc and interface design does but it might be a good idea to set some style boundaries/goals early?

on potential styling: I'm more a fan of industrial/military over gothic. I'll take it on board mulletdulla and see how it sits as I progress.

Thinking of the concept of defcon and interplanetary conquest it kinda reminds me of the more classic and retro sci-fi styles. I think a retro rocket-ship style it could lend itself very nicely to the design of this game. :)

Some examples:

http://www.megomuseum.com/catalog/1979/images/buck1.JPG
http://bws.deviantart.com/art/Retropolis-Rocket-Works-2-5544448
http://bws.deviantart.com/art/If-I-Only-Had-Wings-I-d-Fly-62636569
http://bws.deviantart.com/art/Retropolis-Rocket-Works-1-5485015

I like the idea of reverting the art style to the cold war era but none of those examples agree with me. Give it a shot tho and lets see what we come up with :D

I've read back through the design document and assembled a list of all the things I could see that we will need some concept art for. feel free to suggest additions/removals etc.

concept art list:
solar systems x2 (planets, moons, central star, asteroids/asteroid fields)
star fleets x2:
Artillery Ship (planetary assault)
Attack Ship (fleet attack, fleet defence)
Defence Ship? (fleet defence)
Carrier Ship (personnel transport)

manufacturing ports
research facilities
fuel harvesting/processing plants
defence satellites
orbital defence systems
terrestrial defence stations

---extras to consider---
black holes
worm holes
unmanned war heads?
Comets
Alien ships/Aliens
ghost ships/stations

"Hi all,

I've been playing around with Unity to see what it's like. While I can see its advantages I would rather use something that allows access to the source code. As a programmer having access to source code just makes life easier.
Using C# script I was able to implement working code for a solar system rather quickly in the matter of an hour. My issues arrived however when I tried to implement a simple GUI for selecting an individual planet, 4 hours later still not working the way I want.
If we do go with Unity I won't mind, I just wanted to throw my opinion out their."

Firstly, thanks for jumpin in and having a good muck around with it.

I didn't realise you couldn't get inside the source code - that does seem like a rather large problem considering the amount of changes we need to make to the engine to make the game an RTS

- RTS cameras
- selectable and moveable interface

althought I am suprised that the gui for selecting objects would be so difficult.

Do you have suggestions for another engine?

Hey Mulletdulla,

I've been playing around with Unity and briefly looking over it's GUI, it seems to have a few pre-built options for it.

Have you as yet investigated the documentation support for Unity? Theres an entire section dedicated to it's GUI system.

Or if you're seeking advice, how about asking on their community forums? They've been helpful and quick to answer with my questions so far. :)

I know that TDEA allows you to edit its source code. But it's also $100USD more expensive per person using it then Unity.

Cheers,
Chris Watts

I have played around a bit with the gui stuff and the skinning options looks like a lot of the 2D stuff as far as buttons, tooltips, windows and scroll bars etc would be much easier using the built in unity system. Picking in 3D would probably be another story.

I have also looked at their first tutorial about creating a 2D platformer although it does not detail that much of the scripting in the tutorial (pretty much says "use this script"), I beleive a lot of the camera stuff can be handled by the scripts. It may not be as efficient but it should be suffice shouldn't it?

My reasons for going the Unity route has been posted about before (it seems to have so many pros for it like multi-platform, network / physics / sound, good tools and support, plus if we could build a knowledge and sharing base here for future projects, it would be awesome) but I'll be happy with whatever the programmers choose to work with since they'll be the ones dealing with it.

So I want to get this thing going all ready.
So I'm going to help the decision making process along.
Lets start by defining what we require from the engine.
These are my Ideas and not necessarily the requirements we will be using, here goes.

*Robust Documentation
*Strong supporting community
*Ease of programming
*Asset Support, What tools and file formats supported
*Price, what we can afford
*Supported platforms
*network support

What do you guys think? Anything I missed?

So far as I have been reading, Unity suites all these purposes.

But what will be really important is having a versatile engine that can create a point and click interface that moves independently from the Camera.

From what you were trying to prototype with Unity, is this possible? If we cannot select planets in an orbit like you described -

"My issues arrived however when I tried to implement a simple GUI for selecting an individual planet, 4 hours later still not working the way I want."

This becomes a really big problem for the development of this game as the interface will be dependent on selecting the various planets, fleets and other misc objects on our battle map.

I had an idea that while we render planets, fleets and misc visually in 3D - could the actual GUI be based on selecting 2D invisible overlays or bounding boxes? Then again I don't know if you already tried that.

If we cannot solve this problem without ripping into the source code of Unity (which we can't do, it only provides scripting) then we should thoroughly look at other options. If we can solve this, I am for Unity all the way for all the features it supports.

The issue is due to the way I had sorted the planets and moons. Changes you make to certain data cascades down to objects enclosed by the object who's data you changed (if you follow me, damn repetitive sentences). I didn't want to resort to reordering the planets, but it will work.
I guess solving these kind of problems will just require changing ones approach.

And yes I'm using bounding boxes.

You're talking about changing parent data and having the children data affected yeah? Haha I've had frustrating situations come up from that too.

Just tell me if we can make an effective rts interface with the unity engine or if you have another engine you would prefer to work with.

Personally I'm ok when it comes to scripting, but I'm much better with a really good visual engine editor - that being said most of the development work for game play won't be dependent on using a visual editor haha.

anyone else got input on this subject matter?

I'm quite pleased with what unity has to offer. Is there a trial version of TGEA? There are demo files on the website but I'm not 100% sure they are a trial of the engine or just demos showcasing what it can do. I'll check them out tonight.

I'm willing to go the Unity route if that is the general consensus. Are there any people that disagree with using unity?

If we cannot solve this problem without ripping into the source code of Unity (which we can't do, it only provides scripting) then we should thoroughly look at other options. If we can solve this, I am for Unity all the way for all the features it supports.

This is definitely where we're at at the moment. Roger, if you could check the support forum at the Unity website, that would be great. If it's an issue that can't be resolved easily, then by all means, look into another engine that fits our requirements.

I would prefer TGEA, only because it offers me the experience of using C++ language code. Experience with c++ and source code is important if your looking to become a game programmer like I am.
However if everyone is going with Unity I'm still on board, as this is still important experience.

@Suggo I've downloaded the TGEA demoes and they are just demo games not a trial version, sorry.

This is an issue that I have resolved, so I don't think their will be any problems we can't solve.

Pity about those demos, I will try and look into TGEA a bit more before we come to a decision.

I would be more comfortable with C++ than C# myself, as I'm more familiar with C++ and it would probably be a very beneficial experience seeing the source code for the engine. However I also feel that the unity documentation is more straightforward and simple compared to what I have looked at with TGEA.

Ultimately, it's yours and Sugo's call since you'll be the guys working on the engine side. I'm happy with what decision you guys make. I don't know how robust the network side of Unity is or what unforseen problems may occur with it, so spend some extra time on researching the best solution for what you guys need to work with and what the project requires, and we'll go with that.

When you guys (Roger and Sugo) make a definite decision on an engine, please let me know. I want to approach some devs on sponsoring us some licenses.

*pouts* You guys can get sponsoring?

Now I feel sheepish for going to pay for licences out of my own pocket. XD

I can't make any promises. We'll probably have to pay it back, however.

Sounds good Souri, we'll let you know

Alright we've all had a bit of a hiatus over Easter I'm sure. You guys made a conclusion as to which engine you want to use? I really wanna get the ball rolling.

I did some paper prototyping, I'm pretty happy with the results. Gonna spend the new couple weeks building the basic concept in flash.

Updates on everyone else's status?

Actually, doing a mock up of the UI in flash would be a great help. It doesn't need to be fancy, just some mock up screens starting from the beginning of the game right to game selection showing menu selections as well as in-game UI roughs would be a great help for me.

We're currently waiting on JohnN's concept art, and the programmers to choose the engine. For me, I'll need the programmers to give me some specs on resolution size so I can do work on the menus etc

Ok,
I've done some researching on unity and TGEA and made some comparisons.

They work out equal with these specifications
*Multiplatform support - they both support PC/mac/web with optional extras
*Partical systems - they both support decent partical systems
*Lighting - they both support per-pixel lighting
*texturing
*physics
*GUI
*networkin - both systems will work
*editors - both engines provide easy to use editors
*Community support - both engines come with a great community

Unity has the advantage with these requirements
*Asset support - unity supports all major file formats
*Documentation - has detailed documentation
*price - 199US vs 295US per seat

TGEA has the advantages with these requirements
*Ease of programming - TGEA allows access to the source code with a decent code library

Conclusion
Unities Asset support counters TGEA's advantage of being easier to program as far as development time goes. Leaving Unity as the winner with better documentation and price.

I am disappointed that I won't be programming in C++ but that's how it is. Let's see Sugo's oppinion on this matter.

There will be plenty of time for you to program with C++ in this lifetime I'm sure haha.

Thanks for the comparison Roger. The only real stand out Unity has is the support as far as I can see, which would undoubtably be very useful considering we are all entering this at an amateur level.

~ edit i cant think proprerly, whats redoubtedly? haha

I don't think there is anything you have missed, good work. the only thing I would have also mentioned is that TGEA was built around network code, placing it at the core of the engine, which could be advantageous when it comes to implementing the networking side of things (according to what I read on the website it is a top notch networking framework, however I can't tell if that is marketing or fact) but I don't think this outweighs the Unity so much to justify us going with TGEA, after all it can still be implemented with Unity at a lower cost.

I am happy to go with Unity, The asset importing I also think is very important, while testing it out I could very easily create objects in blender and just drag them into the engine which could become very useful. Source code and C++ would have been nice too. In the long run I think TGEA would cost us more time.

on a side note, I also noticed that the new torque 3D release that is coming up has a licensing scheme similar to unity, US$250, no source code and it also lacks the web publishing that unity has, just thought this was interesting.

So I agree it looks like Unity is the engine for us!

Any news on the Unity licenses. Will we be paying for them ourselves?

Ok, I'm feeling a bit bad because I've been pushing Unity all this time, but it means you guys don't get to work with C+++ and source code. I know how important this is for you guys, particular since it will be you two who'll deal with the actual engine anyway, and I know how important this project can be for your portfolio. I am more than happy if you want to go the TGEA way, so please ponder on it a bit more and give me your final choice on Sunday night, and on Monday I will be seeking companies to sponsor a few licenses of which ever engine you choose.

Can I just add to this that the scale of the game we are attempting to make is quite large. Larger than we all are really anticipating. In all honestly it could be a 6 to 8 month development cycle.

I personally don't want this as just an item for my portfolio. I want to make a somewhat successful indie game out of this; we have the means and the capabilities to do so. There is nothing to stop us from doing so except ourselves.

Working with C++ is definitely important for professional development but having a shipped title is more invaluable than anything else. I don't mind which engine we use, I would just prefer the one which will make this game the best it can be, if TGEA with C++ will do that then let that be the deciding factor.

You can't really say which engine will let the game be the best it can be, both engines will result in a very similar game.

I went with Unity because it seems to have an advantage in production time allowing us to put more time into polish. So given equal production time Unity leaves us with a more polished game.

If however you don't care how many months our project takes to complete TGEA has the advantage over Unity.

Hope that helps. Anything extra Suggo?

I would advise this team exercise caution and take on a methodical process to the idea of making this project a long term, published and profitable indie game. Rather then a demo or free-to-download experience.

Taking a project from something that's designed to improve everyone's folio to the level of making it a polished, published and money making indie title comes with a number of considerations. Here's a few:

- Profits : Who gets the profits of this project? Is it intended that profits will be split up equally between all contributors of the project. And additional to this point:
- Who will pay for the expenses of the project? And will they receive the majority profit to cover their costs.
- How will you measure the value of each members stake in the profits?
- You will need to write a contract and agreement for all who work on the project. Getting a lawyer to proof it is a good idea as well.

- Project Management : The scale of this game is quite ambitious, and as such your going to need at least one person dedicated to being the project manager. He'll monitor and measure everyone's tasks and progress. I can't stress how much any team over 2-3 people needs a project manager.

- Production Plan: Design documents are the first step of a game design. But to bring that design into reality the team will need a well considered production plan that elaborates on how the production of this project will be carried out. Without this plan putting together the game and assets will be a haphazard process.

To give you guys just an idea of how much work can go into keeping a team together. I work 30-40 hours a week on my design folio in creating design documents, video logs and level designs for the tower city prototype demo.

I also spend an additional 15-30 hours a week in keeping up with e-mails to the prototype team, writing up production plans, bringing art and code assets together into unity to create something tangible and the other bits of bobs of leading a project. The position of project leader can't be taken lightly.

Overall though from reading the posts about this game. I think, for the fact that this is the first project for many on the team that it needs to be simplified somewhat. You guys have some awesome ideas. :) But one needs to sit down and consider each feature on it's own merit and how much it'll bring to the player experience.

So in summery:
- If this indie game is for profit, work out the details and write up a consented contract for all who work on it.
- Find a dedicated production Manager and nominate a leader. Make sure the leader is willing to accept some harsh time requirements for the project.
- Create a production plan to work out how this game is going to be created from pre-production to polish.
- Refine the feature list and make sure all features are worth their implementation time and resources required to create it.

I hope all this helps you guys out. :)

Cheers,
Chris Watts.

No matter which engine we go with we are going to be doing some learning. I suppose that is the main purpose, to gain experience. If we look at what we want to get out as far as experience is concerned, access to the TGEA source code could be very good for our education. This decision just keeps getting more difficult. I think Unity provides a simpler way for us to get the finished product but TGEA allows us more access as to how we get this result.

Both engines are quite capable of completing the task. TGEA has a different approach to the object import. Unity allowed me to drag and drop, it doesn't get much simpler. TGEA we have to export in a specific format which shouldn't be a problem as there are numerous exporters and scripts out there for most major 3D modeling packages I had a quick look into an export script for Blender but have not been able to test it but the facilities are there.

So I am leaning a bit more to the TGEA side now. if we go this route it will provide more experience for myself and roger. I think TGEA would be a good choice and provide a more professional level of experience. I do like the look of how Unity works, it speeds up game development as an engine is supposed to. let's say for experience I would go with TGEA and if the production schedule was my main concern I would go Unity. I'm still a little torn as to which way to go. but as has been mentioned myself and roger will be the only ones really affected and what we are more comfortable with could be just as beneficial as an efficient engine like Unity. I for one have never really used c# except for one hello world test I did a few months back, C++ is more my thing and learning a bit of torque script would be fine with me.

Roger if you would rather use C++ and torque script we should go that route. I'm still a bit unsure as to the better choice. I suppose I'm a little worried that we will get tied up in too much code if we go TGEA. Roger do you have any concerns with either engine?

EDIT: Sorry for being indecisive about this. If you are already shopping around for Unity licenses that is fine. I just had some thoughts and wanted to throw them out there.

I think we should be treating this project more as a learning experience then a successful product. While it will be great to be a part of the process for delivering a successful product, and a great feather in our caps. This is a first time project for many of us and having experience is more important then contributing to a successful product.

So just in case this product sees very little interest lets concentrate on homing our skills. If our end product does earn recognition and success that will be a great bonus.

Having said all that, with the intention of earning valuable experience I would choose TGEA.

wow these shows look great.

Largely what ever style of art we wish to pursue will be dependent on the Engine we choose to build from.

I was looking at Unity because it is incredibly flexible as well as powerful.

Also the scale and focus of our game is simultaneous battles across different planets, the player will often be needing to see an overview of the entire campaign map. Here we can only effectively represent fleets as blips due to scaling constraints.

To include some fantastic scenes like these we can do what Sins of a Solar Empire does. They have a unique and very streamlined zooming feature that takes you in and out of viewing very close up to galaxy extremes. We could do something similar at each home planet but we must be careful as this could take away from the players ability to assess the entire match. Information can always be well supported by a UI however.

Here's the engine pushing a 30 million polygon ship.

http://www.youtube.com/watch?v=ULb4hcteIUo

We're not going to be doing anything close to that, but yeh, Unity 3D can certainly handle the polygons.

Unity 3D looks like a pretty cool engine. Anyone know the price for an Indie license? or would you guys rather go for something open source and free for commercial use. Some free ones include: Ogre, Irrlicht and Crystal space. I suppose this is more a question of preference and more suited to Chris and I as programmers, the only two I have touched are Ogre and Irrlicht although only very recently. I haven't looked far into crystal space but it is probably the more game focused one of the three the others are primarily graphics engines which can be used in a game along with physics input and sound.

Also these free engines will probably not be as good as something that costs us money. What does everyone else think?

Unity 2.5 on an indie level costs $200USD per developer.

To put that into a more tangible scene. Each person who directly needs to use the engine, 3D editor and tools will need to pay somewhere around $300AUS [depends on exchange rate.] for their own licence.

That sounds like a drag. But when considering how much you actually get for that $300. It's money well invested.

Prices can be seen at:

https://store.unity3d.com/shop/

$199 (US or $282 AU) for the Indie license
$1499 (US or $2,130 AU) for the Indie Pro license

Here's a comparison of the differences between the licenses...

http://unity3d.com/unity/licenses

My main argument for using Unity is if we eventually want to do a demonstratable web version, Mac version, or further down the line do a customised iPhone version (or even Wii), it would be much easier going the Unity route and understanding its nuances than the other options available. It also helps that it has all the physics, and sound etc already.

We'd probably need to get you two programmers the indie license first off, and the rest of the team can simply send you the assets to compile. Mulletdulla would need it also to tweak the game as we go.

The Unity Indie License is US$200.

The reason I was drawn to it is its flexibility into building platforms. It can easily be deployed to web browsers which is a great platform to publish games - look at the recent success of Quake Live.

It also has a shit tonne of networking and multiplayer support which I thought would be integral.

However I am not a programmer and truth be told I can only take a lot of this for face value.

I had a look at Irrlicht - Theres a space based RTS called galatic Dream that was built with that engine. So it seems to support what we want to do. Your experience with it would also be of great benefit.

Unity is prettier tho :D but $$

Well I definitely like cheap but I think I'll download and try out the 30 day trial of unity and see what it is like. I agree it is a much more polished engine than anything we could get free and deployment to all those different platforms is something to consider. I am starting to like the sound of unity more and more and the price is not looking too bad.

Given that we are drawing gameplay inspiration from a very simple looking perhaps we should keep that in mind in terms of the art as well.
after reading the game brief i had and image in my head of a 3D star scape where the player can move the camera around at will, but keeping the fleets as 2D icons.

anyone have any thoughts on this?

I think the simple art style would be good but as Souri said with this many artists working on the project we can probably give them a bit more work than just 2D vectors. We could possibly come out with a large array of very nice 3D models.

Hi all,

I've been playing around with Unity to see what it's like. While I can see its advantages I would rather use something that allows access to the source code. As a programmer having access to source code just makes life easier.
Using C# script I was able to implement working code for a solar system rather quickly in the matter of an hour. My issues arrived however when I tried to implement a simple GUI for selecting an individual planet, 4 hours later still not working the way I want.
If we do go with Unity I won't mind, I just wanted to throw my opinion out their.

Just a note that MulletD has continued talk about the engine in the engine thread here: http://www.tsumea.com/node/9091

I suppose this is the right spot to post this, the thread diverted into engine talk for a while.
Some initial sketches to warm up for the task at hand. Designs are loosely made in sets of 2. If anything is jumping out as potentially worth expanding/exploring for fleet designs to anyone please post your thoughts.

Do we have any documentation that addresses back story or thematic settings for the game? might help narrow visual design goals if we do.

I love these, you have captured some really cool feels here.

Standing out to me so far are:

1) as an orbital bombardment type ship
7)/8) could both easily be Engineer Ships
11) suites the purpose of troop carrier drop ships - ie the pods launched to the planets surface carrying troops
2)/12) seems like a good fighter type ship
I also like 3) as another artillery ship
6) is another good fighter type ship

However the gothic machine style of 1) and 8)is my favoured theme of the lot.

Currently there is no back story or thematic setting written into the design of the game. I have however reduced the scope of the game to be set inside only one solar system so perhaps the technology of the ships is not as far reaching as what we normally perceive in galaxy based sci-fi settings. From this a more simplified, industrial theme could be established? I'm not entirely sure.

If anyone has any ideas for themes, settings and back stories feel free to post about it.

Looking great, mate!! I like how the silhouettes are different which will help making out the type of ship at a quick glance.

Hey Chris or any other Artist,

I just released an updated GDD. In this includes a new Node system for the planets. The idea is that the Nodes are directly represented in game on the planet's surface by a series of circles that appear embedded into the planet. These nodes are purely a GUI aspect of the game - the player interacts directly with these node circles to build structures or attack structures. If they are a resource node they will also display what type of resource they contain.

I drew up some simple 2D diagrams of how I anticipate the nodes to work both visually and interactively. What I need from you guys is some concept art that will show how the node system can work when rendered in 3D. So imagine a 3D planet with a GUI Node system embedded into the 3D art/model. You will also need to keep in mind that when a structure is built onto the node that the structure becomes part of the planet but rests in the node area. You would have a 3D representation of the structure as well.

Currently the game is played on a top down 2D plane with an X and Y axis. While the player may not be able to enjoy the full 3D open world that space is, we can still create the illusion that exists with fantastic 3D models, art and depth. These nodes are designed to be interacted with on a 2D level so it doesn't matter to much if the system no longer makes the planet's seem true to life but as long as you can create something that maintains the illusion of space that would be awesome.

I hope this makes sense? Lets see what cool concepts you guys can come up with :D

my final post for the evening on this project. I'm hoping this might provoke more feed back with focused direction to head with next round of sketches. My aim is to reduce the each fleet to a handful of design features/principles then build up each fleet from these.

I'm entertaining the idea of attempting some distinctly alien ship designs with the idea of the game being Human vs Alien. Any comments on that as a potential scenerio for the game?

I want to condense the variety of designs down. On coming back to the sketches:
I think the bulbous base shapes of #9 and #10 could be a distinct fleet trait, but no one has warmed to them :(

I also think #7 and #8 could make a distinctive fleet. They are based on modules and scaffolding. Some might say these designs suffer from 60's sci-fi styling too much but the angles/shapes of #11 and #12 could be incorporated into these designs to lend a contemporary look. (In retrospect #1 and #2 were warm ups for #7 and #8, so lets chuck them out)

#3 and #4 are starting to head into the relm of alien design. they were based on the idea of segmented shielding over an inner structure. I'm luke warm on them but if they are poplular I can work them further (I actually have preexisting thumbnails that i really like based on the same design ideas).

#5 has curving lines from modern automotive design. I really like this sketch and think a whole fleet could be modeled on that principle. #6 was a failed attempt on the same idea, it got a bit bitsy.

Does that shed any more light on potential directions with art? any validation or dismissal of paths to go down would be greatly appreciated.

I like your idea about merging the angles of 11 and 12 with 7 and 8, 7 and 8 looked a little boring to me. I suppose it is just my personal taste but the ones I like most are 3,4,5,6,11 and 12. I definitely agree that the silhouettes should be quite distinctive which could easily be implemented with an alien versus human type scenario.

Nice clarification there Chris, it does shed a lot more light on what you are trying to achieve.

"I also think #7 and #8 could make a distinctive fleet. They are based on modules and scaffolding. Some might say these designs suffer from 60's sci-fi styling too much but the angles/shapes of #11 and #12 could be incorporated into these designs to lend a contemporary look."

- You've hit the nail right on the head there. I think merging those two for a distinctive fleet feel a lot better.

"I think the bulbous base shapes of #9 and #10 could be a distinct fleet trait, but no one has warmed to them"

- they sort of remind me too much of the Dragonball ships; I was never a fan of them heh. I vote to scrap those ideas.

"#3 and #4 are starting to head into the relm of alien design. they were based on the idea of segmented shielding over an inner structure"

- These two I like quite a bit for the purpose of alien ships. Although I prefer the design of #3 over #4 - I would suggest maintaining a design similar to #3

"#5 has curving lines from modern automotive design. I really like this sketch and think a whole fleet could be modeled on that principle. #6 was a failed attempt on the same idea, it got a bit bitsy."

- Interestingly I actually like #6 much more than #5; #5 feels to curvey and sleek for my liking. What I would really like to see is a merge between #3 and #6 in design.

You keep pressing for a story driven design to emerge and I think you're right about that. I definitely like the idea of having Alien Races and Human Races. For the purpose of your concept art, if you want to develop further #3, #4, #5 and #6 into a more complete fleet based around alien life forms - blending together especially the designs of #3 and #6. For the human fleets definitely look at merging #7 and #8 with #11 and #12.

If you can, can you conceptualize each individual ship type I have currently written up for each race.

- Engineer Ship (I really like the look of #7 to suite the purpose of a human engineer ship)
- Artillery Ship
- Troop Carrier (perhaps a more bulky version of #5 to suite the alien troop carrier)
- Assault Ship (#6 would be my preferred alien assault ship)

I hope these ideas help. Please dont hesitate to reply with more questions

Cool, i got some ideas forming in my head, should have time on the weekend to get drawing!

just out of interest.. do we know what units setup and scale to work for in 3D? I've been messing around using johns concept art to get a start on some modeling and then it occurred to me that it would probably be a good idea to know what restrictions we need to work to i.e poly count, texture size, etc.

If your creating initial assets, greyboxing would be the first step. Which is usually a low but clean poly count and mesh construction, and very small textures that are also clean, usually just a solid colour.

Starting with greybox assets will allow you to make tweaks to the units scale and look fairly easily instead of jumping right into high detail asset creation. And by making many you can use them as temporary asset placeholders that programmers can link to when creating ships and stations, instead of having to rely on programmer art. :)

Good idea. Which spaceship are currently working on? So that I could work on another to speed things up.

sorry for double post. I though my browser crashed!

sorry, ignore this post. I'm a goose who can't use the internet

I've been chipping away in the background still! sorry for gaps between posts I've had some unavoidable hiccups that have upset my apple cart so to speak. Anyway, here is my next update to follow up feedback:

These are not to scale and i only had a loose idea of ship roles as I sketched. feel free to suggest your own interpretations as it might help me refine and create new options. All three ships are designed to be from the same fleet.

1)Artillery/planet attack ship. Very, very large scale compaired to others.
2) Engineering or troop drop ship. Could elongate it and unlarge scale to consider it as an option for planet attack ship
3) Small fighter.

Briefcase & USSMC, you might want to hold off on modelling until we have finalised basic shapes of both fleets. Iexpect to do a few more rounds of refinements and options before moving onto smaller details.

Hope you are all happy with progress,

John :)

The unified theme is really sweet. You can tell there is good cohesion across the three different ships. I feel #1 is a step in the wrong direction, looks too thin and too alien compared to the uniform look the second two really exhibit. Referring back to your original concept art, 1# really carries the size and weight of an incredibly large cruiser and if you blend the uniform exhibit in these artworks into the shape and size of that original drawing then I think we have an awesome artillery cruiser :D.

hope that helps

cheers for the sweet work

Nice and neat. #1 and #3 doesn’t look threatening to be an Artillery/Planet attack ship/Small Fighter; maybe you could add wings like the B-2 Spirit bomber, and sharpen the front a bit like today’s modern aircraft fighters. But hey, maybe it’s just me:) nice work!

Agreed #1 is too alien in design. below are 2 more attempts, I think #5 might have promise.
ussmc, I'll revisit details once I got basic shape & proportions of a full set of craft done. I'll keep your comments in mind as I progress.

Great work as usual, John! That's awesome stuff, and I like them both.

More thumbnails to look at. These are all working the same design. #6 is a medium sized verison for engineer or troop ship and the rest are attempts at larger variations as artillery. I was entertaining the idea of the nose sliding out and back to reveal a planet destroying sized weapon.

I like bits of them bit none are quite working for me in relation to the other designs.

By the way this is just a quick overview of the features and style of game play I have designed - I will be writing up a completely fleshed out document over the coming week.

This is really for you all to read points on, see what you like and what you don't like so i have a bigger better picture for what we all want to work with while I write up the main game design document.

SO dont be shy! hit up the feedback.

I like your ideas, especially the rotation of the planets in orbit. this will require the player to be careful while timing their attacks and adds a very interesting twist to the gameplay.

One thing that I am not so keen on is the resources and research stuff. My point being I think it would draw away from the defcon like play and lump it into the general RTS category (mind you I don't play many RTS games and when I do, I tend to lose).

I think if we have these areas we should try and keep them simple and not too complicated. You mentioned credit, energy, metal and fuel, the ones I really like are fuel and energy, these can easily just affect the speed of units as they move and their production, fantastic. If a player simply takes control of that area by having a base or whatever within range or destroying the enemy, therefore taking control of the region. I am a little bit worried that credit and metal may over complicate it. Same with the research stuff, I wouldn't want to see too much focus on research to make the units stronger etc. defcon is a timed game and I would like to see ours also very focused on time and destruction as opposed to research and upgrading units, although research and upgrades would probably lengthen the replay factor, which is good but it would also increase the length of matches. Defcon allows you to play at almost whatever pace you want, fast or realtime, this is another element I would like to keep.

Let me know what you think, these are only suggestions, I would like to hear what others think also. I think that the success of defcon is in it's simplicity, it eliminates a lot of the complicated things in most RTS games, I know we shouldn't be cloning defcon but I feel we should try and keep some of the core gameplay elements of defcon.

"I think that the success of defcon is in it's simplicity, it eliminates a lot of the complicated things in most RTS games"

Once the initial launch hype of Defcon was over, not as many people stuck with the game unfortunately. I think that can be pinpointed to it's simplistic gameplay (where it's carved out a niche of fans of that type). I've read so many comments from people who've tried out the demo and said it was fun for a few rounds, but it didn't create enough interest for repeated play.

I agree, Defcon wasn't set out to be an RTS, but I think there's a great potential to expand on the idea and add more strategy, depth and lastability that RTS elements would provide.

Due to the opinions here I went about adding depth into the design brief.

Suggo I agree with you too. One of the things I do not want to do was take away from the emphasis of the defcon game play by adding additional elements. Realistically what needs to happen is these elements; resources, research etc etc need to only enhance the core game play of timed, critical execution.

If we factor in the idea that we want to explore the possibility of added forms of gameplay then as we design, build and test we can work out whether they work, how effectively they support the core focus of the game and how best to iterate on it.

It becomes a lot of work but if we can solve the problem of adding these additional features without taking away from the core game play then we are ultimately sitting on a winner!

While looking at interplanetary Defcon you should also look at Planet Attack. It seems similar to what you are looking at here though it doesn't have defcons.

The game is based on population, there is only one resource and that also equals your score. Everything you buy costs X and each use costs X. It is hard to get the hang of (I hope your controls will be easier to pick up) but once you get there it is a good game.

first and foremost.. I'm glad you noted a planetary orbit system, it was one of the first things that came to my mind when the idea of defcon meets space was being thrown around. purely cause you don't often see it in space strategy games.

over all I'm very excited about getting started on this game just from looking at the basic outline, although like others the number of resources scares me a little. I think toning it down to 2 or 3 would be much simpler and less frustrating.

also i was wondering if there was any ideas for art direction or if anyone was in charge of concept art?

I've made a separate thread for discussion on the art. You can see it here.

To push the project along a bit further, could you break it down so that the types of vehicles and assets needed are listed? Just want to get a better idea on what's needed so we can allocate jobs to the artists and get concept art started.

Also, Roger, if you're reading, can you comment on the choice of game engine please?

Hopefully by the end of tomorrow I will have a fully fleshed out design doc for viewing. I'll include in it preliminary asset and feature lists for the artists to get that ball rolling then.

The next steps should really be to build a low level prototype of the game. I might try to do this on paper and I will post all the material I make from it. The game is heavily systems based so I want to get a really good idea of those systems flow and what areas need to be focused on the most.

I also had a bit of a look at Unity over the weekend - its a beautiful little package and can work really well to support the location issues we will no doubt face. Everything works in and out of a meta data asset library; if we can set up a server that we can pass these assets over then a lot of those boundaries can be crossed. We can get more into this later; I still need to check out some of the other freeware engines mentioned.

No need to rush, just making sure everyone knows where we are at, at the moment.

I think the version control / asset management for teams thing is only for the pro license of Unity. Unity also has network functionality in the indie license which is something we'll definitely need.

a new design brief has been linked - im gonna make a separate thread for asset lists

Just a note, we should be getting industry feedback on your design document real soon.

He Guys,

Over the last couple of days I've been doing some basic prototyping on paper.

I drew up 2 solar systems with 3 planets each on three different orbits. The solar systems were roughly symmetrical with the planets roughly the same distance from each other with the same orbit lengths. Each planet contained a different number of moons or resource slots but the total resource slots were equal over both systems.

The flow of the game play was taken in turns by month - each aggression protocol having 16 months total. However I only got through the first Aggression protocol for reasons I will explain later.

Each month the planets moved around part of their orbit and updated the players resources.

I mocked up some basic stats for the resources:

Fuel stations gave 1 fuel(1f) each month
Fleet movement cost 2f per cm of travel on the paper.
each cm took 1 month to travel
home planets contributed 2 credit (2c) per month
Mineral stations contributed 1c per month

I set the game up with 2 players - both started with:

1 home planet
1 fuel station on their local moon
tax
1 engineer fleet
2 attack fleets
1 artillery fleet

As I started playing the game out two things became abundantly clear:

The orbital system is really awesome.
I sent player 1's engineer fleet to a resource node on the first month while I sent player 2's engineer fleet on the second month - both arrived at their destination on the same turn but because player 2 waited a month the destination of the resource node became closer by orbit costing them less fuel.
Other times a player couldn't afford to send a fleet to a given destination until the fuel consumption was efficient enough.
The strategy and forward planning there is excellent

The second thing I noted was just how taxing it was for me to complete the calculations on paper for things as they accumulated each month - keeping track of what was building, what resources were coming in, fleet movement. Even though I kept the numbers small this became difficult to manage.
Moreso, I found the initial figures I set for the resources, especially the fuel were too taxing on the player so I had to start again with a different set up.

In conclusion, given a set number of rules, the underlying systems of the game can work really well. I just need to set up a better way to prototype it that allows me to play around with the figures by inputting different numbers.

It will take me a few weeks I imagine to set up a working prototype in flash. If any of the engineers wanna give me a heads up and lend a hand to this prototype it will be more than welcome.

In the meantime I'm gonna mock up some basic UI sketches for Souri to work from and flesh out the amount of feedback that needs to be presented in the UI.

Cheers,

Ryan

'feedback' over states the notes i made whilst reading the design doc. More a list of things that triggered in my mind whilst reading that i thought I'd post in case they fired off more ideas for others. I should qualify that I'm not a RTS fan, so I rate some game play details as tedious rather than engaging, so if the goal is an absorbing RTS style game my comments on those details should definitely be ignored.

Okay here are my notes:
-------
Distances within system very small vs distance between systems = travel problem (more a general statement than addressing a game aspect). Decreasing time scale through game may lock in styles of game play rather than allowing variety of tactics to be feasible...look into other options?

eg: Slingshot ships around planets to accelerate them to the enemy system? Creates handy excuse to remove travel time between systems.

Potential micro managing game play (research, orbit distances, attacking sections of plants, resource gathering) may detract from key elements/novelty of game? Eg: Simplify to ships that are in orbit replenish consumables (ie.fuel/attack&defence energy) or all altercations are 100% win/lose outcomes.

Moons could represent resources/launch aid making planets with moons more tactically valuable (more moons = more valuable).

Imposing defence condition levels may lock in styles of play or restrict tactics unnecessarily? May be create game play that will naturally escalate progressively. Aggression level set by events, events are not set by aggression level.

'subdued home-world loss' pointless option for defending team – total destruction more dramatic outcome too.
---------
good to read you are doing some tests with the orbiting systems mulletdulla, I suspect if vaguely realistic travel is implemented jumping across a system might be super complicated!

Hey John, thanks for the feedback I like this.

First of all I'm not quite sure what you mean here,"Distances within system very small vs distance between systems = travel problem" by travel problem, what are you describing as the actual problem?

---

"Potential micro managing game play (research, orbit distances, attacking sections of plants, resource gathering) may detract from key elements/novelty of game? Eg: Simplify to ships that are in orbit replenish consumables (ie.fuel/attack&defence energy) or all altercations are 100% win/lose outcomes."

This is definitely something that I'm concerned about and there are a couple of steps to solve some of the issues presented by it

- things like researching, orbital distances, resource gathering and travel planning should be incredibly well streamlined.
- for instance, to set up a fuel resource on a planet or moon you will need to select a resource team carrier and move it to the resource node destination. This requires both travel time and then set up. The interface of the game should provide the player with streamlined information necessary to simplify these actions. With the fleet and the destination selected the interface should inform the player of the fuel/time to the destination as well as provide the necessary option to set up the resource station on arrival. All the player has to to is select their fleet, locate their destination and choose the appropriate option. Bang, you have resources gathering!
- further considerations to travel can be taken to provide optimal paths, a selection between the fastest or cheapest route etc etc

However, the idea of additional orbital territory interfaces and attacking sections of planets is something I'm not overly keen about but a feature I wrote in to provide the artists with an are to showcase awesome art, models and particle effects at a closer and more detailed proximity.

---

"Imposing defence condition levels may lock in styles of play or restrict tactics unnecessarily? May be create game play that will naturally escalate progressively. Aggression level set by events, events are not set by aggression level."

These features come purely from the fact that we are appropriating a game called Defcon. Defcon was heavily built around different aggression levels that restricted player capabilities.

It's also important to note that restricting a players abilities does not necessarily mean we are restricting their tactics. The core idea of the Aggression Protocols is to allow the players to set up and prepare for a final offensive through a strict set of governing rules. By providing gates game play the players now what they can and can't do and will inevitably hone into the most efficient tactics and strategies presented by these rules.

As a great example compare Team Fortress 2 to Call of Duty 4. in COD4 the players freedom is almost limitless, any combination of weapons and the multiplayer maps are always very open. In Team fortress players are restricted to the class they chose and it's abilities while the maps are generally very tunneled, leading the player to specific points. While Team Fortress tends to restrict the player more, the tactics are just as highly evolved because players have such a complete idea of the rules they are working with; they know what to expect or how to best gain the upperhand on the enemy etc etc.

This is one of the feelings I am trying to capture.

---

I hope this answers some of your questions. OH yeah and I agree with total destruction being a more dramatic outcome - I'll amend this in the design doco hehe.

I really gotta play the demo of Defcon. I down loaded but have had no time to have a look at it yet. I'm sure once I have looked at it the attraction of that style of game progression will become apparent to me.

My comment on the distances was really a general thought about the potential game play problem of travel between solar systems. The time to travel across a solar system will be negligible compared to travelling between two different systems. I was thinking the game might need a 'excuse' to reduce the distance/time between systems such as hyper-drives and/or worm holes to bridge the gap so to speak... May be a detail that could call into things to consider when looking at types of research can be done during the game or the likes.

more random ideas whilst I'm typing here:
*simplify resources but making fuel, attack and defence strength all tap from the same energy store a fleet has. ie the further a fleet travels the weaker it's attack on an enemy would be.
*Option to increase speed of travel at cost of increase energy usage.

don't know if any of that is really going to help but there it is anyway :)

"My comment on the distances was really a general thought about the potential game play problem of travel between solar systems. The time to travel across a solar system will be negligible compared to travelling between two different systems. I was thinking the game might need a 'excuse' to reduce the distance/time between systems such as hyper-drives and/or worm holes to bridge the gap so to speak... May be a detail that could call into things to consider when looking at types of research can be done during the game or the likes."

Spot on dude, thats exactly the sort of gaps in the game play i was hoping research will hopefully fill. Problem is I can only speculate the kind of issues that will arise from the scale of the game, so I can provide any answers yet haha. It should all hopefully full somewhat into place after some development and testing.

Definitely having an option to increase speed at the cost of fuel is a good one tho. I'll make a note of that.

Ok, got some great feedback from Steve from Infinite Interactive who's had a quick look at the GDD.

Hi Souri,

I've just been having a brief read through your design doc.

It looks very cool, but does have a number of what I would consider very hardcore & esoteric elements in it.
Nothing wrong with that.
The main thing is to gradually introduce these unusual concepts (such as Aggression Protocols) to the player and make sure there is a good (and I mean REALLY good!) set of tutorials behind it all.

My advice on the dev cycle would be NOT to develop the initial maps/systems first (which is often very tempting), but to do them last. Seriously, don't even try to write up the GDDs for the first missions... just leave them blank and revisit them when EVERYTHING else is working.

Writing tutorials is NEVER fun, but a game like this with some new concepts can live or die based on the quality of the player's learning experience.

I'll continue reading and will send you some more thoughts on the design details as I get time to have a look.

Cheers

-Steve

Hey guys I've done a major revision of the GDD for our game an so I've released a new version, 2.0, that you can grab here

Solar Wars: Armageddon Game Design doc v2.0

I took in a lot of the feedback you guys have been posting. Basically I think the scale of the game we want to make is too large, its beyond what we can accomplish. I also respect the fact that the majority of us want to keep this as a portfolio piece rather than a commercial game, so that has also affected the scale and scope of the game design.

I have also had a lot of trouble trying to effectively design a interface system in the game that allows for the artists we have working on the project to develop fantastic looking art while still supporting the large scope of a galaxy. I know there are ways to develop interface systems for this purpose, sins of a solar system is one great example but again, this is beyond our scope.

In light of this I've made the following revisions:

The scale of the game has been reduced to a single solar system. The solar system is divided into layers; with the primary, player owned planets in the middle of the solar system. The primary planets are surrounded by resource planets on the inside and outside of the solar system.

With one Solar system we reduce a lot of the need to scale the interface as much. It also provides a smoother flow for our orbit and resource systems making them easier to play. The entire game can be rendered in 3-D now with players moving around the campaign map easily. This gives our artists a lot more freedom. The interface will still need to scale to support the size of even a single solar system but this should be a lot easier to achieve now.

Previously the design only allowed a 3-d interface when in the orbital territory interface. This interface has been completely removed from the game now as combat should be supported directly on the main campaign map. In its place a smaller, simplified version of a planet's territory has been designed.

Version 2.0 also introduces a more in depth Node system. Nodes are the slots on each planet that allow for structures to be built. These nodes appear directly on the surface of the planet and detail what resources the planet has and what structures are built on the planet. Previously I had thought that the best way to represent the information of a planet would be on a side bar; this system reduces the need for a heavy GUI and an overload of information. It also supports the design of bringing combat directly onto the solar system campaign map.

The last design changes all revolve around bringing the other systems inline with the new systms; such as combat, features and more.

The next design changes will involve a major overhaul of the combat system. I don't think this is functioning to well. In line with this will be a proper write out of the games User Interface.

Any update on the licenses Souri? I'm really keen to get started on building this baby now :D

my head is still spinning from the potential complexity the game could involve. But I generally felt things are refining in a good direction. Does anyone else feel nervous about the scale of the game still? From a game play refinement and programming point of view I suspect the project might still be a monster!

General mind-dump on what I read with ideas/question:
*home planet orbits are very close. On the assumption all planets orbit at different speeds will they pass in very close proximity to each other during the game(!) might this be the agression level 1 event? might this present a game play problem?
*a player based near the centre and a player on the edge of the system might reduce this issue -- and lends itself to an alien invasion scenerio(the GGD is game mechanics focused, a document on story/scenerio might help set some boundaries with things like this)
*6.1 units: the table needs some clarification :(
troop carriers are both a strength and weakness of defence stations? a good way to indicate the defence/attack differences between each ship type might be to make a (bigger) table. List each ship type in the x and y axis (in the same order). In each cell mark down the attack advantage the x-axis ship has against the y-axis ship. This should result in a nice table with some strong patterns running through it and will provide an accurate starting point to test fleet strengths within game play (I suspect).
*to suggest complicating the interface more after you paired it down: I was thinking about the idea of an interactive 3D hologram command map (think starwars where the rebels are planning their attack on the death star) wire frame planets in 3d could be a nice tipping of the hat to Defcon as well.

does that help, hinder? hope it at least fuels the fire of thought.

Thanks for the feedback Chris. I'll try to answer some of your questions and present some of my own.

"home planet orbits are very close. On the assumption all planets orbit at different speeds will they pass in very close proximity to each other during the game(!) might this be the agression level 1 event? might this present a game play problem?"

- This is something that does quite concern me and something I have not been able to accurately solve as yet. There will certainly be times that the planets will pass in close proximity to each other and there are a few potential ways to solve this:

> We can control the speed/starting place of each planet so that their positions during aggression level 1 is balanced evenly - though of course they will still be moving during this phase so they may come to closer proximity. This is a major feature of the game tho, a moving campaign amp that will force players to predict their strategies in correspondence to the location of planets well before they initiate their moves.
> Another way to solve this issue is the really extend the size of the campaign map so that the actual distance between planets is still large enough to not be considered close - this introduces more challenges to the travel time and distances between farther reaching planets.

- The best bet I feel will be to find a balance between these two points and see how it plays out. I certainly want to allow planets to pass each other on orbit and I dont want to hinder the travel times too greatly. This game play problem will really come under scrutiny when we have a prototype in the works where we can see just how it plays out.

"a player based near the centre and a player on the edge of the system might reduce this issue -- and lends itself to an alien invasion scenerio(the GGD is game mechanics focused, a document on story/scenerio might help set some boundaries with things like this)"

- The major reason I went for a three layer planet system was to balance the access each player had to resources. I initially redesigned the solar system to only have 2 layers, an inner and an outer rim. The player controlled planets would exist only in the inner rim while all the resource planets would exist in the outer rim. However, this presented a balancing issue as players closest to the sun would be at a disadvantage to gain resources compared to the player closest to the outer rim. To solve this I introduced the Primary planet layer and split the resource planets between the inner and outer rim.

- The system I designed, is designed to support multiple players beyond a one on one game and what I think you're asking for is to but the point I'm getting from you is to minimize the game to a 1v1 scenario of aliens vrs humans. This is definately a point not to be taken lightly for a few reasons:

>It reduces the scale of our game - making the development process easier
>By limiting the scale of our game to two team multi-player it also limits our opportunity to expand the game in the future. This could also work to our advantage.
>It allows us to create a story driven scenario of an alien invasion giving more depth to the art design
>It also means another major redesign of the game to cater for a two team affair rather than a death match
>Could return the solar system to a 2 layered affair with the alien race occupying the outer rim and the humans occupying the inner rim

So in light of these notes it may be required to redevelop the scope of the game once again. I actually think you're onto something here. By having a team based, alien vs humans affair it still supports all the major game play features but introduces new aspects and depth to the game. I'll return to this point at the end.

"6.1 units: the table needs some clarification :("

- thanks for your notes on this. I mentioned before that the combat chapter will come under a major redesign. I'm not satisfied with the current fleet archetype set ups nor with their abilities so I will take these notes on board when I re-write the section :).

"to suggest complicating the interface more after you paired it down: I was thinking about the idea of an interactive 3D hologram command map (think starwars where the rebels are planning their attack on the death star) wire frame planets in 3d could be a nice tipping of the hat to Defcon as well."

- You've really grabbed me with this idea. However I can't quite picture it. I get the star wars picture but I can't yet appropriate it to the look of this game haha. I've been looking at implementing a semi wire-framed HUD GUI. Perhaps when I've finished documenting that bit you can go over it and attempt to conceptualize and convert the ides further to a 3d hologram style.

So to return to the major point of redesigning the game to support a team vs team combat feature I am going to ask for everyone to reply to whether they support a change like this or not. The more I think about it the more I like it so I'm willing to make the change and I definitely think it supports the artists better while not taking away from the core strategy elements of my design. In essence it will be trading a death match style everyman for themselves strategy to team based combat where each player on each team supports each other. It also means we lose alliances - which I don't mind at all.

so everyone throw your input in for this one!

Sounds like you are across the details that grabbed me whilst reading which is good.
I'll do some concept arty stuff to illustrate with what I mean with a hologram wire frame tactical map.
I had lost sight of the expandibility to include more teams... I actually think designing to leave that option open is a good idea if possible.

...oh Just had an idea for the home planet issues that might be very scalable!:
All players are 'aliens' to the solar system (various races expanding territory). Each player has a Mothership rather than a planet as a starting point. Mothership navigation is decided at the start of each aggression level and travels through the planned navigation during that phase. Players can then choose their positioning in relation to planets and also dictate their proximity to other players for launching strikes, making allies etc. This would work for multiple players and even multiple systems I think.

you sure you dont want to design this game? haha

Thats brilliant! I like it a lot. When you first mentioned alien invasion I had a glimpsing thought of placing the alien race in a mother ship instead of a planet but didn't really explore the idea. It could definitely work but does introduce more complex elements. I'll have a think about it over the weekend write some fresh designs down and see what I come up with. At the moment my biggest concern is whats navigating the mother ships (player or system) and why. I feel confident that these issues can easily be worked through on paper.

Cheers for the idea.

You guys seem to be coming up with some great ideas. I am definitely all for the humans verse aliens idea or multiple races etc. Your mothership idea is looking brilliant. The motherships would allow for more diverse and variable game play experiences on maps which are essential very similar in terms of planet and moon placement. Rather than a player using the exact same strategy when he knows where the planets are going, motherships would add another variable to the map, making the same map almost different every time you play depending on how each player chooses to move. You could probably have a large number of spawn points for the mothership at the beginning of each level that would dramatically change the way the game is played out.

Hey guys,

I picked up Sins of a Solar Empire finally over the weekend and have been having thorough play through of the game. This is a game we can definitely take a lot of influence from in terms of user interface functionality. What I found quite is that a lot of the elements of our game are similar to Sins in terms of functionality while the game play still differs.

I wrote up a bit of a document about it including screen shots of all the major features that I think we should incorporate to a similar style into our game. It should also give a fairer idea to you about the game design I created. What I found most promising is that a lot of the systems I attempted to design are proven to work in sins of a solar empire. The document is pretty large but fairly informal, again feel free to post any questions.

Sins of a Solar Empire Reference doc

Going back to the progress of the design for our game. I started to explore a lot of the new ideas we came up with Chris but ultimately it was just creating more questions I can't answer just yet. I am more concerned now that we have our engine licenses underway with creating a working prototype. That should provide us with a platform to really test our major game play concepts and then incorporate any additional changes.

For now Chris I would definitely aim to conceptualize 2 races. The game will definitely be built around two races to support a whole aliens vs humans scenario. What I would really like to do in the end is actually build all forms of game play that we have mentioned into the game in the form of playable scenarios. So we would have a standard death match map with the players centralized and the resources moved to the inner and outer rim. A team death match of aliens vs humans with the aliens occupying the outer rim and the humans occupying the inner rim. And finally we could also create an additional scenario that uses these motherships we have mentioned. I'm a bit annoyed at myself for not thinking of this earlier when i mentioned how changing these aspects of the game play would limit the scale and expansion of the game haha.

I've actually been looking at Sons of the Solar Empire for art references, they do a pretty good job there too.

Hey hey hey another big update in the works here! Very exciting!

What I have for you today is the preliminary designs for the User Interface.

User Interface 1.0

also added a .rar archive of all the jpegs

User Interface Diagrams

This short doc is a brief of the User Interface section of the main GDD. It includes the overview of the functionality of the user interface; The HuD and the overlaying GUI, a look at how the Planet GUI will work and most importantly it has a story board of the User Interface in action.

The story board also details how a lot of the game play will operate so its good for everyone to read. I'm posting this out first so everyone can have a good read and hit me up with feedback before I finalize the details and add it into the main GDD.

There's a lot of work to be done with UI Souri. My first recommendation would be to organize with Chris N a unifying Art Direction for the game and start assembling the pieces from there.

There is a lot of Iconography for the UI that I'm sure you will need more detail on later but a great place to start would be specific iconography for the fleet types that would work in both the Fleet Listings, Build Menus and on the Campaign Map.

As always hit me up with any questions.

The note of who is where and does what is a good addition.

I still have to look over all the details you linked, but yeah everything there does seem a bit pricey, I'll let you know if my team stumbles across anything we'd like, but hopefully we can get this done without expensive licences.

These licences are expensive, additionaly the prices listed pretain to per programmer using it. So if you have 3 programmers working on a game using unity. It's going to cost you $600 USD.

Team Tower City [team of 2 people so far mind you.] Are currently looking into the engines Unity and TGEA to compare their capabilities from a hands-on perspective. We're still weeks away from coming to a decision on which one we'll be going for. [and I'll be paying for it out of savings.-ouch!] But from their face value so far it looks like that extra $100USD per licence you pay for TGEA is for more documentation and being able to edit the source code of the engine. Where as Unity doesn't seem to let you or only do so in a limited sense. That's the face value assessment but I could be wrong in these findings. We'll spend the next few weeks looking deep into both engines before choosing.

I would suggest with teams A - B - C that they to download the one month trails of these engines and assess them. See if they pose benefit to use.

Cheers!

Name: John ho
Location: Brisbane
Focus: Game Designer/3D map/environment modeling/little visual design
Skills: 3D environment modeling/map concept, QA (like testing game), some visual design,a little marketing management/research

I hope it is not too late to get something to start with..

I really hope can get some job/experiences in the industry

Sounds like you've got a solid team and idea happening! Can't wait to see how the game progresses. All the best, guys!

Fingers crossed we can show you guys a prototype, GDD or some art as it progresses soon.

Things are looking good, slowed down a bit over Easter break but that was to be expected.

Quite possibly we should have a playable prototype within a fortnight which I will put here for people to view and comment upon. I'll do it probably with another update, any art we have by then, and possibly a properly documented GDD (it's currently spread across a wiki, but I should try compile it to throw alongside this package).

Awesome job on this, mate! Btw, the 200x600 placeholder graphic for the side - you can grab it from here.

To move the project forward, Charcoal will need to playtest and fine-tune the settings.xml... Also, Charcoal, you'll need to provide some specs on the content needed so we can make a complete game from this. Make a bullet point list and we'll assign the jobs.

And was suddenly reminded of my second ever gameboy game "Mario & Yoshi". In this game you did not control the blocks, but the platforms. Mario and Yoshi also had the top of an egg and the bottom of an egg as two seperate entities, and the top would always disappear meaning you'd never be left with blocks you could not remove.

With a quick playtest of Burger Time, I can tell it needs some tinkering. It took me 20 seconds, whilst only holding down, for me to lose as burgers kept stacking up. But so far so good, always good to see early stages and how they develop onwards.

Just one question - is Burger Time the official title for this game?... Because BurgerTime was released in 1982, it was my favourite game on Intellivision >_>

I don't think it is official ... The design doc did have the name as "Stop! Burger Time!", I just got lazy and dropped the 'stop'. :)

I would say Burger Time is working title of the game ;)
And Stop! Burger Time! should never be in the running for discussion as the game's title.

squashed_bug: How would you feel if I changed the type of puzzle game we use?
I've been playing the prototype and I keep coming up with problems that I have a very hard time fixing.
After reading David's comments about the GDD, I think that a match-3 type puzzle will work better...

Propose what you want and I'll comment on how feasible it is.

What's a match-3 type puzzle. Is it basically a falling block game where you match two buns with a filling? Or somthing without falling blocks or hamburgers altogether?

Basically it's Bejewelled, or Puzzle Quest.

The way I see it now, you don't match up gems in a sequence to make hamburgers, but you aim to make cascades, to add the fillings to a burger/sandwitch/whatever.

From what I imagine on your end, it would mean a re-write of most of the game.

• *It's still on a grid, but it's always filled with gems.
• *Instead of moving a group of three gems you swap two adjacent gems, to create lines of three or more.
• *After a match has been made, more gems fall in from the top to fill up the grid again.
• *More matches can be made by the falling gems, adding more fillings to the burger.
• *After the cascade has finished, a score is derived from the combination of fillings resulting from the cascade.

This time I will mock up a series of screen shots ;)

A question that's' popped up into mind as i've been following the development of this project:

Any particular reason the theme is fast food burgers?

Don't get me wrong. The setting of a puzzle game can be anything really. I am curious to know why the game is themed around burgers. I just can't find a context between gems and fast food.

When I think of gems, I think of riches and miners and old commodore games. Anyone remember those games where you had to dig yourself out of puzzly mines full with dirt, boulders and gems?

I made a quick mock up of kinda what I think a theme with gems possibly could be:

[advance apologies to all for the poor vector art.]

That's all really dude. I understand that the dressing for the puzzle game can be anything really. [Although good context can definitely help with the aesthetics of the game.] Just curious about the current decision. :)

Cheers!

I used to play it all the time on the C64! They've remade it for the DS, and it looks *awesome*. They got the style and cuteness down pat.

The decision to use burgers as the theme came about when I first started thinking about what game to make.
I walked away from the computer and joined my housemates in the living room, watching TV.
As I was thinking about what time of puzzle game to make, an advertisement for Hungry Jacks came.
From there it just went together in my head; stacking specific patterns of gems.

Also, gems are just a naming convention for the movable items on the game board.
If it helps, we could start calling them ingredients :P

I too remember boulder dash on the C64.
A bit different to what you've suggested, as you can see in the youtube Souri posted.

calling the movable items 'ingredients' from now on is a good idea. It'll help people quickly associate the game elements. I can make a link between burgers and ingredients. I pointed this out thinking back to my experience with the lead level and game designers at Bluetongue. They where always quick to point out things that where ether inconsistent or didn't fit in with the theme of the game or presentation. Someone needs to put these questions across even if they seem a bit trivial at the moment.

The vector art mock up isn't really specific in any way other then having a mining themed title and little man with a shovel. Didn't really want to suggest a puzzle type or outwardly replicate boulder dash. Just wanted to get the retro-esqe spirit of the game across. :)

Cheers!

I was thinking about this today and I have a few tips:

1) Specific orders, you have to make a specific thing.
2) The Menu - have a list of things that the ai can order, you can change the percentage of price (which then goes to score)
3) You should have a customer happiness bar, this goes down the longer you take to make the burger.
4) Ingredients cost.. When you match an ingredient you don't need it still gets subtracted (from score/money)
5) You can have 3 burgers being made at once.
6) You have upgradeable staff/store (you upgrade as a whole) in categories such as drinks, sides, cleaning and customer service. These allow for drinks and sides to be served better and faster, the store to be more clean (so that while they are waiting in line they are more happy and they may chose to eat-in more often), and to have the servers temp the customers into buying more.

Basically with the menu I was thinking you could have (for example) 'Burger with the lot' and you have to make that, but you could also have 'Burger with the lot meal' (comes with drink and side), this earns you more points but is less likely to happen and depends on you upgrades.

PS: This was to work with the match-3 style game that I saw at Dissecta.

Can't wait to see some of it.

I have a female and male chef concept as well ill post em after a little cleanup

Very much looking forward to seeing them! The cooking mama + My Sims style would be an awesome style to adhere to. Perhaps we should post some links and pictures as references for the art team?

I've done some vector artwork for the team b casual game, decided in the end to not do the 3d route because i couldn't achieve the look i wanted.

Click Here!

Very awesome work there. A clean presentation which is what's needed. :)

That's some pretty clean vectors you've got yourself there.

Very very nice.

Although, how would it look if there were some grill marks on the beef?

I've asked John Passfield and David Hewitt for some feedback, and you should get a response from David soon. John's heaps busy with his stuff at 3 Blokes Studio, but he's interested in providing feedback in other projects in the future. David's the Creative Director from Tantalus, and I'm sure you would of seen him in a few of the videos in our media section. He's in about 3 or 4 of them.

I actually had an interview with David about a year ago, so I've met and know a bit about him.

It's great that he's casting his eye over my work, but I'm scared :P

Great!!

This gives me somthing to work with. I should be able to have a little prototype up in a couple of weeks.

One design issue I see is, What happens when a filling doesnt have a bun underneath it? ... The filling will be stuck on the grid forever.

The only thing I don't agree with are the hours of gameplay required. I think a level shouldn't take long to complete, around 10 minutes. Also the time taken to complete the 'story' mode should be well under 20 hours.

The bun problem is something I've thought about (but only after putting up the design doc) and can think of four ways to deal with it:
1. Just leave it, if the player is careless/unlucky, then it's their problem.
2. Have a "flame" across the bottom, that destroys gems that stay too long on the bottom.
3. Be able to make burgers horizontally, which doesn't totally solve the problem, but makes it easier
4. Have a row of bun gems on the bottom that automatically replenish when used.

I think either 1 or 4 might be the best. But with 4, the size of the well might have to be adjusted...

The timing was just a very quick idea. I'm sure that David will have some comments on that. Also, I think how long one game should be once can only really be judged once the basic game is playable.

I'd like to read the document. =D Would you happen to have it in ye old .doc or .txt format? =D

I'll convert it to the old .doc format right now ;)

Edit: It's up

*Has a quick sqizz through the doc.*

Well. A few points from myself.

1 - Some diagrams to compliment the writing of your document would go a long, long way. As a more visual person myself I'm trying to visualise in my mind how grids, gems and burgers mix to make a compelling game play experience. You can better communicate the concept of the game play by having pictures, diagrams and animations/videos to compliment your writing.

Better yet a mock up of what you think the game would look like. Dev studios do this all the time when pitching game ideas before they even have an engine. Did you know that Bioshock was green lighted on presenting a 1 min video render of an underground nazi bunker? :)

2 - Don't use works like 'could' 'might' 'I Imagine..'

The reason I say this is because you’re presenting this document to people as a reference of design and fact. Not speculation. When explaining things in these GGD use words like "Will" "The way it works..."

Write like you have confidence in your design. :)

3 - Bullet points are your friend! Remember readability and ease of communication are key for a game design doc.

For instance...

Currently:
SINGLE-PLAYER GAME DETAILS:
Each level is based on a franchise location. To progress through to the next location, a player will need to serve a certain amount of customers. To make it easy for the player, the customers don’t care what burger they get. I imagine there will be around 50 levels for the player to progress through.

The player starts out only with the bun, beef and cheese gems. After every 5 levels/locations, a new gem is introduced to the player. This obviously continues until all the gems are introduced, after 15 levels.

In bullet Point:
Single-Player Game Details:
- Each level is based on a franchise location.
- Completion of level is based on serving 'X' amount of customers. [X being the number of customers per level]
- Customers don't care what kind of burger they get.
- There are a total of 50 levels.
- Game starts with only 3 gems available to the player.
- A new gem is introduced every 5 levels until all gems are available.

Anyway dude. I hope that helps!

I generally agree with the 2nd point of Mr watts above, have no real qualms about the 3rd point, however I'd have to disagree with number 1. As an initial game proposal, throwing images in is inconsequential. Though you're right in saying dev studios mock up and provide images for their proposals, this is usually when they have a large team working on just a simply proposal to get the publishers approval. Words on a page will still go a long way currently, though I admit I'm not "a more visual person" and have a rather vivid imagination.

I'm not going to comment on the game mechanics or ideas, but like watts above I'll give some thoughts on what you've put down.
1) Some of the wording is not standard, and though that's fine, questions as headings can easily lead to confusion. Example: "What is the main focus?" I would have replaced with "Player Motivation" since the main focus could be construed from the view of a player in playing the game or the developer in making the game.
2) "What's different" should probably also make mention of some competition (or games with similar elements), if only to make the rest of the team more aware of both what the game may be comparable to and what they should not try to copy too much of at the same time.
3) "Design Goals" are something I've picked up as useful in early proposals. I use this heading to state a few key concepts that, no matter how much I might change the game from the initial proposal, I should keep throughout design and development. A design goal of this may be something like "Time-stressed puzzle" or "Childish and Cartoon-style".

I probably have other things to expand on, but this is v.01 and a GDD for a short casual game only. So far so good I would say though.

In follow up about Point 1.

From my experience in the game dev scene. Pictures and movies compliment presentations. You can definitely keep an audience attentive to your explanation of a game feature if you have visual presentations to back them up.

But as this is about the early stages of a game design document lets put that to the side.

As it stands with the current state of the document. While there's no need for videos or detailed concept art. I think what would really help reinforce the core gameplay concepts prose would be a simple 2D diagram that shows a visual representation of the grid and the gems that reside inside it. This could be something easily sketched up within a few minutes. This diagram builds a image that I as a reader don't need to conjure up. Which leaves my mind open to contemplate other aspects of the game design.

As designers we need to illustrate our points as clearly as possible because you'll have all sorts reading it. If my brain ends up visualising what's been written incorrectly then there's a problem. Effective writing is rightfully so No:1 but inserting other forms of communication where it's in logical context only helps to strengthen the design. :)

Thanks for the feedback, I've only ever done one full GDD before and that was as part of some study.
The only other GDD I've worked on was to do with some RPG systems and how they would work with an already designed and prototyped puzzle game.

Version 0.02 is going to be so awesome now ;)

Now that the demo is up we should concentrate on the key gameplay and try and make it as fun as possible.

My first issue with the gameplay is that the grid fills up too quickly. Completing a burger hardly slows down the rate that the grid fills. Perhaps designing some sort of reward/bonus/power-up system could help. An example of a reward might be converting the bottom row into buns ...

Note: I you can get the demo from the Burger Time Demo thread.

Alrighty. I gave the demo a go. Here are my musings. =D

- Small point: Being a grid based game it would great if, like in tetris the gems fall down per square row in a timed interval. This actually affects gameplay as it's a way for people to judge and time their movements on the grid. Additionally it’s visually jarring to have an object smoothly scroll down rows of a grid.

- Big point: I understand this is a bare-bones implementation of the game. But as an end-user playing it. I had no idea what to do. This is because of two reasons:

1: I don't know what the aim of the game is. For this early in the prototype stage all you need to do is have a screen before the game begins that tells me in words and/or pictures what this game is about and that I need to align gems to create a burger.

2: Now that I know the game rules. I didn't know what coloured blocks represent what gems/ingredients. What colour are the buns?

You can solve the second issue by placing a small diagram next to the puzzle that displays what colours represent what gems/ingredients. Also a diagram under it just showing show creating a burger works. Which needs to be no more complicated then showing two yellow gems and a few gems between them.

- Big point: About the gems themselves. From a glance it looks like your gems/ingredients are being randomly generated. And it's simply the case that the yellow/bun gem isn't appearing often enough to let the player clear the screen. As it's the core gem it needs to spawn more often then it is now.

If you're using random generation perhaps adding a higher percentage of yellow block generation chance will help this issue. Play around with this percentage as well. Experiment.

Additionally. Adding a few rules to your block generation will help out, like making sure there's never more then one yellow block per drop. [So it doesn't just despawn upon landing.] Other gems/ingredients are fine to double up on.

Hope you guys find this useful. :)

I like the prototype, it's given me some ideas for improvements to the design doc.

I agree to the movement being limited to the grid. The smooth falling seems to be wrong, I think this is mainly because other games of this type do it that way :P

Also, a guide to the gems to the right would be nice for now.

Lastly, having weighted options for each of the gems would be great.
That'll be one of the next things I write in to the design document, with some preliminary values.

^^ that's me.

The new version is on the Burger Time Demo thread. I've also updated my post with a bit of a description for each of the xml elements in the settings file.

Demo-003 changes:
+ added settings file (settings.xml). Now you can have a play around with different settings.
+ added gem weights (they can be modified from the settings file).
+ added the option to stop multiple bun gems from spawning (again modify from the settings file).

Next Release:
+ implement dropping by cell.
+ If someone sends me an image which acts as a guide for the player, I can throw that in. The image will stay on screen the entire game with dimensions 200x600 (the background should also be transparent).

I can do a simple guide to start with. Also, can you provide some specs for the artists to work with? What resolution would they need for background pics, title screen, gem icons etc?

That was a very quick response time. Well done on getting these changes done so fast!

Some new points:
[Although please note these are always directed at the team which includes the programmers, designers and artists. Additionally my feedback should be always reviewed by the project lead so he can evaluate the feedback.

In less words: Don't do what I point out unless the project lead wants it done.]

- ingredient build up. Now that buns are more abundant and I'm able to string burgers together I start to notice just how quickly the ingredients at the bottom build up. This issue needs an elegant design solution.

I would suggest that a way must be created that both clears the bottom but also effects the player adversely due to his sloppy job. take for example:

Timed ingredient burner:
Every 10 seconds [or more/less] the bottom row of gems are cleared from the grid via incineration. For every ingredient gem that's incinerated deducts 10 points [or other value] off the players score. Buns are exempt from both incineration and score deduction. This will lead to buns eventually falling to the bottom grid and staying there until a burger is made in that column. So while incineration clears rows of unusable ingredients and sifts bun gems to the bottom row it also penalises the players score.

- Implement scoring and a goal:
Now that you have editable values. It would do well to experiment with different weight combinations and seeing what works and what doesn't. [hint: ingredients that carry a bigger score should spawn less.] And getting a scoring system up and running will help you as well. Attaching a score based goal as well so as you're playing the game you have something to work towards. Once that goal is reached you can simply reset the demo.

It falls to everyone on the team to test the game as much as possible. get some solid weight and score values for the gems, burger combinations, possible score multipliers and a score based goal. :)

Cheers!

Again it's on the Burger Time Demo thread.

Demo-004
+ Added the option to drop per cell
+ Added options to remove old gems

I'll throw the descision for resolutions over to the designers and artists. At this stage it's a matter of what works/looks best. My 2 cents anyway is 800x600 running in a window (which is what is running in the demo). I don't know about gem sizes as it really depends on the screen layout and what grid dimensions works best. Since the gems are all going to be created as 3D models (?) it might be more important to determine the width to height ratio for a gem ( perhaps 2:1), as it will be simple to render them to any screen dimension we choose (?).

The scoring could be based on making the customer happy where a customer has a random set of requirements for their perfect burger based on none or more of following attributes:
- Order of the gems.
- Whether the burger has (or doesn't have) a particular gem.
- Size of the burger.
So some customers would be easy to please (they might even be happy with two bits of bread) and other would be more fussy.

I don't really like the gems being cleaned up on a time basis (they do need to be cleaned up somehow). Maybe cleaning up the bottom row could be given as a reward for making a particular burger or by using some sort of power-up gem (?).

Sorry guys, the executable from Demo-003 was in the Demo-004 zip. This has now been fixed.

Ok, I know Charcoal is dreading/looking forward to this, so here's some awesome and very constructive feedback from David Hewitt!

----

Sorry I didn't get back to you sooner, Souri! It's been a slightly crazy time around these parts lately!

In any case, here are some quick thoughts on the document (I hoped I'd have more time for this, but my dance card has become very full in anticipation of GDC next week):

The intro needs to start with an executive summary. Tell me what platform it's for, who the audience is, what the expected rating is, and so on. This can just be a quick table, but it needs to be there.

Page numbers and chapter/section numbering is a must when you're working with a team. A nit-pick, but it's important.

Use active voice and present tense, where possible. There's also no need to keep referring to the player in this context - we know they're present. "While the player is playing" is redundant, for example.

The "features" described aren't really features at all. They're marketing speak. "A new twist on proven puzzle gameplay" isn't something a programmer can implement, or something that can be put on a list of deliverables. This needs to be broken down into entities and mechanics that will actually appear in the game, and need to be built.

When describing the different gem types, a table would be easier and clearer, and a quick sketch wouldn't hurt, either.

This is obviously early days, and the doc is very lean, but I'd look to include some more detail on the scoring system, a representative 5-minute gameplay example, some sketches and layouts for the menu screens and HUD, some details about any particle effects and animations required, any pop-up messages that'll be needed, the unlocking or reward schedule, the difficulty progression and how it is implemented, the save data requirements, etc.

There seems to be no plans for a multiplayer component, so referring to "single-player" in the various game modes is redundant and potentially misleading.

The design needs to be expressed in specific, definite language. Features need to be built and then tested against the design. "I imagine there will be around 50 levels" and "The player wins by setting up a franchise on the moon" aren't helpful. Say "there will be 50 levels", if that's what you think. If it's wrong... change it later! If the player finishes the 50th level successfully, and then a cut-scene is displayed and the credits roll, say that. If the final few levels are set on the moon, and a different set of art assets will be required - this needs to be specified. Bear in mind that a first-pass design document is used to determine a feature list (i.e. some things the programmers need to make happen), an asset list (i.e. some things the artists need to build) and the project scope (i.e. how long it'll take the programmers and artists to do all the things you've described). You know this will change, but have a crack at it - it needs to be looked at and measured.

I'd also recommend writing the design in terms of user stories, effectively describing the various things that the player can do in the game, and how the game responds in each case. This provides a more specific, user-centric look at the game, which helps the reader visualise it, and also helps the programmers and artists implement what you've imagined. A feature doesn't exist until it's exposed to the player - a combo system requires pop-up messages, audio feedback and other niceties on top of the underlying maths. Designing features in a way that's descriptive of the end-user experience helps ensure that all these things work together. It also helps with testing - these user stories should be written in a way that can be easily verified. When I press the action button when next to this thing, does the described action take place?

As for the design itself (without yet having played the demo):

The first thing that leaps out is that the game's length and scope is out of control. What you're describing sounds like an old-school score attack game. I love those, but they only take an hour or two to play through. Do you want to play this game for 35 hours before reaching the end? Do you need to have a large number of different settings that are functionally identical?

If the game's about a high score, make it short and make it hard, and most of all make sure there's some depth and complexity to the scoring system itself. The player needs to be tempted to take risks in order to pay off big, but risks that could be costly if not executed properly. The very first thing I'd want to see in a game design of this sort is a breakdown of the player's thought process as it relates to the game mechanics - specifically in terms of risk/reward. Tap into the player's greed and their ego - when they do well, they need to feel great about it (how does the game pat the player on the back?) and when they lose, they need to ask themselves "why they heck did I get so greedy there?".

The game obviously has some influences (Burger Time, Puyo Puyo, Columns, Diner Dash, etc.) - I'd analyse these in the design. What makes them work? What's their scoring system? What's their risk/reward equation? Then discover what you're taking from them (there's nothing wrong with this - we're all standing on the shoulders of giants!), and why, and what you're changing, and why.

The different locations are mentioned repeatedly, but sound functionally identical. Why not mix up customer types/requests? Or the assembly grid layout? How about some picky vegetarian customers, or meat lovers who demand multiple beef? Don't add complexity for the sake of it, however - if the game's about a simple, linear scaling up of a timing/dexterity challenge, then don't fuss with the locations. Keep it simple.

The biggest issue, in my opinion, is that around the scoring and risk/reward system. Every good puzzle game has this at its core, and it needs to be designed - it doesn't just happen. Going for a four-row "tetris" clear? Oh oh, there's nothing but Z-blocks, and your pile of junk is mounting up. Setting up a 5-chain? Oh oh, the opponent's garbage blocks covered up the trigger square. Give the player a reason to make their situation progressively more precarious, in the hope of paying off with a big combo. They should feel courageous and awesome when it comes good, and foolish and greedy when it doesn't.

Now, after having had a (very quick) look at the demo:

I love the fact that this is being prototyped very simply like this. Getting the core of the game sorted out before working on the window-dressing is exactly the right thing to do.

The next thing to implement is the scoring system. If the game really is about scoring, then this needs to go in early, so you can see if you're generating the right risk-taking behaviour in the player.

What happens to non-bun gems that don't have a bun under them? Are they gone for good? Is there a way of getting rid of them? They're unavoidable, in the current system.

Think about allowing the player to make burgers horizontally and diagonally, maybe? I can't see how you'd generate combos in the current system. How does clearing some gems by making one burger cause another burger to be made? Or perhaps you might want to explore making double- or triple-width buns a source of combos. Or maybe grouping multiples of a single type together "creates" a bun gem somehow?

How about a "bad" gem that you need to deal with? Perhaps if you get three of them together you can clear them, but if they go into a burger, they make a customer sick? Just a thought.

Why 3 gems together? How would 2 work out?

Some of the burger-making rules are a little complex (can't be higher than X gems, can't have more than Y of each type) - these will need to be clearly and visually communicated to the player. I'd look to simplify here, or just loosen things up.

I think I'll leave it there for now - sorry for the stream-of-consciousness rant, but it's the best I can do at present, in the midst of a busy patch. Let me know if you'd like to talk in some more detail about anything I've said here - I'm looking forward to seeing this thing progress and mature.

Oh, and I'm making burgers for dinner! (Seriously!)

David Hewitt

Creative Director
Tantalus
www.tantalus.com.au

I've read David's comments and have been playing around with the prototype. The prototype only brought up many, many problems with my initial design.

So, I now have a short video of where I think the game go.

Any updates on the revised design document?

Anyone know where he's been? He's disappeared since the Dissecta event. I sent him an email last week and haven't received a reply.

I did meet him at the Dissecta event, but I haven't seen him since then.

I know he was dismayed that there didn't seem to be much activity here, but I doubt he quit since he still seemed quite encouraged by it all...

In general guys, don't die. If Charcoal does not rear his head in the next couple of weeks, go on another hiring spree. Don't let this get too inactive, else it might be more than Charcoal that leaves.

The only reason I haven't replied in this thread is because I haven't heard back form either Souri or Squashed bug.

Also, I emailed you on the same day I emailed Souri...

I didn't think I needed to respond to it, I was just checking to see where you were. In any case, at the moment we're still waiting on the revised design document, and Squashed Bug's input on the game changes.

We'd also need Squashed Bug to give us some specs on screen sizes so we can think about the gui, menus, and background art.

The video is looking a bit identical to bejeweled and puzzle quest. It's going to need some addition mechanic that sets it apart. Any ideas?

As for screen sizes, 800x600 windowed is as good as any. These dimensions can easily be changed if the design of screen layout requires somewthing different.

If we discuss a bit more about the new gameplay, I can throw together another prototype.

^^ Thats me. ^^

In my mind the difference is more of a focus on creating cascades/multiple gems matching at the same time.

Also ,we can add people that are ordering specific burgers.
And have a bonus for getting the right burger.

Then later on, if that isn't enough we can wrap a management meta game around it.
With effects on the burger making game.

I think it's better if we can tie down and prototype the basic match-3 game first, then start adding the fluff that will make it a great game.

I can build a basic match-3 prototype. Probably won't have time until sunday night to make a start on it. I'm not doing much next week, so I should have somthing running before next weekend.

Hi, my name is Ray. I am looking for a 3D modeler/animator position here. I am a graduate from COFA in Sydney.

Here is my skillset:

Autodesk Maya – With 4 years experience on practicing from simple objects to realistic human modeling. Capable of animating, texturing, lighting and rendering complex 3D animations. Have good understanding on using Maya Hair, Particles and Mental Ray.

Zbrush – Have good understanding of the intricate interface. Use as an additional sculpting tool in conjunction with Maya to achieve a better result on realistic human modeling. Also able to create texture map through the use of Z-Mapper.

Adobe Photoshop – 5 years experience on image compositing and photo retouching. Able to create textures for 3D models confidently. Familiar with most tools and functions from the tool palette to the actions function.

Adobe After Effects – 3 years experience on compositing both 2D and 3D animations. Capable of applying various effects on videos and animations through an effective use of layers.

Final Cut Pro – Used as editing software for both video and sound files through the use of various tools. Able to integrate it with Maya and After Effects for an efficient production workflow.

Adobe InDesign – Usually integrate it with Photoshop to design professional layouts for print and digital publishing. Have experiences on designing business card, book layout, DVD and DVD case cover.

Macromedia Dreamweaver – Capable of designing web pages through the use of design interface and HTML coding. Also able to integrate Dreamweaver with other multimedia based files.

Macromedia Director – Have experience on creating interactive game for web design purposes. Able to navigate the complex interface with confidence.

I have been working as a freelancer for a while since I graduated. And I am hoping to gain some experiences in the game industry.

My email address is chunhol2000@yahoo.com.hk

Looking forward to your reply!

Keep your eyes peeled on this thread as we get some more interest. Be sure to register an account in the meantime though!

Have already registered~!!!

Let me know if there is any news.

Looking for character animator position here. I’ve been using Maya since late 2004.
Showreel: http://www.youtube.com/watch?v=xegIMpl5PQ8
Email: ussmc2@hotmail.com

I have an idea for a game...

And this is where alarm bells should go off, because I'm simply not a game designer, but hopefully we can attract some interest from a game designer who's willing to take on this project and fill in all the holes and voids of my idea... or if it sucks, come up with a better one. I know game designers have ideas for a great strategy game.

But my idea was to extend the Defcon indie game idea. Now, there were some major faults that Defcon had, mainly that it just didn't have much depth and replayability. We can expand it by theme (making it cover solar systems and alliances), and better it with game play (strategy, conquering, more resource gathering, building etc).

I'm pretty interested in the aesthetics in this game, and how the project can be assigned to different team members and artists. However, I'm not sure how much of a task this would be for the programmers and if it's a realistic one at that. In any case, this project is much larger scaled compared to that of Team B.

Personally, I'm willing to put my hand up to do the fancy UI and menu design in the game and texture work. Any thoughts?

I'm up for some stuff. I have no industry experience but would love to give it a go. My weapons of choice are 3ds max and photoshop and am probably better suited to modelling buildings, vehicles etc.

Dam I wasn't logged in when I posted my interest as a 3d modeller. But yeah I'm keen.

Heh Defcon is a psychotic game really. I think you feel really get that feel most from the somber ambiance of the audio and interface. The problem I see is if you expand on what game play it had by introducing resourcing, building, armies, etc then it will lose its simple focus and emphasis.

You could however reverse engineer the idea and operate it like the space race in Civilization by being the first to build and launch the nuke. In this case the game takes shape with resource gathering and controlling, research development and simple attack and defense systems.

The idea being that you control one army (planet, nation or otherwise), you are responsible for developing research into the nuke, gathering and processing the resource for the bomb and finally its manufacture. You will have to deploy defensive measure to protect these facilities and resource nodes while at the same time develop strategic offensives to sabotage, assault or capture your enemies facilities and resources.

By the way I'm a game designer with some experience. Hopefully that fills any voids? haha

Not quite sure either how to handle the specifics of the programming for said project but I imagine if it is a heavily single player experience than an effective AI system would be in great need.

hey guys, I'd be interested in working on this project. I don't have any industry experience but i see this as a great opportunity to continue to work on game related stuff during my leave of absence from study.

the tools of my trade are 3Ds Max, and Photoshop.

So far for Team C, we have a interest from:

kthuynh86 - Project manager, game design
mulletdulla - Game designer
Roger - Programmer
Sugo - Programmer
CopyRay - 3D
ussmc2 - Character animation
MattD - 3D
Briefcase - 3D
HemantD - 3D
OverActive-Imagination - Sound design

..and myself for UI design, menus, presentation and that sorta stuff.

Judging by the response, it's probably best if we start off with a smaller game than I previously mentioned.

Currently, we're looking for programmers into the fray.

I posted before as a Game Designer

Ah, it seems that you did! I wasn't sure... Anyway, any programmers interested in taking part? btw, do you want to come up with some suggestion for a game? Perhaps a brief description for now, and if everyone is interested, a longer document later on?

I have a Computer Science degree and can write C/C++ and I would be willing to learn a little C# if necessary.


I have been trying to put together my own demo for a while now, playing with SDL, OpenGL and a bunch of other libraries. Recently I have started looking at some engines(Ogre3D, Crystalspace and Irrlicht) although I do not really have anything to show for it yet.


I am keen to be a part of this project. I just feel that I would need some help from someone more experienced in programming as I have never actually completed any of my own projects. Any more experienced programmers out there want to give me a hand?

I wouldn't mind signing up for this.

I'm an AIE prgramming graduate and I have worked at Transmission for a few months as an intern. I've also got a B. Comp Sci and have worked as a .Net programmer for a few years.

I also have some experience with OpenGL, Gamebryo, PhysX and FMOD.

How does this work anyway? Do we express interest and we just go straight on the list or do we need to somehow prove ourselves?

I'm also working with a few others on an independent project of our own which we are only at the planning stages of at the moment. Would it be possible, once we discuss it, to move that over to this initiative you reckon? (Though I'm thinking not since there is like 10 of us on it at the moment). I'm not exactly sure how this works so forgive me if it sounds stupid.

If you're sure you're capable for the job, then you're onboard. I'm sure most people are capable of doing something in their field, but we'll have to rely on people to nominate the tasks they're most comfortable with.

I'm not sure what you mean by moving those people over to this initiative? Did you mean once that project is done, to move them onto this one? Or to move that project over here (making it a Team D)?

I was thinking the Team D option, but it sounds like they aren't too keen on exposure for it at this time, they want to keep it under wraps, which is fair enough, so for the time being I don't think we'll be doing that. Would it be at all possible in the future though, hypothetically?

Also I'm still up for joining Team C as well, so far the Defcon based design ideas sound interesting.

Hey there DrSphere :)

I'll be showcasing a game design project in early April. And while it's not my intention to initially get a mod or prototype going it might be once the project gains momentum. It might interest none the less as far as upcoming Aussie indie projects are concerned.

Cheers!

I'm perfectly happy for you guys for a Team D. Hunt around to find the thread on the facilities and what the site can do for you. You're happy to choose to utilise what you want or don't want.

I would love to do a Defcon-like title. Do you think you can handle the programming side? Can you delegate tasks or split some jobs with Suggo?

Name: Khanh Huynh
Location: Melbourne
Focus: Game Designer
Skills: Organisation, QA (no experience but i have time to put in), very little programming and basic 3d modelling

Hoping to get more insight of a game being put together. Currently studying Game Design at QANTM and would like any experience that may enhance my studies or future career path.

I like the idea of a Defcon style game. (haven't actually played it but did some quick research on the web) I think we should be able to mix it up enough to make something new and fun, although all of Souri's suggestions may be a bit much. I am not sure what I'm getting myself into here, but I would like to see the continents extended onto separate planets so it became a space battle also.


The main thing that I probably suck at for this project would be AI. It's not something I have ever put much thought into and haven't coded anything in that area. If someone has experience in that area it could really help.

I posted before (Subject: Interested) and would like to animate for this project. I have no experience in the game industry - question: what format does the animation has to be? ie .mov, .avi etc.

It'll depend on the programmer and the type of game we're making, but most likely you'll have to pass on your source files.

I think a bigger project like this would need someone to organise and look over everything. You're most welcomed to take on that role, as well as help out with the game design.

It looks like we have enough people interested in the project to get something started, and we're looking into the idea of a Defcon sort of game (descriptions in this thread).

To move things forward now is for mulletdulla (the game designer) to write a brief game design document and outline their proposal for this game and to give the rest of the team a good idea of what the game enatils and requires.

Sorry about this guys but I just found out today that I've got full time employment. Because I have have the other indie project that I'll be working on as well I'm just not going to have time for this. Sorry if I let you guys down at all, but good luck with it anyway.

Hi, my name is Chris. I’m a graduate of QUT Brisbane.

I have a degree in I.T (Games Technology)..
My Programming Skills include C/C++, C#, .net, HLSL, DirectX, OpenGL.I have knowledge of the latest Shading techniques, and engine programming.
I also have good knowledge of 3d maths.

Mostly I’m looking to get good industry exposure. Please get back to me.

Hey there Chris. :)

I suggest that you make an account here at Sumea or at the last leave a contact e-mail or msn so people can respond in private.

Cheers!

Hi all again, this is Chris.

The lack of contact details was due in part to connection issues on my end. Probably also because it was very late at night.

Anyway my contact details are in my profile.

running AI for a strategy based game I imagine would be fairly difficult.

I have experience scripting AI together from a game design perspective but not on the actual programming. I can however lend tips to what I have found that works well in the past.

going back to Defcon. I quite like the idea as well of extending it onto separate planets - actually an interesting idea would be to convert it Earth vs Mars. Have Humanity on our end and Martians on the Mars end battling it out through the solar system?

Sounds good to me. If we can implement your AI ideas and algorithms we may be in business. This looks like it is going to be a fun project!

I think doing planets would be cool, I think we could have either more than 2 planets or perhaps a couple of nations per planet? that could be interesting.

Modeler with 3 years experience in TVC and Game Industry!

I'm a designer, have been modding games for 10 years.
I also have competed an advanced diploma in Game design (2 year course) and have 7 months experience in the Industry as a Jr. Designer.

Can you come up with a brief proposal for a small scaled game? Perhaps requiring three or so artists, one or two programmers, and yourself. I'm sure we can drum enough support to get something happening if people understand the kind of project that this team is veering in.

Hey, no experience as yet but can use maya and lightwave. Aswell as photoshop and illustrator.
I like to create weapons, vehicles and assets. Lmk.
Endarkened.deviantart.com

cheers.
Plusie

Premise

The player is in charge of (a character?) making hamburgers for a hamburger store.

High Concept

This is a columns-like puzzle game. Instead of matching groups of specific gems, the player stacks games in a specific order. The gems are based around the idea of the main character making hamburgers.

Gameplay

During game play, the player will move, rotate and drop groups of gems into the playing well. To clear gems out of the well and score points, the player has to stack the gems in various orders (bun – beef – bun, bun – beef – cheese – bun, bun – beef – cheese – tomato – lettuce – bun, etc). The more complex the stack, the higher the score, but there will also be a set limit of how high the stack can be.

There will be a story mode and a free play mode. The story mode will also act as a tutorial. Playing the story mode, the player will have to make a certain number of burgers each level. Each successive level will unlock another gem the player can use to make burger stacks. It will culminate in a level that has all the gems unlocked and never ends. This final level is also how the free play mode will work.

In total there will be six different gems; Bun(yellow), Beef(Brown), Cheese(orange), tomato(red), lettuce(green) and onion(white).

Concept Art

This game will be very “cute”, in an anime way.
http://www.mikoto.com.au/wp-content/uploads/2008/07/ricegirl300.png - The thick key line and solid colours
http://www.blog.spoongraphics.co.uk/wp-content/uploads/2008/08/55.jpg - Just the general loock (wide eyes, tongue hanging out) and this site had a tutorial for it (http://www.blog.spoongraphics.co.uk/tutorials/create-a-cute-vector-mons…).

Hardware Platform

I see this game being made in Flash. It has a fairly quick turn around time and can be played on many devices, giving it a very wide audience

This sounds like the perfect game for a small team to work on. I reckon this would be perfect as an iPhone game, but we'll see if anyone is interested in doing it for that.

If anyone would like to chime in, what do you think is the amount of people required for this project? Anyway I'll make a call for people once it's decided how many people are needed for this project.

We've got some 3D artists interested, but it seems this game calls for traditional 2D line art. Anyone into doing this kind of art?

Since what I can contribute is graphic design related, I'll be happy to nominate myself for the front end, menu, gui etc sort of work for this project..

An iPhone game might be interesting.

One thing I have to ask, is how are iPhone emulators? I know I don't own or have access to the actual hardware and I'm sure there would be others that don't either.



Having said that I feel that platform doesn't really matter too much and we should be open to changing the platform according to the coders' preference.



Also, if we do pick a platform that can do 3D, why not let it use 3D assets, but leave the gameplay tied to a normal 2D grid?



I don't have much experience in group sizes or project timelines, but I could see this project being done in 4-5 months with 2 coders, 3-4 artists and 1 audio person. From my point of view the game will be fairly easy to program, but there's the possibility of it needing a lot of art.

You know what im already in team A working with Bittmans team but i like the concept and look if you need an artist id be more than happy to contribute, as long as there isnt a rule against working in more than one team souri???

My skills are predominantly focused around character art, and i am stronger in 3D than 2D i have a journal post with some portfolio stuff in it if you're interested http://www.tsumea.com/journal/cad/290109/quick-portfolio-for-indie.

CAD

This is a *very small* scaled game which is the goal for team B, so I don't think it will take you too much away from Team A's development.

In fact, I think we have enough artists if you're interested, and we have a game designer (and one UI person) as well. We just need one programmer!

Yeh, it seems all the artists that have put their hand up here are 3D artists, so that might be the plan. It might be pre-rendered in 3D and handled in 2D if needed (see Torque 2D).

The idea to publish on the iPhone was to get some monetary returns on the game, but if anyone knows any other avenues for revenue, please do suggest it. I understand that it might not be a lot, but if it's worth doing, then it's worth getting some return.

The Unity 3D engine is coming out for the PC which can export to the iPhone, or we could use Torque 2D iPhone instead. The licenses are a bit expensive, so maybe a dual boot solution could suffice for the programmer. I guess we can leave that up to whoever volunteers to program this, but what do you guys think.

2D > 3D processing was something I thought about, but if we have 3D artists, why not use 3D assets?

I honestly never thought of any of this projects as any kind of money generating thing.

As far as other avenues of revenue, here's a few:

• *Flash game, with MochiAds
• *Flash game, on Kongregate
• *XNA game, on XBCC
• *PC game, sold through a store (attached to tsumea.com ?)

Or we could do all of them...
Create the game on one platform, then port it over to other platforms later.

I would be up for making a small and well polished game.

I mainly program in C++. I'm also competent in C, C# or Java, and I can always learn somthing new.

I've have a science degree with a computer science major and I'm now working in the IT industry.
I can contribute about 10 hours a week.

You're just what we needed to get this project going. What platform are you most happy to develop for? The brief game design docs are in this thread, so you could probably suss out what you need to do and what's required from the artists. You can talk to Charcoal if you need to clear anything up.

So far for this project, we have:

Charcoal - game designer
Squashed Bug - programmer
Cad - 3D artist, with specialty in 3d characters
Plusie - 3D artist, with specialty in vehicles and weapons (although we'll have to see if you're)
Raymondl - 3D artist
Me - Graphic Designer, happy to do menus, buttons, logo, UI etc

I was thinking, if Cad can do one simple cute 3D chef character as part of the presentation (for use in opening screen, menu etc) in a stylish vein, for example the characters in My Sims, that would be awesome (would be great to provide some brief animations too)

Plusie and Raymondl, perhaps one of you would do the burger assets (which shouldn't be too hard), and maybe both of you can come up with background designs for levels? They'd be simple colourful 3D designs of maybe the burger store, kitchen, or food etc, reated stuff like that. For style, I was thinking of the stuff like in My Sims as well.

Anyway, they're just some of my suggestions - they might not be what Charcoal intended. Charcoal, post about what those guys can do with the goals you had in mind.

I just checked out the My Sims stuff, it seems nice. If we use that as a base for our art style, I don't think we would be going too wrong.


The distribution of people that you have put down seems to be good.


Cad: If it's not too much, I think having (at least) two characters would be best, male and female.


Plusie and Raymondl: For backgrounds I'm thinking that some simple ones, based on locations (kitchen, burger store, American diner) would be good. For this project, I don't like the idea of a kind of abstract backgrounds.
I've laid out what colours I think the gems should be in the proposal. I need you guys to come up with very distinctive shapes for each of them. For puzzle games, the gems need to be distinctive in both colour and shape. Puzzle Quest's Gems are good in this area, both the borders of non-mana gems and the internals art of all of gems.


And I'll start writing up a full GDD over the weekend.

The first release of the game should definatley be on Windows, since it's easy to develop for and the most commonly used. I'm happy developing in C++. I generally build my games on top of SDL and OpenGL. These libraries are supported on Mac and Linux, so porting to these platforms shouldn't be too much trouble. Porting to a handheld device is going to require a fair bit of engine work though.

Just so you know I don't have too much 3D programming experience. I can load a textured, shaded 3D model/scene, however I haven't done anything with 3D animation or shaders. We probably wouldn't want to make thing too 3D intensive as this type of game is targeted at a casual gamer who wouldn't necassarily have a dedicated graphics card and a modern computer.

What I need from Charcoal is the core gameplay designed. Once thats done I should be able to get a playable prototype up in a couple weeks.

Any updates on the full GDD?

Unfortunately I had less time then I thought I would on the weekend, so I'm spending some time on it now.

Should be able to put a draft up tomorrow, before I have to head off for a few days...

BTW, how is Word 2007 format for everyone?
At least for the first few drafts it's good for me, but it might be nice to get a secure wiki once I/We have most of it figured out...

Hey Guys,

Just thought I would butt in here.

I'm part of the team over at Aberrant Entertainment (http://www.aberrant.com.au), we've been around for a few years and used to be known as Gridwerx. After Gridwerx disbanded we jumped into developing casual games. I just thought I'd give you some pointers on the industry.

Your idea has a very interesting and cool game play style. If you have the artwork to match, it will be a very cool game. However, casual gamers are evolving and aren't really looking just to kill time anymore. They do it for reward. For example, there has been a big push in games where you complete a level and get rewarded with a motivation that doesn't really affect gameplay. My suggestion here would be, you complete a section of levels (maybe 5) and get rewarded with a "franchise" in another city or something along those lines. These don't have to necessarily do something, but gives the player something to aim for. I would bring up a map, or even a world globe and allow the player to choose where they want to open their franchise, and as you progress through the game keep track of where the player has opened up, maybe even do something clever with your points, make it "x million served worldwide", instead of just ordinary points.

For distribution options, hit up every major portal when you finish the game. Build yourselves a promo website for the game, and just email them the link with a brief description. It is important that you saturate it across multiple distributors. This way you will get someone either that takes it, or gives you pointers on how to improve. And not to mention these guys can take their sweet time to do a reply. Don't go for the retail market either, it is too hard to get into with these sorts of games. Online distribution is god.

For game testing, advice and feedback. Utilise the internet, tSumea will be a great resource when you get to this stage, but there are plenty of other forums etc. where people will want to play new games. And use local resources, at Aberrant we are based out of Brisbane, so when we wanted to test our game we approached local unis / tafes who have game development courses, such as QUT & Qantm and asked if we could do gameplay test sessions and deliver a free lecture afterwards about our experience so far.

I hope that bit of advice helps as far as casual games are concerned.

I like the idea of franchises, might have to steal it :P

For this I haven't been thinking about any kind of progression/reward,but I'm about to put some kind of "achievements" into another game I'm working on, so I'm sure it would have come over eventually.

Also, the first draft of the design document is coming along, I should be able to post something up tomorrow sometime...

Absolutely awesome suggestions, man :)

Yep, the website thing is something I can handle for the team also.

I'm hoping to send your design draft off to someone like John Passfield or David Hewitt for some comments and suggestions, I hope you don't mind.

When you do it I'll be quietly shitting my pants, but having a professional or two look over it will be a good thing for all of us.

Yeh, the 3D stuff I would think would be pre-rendered stuff rather than realtime.

Anyway, did you look at the design doc? Got any questions for Charcoal? Can you come up with some specs and needs for the art team? What sort of screen size / resolution are we looking at for this game?

Having recently run out of money to continue my study of games and interactivity at swinburn i was wondering if there was any need for another 3D artist/animator on this project. Im finding i have a lot of time on my hands at the moment and Im pretty anxious to fill it with something constructive.

We already have 3 artists on board with their duties assigned to them. I know CAD and Raymondl are already working on stuff, and we haven't heard from Plusie for a while now. If he drops out, you're more than free to take his spot.

Otherwise, post your interest in Team C, and hopefully we can get a project happening there real soon.

ah, coolio thanks for the info and keep me posted. I'll also hit the C team forum and post my interest there.

If it's not I'd be interested in working on it... but it looks dead.

I'm a concept artist/designer who can use maya to a degree... I'm also a multimedia graduate who until a couple of weeks ago worked at a burger shop haha.

Well, hit me up if it's alive and kicking and you want a hand. I'm really keen.

Is this still active? and if yes I would also be available for helping on the 3d side.
I have around 10 years professional experience in especially low poly modeling texturing of characters vehicles and props.

Still trying to drum up some interest for this team.. we particularly need programmers who want to delve into Unity 3D

Interested Interested in in Helping!

Name: Chemère
Focus: 3D artist
Skills: 3D Modeling and Animation, Also interested in Concept Art and Background Painting.

Name: Josh Harvey
Location: Geelong, Victoria
Focus: Game Designer/Manager and Advertisement
Skills: QA (I have time to play games), basic 3d modeling, learning programming, have a list of games ready for development?

Other: Website space (if needed)

I would be interested in doing this.. Would get me some experience, well.. more notable experience anyway.

It used to be mods where groups could work together in their spare time, but the effort and scale of a mod project is just too much these days. The casual space is really exciting at the moment, particularly with the stuff that's happening on the iphone, and it's much, much, much more realistic for a small group to get something completed and on the market.

Anyway, it sounds like a great plan, and if you need some more exposure or make a call for more interested parties, I'd be happy to post about it on the front page. Also, if you like, you can also create a group (private or public) in our groups section so that members can talk about the project.

Oh look, we have groups.

Cheers Souri, I only ever use the forums here but I really should be using the other things.

And yeah, lots more market for casual games nowdays not just on the iPhone. I'll see how much interest comes along, but I'll keep your offers in mind.

Name: Curtis Davidson
Location: Canberra, ACT
Focus: 3D artist
Skills: 3D modelling, character art, decent animator

Sounds like a good idea im still looking for a job in industry at the moment and reckon this would be a motivation boost for me. ill be posting some of my work in a journal soon so you can see what i can do.

Excellent, but it's not an interview so there's no portfolio thing to do to get in. Basically it will be a group of everyone who puts their name down, even if it means we have 5 game designers, 2 artists and no programmers all of different abilities.

I guess this is a pretty useful idea for people who may feel a bit segregated from companies such as yourself in canberra.

Name: Troy Boundy
Location: Canberra, ACT
Focus: IT Project Management/Quality Assurance/Design
Skills: Worked for the Government for the past 7 years in the above fields. Skills range from Q/A testing, spec design/publication, through to Project management.

Name: Brad Thomson
Location: Melb
Focus: modeling
Skills: 3D modeling.... lots of other things that dont really apply to a small indie

Yeah id be keen for this

Name: Jay Taylor
Location: Sydney, NSW
Focus: Sound design
Skills: Original music composition, sound effects, audio editting.

Hey. I am currently working full time in the business sector. My passion has always been music and sound but I didn't know what to do with it, I only got into sound design lately & have landed my first paid gig doing sound for a project to be released via XBox 360 Live Arcade. Everything is moving along nicely As such I am quite busy but I am prepared to put work into this as sound designer - I would love to do something as a indie team locally - the team I am working for currently is based in California. I play guitar in a band & view this akin to forming a band! Should be fun.

I also agree with the idea of doing a small project.

You have any game ideas Andrew?

I kid. Of course I do, but until I know what sort of team we're working with, where the skills lay, what other concepts other designers have, target hardware, etc, nothing concrete. Don't know how small we'll make the project, depends on the team size so it may even be something we can take somewhere interesting.

Also, great that you're a sound designer. Was just thinking how good it would be to have one, and voila!

And now, just like the real industry, we appear to be short on programmers =P

7 years of work experience probably already outweighs us. Also, just prefer if you also had a Sumea registered name we can work by. I'll probably have a group here and you'd need to be a member to join. Reply to this when you get one.

In the words of....well myself really..."There is nothing irrelevant to game design."

Of course, I'll get a better list of skills when we get cracking. Would be a shame to go through a project without knowing we had expert pianists (or something) and letting it go to waste.

Also wondering (will depend on team size though), whether we should actually try 3d the game. It's more work, but it would be much appreciated practice for all I think.

Sounds good Andrew. Fyi strengths for music is electronica, ambient & rock

I know a few programmers, might be too busy but i'll ask around.

Yea good ol' ACT is tooootaly the gaming hub of Australia :( if only txt could express sarcasm :)

and dont get me wrong i understand that its not an interview sort of thing, i just meant that if you are able to see peoples work (maybe not now but later on) its easier to utilize their skills more effectively.

sorry mate thought i was signed in when i posted my details.

Sumea user name is Boundos for adding to groups ect

No, nothing dramatic.

Just letting you know that I'll just leave this here for another week before we get cracking. Tell your friends, I should tell mine too actually (yes, I have friends). Long weekend + another week of work should make sure anyone who visits here even occasionally might stumble across it.

Also wanted to leave a note: If you're worried that you won't have the time to contribute to the project at the same level as others, do not fear. I expect most people here to be preoccupied with work, games, personal portfolios and chatting up ladies to have daily contributions. If you looked at this and thought it was good, but were worried that you might only be able to help out once a week or something, fear not and put your name down. I almost expected there would work out to be a core team and "other people who watch our progress and help a little" team.

Also I would encourage anyone who has put their names down to look over some indie games which are floating about at the moment. The Escapist has a good demo of indie games with a rundown and some interesting things, but look around the internet and try get an appreciation of what exists and the scale at which we will aim. Now, I should follow my own advice and play some myself.

Name: Lindsay Jarvis
Location: Gippsland Vic
Focus: modeling, animating
Skills: Proficient in most aspects of 3D creation in Max or Maya,
Model, unwrap, texture, rig and animate.

Sounds like a plan... well almost.

I just made the group, gonna Invite everyone that's put their names down now. It's joinable, so if anyone sees this after we start, feel free to join up (even if you're only going to watch our progress).

I'll start making most comments and things in the group forum section now, but I guess I'll update this again by the weekend just in case someone missed it.

We won't be really starting anything (i.e. organisation first) until this weekend anyway.

pssst.... I just finished uploading the PopCap keynote session from Game Connect 2008.

http://au.youtube.com/user/tsumea

Check it out. They show and describe how they prototype and muck around with ideas. It might be some inspiration for the team.

hey hey linds, nice to see you here =)

Brad btw

god dam it must hit the wrong reply button =(

Well I guess I'm currently new to this indie/mod game thing. Here are just a few basic questions:
Did you have a preferable deadline (for the completed game)?
How did you want content shared?
How will project management work on a "whenever you can" basis?

Those are the main question I have at the moment. Apart from that I guess I'm slightly interested. I'd prefer it if we could get organised meetings in person.

Name: Argirios Mavroudis (Just call me Arg)
Location: Melbourne (Western Suburbs)
Focus: Gameplay Designer, Programmer (C# or Actionscript)
Skills: Programming, General 3d and other things.

I studied Flash for a while as part of my Cert 3 multimedia in to my advanced diploma info tech (multimedia). Currently studying game development and am in my 2nd year. The course uses mostly C# engines. Considering that you aren't planing of "over the moon" stuff. you might not need a C++ programmer. I am studying C++ on my own however not sure I'd appreciate doing all of the programming in C++ , alone.

Quick note: I'd say that I am mostly focusing on XNA at the moment. This would mean that if the game is a 2d game then it will help me out a lot, or else you may need to learn "XSI mod tool" for 3d models (at least by the animators).

For those that don't know - XNA is a C# engine that Microsoft releast for the PC and Xbox360. The PC version will cost nothing however the Xbox version will require $100 to publish the games. XNA can also support multiplayer functions.

Meeting in person would be quite hard for some people and quite costly. It would also cause arguments between where we are going to meet each week and who can host the event.

This is partly why I asked the other questions. Don't know if the forums covered development annoyances. Stuff like Content not uploaded in time, (important) people randomly unable to be contacted, and the like.

Also do you have a central server that can maintain version control?

From my own viewpoint of course, since I'm organising this:
- Deadline: Impossible to say given that the team isn't finalised, we have no written goal and I don't now our skills. I would love to say before the end of the year, but who knows.
- Shared content: Though discussions, meetings, etc will be held over sumea and some sort of chat medium, I do expect we'll need some space to upload content for others to see. It's something else I should ask opinions on, though I do remember a good upload management site (I'll go look for it again)
- Project management with this approach will rely on two things. Firstly, a relaxed attitude and secondly version control. You'd be surprised how far both of these things can take you when the team works somewhat independently.
- Meeting in Person: As said, too costly and unreasonable given the goal is to make a group of people from various areas in Australia. That said, if you're in my hood drop me a line.

Thanks for putting your name down, good to see you have some programming experience. You're automatically the most senior programmer here, haha.

Because I have answers below, but:

My philosophy for those who don't meet deadlines is not to fire them, because really we need all the help we can get and I'm doing this for everyone to have a chance. However, not meeting deadlines is recorded and the less trustworthy and efficient someone is the less work I would assign to them even if their skill level was above others. Remember, this is a project which will be extremely beneficial to getting a job in the industry, so if you want some poor impressions of your work floating around you'll have no-one to blame but yourself.

Of course, this same philosophy applies to me. Call me out on it if you feel I'm slack.

Hey guys,

My details are:
Name: Craig Peebles
Location: Melbourne
Skills: Modeling (Max), Programming (C++)

I'm definitely interested, however I'm not sure which area I'd be best to work in - 3D modeling or Programming. I got interested in game development rather late, after already having completed an engineering degree and currently work in CAD, so i'm doing online study in my spare hours in 3D modeling. If you need any help with modeling, probly best would be for me to start on static assets, as I have very little experience so far in rigging, animation, etc.

Programming is a more recent interest for me, and has actually ended up taking a fair amount of time away from my 3D studies, so i'd be eager to help you out with that. Most of my early experience is in various engineering and maths packages (MATLAB, Maple, etc.), but I also have experience in Delphi, Fortran, parallel coding, and more recently some experience in C#. I've recently taken all that as a basis to teach myself C++ (and the engineering mindset definitely helps with that), though I'm tempted to get into an online course in that as well just so I have something formal-looking to back it up.

As you have less programmers than modelers and designers based on previous posts, I'm happy to put my hand up to help with that. A project like this would be great as inspiration to get me learning new things and actually have something to apply them to, however I would have to take it in baby steps to begin with.

Cheers all,
Craig.

You and another programmer just joined. The tears of joy won't stop flowing!

Also, in other news suddenly our team is quite large. I'll keep accepting everyone and anyone, but if I get too many people I might split resources over two games. "If" is a big word though, in the right context. It heavily relies on all members being quite active, so we'll see how that goes.

Guess it'll then come down to the old quality versus quantity debate.

I am in... if I might join

Example:
Name: Marcin Kurczewski
Location: Poland
Focus: Game Art
Skills: Primarily modeling/texturing, some experience in game design and level design.

To have an Australian based group. That said, I guess I should just leave it open to the world, no sense in limiting the team by geographical area. I mean, we're already only meeting online, distance became obsolete the moment that was decided.

You'll just have to remember though, this will be targeted somewhat for Australian release, but aside from having the chance to meet the rest of the team in person living in poland should hold no other limits.

So: come ye scurvy internationals if ye dare (turns off worst pirate accent ever)

Hi guys, I'd like to help out where I can...

Name: Jarrod Penfold
Location: Sydney
Focus: Creative writing
Skills: Fictional writing, specialising in copywriting and scriptwriting for film/tv (15 sec TVCs through to features) - writing narration, dialogue, scenes, backgrounds, etc. Also do PR writing and pressers.

Cheers,
Jarrod

A man goes to knowledge as he goes to war, wide awake, with fear, with respect, and with absolute assurance. - The Teachings of Don Juan

The group is that way *points to group section*

Invite yourself, I accept and then you can introduce yourself to the team a bit more formally in there.

fantastic piece and you did it with a day to spare, congratz. Killa Dee2007-07-30 15:40:22

superb! I love it!

I really love it from the shoulders down! So few marks but so descriptive. Glad you could squeeze in a quick post for the topic.

one mean looking cyborg. I missed the boat all together! next month tho. nice work

Nice work man... the pose is strong and looks as if she can do some damage!

My only crit would be that the strong armbands around her bicep make the form look flat, otherwise great stuff

As IronhideNT commented, the upper arm does look sorta flat. But she looks really good all up.