Jump to content

  • Log In with Google      Sign In   
  • Create Account

slayemin

Member Since 23 Feb 2001
Offline Last Active Today, 05:17 PM

#4993738 How/Who create the GameObjects?

Posted by slayemin on 25 October 2012 - 04:33 AM

Back on topic....

To OP: I follow a similar pattern. I consider myself somewhat of a novice at designing game architectures, so take what I say with a grain of salt:
I have a base class which every game object inherits from (already may be a bad idea). The class is abstract and pretty much worries about assigning an incrementing ID, possibly accepting a given name, maintaining a queue of messages, and enforcing the implementation of update and init functions for classes which inherit from it, and acting as a generic object which can be used by containers (pretty much polymorphism). That's it. Any inheriting classes will extend this base class.

Here is the C# code for my base class:
public abstract class GBO
{
	 UInt64 m_ID;
	 static UInt64 m_nextID = 0;
	 protected string m_name;
	 public Queue<GameMessage> Messages = new Queue<GameMessage>(10);
	 
	 public GBO()
	 {
		  m_ID = m_nextID++;
	 }

	 public GBO(string Name)
	 {
		  m_ID = m_nextID++;
		  m_name = Name;
	 }
	 public UInt64 ID
	 {
		  get { return m_ID;}
	 }
	 public string Name
	 {
		  get { return m_name;}
		  set { m_name = value;}
	 }
	 public abstract void Update();
	 public abstract void Start();		  //I use "Start" instead of "Init" for Unity3D
}

Looking at my base object and thinking about it, it does have some weaknesses:
If I decide to create particle engine and each particle is a GBO class, do I really care about the name of a particle or any game messages it may have generated? Not really. I could slice those two variables out. The ID is mostly used as a key for dictionaries and hash tables, but would a particle ever be stored in a hash table or dictionary? Not really. So, if I slice that out too, then my base class would just have an abstract "Start()" and "Update()" method. Do I even need those? I already know that all of my game objects have to implement initialization and update functions, so enforcing it is a bit of a moot point and possibly restrictive since they don't have input parameters. I might as well have a completely blank base class to support the most flexibility... but why even have an empty class if it doesn't do anything? Do I even NEED a base class?
"Oh, what about using the base class as a generic container object? That way, you can have a single list of all your objects in the game and call their update() method!"
Well, every inheriting class would have a corresponding manager class. The manager class itself can have update called on it and we'll let the manager worry about updating its objects.
Instead of:
foreach(GBO obj in m_allObjects)
	 obj.update();

we can do this:
MageMgr.Update();
MonsterMgr.Update();
PlayerMgr.Update();
BulletsMgr.Update();

Is this "better"? One immediate disadvantage is that we explicitly have to create and call the update functions for every list of items we have in the game. This adds extra programmer overhead. But, is there an advantage to asking the manager to update its contained items? I think so. The manager can worry about the game logic in regards to the object. So, for example, your mage manager would not only call update() on all of the mages in its list, it would also manage the list of mages by removing any mages which are dead (hitpoints >= 0) or perform any other trivial object specific management.
If you really like the super simple single update, you can let your manager classes derive from an abstract manager class which has an update function. Then, you'd have a list of managers, for which you update every frame:
foreach(GameObjMgr mgr in m_managers)
	 mgr.update();
Then, you just have to worry about instantiating a manager class and inserting it into the manager list.

Anyways, I really don't know much about "good" software engineering and game architecture. I may be oversimplifying the core of game development: Managing lists of "stuff" and applying rules to them.


#4992692 2D tile based collision

Posted by slayemin on 22 October 2012 - 12:51 AM

I think I understand what you're asking.
The advantage of using a Rect is that it saves you CPU cycles and it simplifies your code. If you're not using a quad tree and just going with a dirty O(n^2) collision check, your going to have to spend extra cpu cycles calculating the bounding areas of each rectangle. You're right about the rect consuming more ram though.
Idea #1:
You could create your own rect class. Have two versions:
Version 1: It's just a wrapper for the build in Rect. If this becomes too ram heavy, switch to version 2:
Version 2: Assuming your rects are all squares of a fixed dimension, all it stores is the center X/Y coordinate. But, it has the same methods as the built in rect.

Idea #2: Collision detection with really fast objects.
The general idea is to draw a line from your moving objects current position to the next position its going to occupy. Then, do a line intersection test with all collidable objects. If there isn't anything colliding with the line, it's safe to move the object to the next position. If there is a collision, then you know the position on the line you're colliding at and you set your objects position to that point on the line. If your moving object is thicker than a pixel, then you have to find the edges and draw two lines to represent the thickness. Example: If your object is 5px wide and is falling straight down, then your first line starts at x, second at x + 5, and the end points are the velocity position with the same X offsets.


#4992465 2D tile based collision

Posted by slayemin on 21 October 2012 - 09:48 AM

Ooh... I think you might be over thinking this a bit. C# comes with a Rectangle class, which comes with a built-in collision check method called Contains. If you use that, you can probably reduce your 54 lines of complicated looking code into about 5 lines of code. Ideally, this is what your code should look like in your update method:

pseudo code:
public void Update(GameTime gameTime)
{

position += velocity * gameTime.elapsedMS;

foreach(GameObject obj in AllMyCollidableGameObjectsList)
{
	 if(obj.rect.Contains(this.rect))
    {
		  this.HandleCollision();		  //varies by what your colliding with (bullets, terrain, items, etc)
    }
}
}

The collision detection is overly simplistic here just for illustratation purposes. In your code, you'd want to handle the extra stuff, like object elasticity, overlap of bounding areas, pushback, changes in velocity, etc.


#4992457 How much CPU usage should just an empty game loop have

Posted by slayemin on 21 October 2012 - 09:28 AM

Okay. I used an event and WaitForSingleObject to wait for a maximum of 100 ms when the game doesn't have focus. Now when the game doesn't have focus it uses up almost no CPU time at all. When nothing is running except windows I have 10-20% CPU usage. The game loop doing nothing at all (I event commented out every single call to update a subsystem) shows 50-60% CPU usage. So my game loop accounts for about 40-50%. What's weird though is that when the game is running logic it stays at just about exactly 50%. Why would this be? I'm doing some more work, but my CPU usage doesn't end up fluctuating as high. Could it just be a fluke and the OS is doing stuff behind the scenes? Or could it be because I send tasks off to other cores with a thread pool?


What you've got is something similar to a "spin loop", which is commonly used in multithreading spin and wait until a resource becomes available again. Except, it's really just an infinite loop. It'll run as fast as it can, provided the operating system gives it all the CPU resources it can.

I'm guessing that your computer has a processor with two cores. The spin loop is running in a thread on one of those cores and maxing it out at 100%, and because you've got two cores, one of which is 100% and the other at 0%, the average CPU usage is almost exactly 50% (with noise from other processes/threads causing fluxuations). If you're using task manager to measure CPU usage, you can view each core independently: View -> CPU History -> One Graph per CPU

You'll want your game loop to return the CPU to the OS until a desired time span has elapsed (which I mentioned above). You can use the Sleep function and probably get away with it without having any issues.


#4992141 How much CPU usage should just an empty game loop have

Posted by slayemin on 20 October 2012 - 07:33 AM

Your CPU usage should be around 0-1%.

Don't use sleep calls. Instead, calculate how much time has elapsed and update when you've passed that time span.
If you want to update 60 times a second, then there are 1000ms in a second. So, the time span to process a frame should be 1000/60 = 16.66666666666667 ms
When your game loop starts, record the time. Your loop processing will complete long before 16.66ms has elapsed, but as you add more logic, the time it takes will increase. So, you want to make sure that before starting the next frame, the current time >= last frame time + 16.6666ms
this would lock your FPS at a max of 60. But, when you're moving stuff around in your game, don't move it a fixed amount each frame. Move it based on how much time has elapsed between frames. That way, if your actual frame rate increases or decreases, your game state model is still running according to real time.

If you process your next frame when a set time span has elapsed, you should get about 0-1% cpu usage since it takes next to no time to process your update loop.


#4989404 "Getters" and "Setters" - do you write them if you don't...

Posted by slayemin on 12 October 2012 - 03:25 AM

Can I hijack this thread a little?

Now, in uni we're being taught OOP, using Java. One thing that I didn't quite understand (and if I did, then I disagree) is making (protected) setters of the (private) attributes of a class for using them in the constructor of the same class.

What's going on there? Encapsulating the class from itself?

IMO looks useless and inefficient. The first thing that comes to mind when I think "What could have free access to this class's properties?" is the constructor. Why should need to use methods to access the class's attributes its trying to construct? It's one of those "It's in the paradigm!" things? Moreover, the classes that inherit from such class will also carry the "burden" of accessing itself through methods instead of simple direct attribute access.

I'd just use the getters and setters if I need to access the class's attributes from outside the class. It doesn't makes any sense to me to encapsulate the class from itself on constructors nor methods (except some "high risk" public method that could screw up the object that is, but probably that one should be implemented as a separate class anyway).


Let's review access levels:
Public: Everything can access this member function or member variable
Private: The member function/variable is only internally visible to the class
Protected: Publicly accessible by classes which inherit from this class, hidden from all other classes.

So, if you make the internal variables private and the accessors are protected, you're creating a layer of insulation between the internals of your class and any classes which want to inherit from it. This is handy for doing error checking to make sure that class data conforms to the class logic.

To OP:
Personally, I like accessor functions. I like to make a distinction between properties and methods in C#
//These should NOT be "methods" because it's not really doing anything complicated to the data. It's just exposing the data to public use.
public int GetX()
{
	 return m_x;
}
public void SetX(int value)
{
	 //arbitrary rule being enforced
	 if(value >= 0)
	 {
		  m_x = value;
	 }
	 else
	 {
		  throw new exception("X shouldn't be negative!");
	 }
}

//instead, I like accessors which make it clear that you're accessing and using a property
public int X
{
	 get{return m_x;}
	 set
	 {
		  if(value >= 0)
			   m_x = value;
		  else
			   throw new exception("blah blah");
	 }
}

Functionally, Get/Set methods are the same as accessors and can do some light error checking. But, I like to think of "functions" more as a set of instructions used to do operations on data. These sets of instructions are like a true, mathematical function and thus deserve the term "function" unlike simple get/set methods.
Example:
public int Mandelbrot(float px, float py)
{
	 float x = 0;
	 float y = 0;
	 int iterations = 0;
	 const int max_iterations = 100;

	 while((x * x + y * y < 4) && iterations < max_iterations)
	 {
		  float tempx = x*x - y*y + px;
		  y = 2*x*y + py;
		  x = xtemp;
		  iterations++;
	 }
	 return iterations;
}

The following advice may be frowned on or considered "bad", but its pragamatic:
If you're the only person working on a program, you can probably just let all of your class properties be public since you're the only one who will be using them. Nobody else is going to interfere with internal class data. I assume that you know what you're doing and how the class works internally when you're accessing variables which would otherwise be private. In general, the principle of "information hiding" is encapsulation in order to create a contract between the class creator and the class users. Since you're both creator and user, you probably don't need a contract with yourself (but you could treat your future self as a class user since you could forget implementation specifics).
If you're going to share your code, work with other people, or use it as a library, THEN it's a good idea to hide stuff you don't want people to access (to prevent other people from breaking your class). Generally, it's just a good habit to encapuslate data and expose it through methods and accessors (and to enforce validation on data that needs to be validated), but it can also be a waste of time if you're going solo. Use your best judgement.
Personally, I practice encapsulation and information hiding even on small personal projects. It's just a habit of discipline and helps manage where & how my classes are being accessed.


#4988543 3rd party software for game dev

Posted by slayemin on 09 October 2012 - 06:17 PM

My background is in C++ and C# with DirectX and XNA. I've spent quite a bit of time writing boiler plate game engine code (like particle systems, input systems, physics and collision detection, etc). I'm reasonably comfortable with my coding skills, so I can somewhat trust my abilities. But, I'm slowly coming around to the realization that all of this is a general waste of time because there are existing game engines which do everything I'm trying to do, and do it much better and have been built and thoroughly tested by teams larger than one person (me). So, I could waste lots of time building a game engine or I could spend lots of time building a game. I prefer the latter :)

With consideration for platform support, my coding background, learning curve ramps, and customer support, I'm looking for software and solutions to help speed up my dev time.

Game Engine: Unity3D
Trees and Foliage: SpeedTree 6 (I started wasting time trying to create fractal trees, then found this today and abandoned my project)
3D Modelling: I personally like Wings3D because the learning curve ramp is short. Blender would take me a month to master.

I'm currently working on an indie game during my free time (learning tech and prototyping phase) and will ramp up into full time when I'm out of contract work. When I start my project in earnest, I'm planning to hire the most talented graphical artist I can find and will pay them well, so I'm inclined to let their skill set dictate what graphics software we'll use.

So far, I love Unity3D and SpeedTree looks like it's exactly what I need for generating good foliage assets. So, my question is this: What other 3rd party tools and solutions are available which would save me money (time is money)? What tools and services are you using on your team to build games faster and better?


#4986455 Game creation software

Posted by slayemin on 03 October 2012 - 11:15 AM

Why java? Java is an interpreter that is bad because instead of directly being able to directly run your program it has to first in real time convert your code into machine code then run it that means slow down. Also java has no support for unsigned numbers this is bad. I can not go with out unsigned number. I needed them my programs would use a lot more ram if I could only used signed numbers. I would recommend C I write and C and my programs are fast.


Mine craft is writen in Java and it doesn't have these "performance" issues you're alluding to...and its a significantly large game.

The difference between signed and unsigned numbers is whether or not the last bit is used to represent a sign bit or a number value.
unsigned int range: 0 -> 4294967296
signed int range: -2147483648 -> 2147483648 (Note: 2147483648 - -2147483648 = 4294967296)
So, a signed int or unsigned int uses the same amount of memory: 32 bits!!! Using unsigned ints doesn't use less memory, it just changes the range of min and max values.

Java is actually a good language to use because it's trivial to port to other platforms and it has some of the most robust networking capabilities. If you're good with it and comfortable with it, it's a very good language to know! If you're concerned with performance problems, the first thing you should do is look at your algorithm design rather than blaming it on the JVM. Example: bubble sorting 1000 items will be slow whether you use C/C++ or Java because its a O(n^2) algorithm and not O(log n) like quick sort.


#4986378 Seniority, and how to get there

Posted by slayemin on 03 October 2012 - 07:42 AM


-It could just be a presentation problem/language problem which would make it a hard sell. Rather than calling it "where I've failed this week" (which sounds negative), call it "Valuable lessons learned" and put the dissemination into a format which allows it to be shared with other team members (informal, short meeting? A newsletter? email distro?)


I can see this being interpreted as 'childish' for some of our developers. We don't just have juniors, there are a few seniors too, and how exactly do you draw the line? It would be judgmental to bring in people under 3 years and keep everyone else out because, there is just no radical line here that can be traced without hurting people's feelings I feel, and yet, some people will just get offended to be or not be a junior/senior.
I really like the idea of hosting some kind of a discussion about something that has been learned this week, but it feels either like kindergarden or a therapy group, and I'm looking for a more organic way to integrate this.
I've actually managed to raise quite the bar on post-mortems, but these occur only after a final delivery. I know some do end of sprint post-mortems, but I'm affraid I don't have all that much latitude with how much time I can consume with something like that (it is a hard sale for upper management).

The branches of the US military do "Lessons Learned" (Marines and Army). It's a way to learn from mistakes and pass the knowledge on to new people/units (usually battle field replacements). In practice, I haven't heard anyone think that it's childish. The main problem is that we can't disseminate and incorporate enough of the lessons learned throughout every unit. Sometimes.... these lessons costed lives to learn, loads of money, or tons of effort (which equals tax payer money). It's pretty humbling, actually.
In the case of your company, I'd just get the team together and tell them your intent to pass on knowledge and you're going to leave it up to them to figure out which format works best for them. Would they like bi-weekly meetings? a quick team huddle? a mentorship program (which could lend itself well to cross pollination to develop new talents)? Try out a few iterations, and then evaluate the usefulness and effectiveness, and then either tweak the format or discard it all together.

I had the misconception that you were running a company and had all the influence/power you needed to make cultural changes. Sorry about that! I don't know the situation you're in, so I can't make exact recommendations on what would be the best approach. Generally though, you just need to persuade the buyer that the value of XYZ is greater than the cost and that they'd benefit from having XYZ. You're going to need the support and backing from the upper echelons of management and grass roots support from the people you're managing. But, the critical part in all this is to see the higher and lower echelons as resources you can use/leverage to create the best framework, rather than obstacles which will resist whatever you're trying to do. So, ask for their input and suggestions. They'll have different considerations, perspectives and interests which can hopefully be merged together into a workable framework.


So, ideally you'd want members of your organization to share their mistakes/failures and how to avoid them so that other people will not repeat them. It's a tough mental block for organizations to overcome and for people to personally overcome because failure is stigmatized and associated with incompetence.

Unfortunately, I'm not at liberty to remove that threat. It is very real, and higher management might not understand the impacts and ramifications of that, but they still need to run the business, and I can relate to some of these decisions. The downside is that, obviously, some other people onboard will feel concerned. That said, this isn't a terror-climate type of studio, so there is some latitude I can use there, I'm just not at liberty to alter the culture altogether.

Ah, that's unfortunate. Again, it's a tough mental block to overcome :) It's a "selling a management style" problem, so see above.


On a slight tangent: I play chess quite a bit. I used to be very concerned about losing games, so I'd get anxious about playing someone equal or better than me because the possibility of losing was frightening for my ego. I'd put extra mental effort into each move and decision to avoid losing the game. However, once I started playing chess every weekend for five years straight, I had lost so many games that I just stopped caring. Losing lost its sting. I got used to it. So, I just started putting in lots of time into getting good at playing the game, trying out interesting ideas and risky moves. It turned into a casual hobby which I got very good at (I once won 15 games in a row against three skilled opponents). The same thing happens in other games which I play competitively (Starcraft 2 ladder). The trick is to handle loss/failure as "no big deal" and just analyse the first error (which usually cascades in effect) and train yourself to avoid repeating it. The most important aspect is to put in a lot of time and effort into improving (or training, as athletes see it).

I can totally relate here. I was ranked Diamond on Starcraft 2 Ladder a while back, and it took me everything to muster the courage to play a game. The fear of losing was to elevated that I just waited until I was into my best state of mind with nothing around that could potentially disturb me. It felt like I was going into an interview everytime. Pretty much the same with chess: I'm a competitive kind of guy when it comes to these games.

Yep, I know exactly what you're talking about. I got up to diamond league as well and was at the top ranks of it. The pressure was pretty intense! I was terrified of trying new things and generally just messing around as I would if I was in a bronze level league.


it may be a good team building exercise to spend time playing games competitively with each other and using it as a way to disseminate a positive culture for handling failure, learning from mistakes, and fostering a mentorship mindset

This is hard to implement. For starters, not every developer is a gamer. We have a lot of people that don't actually play games, but their skillsets are required. Also, not all people agree on types of games they want to play (obviously). Also, this is a large office, with masses of people. It is hard to coordinate this across the board. The best I could come up with is small-team gaming, and even so, the first issue soon resurfaces. In a unit of say, 9 people, very few of them actually share any interest in terms of gaming.
If the synergy was there, I'd employ it, but I'm having a rough time figuring out similar interests amongst peers.

There's always the option to create a 'studio-league' from the studio roster that's not directly tied to the studio itself, and get people to help one another get better. It isn't a bad idea, and I can see how some competitive games could help shape the attitude of certain people. That said, we're not really forcing anything, and just like anything else, people will learn at their own pace, or won't learn at all if they aren't interested. I'm not exactly sure about the real output of this method.


Hmm, that's a good point. I mistakenly assumed that every developer in video game development is naturally passionate about gaming and is a gamer. It's just an idea which implements the principle of a team building exercise which transfers over directly to work experience and relationships. If it's not feasable, then scratch the idea :)


#4986158 Seniority, and how to get there

Posted by slayemin on 02 October 2012 - 01:20 PM


The best thing you can do is encourage people to be introspective about what lead up to a mistake and try to learn from it. Make it an org culture value and build ways/means to share that knowledge within the org (forums, wikis, weekly email distro lists, etc). That way, everyone benefits from the mistake rather than an individual.

I'm looking for a practical way to do this. I don't see the 'where I've failed this week' being a totally constructive element to add to a company, even if it does encourage introspection. I've discussed with team mates, and we've come to the conclusion that to promote forums, wikis, etc does not make people pay more attention unless they feel specifically drawn to them. We have fairly documented wikis just sleeping about.

There's a couple possible issues:
-It could just be a presentation problem/language problem which would make it a hard sell. Rather than calling it "where I've failed this week" (which sounds negative), call it "Valuable lessons learned" and put the dissemination into a format which allows it to be shared with other team members (informal, short meeting? A newsletter? email distro?)
-The second issue sounds like a problem of buy-in and usefulness. You can create the perfect framework for sharing lessons learned, but if the users think its bullshit, then thats what they'll post (buy in problem). Then, other users will read these baloney posts and think that's the standard/norm and won't get much out of it, and conclude that the usefulness is not there, and the problem will become self-perpetuating. It's not a systematic problem, but a perception and use problem! The best way (at least, what I've found) to build buy-in and usefulness for a product is to get the end users to build and use the system. Let your team figure out what has the best cost vs. benefit ratio for their needs. Your job is to inspire the need to improve processes -- get the horse thirsty, then it will drink the water!


Also, that brings up a very difficult problem to solve: Getting people to admit to making mistakes. That's going to be a organizational culture issue to solve. If people are discouraged from screwing up (to maintain an aura of professionalism & expertise in their field), then your org as a whole will suffer and probably pay $1,000/head for the same mistake. That'll amount to a nice $10,000 training cost in my previous example.

That's a good point you've got right there, and let's be honest, in game development business, a lot of people are scared for their jobs (at least, in the studios I've been). A lot of people won't speak up their own failures by fear of losing their jobs, yet, the most seniors members are those that admit to it.
A recent example from a particularly mature developer went along these lines:
(Code review)
Senior: That code is total bullshit.
Junior (scared): Actually... that's the part you did on the engine like a year ago...
Senior: I know, I get to make epic crap too.

(Lovely!)

Here are some articles you might find useful:
Failing quickly
Fail Early, Fail Fast, Fail Quickly

Here is a philosophy I've adopted:
"An idiot will never learn from their mistakes and is doomed to repeat them.
A smart man will learn from their own mistakes.
A genius will learn from the mistakes of others."

So, ideally you'd want members of your organization to share their mistakes/failures and how to avoid them so that other people will not repeat them. It's a tough mental block for organizations to overcome and for people to personally overcome because failure is stigmatized and associated with incompetence. You should try to remove the threat on a persons job/livelihood based on failure rates, and instead tie it to deliverables output. (The only failure which is punished is consistent failure to deliver on time! (which itself may be a systematic project management/oversight problem as well!))

On a slight tangent: I play chess quite a bit. I used to be very concerned about losing games, so I'd get anxious about playing someone equal or better than me because the possibility of losing was frightening for my ego. I'd put extra mental effort into each move and decision to avoid losing the game. However, once I started playing chess every weekend for five years straight, I had lost so many games that I just stopped caring. Losing lost its sting. I got used to it. So, I just started putting in lots of time into getting good at playing the game, trying out interesting ideas and risky moves. It turned into a casual hobby which I got very good at (I once won 15 games in a row against three skilled opponents). The same thing happens in other games which I play competitively (Starcraft 2 ladder). The trick is to handle loss/failure as "no big deal" and just analyse the first error (which usually cascades in effect) and train yourself to avoid repeating it. The most important aspect is to put in a lot of time and effort into improving (or training, as athletes see it).

Since you're running a game dev company, it may be a good team building exercise to spend time playing games competitively with each other and using it as a way to disseminate a positive culture for handling failure, learning from mistakes, and fostering a mentorship mindset. Ideally, your team members would say "When I tried this strategy/technique/move, it failed. What did I do wrong and how can I avoid it in the future?". That kind of attitude towards failure can translate nicely into work. "When I tried this design pattern/algorithm/method, it failed. blah blah blah, please help me." or "When we used XYZ marketing technique, it had this effect which didn't meet our expectations (fail). blah, blah, blah, please help."


#4985401 What programmers want from a designer

Posted by slayemin on 30 September 2012 - 10:58 AM

Bottom line: Really, all I care about is whether or not I'd be wasting my time.

What do I get out of the partnership?

If you're paying me fairly to work for you, then it's not a waste of my time since I'm getting something out of it (money!). But, how much you pay me had better be proportionate to the work I'll be doing. If you just wrote a five page word doc and called it the game design and I have to do all the rest, I'll be putting in 99.9% of the effort and will expect to get appropriately compensated. If we expect to make $100k, I'd better get $99,900!

If you're not paying me, then I'm already incredibly disinclined to do anything for you because I don't work for free. What will I get? What is the likelihood of project success? My commitment to the project will be as wishy washy as I perceive the legitimacy of your promises to be. If your promises are contingent upon project success and the project looks like it's going to fail, then I'm out. (Note: It can fail in its construction phase or in its business phase)

I'd be happy to work together with Servant of the Lord. He sounds like he's got his shit together and the project will most likely succeed whether or not I'm a part of his team. That's motivating because instead of worrying about whether or not the project will succeed, I'm worrying about whether or not I'm pulling my weight and being an asset instead of a liability to the team. He's got what it takes to see a project through to the end and will deliver results. If you're a designer trying to put together a team, you need to implicitly include evidence that suggests a high probability for project success. What experience do you have? Have you shipped a game in the past? Have you been a part of a team which shipped a game? What will you contribute to the team which a programmer can't do? If I can do everything you do, but you can't do everything I do, then why do I need you?

If you're recruiting, you're also the implied project manager. The project manager for a project is like a train engineer trying to convince people to climb aboard, stay aboard, and get them to the final destination (project success). If at any point your passengers don't think they're going to get to the final destination, they'll jump off and hop onto another train. What kind of train are you operating? Does it exist? Is it a hype train or is it based on something of substance? Is the track already laid to take us to the final destination or do we have to build the track along the way (which means we don't know where we're going)? Once the train gets moving, you are going to be the one shoveling coal into the engine furnace to keep it going with full steam ahead! If your train loses momentum (lack of progress), or steam (lack of money), or derails (lack of direction/side tracked), your passengers are going to jump off and you'll never get them to the end destination. Then, you don't collect the fare and don't get paid. So, when you're recruiting, you're really trying to convince the candidates that you're the best train engineer to take them to their destination. Note that your passengers will have different destionations they want to visit along the way! Some people may just want to make money, some people will want to learn and get experience, others will want to test out an idea/concept, others want recognition, comraderie, status, fame, stability and benefits to provide for their family, etc. The best train engineers can run a train which visits everyones wants/needs while getting everyone to project success. Those are the projects everyone wants to join and be a part of (its not exclusive to just programmers!).


#4985372 Idea to prevent people from torrenting your singleplayer game

Posted by slayemin on 30 September 2012 - 09:27 AM

I'm in Afghanistan, were the internet connections are about as fast as a 56k dialup modem and about as stable as the occupants of a psych ward. I can't play games which require an internet connection to validate that the game is legit. It's a frustrating experience if you ever have the displeasure of going through it.

My philosophy on game dev: I make games for people like me. Right now "me" has no internet access in my room, so if I make a game for "me", then it can't require internet access for single player mode.


#4984757 I want to be an indie game developer, where do I start?

Posted by slayemin on 28 September 2012 - 10:08 AM


...


Thanks this is really helpful, I have been watching some c++ tutorials lately, is this a bad idea? So far I understand everything.

No, that's excellent. Treat the C++ tutorials as a teacher giving a lecture, then assign yourself homework to test your understanding of the tutorial content. However, don't forget that the point of following all of these tutorials is to learn how to build a game so that you'll build a game. There's a danger that you'll spend all of your time learning how to do things but won't ever actually build anything (a case of analysis paralysis). So, my advice is to start building stuff and when you run into a gap in your knowledge, then seek tutorials/references to fill that void :)
Start simple with a "Hello World" type program (get stuff on the screen!).
Then, look into what it takes to get multiple "Hello World" on the screen (like, 1000).
Then, try to put a graphical image onto the screen (may take some R&D)
Then, try to move that graphical image around on the screen (may take some R&D)
Then, try to move that graphical image around based on user input.
If you can do all this, you already have the necessary skills to build Pong.

Pong is an excellent game to start with. It's design is simple, the game is complete, and its attainable for newbies. You can focus on the structure of your game code and building a complete game framework. It's also a great introduction into concepts like AI, input, managing game states, graphics, game play, etc.


#4984439 I want to be an indie game developer, where do I start?

Posted by slayemin on 27 September 2012 - 12:24 PM

Step 0: Have vision.
Step 1: Design a game or have a game idea you want to make.
Step 2: Build the game according to your game design
Step 3: Test and revise your game over and over again until it's exactly what you want
Step 4: Market and release the game to the world

Naturally, step 2 is going to be the most difficult step to do because it's going to require a bunch of skills which you may not necessarily have at the moment. That's okay. This is where you teach yourself everything you need to know, or find people who have the skills you need and you can convince them to work on the project. You'll be learning the exact skills you need and you'll be building your project at the same time, so you get two birds with one stone. You'll go through some learning pains, you'll experience frustration, moments of glee and excitement, your project may succeed or fail, but if you stick with it, you'll learn a ton along the way, gain valuable experience, and possibly a marketable product to sell.

Bottom line: just do it.
An "Indie developer" is just a title which you can take upon yourself. It means nothing, really. What matters is what you create.

As for languages & platforms, I recommend Unity3D with C#, or C# with XNA.

As for producing your game, you're going to need programming, art, music and sound, and possibly writing.

The best advice I can give you is to keep your game simple enough for a single person and beginner to complete. A polished and completed yet simple game is infinitely more valuable than a complex but incomplete, unpolished game. Keep your features/requirements few! Think along the lines of old atari games, like "Pacman", "Breakout", "Tetris", "centipede", etc. and add your own small twist to the design. Then once you start, punch yourself in the face every time you think about wanting to add a new feature (its a project management thing, not a crutch on creativity).


#4984351 Final Year Project ideas :)

Posted by slayemin on 27 September 2012 - 08:02 AM

What do you want your final project to say about you?
"Hey, I can use the things I've been taught to create software!"
or
"Hey, I can teach myself new things or invent stuff nobody has done before and create software out of it!"

In my opinion, the size/scope of a project doesn't matter.
Student: "But, I wrote 10,000 lines of code and have X number of features! I deserve an A+!"
Prof: "...who cares?"

Learning things which are easy doesn't matter (example: Unity3d, HTML, javascript, etc).
Student: "I know we were only taught C/C++ and C#, but I went out and learned Java! Isn't that wonderful?!"
Prof: "By now, that's expected of you...so, who cares?"

The amount of work required doesn't matter.
Student: "I ported this C# project over to Java! It took hundreds of hours!"
Prof: "time spent is irrelevant...who cares?"

Breaking new ground is excellent.
Student: "I've invented this new technique to solve problem XYZ with an ABC boost in performance. Here, look at my scientifically collected metrics which prove it!"
Prof: "Wow, this is good stuff! We should share this! A+++ for you!"

Doing things which others thought was impossible is excellent:
Student: "These qualified experts have said that it is impossible to do XYZ! However, I disagreed and created a project which does exactly that! This is how I did it!"
Prof: "Whoa! that's incredibly impressive! A+++ for you!"




PARTNERS