Jump to content

  • Log In with Google      Sign In   
  • Create Account


how to think like a programmer


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 burnt_casadilla   Members   -  Reputation: 440

Like
0Likes
Like

Posted 17 April 2013 - 10:00 PM

I'm going to be making my own game soon without using tutorials and just using what I know. What I'm having trouble coming up with is the logic of the game. Things like upgrading weapons and towers, how to make ai detect when theres something in their way, things like that. Are there any books or tutorials that help with this kind of thinking while making a game?


If you see a post from me, you can safely assume its C# and XNA :)


Sponsor:

#2 Khatharr   Crossbones+   -  Reputation: 2971

Like
0Likes
Like

Posted 17 April 2013 - 11:31 PM

I'd recommend starting with board games and moving up to simple classics like Pong, Breakout and Space Invaders.
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#3 burnt_casadilla   Members   -  Reputation: 440

Like
0Likes
Like

Posted 18 April 2013 - 12:16 AM

Ive already made Pong, breakout, and space invaders. The logic behind them is easy enough to understand


If you see a post from me, you can safely assume its C# and XNA :)


#4 Khatharr   Crossbones+   -  Reputation: 2971

Like
0Likes
Like

Posted 18 April 2013 - 12:37 AM

Can you be more specific about where you're stuck then?

 

This sounds like analysis paralysis.

 

For AI there are a ton of resources available. It's more or less a decision table that randomly triggers predefined behaviors. More advanced AI just uses increasingly complex selection (by assigning weights to the choices) and simpler actions or a compound system that selects a strategy and then selects an action within that strategy.


Edited by Khatharr, 18 April 2013 - 12:39 AM.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#5 burnt_casadilla   Members   -  Reputation: 440

Like
0Likes
Like

Posted 18 April 2013 - 12:45 AM

Well its really more the things like adding something to an inventory, knowing how to measure where a mouse clicks in 3d space, and things that dont really have a specific answer. Like if you had an inventory, do you use a class? do you use an array list? how do you tell what items are going in an out of your inventory? with a method? a for loop that loops through the inventory? There seem to be multiple solutions to most problems in 3d gaming but I want to learn how to actually apply what ive learned towards a game


If you see a post from me, you can safely assume its C# and XNA :)


#6 JTippetts   Moderators   -  Reputation: 8408

Like
11Likes
Like

Posted 18 April 2013 - 01:22 AM

It's just a matter of breaking things down into a series of small tasks then trying to apply what you know to each task. For example, an inventory. At its heart, an inventory is just a list of items. An array would work well, since most game inventories are fixed size. You would want to encapsulate it into a class, of course, to carefully control the manner in which things are added/removed. When designing an inventory, you would first want to break it down. What kinds of things will the inventory be able to do, and what can be done to an inventory? The obvious things, of course: adding items, removing items, sorting items, displaying inventory contents, etc... Other things such as searching the inventory for a specific item, using an item, hovering over an item to see a description of it, and so forth. This is where design comes in.

It only comes with practice, for the most part. In the beginning, you're probably not going to be very good at it. The first inventory system I wrote was... horrible, to say the least. Riddled with bugs, awful to work with, clunky in the extreme. It looked good in action, but only because you couldn't see the nastiness that lurked underneath. Later attempts built upon what I learned from that first one to make things more elegant and simple.

Key to game development is the term "emergent behavior", which denotes complex behavior that arises from simple rules. That's pretty much what a game is. Or any complex software, for that matter. The trick is to start with the desired behavior and work backwards to the simple rules, the basic building blocks that you need to make it function.

Having a good grasp of design patterns can be extremely beneficial. For example, an inventory system could be elegantly constructed using the MVC pattern. (Model, View, Controller). The inventory array of items would represent the model. It would be a basic, dead-simple fixed-length array of slots, each slot able to hold an item. The view would be the UI representation of an array, the on-screen grid that shows a drawn background with the contents drawn on top. The controller would be the set of methods for interacting with the inventory and for controlling the UI representation of it.

Once you have the details of your model nailed down (1D array? 2D array? Fixed or dynamic length?) then you can start writing the basic methods for the controller. AddItem(), for example, would simply iterate the array and find the first empty slot, then insert the given item into the slot. RemoveItem() could come in various flavors: RemoveItemByName(), RemoveItemAtLocation(), RemoveItemsOfType() etc... whatever the needs of your game. You might write a set of query functions used for searching the inventory: FindItemsOfType(), CountItemsOfType(), CountItems(), FindFirstItemOfType(), and so forth; again, depending on your needs.

Once you've got a good start on your model and controller representations, and you've tested things out to make sure they work, then you might start on your view representation. Don't get fancy at first, just draw the inventory using basic colored boxes. Write a UI class to encapsulate the testing of mouse input against the inventory grid, relaying clicks through to the controller as required.

A left click on the inventory grid, for example, would trigger a method to calculate which slot was clicked, and perform some logic. If the slot was empty and there was an item in hand, then AddItem() would be called to place the in-hand object in the slot. If the slot had an item and the hand was empty, then RemoveItemAt() would be called to remove the item (and the in-hand object updated to this removed object). If both the hand and the slot had an item, then they would be swapped, the in-slot item removed, the in-hand item added, and the newly removed item placed in-hand.

A right click, however, would test to see what slot was clicked then attempt to issue a UseItemAt() call. If the slot was empty or the item in the slot was non-usable, nothing would happen. Otherwise, a message would be passed to the owner of the inventory to attempt to use the item.

As you can see, an inventory would make use mostly of basic array operations, housed within a larger framework. On the top of it, it might seem complex, but once you start breaking it down into smaller tasks you end up with the most basic of array search/sort/insert/remove operations, straight out of a beginner text book. Similarly, other seemingly complex tasks such as AI would also be built up of basic building blocks.

#7 0r0d   Members   -  Reputation: 817

Like
1Likes
Like

Posted 18 April 2013 - 01:27 AM

Well its really more the things like adding something to an inventory, knowing how to measure where a mouse clicks in 3d space, and things that dont really have a specific answer. Like if you had an inventory, do you use a class? do you use an array list? how do you tell what items are going in an out of your inventory? with a method? a for loop that loops through the inventory? There seem to be multiple solutions to most problems in 3d gaming but I want to learn how to actually apply what ive learned towards a game

 

In most cases like what you're talking about there's no right and wrong way, there's only different ways.  Some are better, some worse, but that analysis depends on the specific needs.  We cant help you with that, at least not with the information you've given us.  The best thing to do is write your game.  You'll learn with experience what works and generally how things fit together, so the next time you do it you will already start off with ideas on how to do these things. But the key is to start small.  That way you can finish the game, and finishing is what will give you the experience to do better next time.  Quitting or failing usually will only make you more discouraged.

 

As a more specific answer, and related to "thinking like a programmer", your best option is to do what programmers do for any problem... divide and conquer, simplify, and do general things before you get to the specifics.

 

For example, you want to make a game with lots of characters, lots of weapons, lots of maps, a bunch of different skills and items that can be picked up, etc.  Where to begin?  First you make a single map with no characters.  Then you put one character in it.  Then you give him one weapon.  Then you add one pickup item.  Then you give him one skill.  Then you add multiple skills, then multiple pickups, then multiple weapons, then multiple characters... get the picture?  Start with something simple, the add to it.  As you add code and features you will naturally need to change it, but that's just how it goes... especially when you're never done it before.  Once you'd gone through that several times you'll be able to start writing a new game already taking into account all those things, but for now you dont have the experience.  So, think like a programmer, do what I said above and you'll be fine.


Edited by 0r0d, 18 April 2013 - 01:29 AM.


#8 Norman Barrows   Crossbones+   -  Reputation: 2057

Like
1Likes
Like

Posted 18 April 2013 - 03:23 PM

There seem to be multiple solutions to most problems in 3d gaming

 

and there you have it.

 

for almost anything you want to do in games, there are usually at least half a dozen ways, none of which is optimal for everything.

 

but there are definitely better and worse ways to go about things. much of which is usually game specific.

 

what you'll need to do, is select a game type, then learn how to do the bits and pieces specific to that game type.

 

general algos, approaches, and types of data structures will be recurring themes, but each implementation will be unique.

 

follow a methodology of incremental development. 

 

learn non-game programming skills as needed.

 

if you can't implement a static array flat file database in your sleep, learn to do so before you write an inventory database module.

 

muddling through is no way to run a railroad.

 

i wrote one of every type of app before i started on games. and you really need to know a lot about a lot to do games well.

 

be prepared for the fact that you'll constantly be learning new techniques.  i've been building PC games for 32 years, and still spend as much as 10% of my time in pure research on coding techniques.  if you don't like to learn, you shouldn't be building games.   constant sharpening of the saw is an integral part of the process.


Edited by Norman Barrows, 18 April 2013 - 03:24 PM.

Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#9 Norman Barrows   Crossbones+   -  Reputation: 2057

Like
0Likes
Like

Posted 18 April 2013 - 03:49 PM

Well its really more the things like adding something to an inventory, knowing how to measure where a mouse clicks in 3d space, and things that dont really have a specific answer. Like if you had an inventory, do you use a class? do you use an array list? how do you tell what items are going in an out of your inventory? with a method? a for loop that loops through the inventory? There seem to be multiple solutions to most problems in 3d gaming but I want to learn how to actually apply what ive learned towards a game

 

 

adding something to an inventory is a simple database function.  you'll definitely want to learn how to implement relational databases in whatever data structure you prefer. they are the back end that drives games.

 

3d pick:  us the pickray example code in directx, combined with the ray / geometry intersection test of your choice (from some source). a strong background in 3d math will    help here.       this pattern occurs a lot in games. you need something that does A and B. there's info for doing A, and info for doing B, but you have to hook A up to B yourself.

 

an inventory is a list, IE a flat file database. a static array of structs is the fastest running, easiest to implement, and most memory leak proof way to do it. but some prefer objects.

 

you should already know whats going into and out of inventory, cause you're the one doing it (with code).

 

collision checks will depend on the type of data structures you choose to hold your "world map" info, with collision maps being the absolute fastest.


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#10 Barzai   GDNet+   -  Reputation: 624

Like
0Likes
Like

Posted 18 April 2013 - 07:18 PM

It's just a matter of breaking things down into a series of small tasks then trying to apply what you know to each task.

 

For what it's worth, this is also exactly the same procedure I've used and seen used for any complex system that needs to be built.

 

Building a machine?  You do exactly this.  Your vacuum pump module doesn't know or care what the wheels the system rolls around on are doing, and vice versa.  When I make one, I don't care about the other.

 

Building a production line?  Hopefully the system designers were smart enough to design the system in distinct modules.  Then you simply create stations for building each separate module, or combine them when appropriate.  Sometimes you make sub-assembly stations that get combined into one assembly.  Still, the basic principle of breaking the problem down into digestible sub-components is always there.

 

Heck, even from taking classes, the instructors generally break down the subject matter into sub groups to make it easier to organize the teaching.  Night clubs that operate effectively break the bar into sub stations, and fine tune each employee to optimize their tasks to maximize the flow of alcohol.

 

It works pretty much everywhere, not just in programming.



#11 SnakeM120   Members   -  Reputation: 140

Like
2Likes
Like

Posted 19 April 2013 - 01:23 AM

I'm going to be making my own game soon without using tutorials and just using what I know. What I'm having trouble coming up with is the logic of the game. Things like upgrading weapons and towers, how to make ai detect when theres something in their way, things like that. Are there any books or tutorials that help with this kind of thinking while making a game?

Hm well there are surely many ways how to plan out a game before starting, but my favorite one is surely the UML. You can use the UML to have a graphical view, of the class and actions in them. Point out of which classes you will need for your game. We use for example the Tower Defence, a  very loved game by many. Now what does a Tower Defence need? We surely need a Tower class since there are towers, surely enemies aka the waves that appear, and maybe a upgrade class for some upgrades the towers need. These are just the logical ones for the game you need, now for the needed ones. You need Initialize that handles all the loading of data, a event which handles all input events, loop which handles all the data updates, render which handles all the rendering of anything that  shows up on the screen and cleanup that simply cleans up any resources loaded. These needed ones, i got from the sdltutorials on how to make a tictactoe, if you wish to check out here you go: http://www.sdltutorials.com/sdl-tutorial-basics . Now next after you got all does things we use a Sequenzdiagramm. In there you will produce a graphical display on how the programm handles, like how does the application start? Which class will come first and so on. These are pretty much roughly said the main ones who are needed to think like a programmer while aiming for a game.

 

I do hope i could help you with my ideas and wish you a great day

 

Yours Truly

 

Your friendly programmer :)



#12 Katie   Members   -  Reputation: 1322

Like
3Likes
Like

Posted 19 April 2013 - 06:31 AM

" Like if you had an inventory, do you use a class?"

 

So a useful way to start thinking about this is to do what's called verb-noun analysis. Write some short sentences about things in your world. If you have a thing in your world which has a noun for a name, then it should be a class. It'll then have verbs attached to it, and hence they're methods on it. So; "I want to show the user an INVENTORY. I want the user to be able to SORT their INVENTORY. And that gives you a class Inventory with a sort() method.

 

Eventually you get used to this enough that you can just sort of see the classes without doing the analysis or you can switch to more sophisticated techniques, but it's a good way to get started.



#13 warnexus   Prime Members   -  Reputation: 1410

Like
0Likes
Like

Posted 19 April 2013 - 09:39 AM

I'm going to be making my own game soon without using tutorials and just using what I know. What I'm having trouble coming up with is the logic of the game. Things like upgrading weapons and towers, how to make ai detect when theres something in their way, things like that. Are there any books or tutorials that help with this kind of thinking while making a game?

You can google search on the "ideas" and problems and solutions people ran into when they implemented a feature. The tutorials are out there- Youtube videos, websites, forums. There is a bunch. If you never made a game before but have background in programming experience, you can search for the ChernoProject on youtube. It is 2d game programming tutorials. No book or one tutorial by someone gets the job done. You most certainly need to search everywhere and put the pieces you need and found together.

 

How to think like a programmer. Grab a pencil and paper and start designing. A good design on paper is laid out nicely for the human mind to keep track of the pieces of a larger program and features. Design changes but write a small design, figure out what you know and apply. If you do not know just google search. Google is your friend.

 

If it is a bug in a feature. Read the last paragraph and trace through where the bug lies in the code. Question what, where, when, why and how is it happening. The 4 W's and 1 H does wonders.

 

Learn to not give up. You only improve if you persevere. Learn to finish a project and say "I am proud I completed what I wanted in the game."


Edited by warnexus, 19 April 2013 - 09:44 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS