# Newbie - How to start?

## Recommended Posts

Good day dear people

I'm completely new here and very nervous to be honest. I started with 3D-Design at my traineeship and can slowly start with my ideas for a survival/rpg game in 3d But since I only used RPG Makers until now I wonder how is the best way to start with a game, and what I would need for that.

Have a wonderful day! ^.^)/)

Tootooni

## Create an account

Register a new account

• 10
• 9
• 14
• 16
• 10
• ### Similar Content

• By Angelord
As a member of an indie team I'm interested in knowledge on how to organize the team and improve work efficiency. Can you guys recommend any good learning sources (books/articles/lectures)? Ones covering how to distribute tasks, group the development team into smaller working units and gather data to improve the performance of individuals.

• Solved: didn't think clearly and realized I can't just compare the cross-product with 0,0,0.
Fixed by doing this:
float3 originVector = float3(0.0, 0.0, 0.0) - v1.xyz; if (dot(cross(e1, e2).xyz, originVector) > 0.0) { //... } I'm trying to write a geometry shader that does backface culling. (Dont ask me why)
What I'm doing is checking the cross-product of two edges of the triangle (in NDC space) and checking if it's facing 0,0,0 .
The problem is when I compile I get this error:
this is i guess because if it isn't facing us, I dont append any verts to the stream. I always assumed maxvertexcount implied I can emit as few verts as I like, but I suppose not.
How do I get around this?

struct GS_IN_OUT { float4 Pos : SV_POSITION; float4 PosW : POSITION; float4 NorW : NORMAL; float2 UV : TEXCOORD; }; [maxvertexcount(3)] void GS_main( triangle GS_IN_OUT input[3], inout TriangleStream< GS_IN_OUT > output ) { //Check for backface float4 v1, v2, v3; v1 = input[0].Pos; v2 = input[1].Pos; v3 = input[2].Pos; float4 e1, e2; e1 = v1 - v2; e2 = v1 - v3; if (dot(cross(e1, e2).xyz, float3(0.0, 0.0, 0.0)) > 0.0) { //face is facing us, let triangle through for (uint i = 0; i < 3; i++) { GS_IN_OUT element; element = input[i]; output.Append(element); } } }
• By Viir
This screenshot shows a game with the new bot and map.
Screenshot from the DRTS Devlog at

• Hello all,
I have been working on a game and brought a few others in on it to develop it and make content. The team is currently unpaid (will be compensated after release/funding)
In this setting, what do you think are some good practices to follow to make the project a success and a good development environment?
The project is still early in development and I would consider this to be my first leading role in something like this
As I am pretty directly involved in the development of things, from story to design to actual coding, I have tried to steer clear of 'managing', or over-managing as its a small team and nobody is seeing the \$ to put up with much BS.
I think I have mostly done this with some success, but it has made it difficult for me at times. I have tried taking less of the front seat and letting everyone pedal as well, but I found that people didn't really have much drive to contribute anything unless it was adding to something that I created or was already there.
So far I have created a wiki, a forum, a Google drive, and set up some other tools for the team, as well as a Facebook page and have managed the security of our information (like making everything non-public)
Legal stuff - NDA/other agreements:
When is the best time to do the formalities and write up things like NDA's and other agreements to protect the project? Gauging my team as it is, I think they would not be keen on signing things like this - it seems to be a big turn-off when I start talking about rules and organization.  I can understand the reticence as it is unpaid, but it also seems very risky in thinking of the future. I have already had a developer leave the project, and I have yet to see if problems are going to arise from this.
I know these types of things are very standard for larger projects with funding, but it seems difficult to implement in this setting. I have read many stories of failed games due to petty internal conflicts, developers retracting their contributions, misappropriated funding, and dissatisfied developers that probably could have been prevented if everyone had some type of written, formal agreement adhering to some rules of conduct.
I dont see agreements and NDA's as an attempt to disadvantage people or deprive them of freedom, but as something to protect the project as a whole - which is bigger than any one person and affects everyone.
Is it a good idea to put write something up and get some signatures? If so, when is a good time and what would be the best approach (as far as selling it to the team)? Should any agreement be very light and plain, or well written and very detailed?

• Hello all,
I recently had started making a game and invited some others to join the team as well to create content and write some of the story. The group is small, and there is no funding currently.
The problem I am having is that I have a vision in mind for the game, but have some difficulty getting others to follow it - it follows certain themes and there are certain things about the world that cannot be changed without it being out of place or disrupting the 'feel' of the game.
I have so far been running things fairly casually as it is still a small unpaid team, but there are some things I feel that can't be compromised on. Don't get me wrong, I don't want to stifle my developers' creativity and I welcome new ideas/changes (we have had several good brainstorms in the past) but I think there needs to be a line somewhere so the game stays close to this vision.
In this example, the game is going to be dark fantasy, and have a rather serious environment,  but I have a developer who wanted to add silly easter eggs in as 'comic relief'. When I asked for an example or something similar, he talked about how Saint's Row has some sort of dildo bat that you can use as a weapon in-game. This is very much something I did not want in the game and I had to draw a very firm line there, telling him we are not going to have anything like that (for the reasons above). He said something along the lines of "Well, I am going to put whatever I want in my level". Following that, I had a conversation with him where I told him that while he is in charge of that level, if it is out of place from the theme/doesnt fit in to the 'feel' of the game, that I won't allow it in the game.
The developer then told me I am taking things too seriously, I am thinking too far ahead, and it is not fun to develop the game anymore - he decided to leave the project.  I definitely do like to have fun working on this game, and value the input of all my team, but I think there are times when I need to 'get serious'
I am very compromising with a lot of the story and design aspects, as the team is small and unpaid, but do not want to see this game run wild and turned into a joke. I am close to the design and story myself, and consider myself to fulfill the roles of a creative director and project manager - along with a bit of everything else. In the past, when the game was basically a blank slate, I tried to gather people around to come up with new ideas, but there was little contribution and I am seeing much more involvement after I went ahead and created a foundation of the story myself. I do my best to avoid coming off as 'managing' but it has been unavoidable in cases like this.

If you have read thus far, thanks for staying with me!
My question for you all - What is your opinion on this, what are some suggestions you have to avoid this in the future? I have some people with great Ideas and conflict is inevitable.
Do I need to be more picky with/vet developers better? Is there something dysfunctional in how I am approaching the matter? How do you work with your content authors/designers/developers to resolve creative conflict, and where do you draw the line?

Note: Usually I let a lot of stuff go that doesn't completely 'fit the vision', and adapt to it, in order to keep morale up and not stifle others' creativity, but knowing the guy personally, I suspect he had wanted to have a lot more control over the project and I had a feeling that something like this would develop down the road which is why I wanted to nip the problem early on.