• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

531 Good

About ZeroBeat

  • Rank
  1. I have always been interested how companies work, especially game development businesses. My dream job was to work in the financial department of some game development company. As I was growing up, I played around with Delphi Pascal and 3d Studio Max, HTML, but I didn’t really make anything substantial, just really basic stuff... It was just something I did for fun after school/college.   So yeah, I studied Financial Economics in university (with the idea of being an accountant). After, I spent a summer learning C++ and then did Masters in Business Information Systems. During that time I found about this site. It really helped me with some of my projects even though they were not game related.   Afterwards, I realized that I want to make one game. However this “dream” game seemed something impossible for me. I had to become a much more productive and knowledgeable person to be able to make it. (Something between Castle Story and Stonehearth) So I joined my small family business. We needed a website, so I made one. Then I started to sell online (eBay, Amazon, my own site). From time to time, I make my own websites/tools to help me out.     All of this so that I can made my dream game someday. Well it’s been 4.5 years since having my idea. I failed to make my dream game 2 times now. However I did make a complete 2D space shooting game. Now trying to make it as a releasable product.
  2. 1) What was the first programming language you studied? Visual Basic 5 or 6.   2) Did you have any Computer Science background before your first language (ie: boolean algebra, memory organisation, algorithms)? No.   3) The first language you studied was it self-taught, formal instruction, or both? Self taught. I was 10 or 11, my parents bougth me a book I could follow.   4) Was the Computer-Science background self-taught, formal instruction, or both? Mostly self-taught.   5) When you started to study Computer Science did it help your understanding of the language you first learned? Yes.   6) What kind of environment did you first program in (ie: the IDE or text editor, and the OS)? Windows 95/98 or 2000... Not sure what the editor for Visual Basic was called...
  3. Overall I find programming fun. This is something that I always knew I will be doing....It can be really tedious or challenging at times. But after that, it feels very rewarding to complete those tasks!    I learned programming as I wanted to understand how games are made and how game companies work. Its very enjoyable to research different ideas, technologies. Gradually, I starting making small demos to see how scripting, networking, etc. works. It feels really great to create something and to reach a set goal. I don’t find it fun to program for the sake of programming. Like everything I guess, the process is much more rewarding if there is a goal to be reached.   At work, I use my knowledge to make our website and some other tools. As I can see how my contribution has a positive effect on our company, it feels really amazing. To admit, Its probably more "fun" at work as other people are also affected by my hard work. It makes it even more rewarding.
  4. I bought Sam's Teach Yourself C++ in 24 hours. Probably it wasnt the best book..... (It was the only available book in the shop). With it and xoax.net (video tutorials), I was finaly able to compile and run my applications.   I used the lessons to learn how to program and then I would apply my new knowledge by building something small.  As I got more confident, I started making my own text based games. The book became a reference when I got stuck.   Like Kimmi said, its much better to learn something by appling the knowledge to a project. Start small with console based applications to concentrate more on the standard library and the languange.
  5. 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: http://vimeo.com/24715531       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.
  6. 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 .
  7. (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).
  8. 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 . 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   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.
  9. I am tryitng to show the importance of finishing projects. Finishing projects makes a person better designer, not spending large time upfront on design with no project made beforehand.   Thats why I am trying to push you soo much to make a smal game like Josh did. Then to make another. With each new project, not only will the code become better, you will also start to realise why ECS, DDD, OOP...ect is used when developing games. How they help improve the code base and make it more re-usable code.   In a sense its like driving a car. Its possible to imagine what it will be like beforehand. However when you actually start driving, new problems occur. Things were not as they seemed they woud be. Imagination can only take you so far.
  10. 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.   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. Because its like trying to force a solution for an unknown problem. Hint: It doesnt work like that.    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 hehe. Edit: Read this: http://www.gamedev.net/page/resources/_/business/production-and-management/completion-vs-perfection-r3260
  11. 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.     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).     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.     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)
  12. 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. 
  13. Hi, I think one of the main reasons why most plans don’t work is that it’s hard to adapt them to the future. In a way once the plan is written, it automatically becomes outdated. Life is unexpected; it’s not possible to plan for everything. I tried once for a month or so to hobby program before sleep. It didn’t go well. I would go to bed much later than usual, sleeping much less then I should and being ineffective for the whole week.  Some of the things which work for me: - Having monthly targets. On a list of paper I write what I would like to achieve for the next month/ 4 weeks. Once something is done, it gets crossed. Not only can I see the overall picture but it’s great for motivation to see what I have completed.  Saturday is hobby programming but I try during the week if possible. - Using a notebook. I can write what I have done/ will do for each day. Plan my overall day. When unmotivated to work, I would look at past entries to get that extra kick needed to get back to work. - Using motivation triggers such as a movie clip or some video/article/music. Something which resonates with me and makes me get up and work. Eg probably most people feel something when they watch Indie Game The Movie.   Some general pointers: Having realistic/honest expectations of what is achievable in a certain time. Eg sometimes I wish I got more done, yet other things were more important. Hard to accept that.  Yet by filling your days by having more things going on, somehow more things get done. Some challenges/tasks will take much longer than originally thought. If somebody is doing something for the first time, it will take even longer.   Learning to be more disciplined. Removing any distractions so that its easier to concentrate on what you want to actually complete. In a way, it’s probably related to getting in a better lifestyle, eating healthy and doing some exercise. That way the brain is more active, tasks should take less time to complete.   Programming is not always fun. There are some really annoying parts. Getting them done is sometimes really time-consuming. But it feels great afterwards. Some ideas: Maybe rather than starting new projects with new ideas, write them on paper instead. Think starting those projects will be a ‘present’ after finishing the current one/s. Try doing hobby stuff very early in the mornings and or setting aside a whole weekend day. Planning is like a muscle (in my opinion). You get better with practice. Try to experiment, like you said, its a personal thing. You would figure it out :D
  14. (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.
  15. 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 . 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