Jump to content
  • Advertisement

RPTD

Member
  • Content Count

    803
  • Joined

  • Last visited

Community Reputation

353 Neutral

About RPTD

  • Rank
    Advanced Member

Personal Information

Social

  • Twitter
    EpsylonGame

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. RPTD

    So You Want to be a Game Developer?

    It really starts to get on my nerves if people go around and praise Unity as the "gods send thing" and calling all people idiots who can't stand that mess of an engine. And in the next sentence they say how "annoying" and "troublesome" Unity is but "you can work around it". Sure you can spend lots of time to fight against an engine but that's what I call wasting life-time. Or to use an analogy: Sure you push around a cart with square wheels and find ways to somehow make it a tad bit less obnoxious but instead you could go and put together a car with round wheels and actually start making progress.
  2. I'm working with KDevelop all the time. While it had lots of problems in the past it came a long way. Definitely working well nowadays. EDIT: And yes, KDevelop shows project directory structure. Basically the project file (*.kdev4) defines the root path and some filtering for convenience (like filtering out build directories, doc directories and such). That and the usual class tree listing etc etc.
  3. This is the reason why I went beyond the concept of trying to make reusable modules for compiling into projects. These end up being rewritten for individual projects. Then they start breaking other projects and become incompatible. Then you have again tons of different "version" of the same game engine and you end up with no gain at all. What I did is examine various game components and identifying what "building units" they actually use. These units are large enough to be optimized by modules and small enough to build game concepts. As I see it most game concepts can be broken down into these units. What I have then are independent larger modules (like graphics, physics, input to name a few) which anybody outside the game engine can create himself. These larger modules are compatible and interchangeable even at runtime. You can pause the game engine, switch to a different graphic module for example, and continue where you left off. I am convinced this is the kind of future proof game engine concept many are looking for. It goes beyond your concept though.
  4. Taking another step to the first release with improved Audio System and Behavior Elements. View the full article
  5. RPTD

    Vulkan? OpenGL? What........?

    I guess then I need to hurry up putting those finishing touches in place
  6. RPTD

    Vulkan? OpenGL? What........?

    Huh? No engine with 64bit coordinates CPU side? I hardly belief this. I do this with my game engine and I don't think I'm unique in that department.
  7. RPTD

    A Simple Format to Archive Design Decisions

    Personally I don't think so. It depends on how you organize it. The strength of Freemind is that you can keep all the detail stuff collapsed until you really need it. So if new info comes by you can really attach it to the place where it belongs (adding detail info). It's there while not cluttering which I find a great help. Furthermore the linking helps a lot to keep information tidy while finding it which I find very difficult with linear design docs. It does not matter where somebody thinks a certain detail info is attached to best (often more than one place) because at the other places you can just add a link to it. In my case for example I use to have detail info on character abilities underneath the character. If there is for example a scene/task/plot-point where I want to focus on such an ability I can plop in a node pointing to the root node describing the ability in detail. So if somebody comes by this scene/task/plot-point and sees this link and wants to read the additional info (or add important info himself) he can just straight jump to it without needing to know where the info is located nor having debates about where it should be. I think important with Freemind and Co. is also to have a "links" node which contains child nodes linking to important places. This way you can keep the majority of nodes collapsed, keep the important parts visible, and still quickly locate and update the info you need. As with all tools people need to apply a certain level of discipline. For example to not make more than 10-20 child nodes and grouping them if they get too numerous. If used the right way I think it's a great help especially in contrary to linear design documents.
  8. RPTD

    A Simple Format to Archive Design Decisions

    I like to use Freemind for such stuff. It has the advantage that is dynamic so nodes can be folded/unfolded to keep the information clear. If something new comes around for a specific topic you can just add a child node for this specific topic node to add detail information (for example problems, thoughts, decisions and more). Detail info is then folded away to not clutter the main information. If somebody comes around he can look at the child nodes to see if there is something important. I also attach icons to the nodes if they are of specific importance. Last but not least you can link nodes. Allows to create node groups about a specific topic leading straight to the actual text nodes with the in-detail explanations. I've seen no better tool so far to organize simple to complex project information without turning into a clutter-festival.
  9. It depends what build system you use, and therefore what build management system you choose for your project. Now I don't know what build system you are using but I'm using SCons with the "Makefile" based build system (needs only 2 parameters to be set and SCons rules over CMake anyday). If it's Make/CMake based it should not be too difficult. I quickly tested it: 1) Create new project 2) "Run" -> "Configure Launches" 3) Select project and click "Add" -> "Compiled Binary" 4) Select under "Project target" the build target to use (for example NewProject/newproject) or select the binary location itself 5) Set "Action" to "Build" and using the button right next to it add your project. 6) "Run" -> "Current Launch Configuration": choose the one to use. It's not automatically selected when creating new ones. I hit then Execute and it build and execute. Does this work for you? Otherwise there might be something broken with the installation. Now step 5 is the one which might have bitten you. That's really something KDevelop needs to change (adding these fields automatically when creating new launches). (NOTE: You can skip step 5 but then you need to always "Build" then "Execute" which is something people tend to forget so setting this action properly helps).
  10. It's not "just a subculture of people" as you claim it to be. It's certainly much less effort and engagement to copy-paste a game together instead of doing the assets, scripts, code (if required), sound, music, UI and what not else yourself (alone or with a team). Most of the time these C&P games are bad since you need to understand what you are doing. Just slapping things together is what the majority of people do but real game developers don't. That's why Unity has the negativity attached to it. That and the fact it's a horrible engine to work with. Better use UE4 or some other engine. It's cumbersome to work with too but less of a problem. (Bracing for fanboy down-voting... 1...2...)
  11. What exactly has been the problem? Just curious to know.
  12. Astonishes me nobody mentioned KDevelop. Acts as frontend to GDB as debugger so you get all the power GDB has. Have been using it for all my projects so far. Please DON'T suggest MVSC for C/C++ ! It works well for C# but for C/C++ it is horribly broken. Half the time IntelliSense stops working leaving you with nothing but a fancy bloated text editor. You need to reload files and projects endlessly until it starts working again. Know this from own painful experience.
  13. That's what I do... it's called "L-GPL". A software license. GitHub for example to make the project available. This is what you can do. But don't expect many to give feedback. Most are (as you correctly said) "script kiddies" and don't know solid c++ coding as it is required for a game engine. But that's a normal thing in all software projects.
  14. Actually... get used to working alone. So many claim they want to help and a couple of weeks later they are gone without a trace. In the end coders are the team members sticking to a project the longest. Artists... not so much... unless they are on your payroll.
  15. You're actually quite right about Unity and this "is a religion" thing. But it's not only around here. Say something against Unity (no matter how solid and valid) and you've got all the fanboys over you. I've seen this many times so far. Just ignore them. By not using Unity you do yourself already a large favour. No need to apologize for anything there.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!