Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


ZeroBeat

Member Since 27 Oct 2011
Offline Last Active Oct 29 2014 08:14 AM

#5130072 How to overcome biggest hurdle - Motivation?

Posted by ZeroBeat on 09 February 2014 - 08:01 AM

Motivation is a very personal thing and when you do something for the fist time its always the harderst!

Also I think that disciple is important when programming even if a bit overlooked when programming is a hobby....

This article should be quite relevant: http://www.gamedev.net/page/resources/_/business/production-and-management/overcoming-procrastination-r3261

 

By trying to understand yourself and what makes you tick, its possible to improve yourself.

For example, scratching done tasks gives you motivation.

So writing what you need to do and trying to get more things off the list would make you feel like there is some progress being done.

Hopefully this confidence boost will feed it self so that you work more.

 

By knowing what makes you tick, such as watching something or listening to some music, (hopefully) you can pick yourself up when you feel low and get something done.

 

Also like others before have said, having a list of pre-defined tasks helps a lot. I guess its because the problem(s) that need to be solved are already set. So rather than spending 10/20 minutes thinking what to do, I can straight away get working. More gets done = more happiness = more motivation to continue.

 

Here is a nice video which kinda picks some important parts:

 

 

 

edit:

Failure, even if its demotivating is very important. Generally humans learn by trying things out and experiencing them. So even if you tried your best on a project and it didn't work out: The architecture was awful.... it took you ages to add new parts to the project.... The main part is that you worked on it and (hopefully) tried your best.

 

Its not easy to realise how much you will have learned from the experience. So that next time when you try to do this, you will have an idea how to make it work better. Maybe even you will try to apply the newly learned lessons to the project and re-factor it and cantinue until the next problem.


Hence why, starting small and progressively working on larger projects is preferred.




#5127924 How much planning do game programmer before writing a single line of code and...

Posted by ZeroBeat on 01 February 2014 - 05:09 AM

Doing something for the first time is always the hardest.

Hence no amount of planning can trully prepare the developer for a solution to the problem. 

 

Planing/Design is a very subjective thing.
Sometimes just writing prototype code to see if a design works, can lead to understanding the problem better. 

Rather than having talks with people of what could be and what not.

 

Sometimes there will be a lead designer/programmer who will decide how things will work.....

Some people are very visual, some are less.. so some tools for planning will not be equally effective to get the point accross the whole team.

 

Its really dependents on the team of individuals and how their work well together.  Once one member wrote a design in psuedo code and I just expanded it

while he was expaining to me what he wanted the code to do.

 

Sometimes a whole task is given to an individual with pre-defined list of tasks the code needs to do. eg write the whole MySQL code to get the data from a database.

 

I guess what I am trying to say is, as soon as possible try to get some experiance working with other people and you will understand smile.png.




#5110262 Hours per week

Posted by ZeroBeat on 18 November 2013 - 12:52 PM

(Not games) Somewhat professionally - from 0 to 30/60 hours a week. It depends on what project I am doing or upgrading. Mostly web based.

Games related, from 2 hours to 30ish. Before I would spend my hobby time on learning and experimenting with technologies/designs like OpenGL, Lua for scripting.

I have made 2/3 small game demos (to apply what I am learning ). Currently making my first full game (just a small 2D space shooter).




#5080719 Data Driven Design: Part 2

Posted by ZeroBeat on 26 July 2013 - 06:42 AM

Hehe, you have a very interesting idea for simple.

With that analogy, I was trying to say that, imagination(theory) can only take you soo far. Practice is more important as it shows how stuff really is...Too much time spend on theory is not good (like in this case) as people generally learn by doing. Sorry, I am really bad at explaining things smile.png.

The other things you said about how to do the small projects and advance, I can get behind that. Just how to do it bothers me.

When you have developed something, don't you get a feeling like: I could have done X differently. Maybe by using Y it would have been a better idea. If I do Z next time not W, things could work out better. Listen to your gut feelings and try new ideas for your next project/s. Experiment.

Unfortunately there will not be always somebody to help along this all the time.

 

GameDev.net practicies a bit of tough love. Hehe. I am sure we are all just trying to help biggrin.png

 

I am quite positive that if you try to make the engine now. For one it will take you very very long time. As you said, you are not sure yet how systems will fit together. It will be such a massive project. There will be a lot of new things to learn. Learning new things generally takes alot more time. It may be soo hard, that I am quite sure that you would give up. There will be massive revisions as well. As you learn more concepts and implement more stuff, the want to revisit and improve old parts will be quite high too...

If you actually finish the engine and try to use it, you would probably realise that its over engineered and not useful at all.

 

(I actually wished you realised this yourself, rather than spelling it out so plainly:)

Now imagine that you spend the same amount of time by making games. The goal is still the same: 2D tile generic engine. 

You just made you first game. Took you a day or two. Yes, its not the prettiest code. However you made it. Now you have some idea how to handle game state, collision, rendering, input. How they all connect together to make a complete experience.

case MainMenu:
  PlayButton.Update()
  PlayButton.Draw()
  ExitButton.Update()
  ExitButton.Draw()
break;
case GamePlay:
 Player.Update()
 Enemy.Update()
 CheckCollisions(Player, Enemy) 
 Player.Draw()
 Enemy.Draw()

Yes, the above is stupid simple, However every game has a gameloop, render, input, physics, ai. 

Now you are starting your second game. You realise that the above code is not very reusable. What if you wanted to have more enemies?  We have an actual problem to solve. You may search online/ask teatchers and get some advices.  Then you actually try them out. See what works for the game you are making. There is no right/wrong here. If it works great.

 

Maybe by your third game your entity hierarchy is a monster like this:

Basic
 - Rendable
 - Movable
 - Collidable
 - Flying
 - Boss
 - MegaBoss
 - SuperDupperMegaBoss 

On your next project, you realise that the cool MegaBoss cant really be adapted to your new project. As the game was developed, you realised that maybe the entities or the code will not be very reusable next time. Hell it was a bit hard to work on it as it was, such a large hierarchy. You have heard of ECS which can actually fix this problem. 

This in turn helps you appreciate what ECS is about. So you make a smaller game/project or convert an existing one to use components. Small = less things to worry about

 

Now the next project uses the ECS developed beforehand.

Given the experience of using your own system, you realise that some parts can be improved. So you go and do that before starting next project.

Maybe next time, scripting will be added.

On the next game, even more parts are stored in file. eg the game name, window measurements,

Because each new concept is tackled seperately, rather than simultaniously, it would be much more fun(motivating) to program and much less frustrating.

 

Not only will you have finished products to show (which will feel great and motivtional). With each game your base framework will improve more and more until its the 2D generic tile engine you wish to make.

 

I really hope this actually explains it finally. biggrin.png




#5080683 Data Driven Design: Part 2

Posted by ZeroBeat on 26 July 2013 - 02:14 AM

I've already made small applications with SFML to just render a sprite on screen, handle basic WASD movement (not pretty Lol) and such smaller things.

Now build it up. Eg:

- Draw a box on the screen. Make it move. Add another box (enemy). Check for collision.

- Next show that the boxes have collided somehow on the screen (eg a new box is drawn on the screen).

- Add some logic. Add sound. Add game states (main menu, levels).

Congrats you just made you first game.

(I would seriously put a time limit like 24/48 hours to finish it, even less. That way I hope your design paralysis wouldnt get in the way of doing stuff.)

 

It can be something like a 2D shooter with one level where you shoot at a incoming wave of enemies. It can be pong. Whatever it is, it needs to have sound, game states (main menu, one level), rendering, input, (hopefully collision), AI. Then make something else, then again.

 

That is the only way to see/experiance/understand game design. You will see how all the different aspects are connected together to make a game. As you make more small games you will start to understand why more advanced paradigms are needed and what problems they solve.  As you experience increases you will be able to actually make better designs as you will start to forsee upcoming problems using your past projects as a starting point.

 

It's all Logic after all. It must be logically possible to dechipher this pattern/philosophy/methodology one bit at a time until I got a certain whole :3

The pattern is loading data from files so less parts are hard coded. However without understanding the need for it, its pretty useless. The understanding part comes from experience.

I can understand this way of developing and that is also what I aim to do (Currently). I just can't really get my head around the actual implementation in code. That's all.

Because its like trying to force a solution for an unknown problem. Hint: It doesnt work like that. 

 

I have already been programming for 2 or 3 years. Mainly in Java. Learned C# and have been using it for about a years time. I am a computer science student and finish my profession bachelor in January. I am not trying to use the expressions losely :/. And yes you learn by doing. But with everything you do you'd most likely want to make less mistakes and get more actual results, right? Yes, you learn from making mistakes. But making less mistakes in favour of better results is beneficial right? That's at least why I read up on how to program in the first place so that I could understand what I was doing and then I also had an easier time solving my problems.

Maybe this is the reason for your Design Paralisys. Some of my friends have the same problem coming from academia. They spend soo much time on design, wanting to build their first game. It will be perfect they say, telling me how these systems will fix all the problems. Guess what? When they actually start implementing them, they realise how worthless the designs are. What looks great on paper doesnt look so good when you start implementing it. On top, their systems are soo complicated, it actually makes things worse. Most of the time they cant even implement them hehe. So those friends start small/simple, increasing the complexity with each new game.

 

Dont worry so much about making mistakes, think about them as learning experiences. As I said End result is king here.

 

Like everybody is saying stop thinking and start doing smile.png hehe.

Edit: Read this: http://www.gamedev.net/page/resources/_/business/production-and-management/completion-vs-perfection-r3260




#5080495 Data Driven Design: Part 2

Posted by ZeroBeat on 25 July 2013 - 11:34 AM

Hi, I still think you are over thinking/overcomplicating things.

 

What Josh Petrie advised on the other post was to try and finish a small complete game/s without worrying so much on the data driven design and ECS. Just concentrate on making the game. Like having a main menu, gameplay, sound, input and rendering. eg Pong,

 

After you have done this very small game, you would have learned a lot. Plus it would feel really great to finish something. My advice set a deadline of 48 hours to make it.  

As the game is done it will have

 - some way to render 2D sprites

 - some way to play sound

 - some way to hold entity information

 - collision detection code

Hopefully the time constraint will help to make a game rather than thinking about class design. The code will be quite "ugly/hacked in/not very reusable/" in general. The entities would be defined in code and may have their own update and draw/play sound functions..Probably during development, ideas would have emerged like why not store the entity template in a file or use a component entity system to make things more reusable? Write these thoughts on paper to remember for the next projects.


As you start your second (again small project), some parts could/should be done better given the previous learning experience.

Eg. Maybe this time, it would be better to let the user set the game window's width/height, and sound from a file. 

Also it could be a good idea to store entity information for each game state in a file so that its easier to play around/experiment during development. 


For example something like MainMenu.txt: (can be XML or JSON)

//entity type       //X and Y positions

buttonplay         100 100

buttonoptions    100 200

buttonexit           100 300

 

levelone.txt:

enemy           100, 200

boss              800, 300

You would then have a factory system which will read the information from the files and generate the right entities. The game just became even more data driven :)


On the next project, you can take a step further and have the entity template information stored in files rather than hard coded.

And so on until things become even more generic. As you start 3/4th project, probably you would be able to re-use quite alot of your previous code.

Slowly you will build up a robust re-usable set of libraries to draw entities, manage them, play sound, have physics <<< ie you have a game engine

Additionally, making a bit larger games will become easier as you already have the tools/experience needed.

You are on your way to make ever better data driven engine with games to prove that its functional.

 

Probably you would also be thinking how to implement an entity component system (which you already trying to design hehe)

 

Like BloodyEpi said, there is no set pattern for Entity Component Systems. There are so many implementations and ways of doing it.... Generally there seems to be two thoughts:

1 - Components just hold data and have systems which operate on them.

2 - Components hold their own logic. Systems may store the components/call their functions.


End result is king here. If it works, it works. Nobody will really care when they play the game so don’t worry if its not the best thing in the world. 

Implement it and see if it works. If it doesn’t try to improve it.

 


In DDD you want to update things in pairs rather than in sequence. So instead of doing ABC, ABC, ABC which will have a horrible impact on performance, you do AAA, BBB, CCC and so on.

 

By updating systems by type  (AAA..., BBB....., CCC.....) its possible to use parallelism and improve performance. Eg Physics System divides 2000 components in 5 threads. Each thread updates 400 components. Overall taking less time. Also its cache friendly (should be faster).

 


Dungeon Siege? Made his game and explained in great detail some of the thoughts and considerations that went through the design process. Was also inspired by a few other articles to allow very minimal form of OOP.

 

What component systems allow is for minimal entity hierarchy by inheritance. Rather than using aggregation to develop entities, composition is used. This in turn keeps the entities more lean (as they have components which they need only) rather than extra blob which appears in deep inheritance hierarchy.

Overall the code base is easier to maintain, more reusable and adaptive to changes.  

 


The system is build up of Entities which consist of Components, each defining a behaviour or attribute that the entity can have.

It may be better to split behaviour and attributes. By having some components with logic while others not, it can become confusing over time what should go where... 

Think Single Responsibility Principle.

 

Some thoughts about ECS:

- Some systems will have no components. For example some of the systems which define the gameplay will just have some logic in them to check for game rules.

- How will you handle communication between components (if they have logic)  and systems?

- Also some components will need data from other components. How will they access it?

 

ECS are quite a complex beast to tackle hehe. Truthfully, the best way to get an idea if the system makes sense is to implement it. One great approach (imho) is to convert some small existing game/prototype from a hierarchy design to component based one. 

 

(hope this is actually useful, off to work again hehe)




#5077222 Where to start with program develpoing?

Posted by ZeroBeat on 12 July 2013 - 05:00 PM

Hi, here is the link to one of the best advices: http://www.gamefromscratch.com/post/2011/08/04/I-want-to-be-a-game-developer.aspx

 

(Not sure how much programming knowledge you have...assuming you have no knowledge)

Start by making basic text based applications. That way, its easier to understand concepts and new ideas. Initially programming can be quite frustrating. By just focusing on the language the (already) large learning curve of C++ would be reduced a bit. Try to create small programs/samples with each new lesson learned. This way you can test your new knowledge and see what works/or not and why.

 

When you feel ready you can go with basic 2D games like pong, breakout using something like SDL/SFML. There will be alot of new concepts to learn such as the gameloop, collision detection, adding music, and networking. SDL or SFML make things easier, allowing the user to concentrate on the game development.  

 

Next step then could be to use more low level to Direct3D/OpenGL for graphics and using 3D. (Assuming you are aiming for that).

 

During that time, try Blender (free) or 3D studio max. There are alot of resources online how to use them. The information that you learn about 3D modelling and animation can always come in use. Plus its a good break from programming hehe.

 

One of the main problems with programming is that it can be quite frustrating initially and many things dont initially make much sense until you get used to how the language works. Thats particularly true when using C++ (imho).  Stick to it and get through that barrier.

There is a reason why most people here recommend Python or C# for first language.

 

Edit: Something to keep in mind. There is a new standart for C++: C++11. It makes using C++ a bit easier. 




#5072568 Want to build a game

Posted by ZeroBeat on 24 June 2013 - 02:16 PM

(I just saw a video on youtube how it plays).

Given that in the OP it says that you have some experiance with web applications, this type of game shouldnt be too hard. Definetly doable by one person.  

 

I guess, a very basic prototype:

- there will be a database which will store player information. (knowledge in MySQL/php)

- some kind of timer system, to know when a mission has ended. ( probably done in javascript and/or php)

- able to give/store rewards to the player. (php/MySQL)

- able to store game character information (MySQL)

- GUI ( HTML/CSS)

 

Once you figure out how these things work, think hard about the game design. That should help you figure out the database design. In my opinion that will be the most crucial thing in a game like this.

 

How complex/complete of a game you woul like to make will ulimately decide if its actually doable or not. Also you if you want to accept payments, have 1000s of people. Things can get very expensive to run too.




#5071053 I Need Help Getting Started

Posted by ZeroBeat on 19 June 2013 - 02:31 AM

I am not sure if there is a tutorial which will teach you how to make such a game...  Mostly programming is about problem solving right? Try to isolate different problems and then break them down into smaller workable parts. And practice, practice and practice some more.

 

Eg.  If I dont understand how classes work. Then I would go online/find a book to learn more about them. Eg I would begin at http://www.cplusplus.com/doc/tutorial/classes/

After to test my newly founded knowledge, I would make a couple of small programs. Just to play around with the new concepts.

This way, they would stick in my head and hopefully I would be able to use them in a proper project.

If I dont understand something, I would try to search online/ read more to find the needed information.

 

To make the RPG game, I would need to be able to have/know (from the top of my head):

 - Render the bitmaps on the screen. ( In the OP it says you used Allegro 5, can use it again. Less things to learn)

 - Some kind of combat system.

 - map

 - inventory

 - store character, enemy information

 - save/load

 

You could try to make the game first as a console application, just text. That way it would be simpler to design and you can concentrate on figuring how things work.

Later you could transform the project in 2D/3D. I wouldn't start yet using OpenGL/D3D as the complicate things a bit more.

 

It seems you are trying to take on too many things at the same time and getting lost/frustrated because of that. So put aside this game for now and make smaller projects like Pong, Tic-tac-toe. The design,rules and how these games play out is well know and documented. Eg pong has 2 paddles and a ball.

These two games can be even done in a single main.cpp without any classes. When you get them finished you would feel really good biggrin.png. Maybe after this, you could try to write classes and make the code cleaner easier to deal with.

 

By the end you would probably have your own class to manage windows, some kind of render system, a class to store entity informaion. This should give you the minimum neccessary information to make the RPG. Plus you would get more used to programming. It will become easier to solve whatever challenges come out as you have more practice.

 

Dont worry so much about the different libraries. I dont know anybody who knows these things by heart. Thats why allegro, sdl, opengl, etc have documentation. When you dont know something, can look that up or search online.

 

Before going online to search how to do something, try to solve the problem from what you know. If its not working after a while, THEN go online and seach for a solution.

 

Good luck, and get coding hehe smile.png




#5069333 To make a voxel engine?

Posted by ZeroBeat on 13 June 2013 - 01:55 AM

Probably a good start would be to look at: http://www.youtube.com/user/AlwaysGeeky?feature=watch

Its a youtube series of somebody making a voxel engine/ game .

 

Then there is : https://sites.google.com/site/letsmakeavoxelengine/home/basic-block-rendering

Its a series of articles with a bit of code.

 

It seems that you can:

 

- use C# with a graphics wrapper like SlimDX. No new language to learn so hopefully it would be faster to write code and see progress.

 

- use C++ with DirectX 11/OpenGL/Some graphics wrapper. Probably the performance could be better (if you know what you are doing) but it would initially be quite frustrating. Plus more things to learn at the same time =  more frustrating / easier to give up.

 

To start a voxel engine, just render a 3D cube. Then render more of them. Figure out how to store them and build it up from there.

 

A good idea would be to have some kind of game in mind while you build the voxel engine. This gives a couple of benefits:

- No bloated code. You would know exactly the minimum requirements of the engine and what it should do. Faster developement time.

- Gives you something to work towards. Easier to see the progress you are making = more motivation to continue.

- You will be making progress on the game simultaneously  which makes the engine applicable. Extra motivation. Hopefully speeds up development.

 

(In my opinion just start making the game. The engine will be the reusable parts of the game. Just making an engine with no real purpuse can lead to long development with messy code. When you actually try to use it to make something, you would probably have build too complex of a solution.)

 

The most important thing is to start. Just get coding. When you get to a specific problem, try to see if you can figure it out. If not working after a while, THEN look for resources how to fix it.

 

Good luck




#5040061 Lua scripting

Posted by ZeroBeat on 06 March 2013 - 11:43 AM

If the game code is structured right, Lua would allow rapid prototyping. Imagine that there is no compile button.

This makes it possible to be in a highly productive state for longer periods of time. Rather than making a change and then wait to re-compile. The user

just makes a change and re - run the game. 

 

Embeding Lua is not the hardest thing in the world.

Here is one good example tutorial (in my opinion): http://forums.tigsource.com/index.php?topic=22524.0

 

If you think that scripting is needed to fulfill a certain goal in your game, go for it. If it doesnt work right, at the very least, you would have learned something new hehe.




#5040047 Staying motivated.

Posted by ZeroBeat on 06 March 2013 - 11:12 AM

I agree with 3Ddreamer.  Something else which needs to be considered is this:

 

Intially I think programming can be a bit overwhelming. I also took breaks from time to time.

I guess there is this gap that needs to be 'jumped' through by sheer determination. In some languages this game is a bit larger than in other I guess.

 

Disapline, value of programming (to the programer) and probably many other important things are learned during that 'jump'.

Rather than going for a sprint, why not try to program or do something small for 30min to 1hour everyday. Keeping things simple and small.

Then slowly try to build progressively more complex programs. This way hopefully you will build a small re-usable code base to take care of the basic things (eg window creation ) so that you can concentrate on the more important part.

 

Read this thread too for ideas about keeping the motivation going: http://www.gamedev.net/topic/639171-need-some-motivation

 

Balance is important. Like playing a game 24/7, it does not lead to good things in the long run.




#5039028 Allowing players to create procedures in strategy games

Posted by ZeroBeat on 04 March 2013 - 07:37 AM

In theory making everything manage itself sound like fun. It would be really cool to set up what your units do and then just watch it happen in theory.

 

If there is no user input required after that....wouldnt it make the whole game more like a movie?

The player wouldnt really be as attached to his/her units. Decisions wouldn really matter as much.

 

1) Imagine if the player told his units to build him a city. The units will make a city while the player concentrates on something else.

2) Now imagine if the player places the buidling in the city, makes it look how he wants it to look.

 

If some enemy attacks that newly build city, which city do you think will bring more emotion from the player?

 

Automation is great but I think every game needs to find its own balance. Probably that balance would depend on the strategic level of the game.

 

Maybe some of the more repetetive things can be completley removed to make the more important parts shine more? Ie find the core of the game and only add things which actually make the experiance better, not add unnesseccary stuff.




#5036093 Starting a game

Posted by ZeroBeat on 24 February 2013 - 08:04 AM

Hi,

 

I am not really sure how experianced you are but this is one way:

- I would start by getting an image on the screen. Then moving it arround. Next get some enemies in. Get some basic collision in. and so on.

Ie build the game in small concrete steps. 

Later as things work, some refactoring may be needed but at least the game works. Much better than being stuck in design stage and pre-mature optimisation with nothing to show.

 

Here is a really infomative guide about different ways to implement a 2D platformer: http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/

 

Also there is the lazyfoo  tutorials which can help if you are wondering how to do something in SDL. here is the link: http://lazyfoo.net/SDL_tutorials/index.php




#5035374 Need some motivation

Posted by ZeroBeat on 22 February 2013 - 06:26 AM

As people above have mentioned, being motivated 24/7 in not really realistic. 

There are ways to keep oneself motivated by knowing how he/she reacts to things. Eg some poster or a short video somehow motivates you to work more, be more.

So by sourranding yourself by things that are motivational to you, the productivity period can be increased.

Also being more disaplined as Haps mentions cant hurt.

 

Something which may help is asking yourself: "What have I done today?" Something that you are proud about. Maybe it was designing something new for a game or maybe

doing some research for a project.

 

This is a great video and the speaker talks a bit about motivation : http://www.gdcvault.com/play/1014394/1-Hour-Video-Game

 

In the end though, having a balance is very important or you will burn out.

It may feel great to work 4/5 months at your best. But it doesnt feel so good when the next 8 months are just wasted away. hehe.






PARTNERS