Jump to content

  • Log In with Google      Sign In   
  • Create Account


slayemin

Member Since 23 Feb 2001
Offline Last Active Yesterday, 01:21 AM
-----

#4995905 Looking for a code/desgin review of continous map implemention

Posted by slayemin on 31 October 2012 - 12:19 PM

Okay, I think I understand.

I didn't see this mentioned in your post or in your code, so I'll bring it up. If the player is on the edge of the map, how do you handle it? If you have a grid of 100x100 tiles, the view is always centered on the player, and the player is located at (0,0) (top left corner), what happens? Do you keep the player centered or does the player move to the top left corner of the screen?

(x).ToString() + "_" + (y).ToString();
You don't need to surround your variables with parentheses.

I think your whole approach is flawed, and I'm not saying that to be mean. Here is what I'd change:
1. Use a camera.
2. Store your tiles in a 2D array.
3. Use a quad tree for collision detection.
4. Use "layers" in your map (terrain, static terrain objects, creatures & items, etc).
5. Break your map class up into more objects.

Use a camera:
What you want to do is to create a camera viewing rectangle. If map objects are within the viewing rectangle of the camera, then they are rendered. If you treat your view as a viewing rectangle, you can do a lot more with it (panning, zooming in and out, centering on an object, tweening between points, etc). Rather than rendering everything relative to the character position, you render everything relative to the center position of the camera and, for the most part, keep the camera centered on the player. This makes it much easier to handle the map-edge cases. You could also do interesting features, where if your character is moving in a particular direction very quickly, you can adjust the veiwing area of the camera to show more of the world space in front of the character so that they have more time to react.

Store your tiles in a 2D array:
You can either store the tile objects directly, or just store an index in a 2D array. How you store your tiles should be independent of how you're moving on the tiles and viewing the tiles. Your character movement can be simplified into an X & Y position, and handled with requests to the map manager. Character tells the map "I am at this position. I want to move left one space", and the map manager reads the map array and says "Okay, that's a legal move! you can set your position there." or "Nope, that can't be done. There's a tree there!" or "Nope, you're on the edge of the map and you can't go left any further!"

Use a quad tree for collision detection:
Once I understood the concept, it didn't take me more than an hour or two to get a quad tree datastructure up and running. The idea is to put your spatial objects into the smallest box which will contain them, and keep dividing the box into fourths until its empty. Then, when you're doing collision detection, you only need to compare the objects in the largest box against all of its child cells. This changes your collision checks from O(N*N) to O(log N) (best case). The tiles which are being viewed would be all the tiles which collide with the camera viewing rectangle (don't necessarily need a quad tree for camera rect, you can also do a rect.Contains() call against all tiles in the game model which is more computationally expensive but works)

Use layers in your map:
Terrain is the first, bottom layer. This tends to make for boring maps because they're plain. So, create another layer and add trees, flowers, rocks, and any other terrain objects. These static terrain objects are non-moving, so this simplifies collision detection a bit (you're not checking if a tree is colliding with another tree every frame). Then, you'll also have another layer for moving objects (monsters, player characters, bullets, pick ups, etc). These objects may move every frame, so they can collide with other objects in their layer or objects in the static objects layer. By layering your map, you can be a bit more flexible. A tree can sit on a dirt tile or a grass tile, instead of creating a tree-dirt tile and tree-grass tile.

Break your map class up into more objects:
You're currently trying to do too much "stuff" in one class. Break it up a bit. You've currently got a class which contains map metadata, tile information, character information, character movement logic, screen resolution logic, and resource loading logic all in ONE class. This makes your class design VERY rigid and all of your object interactions are hardcoded. This makes your class have 430 lines of code. You want all of your objects to be as decoupled as possible and interacting with each other via class method calls. I like to use the model view controller design pattern. The model doesn't know about screen resolutions, it only cares about maintaining the game state and game logic, and updating it. The view doesn't care about the game logic, it only cares about correctly rendering the game state to the current rendering settings (resolution, anti-aliasing, shadows, etc). The controller doesn't care about rendering very much (except for getting its controls rendered, such as buttons and drop down menus), it only cares about interacting with the game model.
Some people like to break it out even further and add a data layer to handle data read/writes to and from a file or database. I generally include that in my game model objects.
So, I'd create at least the following classes:
-Map
-Tile
-Character
-Camera
-Player (inherits from character)
-Monster (inherits from character)
The map class would contain one or more 2D arrays of tiles, any meta data about the map (like map name, map size, etc), and methods for loading and saving to disk.
A tile class would contain tile specific information, such as the tile texture, tile dimensions, tile type, movement point costs, etc.
The character class would be an abstract game actor class which contains generic data about a character (hitpoints, name, position, dimensions, etc)
A player class would mostly have UI and controller specific methods
The monster class would be an extension of the character class, maybe with some added AI scripts to control it and do monster specific logic.
I like to keep a global class of loaded art resources (and call it a texture database, or TextureDB for short). Whenever I create a new object, I set its texture to point to one of those stored art assets. By doing this, I can centralize all of my resource loading into one object. Then, all I have to worry about is making sure that the TextureDB has all of the correct art assets loaded up. I can also load art assets into the TextureDB by reading a file for a list of needed art resources (art manifest), so if I load a game level, the level data would contain a list of all the art resources it uses. The textureDB would load those assets into memory, and off we go! :D

Warning: general hand waving to follow:

As for your rendering code, all you should be doing in the draw function is calling each object and telling it to render itself according to its current state. So, if you have a map object, your render code should be this:
Map.draw(spriteBatch);

Since the map contains a list of tiles which will know how to render themselves, it'll do the following:
//you'd also do a foreach for each layer, so you render terrain first, followed by static objects layer from top to bottom, followed by moving objects layer, etc.
foreach(Tile t in TileList)
{
	 t.draw(spriteBatch, position);
}

To move a character on a map, you'd make a request call to the map manager, something like this:
if(KeyboardInput == MoveLeft)
MyCharacter.Position = Map.MoveTo(MyCharacter.Position, new Vector2(-1,0));

And the map manager would get the request and handle it something like this:
public Vector2 MoveTo(Vector2 Pos, Vector2 Dir)
{
	 Vector2 RequestedTile = new Vector2(Pos.X + Dir.X, Pos.Y + Dir.Y);
 
	 if(Tile[RequestedTile.X][RequestedTile.Y].isPassable() and not Tile[RequestedTile.X][RequestedTile.Y].isOccupied() and blah blah blah conditions)
	 {
		  return new Vector(RequestedTile);
	 }
	 else
	 {
		  return Pos;
	 }
}



#4994385 Review of my code

Posted by slayemin on 27 October 2012 - 04:19 AM

I find the Model-View-Controller framework to be a helpful framework to keep in mind and to design to.

Your game is the "model". This would contain all of your data structures, game objects, game states, the state of your game objects, process the next frame, turn, etc. It's the guts of your application. It doesn't care at all about rendering stuff to the screen or collecting input to change the model*. It's very abstract.

Your "view" has the sole focus of representing the state of the "model" to the user. It doesn't do game logic! I like to think of it as the artistic manifestation of your model. Since it's "artistic", that means that you could interchange one view with another to get a totally different view of the same data. Real world example: I've got a database driven application. The model is the data and how it all interacts. The view can be rendered as either a windows application or a webpage. I wouldn't have to change any code in the model because its completely unconcerned about rendering.

The "controller" is how the user interacts with your model. Sometimes, it's intertwined closely with the view (use the mouse to click on a button!), but its not necessary (press "F1" key to fire torpedos!). A controller will send a command (better to think of it as a request) to the model and the model will decide if it wants to honor it and change its state accordingly ("okay! I've created a torpedo!" or "nope, you have no torpedos left or its not ready to fire again!"). Again, we are NOT putting game logic into the controller. We're using it as a way to interact with the model which contains the logic to do the requested action.

So, just by looking at your code, I can see that you have a single class which is concerned with rendering. This would fit within a "view" portion of the MVC framework. It's not enough to tell you anything about whether or not your classes are well architected because we can't see how they're interacting with each other.
One slightly worrisome thing I'm seeing though is your liberal use of public access for internal class variables. Do you do this with your other classes? It may not be a big deal for small projects, but you will start to run into problems with larger projects. I like to assume that I'm writing my classes to be used by the biggest idiot in the world (me). If there is a way someone (me) can completely screw it up, then it's only a matter of time before it happens (sleep deprivation, forgetfulness, laziness, sloppiness, etc). When that screw up happens, I have to waste time debugging to isolate the source of the problem ("OH! I'm getting errors because this completely unrelated class thinks it should be allowed to come into my class and muck around with its variables?! He wants to divide by zero?!). So, when you're designing your class, think of yourself as a miser who will only give access to your class if and only if there is a good reason to, and that access will be on your terms rather than the users terms. If something is public, it's free game for a legion of monkeys to use. Would you like a legion of monkeys twiddling with your class methods or class variables?


#4994170 Do's and Dont's of Recruiting a Volunteer Team?

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

From my experience, the greatest obstacle for your team will be motivation. You can pretty much plot the average team motivation level with the function: f(x) = 1/x, x > 0;
The y-axis is the motivation level and the x-axis is time. As you can see from the graph, it starts pretty high but it quickly dips and starts to taper off. Your people will have a hidden parameter which they don't know and you don't know, and it is their minimum required motivation to continue with the project.

if(currentMotivation <= randYVal)
LeaveProject();

There's also this weird phenomena where as a person's current motivation approaches their minimum motivation level, the amount of work they do decreases as well. The symptoms of this are flakeing out, laziness, lachrymose, etc.

As the project initiator (and presumed manager), the good news is that you've got control of this!! Your goal is to keep team morale as high as possible and lengthen the time it takes for it to taper off to project failure. Ideally, you'll have a project which has a completion time well before motivation failure. You can control when the project gets completed and when motivation failure occurs by ensuring that the size and scope of the project is attainable, by making significant progress on the project, by keeping personality conflicts to a minimum, by paying team members, by keeping poisonous personalities off the team, by setting a high standard and holding people accountable to it, and being realistic about current circumstances at all times. Eventually, the initial appeal and zest for the project fades away and everyone has to put their nose to the grind stone to complete it. It stops being "fun" and becomes "work", so when this happens, it becomes the true test of your project management skills, team cohesion, and the infrastructure you've put in place.

Ultimately, you need to take a realistic assessment of your team and its capabilities and pursue an achievable project which can be completed before morale failure occurs.


#4993860 How/Who create the GameObjects?

Posted by slayemin on 25 October 2012 - 11:27 AM

uart777: I learned a hard lesson a few years ago: The person playing your game doesn't give two shits about whether you wrote the code in ASM, C, C++, Fortran, C#, Visual Basic, LOLCAT, java, javascript, Malbolge, etc. All they care about is whether or not the game works and whether or not it's fun. In 2012 (going on 2013), you have LOADS of language and platform choices to choose from to make a game. Whatever language/platform you choose, your end user won't care because it doesn't matter. If it DID matter, then the language used would be prominently featured on the box art. Today, we've got multicore processors which run around 3.5Ghz , gigs of ram, hard drives with terabytes of space, and graphics cards supporting hardware so beefy that they're practically super computers. We can afford to be a bit more lax with our bits. It's a waste of programmer time to worry about how bits are laid on the wire when there are platforms and technologies which have already figured it out.

Since the programming language doesn't matter much anymore, we are free to be a bit more picky about what language we pick. Here are my principles:
-How robust/flexible is the language?
-How easy is it to learn?
-How easy is it to maintain the code after its writen? (I'm looking at you, x86 ASM!)
-How much boiler plate code needs to be writen to get a feature rich game running?
-How well is the language specifications and API documented?
-How much industry support is there for the language?
-How portable is the language to other hardware and software platforms?
-What is my (or my teams) language proficencies and background?
-How much of an existing code base (libraries) do I have?

If(making games)
{
If you're doing it right, you're sweating over high level design decisions and choosing the best algorithms for the job you're trying to do. Doing this well is much more valuable than sweating over the bit order of a pixel residing in memory.
}

If(Writing hardware device drivers)
{
Okay, sweat over the most efficient ordering of bits for your hardware device. I assume you're working for nVidia or ATI and working very closely with the hardware engineers to maximize driver performance so your end users (API & game devs) don't have to.
}


#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!).




PARTNERS