• 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.

landagen

Members
  • Content count

    191
  • Joined

  • Last visited

Community Reputation

376 Neutral

About landagen

  • Rank
    Member
  1. I am not sure why you would ever want to do this.  It is like building a car with a brake pedal, but then instead of braking when you press it, the car's check engine light comes on as you barrel through a busy intersection. 
  2. I think if you evalute your project closely, you should be able to determine what is best to start with.  Making a game is an iterative process.  It's not like you tackle the fighting system and then move on and never touch it again. You will visit and revisit that piece.  What is next for you?  What can you do that does not have any missing dependencies?  What are some of the biggest questions that need to be answered?  Some questions require experimentation to answer.  If that is the case, then start experimenting as soon as you can so that those questions can be answered.  Always try to find the shortest and clearest route to the destination you are trying to acheive.
  3. I agree that the classifieds is certainly not where I would put it.  I more mean the replacement to the Help Wanted forums is the classifieds and that it is lacking in what I believe is important.  Not to say that the classifieds should be morphed into what I was imagining.  I am glad to hear that there is interest in doing something like that and I hope it comes sooner rather than later.  I believe it can really spur a sense of community here.  The recent articles are definitely a good start to increasing game development information and I hope that it continues that way.   
  4. I don't think articles and "source code repository" are mutually exclusive.  As a matter of fact, I was imagining they would work together.  I just don't want to have to copy and paste code and put it all back together in some files from articles.  Plus typically, articles are only going to be written with one language and it is doubtful someone will go back and convert the code to another language.   A) As I mentioned, have either multiple repositories (one for each language) or have a folder for each language.  I would imagine that there would be people who would duplicate solutions across multiple languages depending on their language of choice so I don't think that would be a problem.   B)  As far as who is in charge of this source code repository I would do something like the Crossbones group that was recently created.  Just get people to volunteer and then eliminate those who are not doing a good job.  Let everyone contribute, but just have a group to review the contributions and commit them.    C)  I don't think anyone can answer that.  How did they answer "Do they have time to write articles?".  You just need to try and see what happens.  What is the worst case scenario?  You had to setup a repository and some permissions and it just sits idle.  Most likely though you will have a repository of solutions that people can study, adapt, and integrate into their own projects.   D)  If you are talking about the engine part, then I would say that would have to be investigated to see if there would be any type of benefit.  There may not be.  But I would like to see a simplified engine that doesn't have all of the latest features that is just designed to be kind of a learner engine.  It is designed to learn the concepts and pieces of how an engine can be put together following some emerging and standard concepts.  It should be simple and straightforward providing a lot of code documentation.  Articles themselves can link to the code repository to show an example.  As far as the other code samples/small solutions it would be different because frameworks are all about being totally encompassing.  There are very few frameworks that are out there that are just there to show a certain concept.  Most frameworks and engines are trying to be feature complete and have been tuned for various reasons.  Typically they are also not well documented and there is no articles associated with the different concepts that they implemented.  There is probably no articles on how the SceneManager in Ogre was developed and how it works and why they made the decisions they did.  It is also surrounded by a million other bits of code that someone has to dig through and understand just to understand the SceneManager concept.    E)  Who is to say the recent article writing is going to live long?  Does that mean they should not try?  Again, I believe the repository should be linked to by the articles and that they should complement each other.  I don't believe an article is the only place to keep code snippets as they are doing currently.  I mean look at CodeProject.com.  They have code in the article, but they also include a download of the source code for the concept they covered. 
  5. Before it was changed, one of my favorite forums to visit was the help wanted.  I loved to see new ideas being posted and more importantly the feedback people gave.  I also liked to see what kind of success they were having in recruiting or what kinds of questions people have.  With the new system, I see none of that.  People post into what appears to be empty space.  It is like announcing your idea to an empty room.  No reaction and no feedback.  When I heard GDNet was developing a new system I was excited.  I started picturing there would be a place to put your project.  You would have a blog about your project and people could watch and stay up to date with their favorite projects even if they could not contribute.  I was imagining that having a project would have community involvement.  You could see how many people were following your project and maybe that would provide some needed motivation.  You as the project owner could post images showcasing what work you have accomplished and blog about problems you have run into.  The community could see who was actively involved in certain projects.  Maybe there could even be a sort of resume about past projects you have been involved with giving you a sort of reputation when it comes to your work ethic on these projects.  I would love to see these kinds of things because it is really encouraging and really gives a sense of community involvement.  Is there any plans for something like this?
  6. What about having an official source code repository.  Something that includes a multitude of example projects showing how to do certain things such as creating a directx or opengl window or an example input class or a starter entity-component framework.  Code should be well written, straightforward and well documented.  It should also have detailed information on getting setup on someone's machine.  The goal would be to give gamedev people a great starting point and to give excellent examples on new concepts.  All of these articles that are being written could have a place in the code repository so that someone could access the code.  You could even have a community engine that people could contribute to.  Hopefully with even community assets that could be freely used for things such as temporary placeholders or to show the functionality of say an animation system that has been added to the official source code repository.  The source code repository could be broken up by language or even have separate repositories for different languages. 
  7. Okay.  That makes sense.  So for performance critical systems avoid the iterating through entities over and over again while processing them.  Instead, opt to synchronize with an optimized format for that system and use that data instead.  
  8.   Could you elaborate on this?  Are you saying that the ID in the component would essentially point to the data that is owned by another system (aka the physics system or the rendering system) and so for anyone to request data specific to one of those systems they would query that system by the ID in the component? 
  9. Thanks Juliean, this helps a lot.  Could you give some examples of components so that I can have a better understanding of the scope of a component.  I understood it to be like a position component, or a mass component, etc.  Basically you would group data in your components in a way that fits your systems.  For instance, position would be in a component by itself because it is used by the render system and the physics system, but other types of data only make sense together such as material data so it may be all contained in one component.  Another question I have is what is an ideal amount of components on average in an entity system.  I can see the trade-off of flexibility versus performance, but where is the sweet spot?  
  10. I have recently read the Entity-Component article on here and I got really interested in the design.  It sounds great.  Functionality through property definitions.  I have been waiting for the followup article about implementation, but it has not come yet.  I have been reading and thinking about my own implementation and have a few questions.  First, I want to start off with my assumptions/design.   1.  All components inherit from a base component class that contains some pure virtual functions to be overwritten. 2.  Components contain only data and do not directly have functionality. 3.  All entities will be kept in a single container as the master list of entities. 4.  Entities are a class that can contain one or more components. 5.  A system can query the master list looking for entities that contain all required components.  Once it finds one, it will then typically reference that entity by an ID number, not a pointer     Some of my design/assumptions may already be drifting away from the concept.  I am trying to stay close to the concept because I feel that if I drift away from the component, then I may end up running into the snags the design was supposed to prevent.  So without further ado, here are my questions:   1.  How to provide custom functionality for entities that contain the exact same components.  For instance, I may want to have different AI routines for different entities.  My thought was to have a component that is a functor to the particular AI routine I would want to run.  That would be a required component in order for the AI system to find that entity 2.  How do most people deal with changes to the component list?  Do they use the observer pattern to inform systems when an entity changes or does the system query the master list every time to find the entities that match its criteria.  The observer pattern is the way I was thinking. 3.  How do you handle shared components.  An example would be several entities using the same material.  My thought was to just have a component that contains a shared_ptr to the material.    4.  Is it okay to have some inheritance at the component level or would this break the design?  Based on what I know, I can't imagine it would break the design.  I wanted for instance my graphics system to be able to find all entities that contain a VertexBuffer component, but I also want my material system to be looking for a particular type of VertexBuffer component (say one that provides texels).      5.  My understanding is that most systems contain a reference to an entity by entity ID and not by pointer.  Why is that?  Is it common for the pointer to change, but the ID to remain the same?  If so, what scenarios would that occur in?  Does constant lookup not cause performance issues?  Also, any articles that go into some specifics about an Entity-Component system would be very helpful.  Thanks. 
  11. In 2D it may not be as complicated.  That does help.  I presume you are in space so this will also help.  The general steps to solving a physics problem is this:   1.  Identify all forces and velocities (in vector form) 2.  Determine how to apply those forces to your object 3.  Sum the forces up in each direction.  Any extra force components on an object get translated into acceleration based on mass.    If you have to deal with impact forces, that can get a little more complicated.  You will have to read and learn each of the individual equations you will need yourself because it is too much material to cover in a forum. 
  12. Hide it through obscurity.  First off, people won't even know to be looking fro an Easter egg unless you tell them.  And second, there is typically over a gig of data in a large game so your Easter egg takes up only a small portion of that.  Just leave as few clues as possible that there is an Easter egg in there.
  13. I don't think the OP was asking for advice on whether or not to start over (he seems to have already decided on that), but rather which language to start over in.  To me, languages are like print versus cursive writing.  They are the same thing, they just look different.  Pick whichever one you want.  Java is going to be closer to the syntax of c++.  If that is a plus for you, then pick Java, otherwise if you fancy the syntax of Python then go for it.  Programming principles for most languages are going to be the same types of challenges in any language.  That is where programming gets hard so eventually you are probably going to run into the same problems you are running into in another language as you are currently running into in c++, it is just going to take you longer to get there.  Although, I will say the syntax of c++ is more complicated than most languages because it has so much more flexibility.