Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

180 Neutral

About trowtlip

  • Rank
  1. trowtlip

    1-1/2 years have passed

      Well, I found the most important things are a) not to get to attached to things... if a project turns out to be completly overscoped, be able to shelf it without second thought. Resizing is good, but all to often much more difficult than starting over. b) not read too much into how much time you spend on "your game dev project"... most probably your "project" has evolved into a "second job" by the time you get competent enough to actually pull something reasonable off if you are a parttimer, or your "project" is actually multiple projects done in quick succession as you try to keep over water while striving to find that one game that is more than just moderately successfull if you do it fulltime. c) not to rely too much on outside help... if you try to build something you cannot finish yourself, and you don't have big pockets to begin with, you project will never be finished. Professional work demands professional level wages, and amateur work will only get you so far... apart from that, working with people complicates the whole process, and unless you find someone who is just as invested into it as you are, you will most probably spend more (not money, but time) than you get back. Keeping the project to a scope you could manage yourself, and seeing outside work as a bonus to shortcut it seems like the better idea.   Game development is never a sprint, unless you are already a very good developer, and do something small. In all other cases its a marathon.       Good luck with your game, hopefully you find help. If not, well, maybe you at least get to build a community. Which today is the most important support you can get from gamers as a dev.     Thank you for the well wish and advice!   Point 'a' is interesting to me. When I started this, I considered building a basic foundation and expanding functionality later on. I was told that idea is generally a no go. I'm moving in that direction with thoughts of adding stacked, sequenced events in the future. Based on my progress so far, it seems reasonable. Early on I had dreams of RPG style play, then flip over to semi-realtime pvp encounters in a 3D environment. I've since dropped any ideas revolving around "realtime", and the need for all that collision detection and what not. There was also a dream of MMO, but that has been replaced with as "persistent as possible".   Thank you again!
  2. trowtlip

    1-1/2 years have passed

      6 years are not an unreasonable estimate for a lone wolf part time even IF the game is actually quite small.   Don't forget the economics of scale. If a team of 4 would spend 6 months on a game, a single lone wolf dev will spend more than 6 months * 4 on it, because he cannot specialize (lets say 3 years). If the lone wolf dev now works part time (the TO said he spends above average time on it, lets make it about 20 hours or about half the normal work week of a fulltime dev), that 3 years double to 6 years.   Even IF the dev can save time with outsourcing work, he will spend the time he saved in marketing and business topics. And then some more.     How big a game can a team of 4 produce in 6 months? Not going to be anywhere near AAA. Even the "No mans sky" crew, which cut corners extensively with procedural generation and a non-realistic art style, was 10-15 people strong and spent quite some years on the game.     A lone wolf dev talking about 6 years just means reasonable estimates, and a not too small scope (nowhere near big, mind you). Is it a good idea to work so long on a single project? Maybe not, on the other hand, some others spent more than ten years on theirs and happened to release it to quite some success, so it can work out.     Thanks for your reply! Good information on realizing development time.   Right now I have a reasonable framework going so there is some amount of pressure removed. If I got tired of this idea, I could back down to something much more simple. In another few months I'm going to leave it "open" on the web with it's limited features, and maybe blog about it. Maybe I'll generate some interest that will turn into help.
  3. trowtlip

    1-1/2 years have passed

      Frankly that's the impression I got while reading the thread. "This guy is biting more than he can chew in a reasonable time frame". While I don't want to make little of the feeling of satisfaction you get from chopping at this, I imagine you would get even more satisfaction from actually finishing one or more projects that are more suitably scoped. I've been working on my current project (Curver, see signature) for years as well, with hugely varying productivity levels over those years. However, I'm quite close to the initial release specifically because I've re-scoped it (multiple times) to something reasonable for a single developer working in his spare time after a tiring day job, without completely neglecting his wife. Instead of developing a full-fledged vector graphics application, with animation and complex shading and a rich set of tools, I'm focusing on providing an efficient and innovative workflow for a specific task.   But if everybody followed this advice, then a lot of great games and programs created by single developers would not exist today.   Good luck, bro.     Thank you!   I have re-scoped as well, and will continue to do so. I've cut quite a bit out and it hasn't taken away from the premise of the game. It's quite possible I may end up with a large portion of the game text and chart based.   I'm actually ok with several more years ahead of me. If the tools I'm using stay relevant for the long run, I'll be OK.   The hope would be to attract an artist and a story person sometime down the road.
  4. trowtlip

    1-1/2 years have passed

      It's fun, isn't it? Part of me knows I'll never finish mine, but the satisfaction of making it through different sections; the planning, the refactoring and reducing, the fluidity of bringing it to life, is well worth it.
  5. trowtlip

    1-1/2 years have passed

    RPG with some 3D components. I've been chopping off features pretty regularity though, to keep it "possible to complete". Technology will probably have a say on the finished product since completion is still years out.
  6. trowtlip

    1-1/2 years have passed

    I meant 6 years overall. I'm hoping it starts to move quicker now that the framework has been set so-to-speak.   Space based, persistent world; economy, crafting, combat (thinking turn based) One person team, working part-time.
  7. trowtlip

    1-1/2 years have passed

    Holy Moley - a real life update, since "how long does it take?" is a popular question for people just getting in. I know it was one of mine. I've been working on my game for just about 18 months. I've written a ton of code, have a good database layout, a thoughtful redis cache, threejs, socket.io, node.js on the server side, and jquery for ease of development. I have  a linux build refined just for my game. I've cleared up a lot of my initial security concerns for a web based game, have all my socket/cookie/session issues covered and solid up to this point, moved some code to stored procedures and have done a small round of refactoring. What I have: register, login, planetary travel (within session and database without error, no visuals), initial inventory and calculations/weighting/character attribute modifiers, dynamic universe map functionality, disconnect procedures, lot's of security checks and some cheese graphics on basic screens for profile/travel/location and game object information. So pretty much all the character location, basic game objects, movement and rate of travel, base modifiers and saving progress under all possible circumstances, is solid.   What I don't have: anything interesting or playable. Granted I've been doing this part time, but I've really been pumping through sections of functionality and correcting the unexpecteds. I feel that my pace is reasonable and I'm putting in above average hours for a part time endeavor (I have no social life and I work 40-55 hours a week at day job). I am at a milestone though, where I can now spend much more time on the game and game mechanics. I'm looking forward to this part, so hopefully it moves faster. Funny thing: I started conceptualizing my game board with threejs in the beginning. After being satisfied with a good start on a map/navigation system, moved on to other things. Probably 9 months later it was time to insert the threejs. Well, the threejs crew changed enoughh in that time I had to rewrite things I wrote prior, which was an unexpected time sink. So I think I'm going to double my estimate and say that it will take 6 years, instead of the initial 3 year estimate to have something playable, and possibly monetizable. I just hope my choice of tools hold on that long. I may have spent some months interviewing the Unreal engine, Urho3D, and some C/C++ related to a client/server initiative before falling back to a web based model, but I don't remember exactly how long.
  8. I know if I have to setup and draw this same "hello" triangle one more time, I'm going to poke my eyes out. 
  9. Thank you! That site looks pretty good!    It seems like GLFW is preferred by many; I think I'm going to try it. I have a lot of code to deal with window resize in SDL. It looks like in GLFW there is one function arg. I don't know, I guess I should try everything before I decide one is better than the other.   Thank you again, I can't wait to dig into this one.
  10. Hello,   I'm trying to get into this openGL stuff, with a pretty clear goal in mind. It is difficult to say the least, but it is coming together - just not fast enough. I'm trying to get an openGL context going in SDL with some basic mouse, keyboard and window resize capture. I've been through lazy foo tutorials, and was able to get a a lot done with the code examples. Now I am on the arcsynth tutorials, but there is a huge divide between the tutorials and the code, and I'm not sure how to proceed. The arcsynth tutorials have helped tremendously with understanding the concepts, but I can't seem to transfer what is happening in the arcsynth code into my SDL window setup. Again the difference between the pdf tutorial and what is in the code is like night and day.   Every learning resource related to openGL is drastically different then the last, and to say it is slow going is an understatement. As a modest programmer I've been able to do tutorials, take the code, learn, build, and implement what I need with positive progress in every language I've dipped into. With openGL, it reminds me of my first C++ class in community college that was taught by a math teacher; she didn't know a darn thing about C++, but somehow we built a calculator. The only problem was I took the class to learn C++.   My goal is to create an openGL context, with two objects in a scene that I can make rotate, and maybe zoom and maybe pan. Then I will build from there, since I will need to implement some sort of picking, then move back to SDL, network and database stuff for awhile.    Can anyone recommend a good way, references, book, process to get to my goal? This doesn't need to be beautiful or ship quality; I'm just trying to get the concept framework going so I can look at all my pieces and work on them all bit-by-bit.   I've taken a look at every engine. In the end, for what I have done already with server code and database, it seems to go this route will still be quicker on the client end. I spend 5 hours on this engine, 10 hours on that engine,  another 8 hours on openGL, 6 hours here another 8 there and I still have next to nothing.
  11. If I had a notion to port my game client code from html5, javascript, three.js to an executable client; what would be the most congruent language and toolset?   I'm moving along very well with the tools I'm using at the moment, and I've de-complicated my goals quite a bit to realize an end. I would like to keep using node as the backend though. I'm wondering what I could build a "real" client in and keep moving at my current pace, assuming I'm using good patterns and practices in javascript. 3D components, but turn based for network and server interaction is the current direction. Maybe a job for Python? Just thinking about removing the "browser variable" as a long-term nugget, and if I can keep the time cost difference low to keep moving along.    Thanks! 
  12. Thanks for the replies!    The more I think about this in terms work to be done, I should really just let it out in a friendly manner, see where it goes and avoid any selfish child syndrome. I'm going to need people involved who enjoy the process. Even though I've done a lot already, it really is next to nothing in the overall. I'm more interested in making the lower level mechanics very functional for the near term, which I know we can both agree on. Much of what I have laid out is very well subject to change over time.   A friendly, agreed upon collaboration contract with equity and stake you mention may be sufficient. Part of the reason I consider this person is for valued input and problem solving ability. If things begin so rigid, it will most likely never really start.    Money is very much an object, but money will be mostly for art and higher level components that will be acted on at a later time, once there is a reasonable working proof of concept. I'm not ignoring the likelihood of failure. And if the partnerships ends, it will most likely be a mutual realization that the project wasn't viable - which is perfectly fine.   Thank you again for your input!
  13. trowtlip

    WEBGL Game; things started in C++

    thank you for all the replies!   I guess I should look at Dartlang as well...   I'm getting terribly frustrated. Wt is more than I want; so much API to decipher to get the pieces I want. cpp-netlib is about the level I want to be working from, but doesnt intend to support websocket, and I'm not sure I want to stick myself without that option. Poco is about the same as Wt, which are both a bit more bloat than I think I need (both following the Qt idea).    Maybe just use boost & write my own everything? I wasn't planning on going there (mostly for lack of experience), but it seems like the only way to get what I want.   Now I'm looking at node.js with (or without) native plugins (plugins = more complication, but does allow me to write the meaty parts in C++), but how long will node.js be popular? On the surface, node.js looks fantastic, and I can certainly handle JS. But what will I have years down the road? A bunch of code written upon an outdated fad library?   So, I don't write code; I read webpages about libraries. I'm ready to poke my eyes out.   In the end, I want to build an App that either fires up http or websockets (prefereably as part of the application), and allows me to spit out webpage/JS/WEBGL.   In the majority of my reading, most people say this is not a job that C++ can fit into. I don't understand why. To me, and aside from the obvious JS requirement, C++ is an obvious choice for inclusion in a WEBGL/HTML5 game that would anticipate high volume.   Ok, back to poking my eyes out.
  14. My comment on graphics was based on gameplay before visuals.   But will the games be accessed more by web browser and less by standard game clients?   Also, how painful would it be to go from say an SFML library to whatever library takes hold for web based gaming?   I know it's like trying to predict the future, but there are quite a few games that died due to technologies becoming obsolete before a game is finished.
  15. I'm starting to build my game. I'm currently getting it started in C++, and I'm doing some initial database interaction with both MySQL and Sqlite3. I'm thinking Emscription to get me into HTML5/WEBGL, as the time may be right for the next jump in browser gaming. This isn't a new idea; I've been fleshing out game mechanics for a couple of years, but I haven't commited to any actual development because I cannot decide on what platform to develop for. With the popularity of "apps" for tablets and phones; the introduction of html5/webgl, and of course the standard client/server style, I still cannot decide. I've been playing around with come C++ to httpd to javascript type libraries, which really fit to my ideas of accessibility, but it seems rather lonely in that area as opposed to using something like SFML. I'm concerned about using libraries that could die on the vine and leave me in a bad place, with no hope to continue. Starting as a lone developer, whatever I do is going to take a long time. At the point that I may become enouraged that my project could be viable, I'll have to then collaborate with other developers and creatives, which will initiate another period of "long time". what is the best bet platform-wise to launch an RTS/MMO game 2, 3 or 5 years from now? Should I develop in two different platform styles concurrently as a backup plan? Say, WEBGL and SFML at the same time. If it wasn't for the handheld market and it was still 10 years ago, I'd probably just go with SFML and do regular client/server. But I'm not sure PC gaming is going to last by the time I'm ready. Should I not worry about this? To me, the server config and presentation pipline is way more work than game logic and mechanics. I'm not sure about graphics, but they may not necessarily play such a large part of the games' draw so-to-speak. I don't know... Any thoughts would be appreciated.  
  • 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!