Archive for the ‘General’ Category

Picking the first language to learn for novice programmers can be a daunting task. For many, they simply have no clear where to start, and don’t know any of the merits and drawbacks of the various choices they have. Even among experienced programmers, the debate on what new programmers should start with is long and has many different sides. In this article I will give my side.

My Perspective

Before I talk about which language people should start trying to learn first, I will discuss where I am coming from when I make that choice. The first language someone learns in my opinion should be fairly easy to develop with, and be able to give the programmer results fairly quickly. The main problem I generally see with fledgling programmers just starting out is that they get very frustrated with error messages, and in general struggle to connect the concepts they are working with to an actual useful program. I keep these things in mind when making my choice.

 

My Opinion

For new programmers, I highly recommend starting with a web development related language, namely Javascript or PHP, PHP being the first recommendation. The reason I say this is simple. PHP is a very easy language to program in. As a scripting language,  development goes much faster (no having to recompile upon changing a single line of code), and the language itself is much more forgiving. A new user doesn’t have to memorize many different syntactical rules, so all they have to focus on is understanding the concepts, and getting practice with solving problems. Also, PHP (and to an extent, Javascript) comes right out of the box with many various helper functions and algorithms that in other languages you need to either import a library, or write the function yourself. This allows novice programmers to solve problems much faster and easier. However, this comes with a drawback. A programmer who gets used to PHP having a lot of functionality built in that other languages don’t have by default may make it difficult for the programmer to migrate to different languages/platforms. On the other hand, while the programmer may become too reliant on these built in functions, they do know to some extent how to solve a similar problem with another language. The new problem becomes finding out how the other language implements the functionality used in the built in PHP function, or how to write it themselves.

The second reason I suggest PHP (or Javascript), and web development in general is because it makes using the various concepts they’ve learned in practice more rewarding. It is much easier to make an interactive GUI with PHP combined with HTML/CSS than with a programming language like C++, Java, or even Python. Because of this, its much easier to make a “cool” application even with only basic skills. Making a website where you can log in and see a welcome screen is extremely easy with PHP and HTML, but would be much more difficult for a novice in, say, C++ or Java.

 

Drawbacks

While learning PHP (or web development in general) first is not a bad idea, there are some drawbacks. One thing, which I mentioned earlier in this post, was that many novice users who use PHP may become dependent on the built in functions that aren’t available in other languages without either importing a library, or writing the code yourself. This can make transitioning to a more difficult language even harder. This type of problem isn’t unique to PHP either, but common to people who start with most scripting languages, and than transition to a more difficult, stricter language. For example, in my school, the introductory programming class used Python, while the next class (Object Oriented Programming) is taught using C++. Many of the students who go from the first class to the second struggle early in the class with the unavailability of certain functionality that they got so used to using in Python.

Another issue is bad habits that are easy to form with scripting languages. Since most scripting languages have no explicit typing, the concept of a variable with a type can be difficult to understand, especially if you have been programming for a good amount of time.

In general, since scripting languages or usually much easier than stricter programming languages, novice programmers are able to progress faster and without much frustration, but they can pick up bad habits, like the expectation of the language to provide certain functionality, or the expectation of the program to handle many things in the background that you have to set up yourself in stricter languages. The example that one may come to think of first is garbage collection, which is available in most scripting languages, and even some strict programming languages (most notable being Java), but not in, say, C++. Scripting languages also hide many of the core functionality that is inherent in the language from the user. This can create programmers who know how to do something a certain way, but have no idea of the concept behind what allows them to accomplish whatever goal they have. This makes it much harder for these programmers to solve more complex problems that require knowledge of how programs and the underlying code actually works. For example, a novice may figure out how to stop a certain PHP notice from occurring by using the notice suppression operator (the @ operator), but may have no clue why that operator actually fixes (well it doesn’t actually fix the error, but rather stops it from being reported) the error.

However, these problems can be resolved by going from learning an easy scripting language to learning a more difficult, stricter programming language like C++ (in fact, I highly recommend starting with PHP/Javascript and even MySQL if you are adventurous, and then learning C++ in depth). This way, the programmer gets the benefits of learning a very strict language like C++, where you essentially have full control over your program and therefore have to know not only how to solve problems, but why certain code and concepts solve the problem. Also, the programmer won’t be nearly as frustrated since they already have a language under their belt. The learning curve of C++ is high enough, but some of that difficulty can be mitigated if you already have practice with most or all of the basic programming concepts.

 

In short, for anyone who wishes to learn how to program and make applications, I suggest starting with web design, namely PHP (but Javascript, ASP, or any other web based language would work) because development is faster and easier for a novice programmer, and seeing the results of your knowledge and making cool, useful applications is much easier, especially if you want to incorporate some sort of GUI elements.

As a side note, since not everyone is interested in web design, or has the means to purchase a server (although you can always download software like LAMP, or WAMP to turn your computer into a local web server), other scripting languages will work as well. If you are going to go this route, I suggest Python personally.

 

If you have any questions or comments, or disagree with what I say, leave a comment below! I would love to have a discussion with someone who has a differing opinion from mine.

This will be the first of 4 part series on getting started with Unity. In this portion, I will go over some things I learned while starting my first project, as well as some design issues I came across, as well as how to solve them. In addition I will talk about starting a game from scratch. This section won’t be too heavy on code or follow-able examples, so if you want to skip ahead to the more code heavy parts in section II, III, and IV, feel free. These posts assume you have basic knowledge of Unity’s GUI, and have to navigate it.

What I learned:

I’ve been using Unity for a few months now, and I’ve learned quite a bit about game design in general. The types of problems you come across in game programming are much different than on other domains. For example, in a web or mobile development, you spend a lot of time processing and retrieving data from various databases or calculations, and presenting it in a simple manner to the user. In game development, you have to work with things like positioning, and rotation, and figure out solutions to things like path finding, combat, and artificial intelligence.

The most interesting part of developing a game is definitely designing the individual game mechanics. When deciding on which mechanics to work on first, starting on the simplest, or most fundamental to your game is key. This is one things I learned while developing the simulated city game I am currently working on. For example, in a game like mine, where spawning certain buildings or other objects in a key part of the game, starting with a simple script to place objects (ignoring resources, and similar) is important. Once you have that basic functionality done, you can continue adding to it without worrying about whether the basic functionality of it will work. In a platformer game (like Lerpz 2), focusing on the movement of the player controlled character is also very important and should be one of the first things designed.

In addition to coding, the look and feel of your game is also important. Unlike web design, where creativity can be borrowed from free templates and similar sources, getting visual content for your game can be difficult. There are online services that offer free game assets, but getting a large group of assets that look good together can be difficult. This actually brings me to my next point.

Starting from Scratch

Starting a game from scratch can become a daunting process, and unfortunately many would be game developers get eternally stuck at this part of the process. I wrote a post a while ago with a bunch of different resources: http://blackscorner.me/2011/10/04/list-of-unity-game-assets-both-free-and-paid/. This is a great place to start for free assets of all kinds. Things like sounds and textures (I use http://www.cgtextures.com/ for textures, and http://www.freesound.org/ for sounds) are easy to get, and using these resources saves a whole lot of time. However, for models, many models, while of good quality, just don’t fit with what you need. Some are too high poly, some or too low poly, and some just don’t fit the style. Sometimes you need to make your own models

Modeling

Modeling can be a very difficult process, especially for those whose experience lies mostly in coding. Choosing what 3D modeling software depends on quite a few factors. The free and open source alternative, called Blender (Blender.org) is a very popular choice for indie game developers who don’t have the money to put towards one of the proprietary pieces of software. Other alternatives are Maya, 3Ds Max, and others. I have experience with Blender, so what is what I will talk about briefly.

There are many online tutorials for Blender (you can find many on this page: http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/Tutorial_Links_List). The learning curve is somewhat complex, but once you learn how to successfully create and texture a simple model, things get easier. I am by no means an expert, or really even good at modeling, but making your own models at least as place holders can really make development faster. You can always change the models, but if you are waiting on models before you can do code related stuff, the development process really slows down. The great part is that importing 3D models from Blender (and really, most other 3D modeling software) is extremely easy.

View the second part of this series here: Link

As a tutor and coding help forum poster, I notice many instances of people using OOP, but using it incorrectly. Now, i don’t necessarily mean that they have errors in their code, or that it isn’t logically correct, but rather that the programmer in question has problems with their concepts of OOP. In this post I’ll be discussing the very basic and common problems I see, and ways to think about OOP such that these mistakes can be avoided. I’ll only be going over two of the simplest OOP concepts, encapsulation and inheritance.

Object Oriented Programming: The Why?

Many people simply use Object Oriented Programming because its the “latest and greatest” paradigm in the computer science field. The problem is that they learn the syntax and semantics of OOP, but never truely learn what OOP is. Let me start by giving a basic explanation of what OOP brings to the table as far as programming is concerned.

First, the basic concept of OOP is instead of programming procedurally, or functionally, you program in such a way that your entire program consists of discrete, separate objects that interact with each other in certain ways. This concept is fairly easy to understand, but doesn’t quite explain how to implement such a program that takes advantage of all OOP has to offer. However, lets take a simple example to further illustrate this concept. Lets say we are writing a program to model driving a car. Each car is a separate object of course, but these objects are instances of the same class (in the case, a car), but have different properties. Some are fast, some are strong, and some have great gas mileage. Each car, consequently, is composed of many other discrete objects. Like the rear view mirror, or the engine (which in turn could be composed of other objects) and the tires (and of course these each have their own attributes). Then there is the driver of the car which is another object that interacts directly with the car. The Driver tells the car to drive, and the car in turn tells the engine to turn on, and tells the wheels to spin. The Driver doesn’t ever interact with the individual components of a car, but rather the car itself. The car interacts with each individual components. In (very PHP-like) pseudo code, this interaction might look something like

$Honda_Accord =  new Car();
$Honda_Accord->addEngine(new Engine());
//add rest of components
$bob = new Driver();
$bob->Drive($Honda_Accord);

//inside the drive method,
$Honda_Accord->start_engine();
$Honda_Accord->spin_wheels();
//etc..

Encapsulation

This is probably the most widely known but often misunderstood concepts that OOP brings to the table. The basic concept is that of data hiding. Each discrete object in your program has data inside of it, that it hides from the rest of the program. If we consider the example above, each car would have certain properties (like speed, gas mileage, etc.). These properties would only be changed or acted with by the car. The rest of the program cannot (and should not) have access to any of these properties. For example, the driver tells the car to start, but the car is the one that sends the signals to the tires to move. The driver doesn’t (and can’t) interact with each individual wheel.

Encapsulation is often widely misused though. I see misuse in many forms, but the most common are as follows. The programmer may completely forgo encapsulation (For example, he makes all data members public). The programmer also may take it too far (he makes every single data member private, even those that conceptual shouldn’t be). I also see many people doing a very curious thing. They make all (or most) of the classes data members private, but create mutators and accessors for all of them, essentially making them public, but writing a lot more code to do so. For example

class A {
private $some_int;
private $some_string;

public function get_some_int(){ return $this->some_int; }

public function set_some_int($i){ $this->some_int = $i; }

public function get_some_string(){ return $this->some_string; }

public function set_some_string($s){ $this-> some_string = $s; }

}

Now, trying to explain how to correctly use encapsulation is almost impossible, since it can be applied in so many ways. However, I often try to tell my students the following, which has mixed, but predominantly positives results: When deciding what data members to make public, which to make private, and which to make accessors or mutators for, consider the following. If we consider a data member, say int x, how is it going to be used? Is it only ever going to be accessed and modified inside the class. If so make it private. If it will be accessed outside of the class, but you only want to be able to change it inside, then make it a private variable with an accessor (like GetX()). If you are going to be accessing and changing it outside of the class without any restrictions (IE a programmer using this class can set the value of x to any reasonable value) Then make it public. If you want to make it so that the data member can be set and retrieved outside the class, but setting the variable has restrictions (Like x cannot be over 10 or below 0) then make the variable private, and use an accessor and mutator.

Lets take an example. Lets say we are creating a Person class. The name of the person would obviously be private (since no one can change someone’s name but the person) but with an accessor (people can still ask for their name). The amount of cash someone has would again be private, but would have an accessor (someone can ask how much money they have) and a restricted mutator (someone can’t just set the amount of money they have, but a store keeper can ask for a certain amount, or give a certain amount back as change.) The class could look something like:

class Person {
private $name;
private $cash;

public function getName(){ return $this->name; }

public function getCash(){ return $this->cash; }

public function giveChange($c){ $this->cash += $c; }//function to return change back to user

public function pay($price) { $this->cash -= $price; }//function to pay for something

}
<h3>Inheritance</h3>
Inheritance is one of the most commonly misused concepts I see. Sometimes even more than encapsulation (since its a bit easier to understand the implications of it in a conceptual sense, so its much easier to correct past mistakes). However, inheritance is slightly more complex than encapsulation. The basic concept is rather easy to understand. Inheritance in OOP models inheritance in real life fairly closely. You have a Base or Parent object, and you have a Derived or Child object that inherits from it. The child has all the properties that a parent has, and more.

The main problem I see many students and novice programmers trip up on is having children inherit from parents for no apparent reason. For example (and this is a real example) one of my students had a lab recitation to model a car (much like the example above, but much simpler). Cars were composed of Engines, and Wheels and had some basic attributes (like model name and number). This student decided to have the engines and wheels inherit from the car because they were part of the class, and he took this to mean that they had to inherit from cars. This shows two things. One, laziness, and two, a complete misunderstanding of the concept of inheritance.

When deciding on using inheritance, take the following into consideration:

Say we have a system where we have a few different classes. Lets say that these classes all have some sort of similarities. If they do, then I would take these similarities (generally in the form of the same attributes, or the same methods) , move them into a base class, and have my other classes derive from them. Inheritance can be used to avoid having to repeat code. However, inheritance is unnecessary or irrelevant if we have two classes that are quite different from each other, even if they seem to have some similarities. For example, if we are creating a GUI system, we may have a bunch of different shapes. Each shape would have some similar methods and attributes (Like the name of the shape, and a method for drawing the shape). Each shape should derive from some Base shape class. Another example would be a system where we have musicians and a music store. Each musician and each store would have a store of instruments (for example, a musician may have a guitar and drums, and a store may have a whole selection of guitars, basses, drums, etc.) Musicians and stores would also each have names, and other things. However, it really wouldn't make sense for either musicians to inherit from stores, or stores from musicians since each has unique data members that the other doesn't have.

Taking the shapes example, the code may look something like



class Shape { //base shape class
protected $name= "abstract shape";//protected so derived class can access of course

public function draw(){ ... }

}

class Triangle extends Shape {//triangle class that inherits from shape class

private $height;
private $base;

function _construct(){ $this->name = "triangle"; } //constructor to set name of this class to triangle

}

 

If you have any questions, comments or feedback, please let me know in the comments!

public function draw() { ... draw the triangle ... }