Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Dec 2011
Offline Last Active Mar 21 2016 01:50 AM

#5273875 Unity vs. a more "lean" game engine

Posted by on 02 February 2016 - 08:15 AM

I just don't find it exciting to work on actual game, but I like to see when the game builds on all the fundamental blocks delivered by the tech.


I can really relate to this, actually.

#5273831 Unity vs. a more "lean" game engine

Posted by on 02 February 2016 - 03:58 AM

The first time I started up Unity I was like dude...? Where the hell is my main? Where do I start typing!?


This was also my first thought. Glad to hear I'm not alone. =)

#5273547 Unity vs. a more "lean" game engine

Posted by on 31 January 2016 - 06:25 PM

Hi there, it's been a while since I've posted.


I'm looking to start a new game project. I've been developing software for a long time, and I recently started learning some 3d game programming (through a university class) with jMonkeyEngine. It's going great! I'm getting more and more comfortable with 3d programming. I still have a ton to learn, but after spending just a few days playing around with jMonkeyEngine, I'm getting the feel for it.


The person I'm collaborating with is an artist (2d, 3d, textures, models, level design, etc.). We're trying to find the right tools for our first project, which will be a 3d game with some simple mechanics. He's played around with Unity in the past, and suggested that I check it out. I'm on the fence, to be honest. I'm a software developer at my day job. I like things to be lean, clean, and minimal. I code in vim mostly. I avoid IDEs like the plague, except in the case of Java, which makes my fingers hurt if I don't have some good code completion. ;) jMonkeyEngine appeals to me because I can just start writing code. Every time I've tried to dig into Unity in the past, I never could grok what is going on; it just seems like a lot of magic. It seems bloated and verbose, and the everything seems very tightly coupled together: level design, game objects, and game "scripts" all just thrown into one massive GUI. I found it noisy and unreadable. Despite all of the good things people say about Unity, I honestly just don't have a good first impression of it.


On the other hand, because everything is integrated, there's no need to figure out how to handle asset pipelines, level design/building, etc. (With JME, for example, I would have to figure all of that stuff out for myself, and maybe even build custom tools just to put everything together.) So already I can see some tradeoffs. In Unity, I/we could build our levels by basically just dragging things around in the graphical editor. With JME, I'd have to either a) find a secondary tool to help me model the levels, b) write my own editor (not ideal), or c) just do everything in code (also not ideal).


So finally to my questions: To those who have experience with Unity, is my initial impression at all accurate? To the veteran programmers out there, what's your opinion of Unity, especially in terms of its programming approach? If I go the "leaner" route (even with a "batteries include" engine like JME), am I going to have to end up writing all of the stuff that's "missing" (which Unity already has)?


I understand that the use of tools and the approach different people take is highly subjective. I'm really interested to hear peoples' experiences and opinions on this.


Sorry for the long-winded post. I appreciate any feedback! =)




#5177649 Accessing other directories

Posted by on 02 September 2014 - 07:31 AM

I'm assuming you mean `sys.path`, not `os.path`. If you want to be able to find and import Python code, there are better ways to do it.


First thing, though. If the problem is that you have multiple subfolders of code, and you cannot seem to import it, you're missing a crucial component in your "package" structure. Do you have an `__init__.py` file in all of your source code directories? If not, you should have them--they can just be empty files. (See https://docs.python.org/2/tutorial/modules.html#packages.) With these, your plain folders become Python "packages". (A "module" is just a file containing Python code which has a .py extension. A "package" is a folder which contains an __init__.py "module".)


An example:


If you want to add the `foo` package to your path, so that you can import code from it, you can do this:

import sys
# you only need to add the root folder to your path
# if your folders have an __init__.py in them,
# python will traverse the folder structure and find all of the code
sys.path.insert(0, '/path/to/foo/')

# now you can make all sorts of imports statements:
import foo
import foo.some_module

from foo import some_other_module

import foo.bar
from foo.bar import baz

import foo.bar.blarg
from foo.bar.blarg import utils
# etc.

Instead of just putting code somewhere and patching the `sys.path` at runtime, there is a better way. It is better to install your code in a well-known way to a well-known location. See https://docs.python.org/2/distutils/setupscript.html. Another thing you can do add the path to the code to your PYTHONPATH environment variable. For distributing code, creating a proper `setup.py` file is better.

#5162984 Map in spacegame? How to avoid all-open travel and "boring" worlds?

Posted by on 26 June 2014 - 04:36 AM

Another alternative would be to allow FTL (faster-than-light) travel in particularly open areas of space where there really is nothing, or at least nothing significant (so you don't have to suffer the boredom of waiting, like the boats in classic EverQuest). When you approach objects with a significant mass/gravity well (asteroids, planets, suns, etc.), FTL is travel not possible--and if you get close enough, you'll get pulled out of hyperspace.


This could really make boring space travel a lot more interesting. For example: Let's say you have a map with known and charted planets/objects. You want to cross a large stretch between two systems which appears on your map to just be empty space. You make the FTL jump, but halfway through you get pulled out of hyperspace by the gravity well of a massive planetoid/star/etc. which wasn't on the charts. So then you can explore it, etc....

#5162019 Noob question on hashmaps

Posted by on 22 June 2014 - 02:12 AM

If you want to have the player object in the hashmap as well, and the hashmap is typed, the player needs to have the same interface as the other objects. That means, for example, that all of the objects could inherit from the same superclass, provided that there are enough similarities for this to make sense, of course. Otherwise, they could just explicitly implement the same interface. Then you should type the hashmap with the superclass or interface.


Make sense?

#5120040 Game design with Collision Detection

Posted by on 30 December 2013 - 10:34 AM

One way you can implement this is for your collision code to have direct control over the state of the sprites, as you've already described. With this design, however, you'll find that things are not well encapsulated. Your collision code check for collisions, decide how to respond to the them, and then act out those responses as a side effect. I think it's better for your collision to be more "functional" and stateless, meaning that it takes as input some objects which potentially collide, find collisions, calculate a suggested response to the collisions, and outputs those suggestions. These suggestions can then be consumed by another piece of code which doesn't have to do any calculation, it simply acts. In this way, your game has smaller, simpler components which are easier to test, debug, and reuse.

#5087284 Programmer's "writer's block" and getting bogged down

Posted by on 19 August 2013 - 06:40 AM

So I've started working on a game, essentially a tile-based RTS-type thing using Java and LWJGL, and I'm having a pretty big issue: I can't get anything done.


For starter's, I can't figure out where I wanna start. "Do I want to start with the display/graphics system?" "Maybe the logic?" "Or how about the input and event systems?" "Maybe I should go back to the drawing board and diagram everything out." "Diagramming takes too long, just a sketch." "Forget it, I'll just jump straight in."


Then there's the matter of how I want to do things. "I want to use MVC architecture." "I can't do that, that's not perfectly in line with MCV standards." "I've heard good things about component-entity system architecture, maybe I should try that." "Wait, how do I lay this all out?" "How do I wanna script this? I like Javascript, is Rhino any good?"


And then there's the infamous, "Okay, new idea, better scrap the whole thing and start again."


Basically, I'm finding my head being a clusterfunk of ideas and can't seem to find a good place to start without getting bogged down. Does anyone have any advice for dealing with this?

It sounds like a typical case of analysis paralysis. The solution? Implement something simple and extend it later. So you're wondering whether to work on the graphics, logic (I'm assuming you mean game update logic), or input/event handling? I say, work on all of it. Build small pieces of each and keep iterating.


I think fir is right: start with your game loop and draw some basic things (the world plus a character in the world). Then implement a basic input handler to move the character. Start with basic keyboard input (arrow keys) and then extend it to use mouse input. Try to add something new every day you work on it, even if it's a small feature.


It is good to study design patterns, but don't start with the pattern--this is the wrong approach to building things. Instead, just start building the thing and make abstractions when it seems appropriate. Patterns will emerge over time with refactoring.


It's just like Lego; just keep building and don't worry about change. Be prepared to scrap large chunks of what you have built and replace it with something better/stronger/nicer looking.

#5083895 2D Map - Data Structure (Not really Java specific)

Posted by on 07 August 2013 - 10:18 AM

I think the last "worry" about my object structure is that I will be putting multiple types in the same array.. including players.
Object[0] = Wall at 0,0
Object[1] = Wall at 10,0
Object[2] = Player at 10,10
I'm sure I can handle this from a code perspective, but you mentioned above avoiding this style of data structure. The alternative is to have a unique structure for every single object type. Only things I can think of are Objects (Walls, etc) and Players. Granted, both can fit into the same category to some degree but they will need their own classes.
Having a unique structure for Objects and Players would get messy.. and also destroy the whole overlapping draw system. In order to have them draw correctly, I would need to add a THIRD structure, let's call it Draw. Draw would contain the "draw order" and would simply point to either an Object or a Player.. but now we're really just back to having everything, aren't we? A little different since the Draw would only contain a pointer and not the object itself but .. now we're up to 3 structures instead of 1.
I think that's it..


There's another way.

1) Keep distinct types of objects in separate data structures (ArrayLists, for example). The most derived classes of the objects in each don't need to be the same, they just need have a common enough interface to justify putting them in the same array.

2) When it's time to draw, search for the items which you need to draw. Make it a brute-force linear search for now, and optimize it later with a smarter search. Once you have this filtered list (let's say, a total of 1000 objects down to 20), sort them by their Z components and render in the correct order. It could look something like this. My Java is a little rusty, so bear with me:

// This is basically what your classes can look like.
public interface Drawable {
	public void draw();

public abstract class Entity implements Drawable {

	public double x, y, z;

// Note I call it `GameObject`, not Object, so as to not be confused
// with java's built-in Object class.
public class GameObject extends Entity implements Drawable{

	public void draw() {
		// TODO: implement me

public class Player extends Entity {

	public void draw() {
		// TODO: implement me

Then you need to keep your various game objects somewhere:

// TODO: populate these
List<GameObject> objects = new ArrayList<GameObject>();
List<Player> players = new ArrayList<Player>();

Then you can implement a filter to search for the only the objects in view, given min/max x/y of the current view.

	public List<Entity> static filter(double minX, double maxX, double minY, double maxY, List<Entity>... lists) {
		List<Entity> filtered = new ArrayList<Entity>();
		for (List<Entity> list : lists) {
			for (Entity e : list) {
				if (e.x >= minX && e.x <= maxX && e.y >= minY && e.y <= maxY) {
		return filtered;

You can call it like this:

List<Entity> filteredStuff = filter(0, 480, 0, 640, objects, players);
// Edit -- then you can render:
for (Entity e: filteredStuff) {

Then you can sort them by having entity implement `Comparable`, and using `Collections.sort`. See http://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html and http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#sort(java.util.List).


Notice that, since your `filter` is a separate, self-contained function/method, you can easily swap it out with alternate implementations, when it comes time to optimize. The inputs and the outputs are the same, but the algorithm can change. Make sense?

#5083860 2D Map - Data Structure (Not really Java specific)

Posted by on 07 August 2013 - 07:36 AM

This had crossed my mind before although I didn't think of it again until you mentioned it. Method 2 makes it easy to find all objects in a given map. But if I wanted to do something like .. find all objects from 2,2 to 3,3, I would need to do a brute force search through my object structure to find them all (although if they were sorted, I could easily stop once I reached 3,4). Using method 3 helps alleviate this. I agree that it is messy though, but I feel like the solution still *has* to be to index the objects by location.


If I understand your design correctly, your game objects can be positioned anywhere, right? "not just locked to the grid", as you said. So that means that any given point in time, your objects can be literally anywhere. So it doesn't make sense to assign them to grid cells, and then move them to another grid cell when they move far enough.


And yes, using this method, if you wanted to find all objects in a given area by looping over each object and checking for intersection is brute force. It's inefficient. But it's also simple and works just fine for small number of objects. When this becomes a bottleneck, you can replace it with some better based on, for example, a quadtree. For now, just make it simple and make it work. Worry about optimizing later. (See below.)


It's funny.. I've been working with a proprietary programming language for medical software for the past 2 years. It was designed around being simple and building interfaces for data entry. Being the person I am, I tweaked it and made a 2D game with it. The problem is, the language is never compiled, only interpreted .. which gives it a TON of overhead. Re-drawing the screen is a great way to make a slow game.
I have a hard time getting into the mindset of "This is a modern language - it was MADE to do this kind of stuff. It can redraw the screen more than once a second and you wont see a problem". So I keep going at this trying to be careful with what I'm doing. I guess it's not really a BAD thing (optimizing the program for performance), but it can lead me to try some strange solutions and make some messy code.
That being said, yes.. I think every time an object changes, I will need to
1) Sort the list of objects
2) Re-draw them
I even cringe writing that because I know in this proprietary language that would not go over well.


You're using Java on modern hardware right? You can draw 60 frames per second, no problem. So put the limitations of this proprietary language out of your mind, they shouldn't concern you.



I see that you're concerned about performance, and that's okay, but I think you're getting way ahead of yourself. Give this a read: http://c2.com/cgi/wiki?RulesOfOptimization


To summarize the rules of optimization:

1) Don't.

2) Don't yet.

3) Profile before you optimize.


So if optimizing early is making you write bad code, stop doing it! =P


Other advice:

1) First make it work

2) Then make it elegant

3) THEN make it fast


I hope that helps.

#5083187 Is Python underestimated with what it can do?

Posted by on 05 August 2013 - 04:52 AM

You seem to be missing the fact that Python is already a hugely popular and successful programming language:
EVE online (among other games), is written largely in Python.
A good chunk of Google's infrastructure is written in Python.
Python is the scripting language of choice for content creation packages like Maya.
TIOBE ranks Python as the world's 8th most popular programming language.
And so on...


A few more specific examples of "popular" applications that I know of:


- OpenStack

- Blender (for scripting, not the application itself)

- The backend for yelp.com

#5083186 Is Python underestimated with what it can do?

Posted by on 05 August 2013 - 04:46 AM

All languages seem to get degraded, lets just call it language insecurity or e-religion, I mean if you compare the language comparison threads with theological comparisons you would actually be quite amused on how similar they are, which would probably explain why some people are obsessed with defending their language of choice while criticising others and religiously sticking with it lol.


The important thing is that you are learning / increasing your knowledge, it doesn't matter if its C, Python, C++, C# or even assembly, the more you practice the better you get (providing ofc you are actively learning and not just assuming stuff in other words making mistakes) and the closer you will get to your compiler God.

Totally agree with this. I think that instead of discussing "what makes language X is better than language Y, Z, etc.", I think it's more worthwhile to discuss "what makes language X good", period. Otherwise, it's just religion, complete with witch hunts and stoning. =P

#5083185 Is Python underestimated with what it can do?

Posted by on 05 August 2013 - 04:42 AM

Some general comments about "speed". Disclaimer: I code (mostly) in Python as a full time job.


First of all, performance isn't just about language choice, but also algorithm choice. An inefficient program written in a "fast" language is still inefficient. So I don't think it makes sense to just label a language as "slow". As others in the thread have said already, sometimes just "fast enough" is sufficient.


Second, you have to take into account speed of _development time_. I realize that this is more of an economic measure, and that most everyone in the thread so far has been focused on speed of _performance_, but do not underestimate the value of this. If the need for development speed is greater than the need for sheer performance, a higher-level language, if it is just "fast enough", is a good choice.


Third, and this is a comment specifically about Python, many of the standard and third-party libraries available have parts of them written in C, thus they can be quite performant. This is a really nice feature in my opinion. The combination of high-level interfaces and the option to write extensions in C to address your worst computation bottlenecks is a pretty good combination and makes Python a good choice for a wide variety of applications.

#5083182 Is Python underestimated with what it can do?

Posted by on 05 August 2013 - 04:21 AM

I think it's hard to work with on projects of scale.


I agree with most of what you've said, except for this statement. Although I don't know understand exactly what you mean by "projects of scale", I'm going to guess that you mean "large projects". Feel free to correct me if that is not what you meant. If it is what you meant, this is simply not true. OpenStack, for example, is written in Python: http://www.openstack.org/. I would consider this to be a large project, anyway.


As a side note: Python is great for scripts, one-off tools, and quick-and-dirty prototypes, but anyone who says that's the _only_ thing that it's good for has probably never written a significant application with it. (Source: In my day job I develop on an open-source seismic hazard assessment engine, which can run regional and global scale calculations and is entirely written in Python. See http://openquake.org/.)

#5070848 Developing a cloud service/server for your app?

Posted by on 18 June 2013 - 08:11 AM

I just want to chime in here quickly and point out something very important: If you're stil in the process of learning, do not concern yourself with Amazon EC2 or "scaling". First you need to make things work. Trying to wrap your head around concepts like elastic cloud computing, scaling, and optimization are just noise to a beginner.


Scaling problems will arise if and when you have enough users. When that happens, you'll need to figure out the bottlenecks. At this early stage, you should resist the temptation to guess how your application needs to scale and just focus on building it.

To clarify, cloud hosting providers are a good option for hosting static servers, as well as dynamic scaling (as dmatter mentioned). My point is, try not to get lost in a sea of buzzwords. Focus instead primarily on just making your app work.