Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

707 Good

About ProfL

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

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

  1. some unreal engine (1) style texture filtering is in.
  2. ProfL

    Path Calculation

    what exactly is the problem? I mean, the trivial thing would be to just create a recursive function, that would mark the current position and call itself for the 4 neighbours. when you reach the goal, you'd check if the current step count is lower than the currently shortest path and then store the way you've walked. I assume, you have problems with some implementation detail? or are you trying to get some particular algorithm to work? in that case, where exactly are you stuck? Or is the 64x64 grid of 64x64 grids the problem?
  3. Hi, Mamounetaleb, your music sounds really epic! I really like it. Arnero, I already work with dummy art, but that's obviously not how I'd release a game. I guess those 'people' that would have most fun with open arena is you But if every dev would only follow this guide, we wouldn't have all the other fun shooters. Thus, I don't mean to clone a game, but rather create a game with a shooter feeling alike these old ones. (Imagine humans have had stopped to produce wheels, because there was already one ) Thanks for your replies!
  4. Hi, thanks for the replies and all the messages, I'm still open for artist, game designers, writers,.. Arnero, I only run linux on servers, I don't have any linux hardware for gaming, hence I can't really investigate your issue. Have you considered to go the official way and report it via: https://github.com/ioquake/ioq3/issues ? I'm sure the devs might know best what possible issues might cause the crash. Yeah, Doom controls are a bit dated, but it's still amazing to be able to play one of the oldest shooters. I guess my goal is more Quake than Doom, but I'll mix and match features as the team will decide. Mamounetaleb, thanks for your help offer. When I'm down to add music to the game, I'll definitely consider you. Do you have a portfolio you could link? Thanks again everyone!
  5. ProfL

    How to become an AAA studio?

    There are many way and it depends on how risky you want it. 1. you can make tons of games and become big, e.g. Rovio with Angry Birds, which was their 30th game. But then, it's very much luck and nowadays not even they can repeat it, hence 2. socialize, there are many who earn a living and becoming bigger, not due to skills or games, but due to socializing. Eventually you'll come along the right persons to create or fund your AAA game. 3. go the hard way, if you are very skilled. work hard for studios, create some AAA games, after 10years, quit the job, and try some funding path (kickstarter, angels, publishers etc.) ... But, all these paths mean hard work. Being just an idea-guy, although it might look like it worked for other people, never works.
  6. I'm a programmer and craving to create an old school FPS that is fun for the core mechanic of shooting and movement. I'm looking for team members with art, music, writing, ... skills. If you'd like to collaborate, send me your discord or skype contact and I'll add you. Let's have fun!
  7. ProfL

    Challenges of 100 Players

    if you are talking about game streaming, then the arch is a bit different. player (light weight input client) -> ISP -> game server -> render/compression slave -> ISP -> player (visualization client, can be different than the input client) 1. You don't need to artificially run a game client, the server usually runs per client data already (which is usually mirrored to the client, but there is no point in that in video streaming, unless you just try to have a cheap/quick port). 2. not sure about that, a Data Center is just the physical space where racks of server (-hardware) is housed where game server (-software) runs. You need locations around the world to have physical servers close to clients/player, to keep the latency low. 3. The biggest bottleneck is most likely the GPU, in means of cost and performance. But that's something that nobody engaged yet, hence there is a lot of potential for improvement.
  8. ProfL

    Challenges of 100 Players

    The biggest challenge is usually to retro fit existing architectures to achieve that. Companies don't write Battle Royale games from scratch, they just take existing engines and make it run, then they try to fix the most critical issues, while expanding the game. The better your engineers, the better the workarounds, but under the hood, it's still a mess. e.g. Game Streaming can solve the scaling problem, as the data does not increase N*N with the user count (N player need data from N-1 other player -> 100 player generate 100*100/(16*16) -> 39 times more data than a 16player game), but stays linear (one video feed). The latency will not be bigger, most likely smaller, but there is no latency hiding on client side anymore, hence player will notice it more. Hard to predict how that will turn out, but game video streaming is more of a business thing than a tech thing. suddenly you can sell your game(-service) to everyone who can watch youtube. That's a far bigger market than these "few" current gen consoles.
  9. I think the simplest network model is to setup a TCP server that receives input from the clients, processes it locally and only tells the clients what to update or to show. Turn based games or maybe even some slow paced games would work. Once you have a simple game like that with TCP, try to get it working with UDP, you'll see it's a different kind of beast (even for people with programming experience).
  10. ProfL

    Why Gaming in the Browser is Inevitable

    You can use c++ (or other languages) and compile it to webassembly. https://en.wikipedia.org/wiki/WebAssembly
  11. ProfL

    Multiplayer Bandwidth

    I recommend checking out a tutorial about network synchronization: https://gafferongames.com/post/introduction_to_networked_physics/ especially the parts about bandwidth optimization: https://gafferongames.com/post/snapshot_compression/ maybe that gives you a rough guess on what to expect after some degree of optimization. BUT, in the end, gamedev works the other way around. You dont write a game and then setup consoles, servers etc.; Rather: you have a budget on how powerful your console is, how fast the network, what cost makes your server still maintainable and that will define the limit of your game. You either make it work within limits, or you'll loose money releasing it. That's the moment you have to hire superb engineers, they love the challenge and most likely, they'll make it work, while you might fail, unless you study programming for 10+ years. (That would be part of the budget you'd have to organize. if you know upfront that you cant, then you might want to make a simpler game, otherwise you'd run open eyes into a disaster ).
  12. +1 really nice looking! I like especially the lights the shade the ships when you shoot!
  13. Is that the game? How long do you usually play your own game? What part of the core gameplay do you consider is most fun about it? What is the reward loop while racing? If you had the choice to play a game when you're done with work, would this be the racing game of your choice for $10? And why?
  14. it's maybe not easy to do proper sampling in reflections, imho hardware derivates won't be correct.
  15. ProfL

    Advice on Starting a Prototype

    Use your existing knowledge/skills: I start by picking the tools I am most familiar with, to really only focus on quickly "getting there". Everyone might suggest you some tool, which might be good for fast results, but learning it while you want to get a prototype is a NO. Rip existing stuff: If you have already some code/art that partially does what you plan to do, just copy&paste it into the prototype. Even external stuff is better than spending time on creating something yourself. (You can always iterate and improve or replace it, if it does not fit your prototype, once it's running) Coarse to Fine: Don't do a classical "Task A, Task B, Task C..." route, instead: attack the biggest offenders. You are not planing to create a product, but to evaluate the viability of an idea. Hence nobody should judge the state of polish, but you should "polish" everything to the degree where there is something else that is more offending the state of your prototype. When you show your prototype to someone, you should tell what it suppose to validate and which part is just a dummy e.g. "The art is just made of boxes, as I only focused on the jump&run gameplay mechanics". Throw it away: It happens way too often that "prototypes turn into products", that prevents you at one side to go fully hacky&productive on the prototype, on the other side you might spent more time to clean up stuff "and get it right" than it would take if you started the project from a clean state. Hence, really try to make it a throw-away thingy. Don't fall into temptation to continue with it. There might be better tools, existing libraries, etc. which you should consider once the prototype is working. Join a Jam (optional): Taking part in e.g. ludum dare is like a prototype paradise. A lot of like-minded, a short crunch, you can learn productivity tricks (e.g. fire&forget tools like a "sound generator" that just randomly generates sounds: learning time: 1min), and when it's over, it's over.
  • 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!