Announcement

Collapse
No announcement yet.

How easy is it to make a stand alone game using Darkplaces?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • How easy is it to make a stand alone game using Darkplaces?

    I have been thinking about it for a while, and I may want to use it in the future. I have these questions:

    Would I have to change the source code?

    How would I keep Quake clients from connecting?

  • Baker
    replied
    No one cares if someone necroposts.

    But not reading the thread and the specific conversation is rude as hell, especially if it is bumping an old thread.

    None of what you posted has anything to do with the very specific line of conversation SpecialBomb laid out, which was quite specific.

    Leave a comment:


  • vibok
    replied
    necroposting

    You probably could use one of variations of Quake 1 engine to make your own games, but I see multiple problems with it.

    License, it's under GPL, you'll have to share the source code of all your games. You probably should do so anyway, it will make supporting it easier.

    QuakeC, it's quite limited. You probably should use Lua or something like that. Or not use scripting language at all.

    Lighting is more limited than in modern engines. Everything must be precalculated (you can still do blinking light), and you can't have good flashlight. No proper shadows, only circles under the model on the ground at best. Not sure how moving platforms will be lit. If you can live without those, go ahead, overwise use source engine or unity or whatever.

    Other than that, it looks quite good.

    It's probably better to be used as a learning material rather than an actual engine.

    Many just recomend using unity or source engine, but those are so complex, and unity is closed source in addition to that. There are many things that premade for you, but you wouldn't be able to modify your tools. This means, you can't make your enemies walk on walls or something creative like that.

    Leave a comment:


  • MadGypsy
    replied
    @dutch - no doubt. That's pretty much my entire argument. Plus, FTE is a hella advanced engine. Ive heard people say DP has more features. I don't know uf that's true and tend to belueve that it's not but, even if it is true how long before it's no longer true? Also, my opinion is that FTE is more solid. Think of all the fixes and whatnots you have to use to get DP to run mission packs and properly handle entities. It seems like a bad design was implemented and then bandaids were just piled up on top of it.

    "Look at my Porsche but don't look under the hood cause, the engine came off a weed eater. It's OK though cause I pay someone to follow me and push me over bridges. You like my Porsche? Listen to that door open alarm purr. That'sa Pirsche door open alarm."

    Bells + Whistles != a band.

    Leave a comment:


  • Dutch
    replied
    @darkplaces vs FTE

    True, but I don't see LordHavoc in here like Spike is. That speaks volumes on what's the better engine for development...the author of FTE is always around answering questions. I'm not bagging on LH, just pointing out that when you hit a roadblock in DP, it's going to be 10x as difficult figuring it out on your own.

    Leave a comment:


  • xaGe
    replied
    For a DARKPLACES thread there sure is a lot of FTE talk.. derp derp!

    FTE is fine and dandy, but yes to this:
    Quake based DarkPlaces is, in my opinion, an awesome place to start game development.

    @SpecialBomb you can change the application icon before you compile it or hack the exe on Winblows(ewww) which can be done in seconds, minimal effort. If you just asked me this on Discord I would of told you that. Derp!

    Ok, Continue on...

    Leave a comment:


  • Spike
    replied
    I really need to add it into the apk by default or something.
    iirc, I think there was some bug where FTE was getting confused over game-created and console-created pics, which meant the console-created ones were getting wiped making it kinda useless. iiuc that's already fixed, but yeah, sorry. it does need to easier either way.

    regarding multitouch in FTE+csqc, each 'finger' acts like an individual mouse each with a different deviceid that gets reused only once its been released. so the csqc receives an absmove, then a keydown (k_mouse1) event, then absmove events until the finger or pen or whatever you want to call the contact point is released resulting in a final keyup (k_mouse1) event. Using this you can track multiple drag events or multiple button presses suitable for an onscreen dpad/joystick or whatever.

    Leave a comment:


  • MadGypsy
    replied
    my cousin and I both tried the "showpic" way based on instructions you sent him and neither of us could get it to work. We tried on 3 completely different android devices. I know if you say your engine does somwthing that means it does it but, this was one feature we had zero success with.

    I could mail you a broken tablet to test your engine on. I believe the battery is fucked. Getting the tablet fixed should be cheaper than buying a new one. Its all yours if you want it. Or maybe you are good at electronics and could fix it for "nothing"..?

    This is all on the assumption that you still have no android deviced as that was the case the last time we messed with droid fte.

    Leave a comment:


  • Julius
    replied
    Originally posted by Spike View Post
    I was kinda hoping that someone would make some csqc-based onscreen controls.
    you also can create some simple 'buttons' via the 'showpic' command, and set them to issue some console command when pressed (including -prefixed commands when released). I was going to bundle some config to add some by default, but they never quite appeared.
    I doubt a CSQC version would work. How to do the necessary multi-touch and maybe even gyroscope input? At best you might be able to run a mouse-pointer via the touchscreen input, but that seems to be blocked on many non-rooted Android devices?

    I guess the best would be a SDL2 based engine plug-in with a screen overlay that lets the engine think it is dealing with a regular game-pad or such. I think someone already implemented something like that for an ioquake3/OpenArena Android port, see:
    https://github.com/pelya/openarena-engine
    https://github.com/pelya/commandergenius
    https://play.google.com/store/apps/d...rena.sdl&hl=en
    It claims to support "5 touchscreen control schemes, gyroscope aiming, gamepads" and so on.

    I guess since it is Q3 based, porting it over would at least seem somewhat feasible?

    Originally posted by Spike View Post
    regarding vr:
    unless cardboard's source is released under the same license as its headers (or other gpl-compatible license), or its made into an actual system component, then I cannot provide a cardboard version of FTE without violating the GPL.
    this is true of most vr libraries.
    the framework bullshit that so perverts android makes it really awkward to make even half-arsed attempts to claim it as a separate work.
    and I also do not have a real device, and thus would not be able to make sure the gyro+accelerometer stuff was even working properly. and I'm lazy, so don't offer to send me one, grr. its my excuse and I'm keeping it.
    Yeah, I understand... it's still a mess. However it looks like the "new Cardboard" i.e. Daydream is a integral system component of Android 7.0. At least that is what the Wikipedia page on it claims: https://en.wikipedia.org/wiki/Google_Daydream
    Since the current compatible phones for it are still a "bit" expensive, no worries I will not just send you one Would be still awesome if this was implemented sometimes, as Quake in Cardboard VR with the above mentioned Darkplaces port works actually really well.

    Edit: Actually.. we are really derailing this discussion...maybe a mod can split it off and/or merge it with the FTEQW engine/client thread?
    Last edited by Julius; 11-23-2016, 05:22 AM.

    Leave a comment:


  • Spike
    replied
    I was kinda hoping that someone would make some csqc-based onscreen controls.
    you also can create some simple 'buttons' via the 'showpic' command, and set them to issue some console command when pressed (including -prefixed commands when released). I was going to bundle some config to add some by default, but they never quite appeared.

    regarding vr:
    unless cardboard's source is released under the same license as its headers (or other gpl-compatible license), or its made into an actual system component, then I cannot provide a cardboard version of FTE without violating the GPL.
    this is true of most vr libraries.
    the framework bullshit that so perverts android makes it really awkward to make even half-arsed attempts to claim it as a separate work.
    and I also do not have a real device, and thus would not be able to make sure the gyro+accelerometer stuff was even working properly. and I'm lazy, so don't offer to send me one, grr. its my excuse and I'm keeping it.

    Leave a comment:


  • MadGypsy
    replied
    @easier to port on screen DP controls

    I don't use DP products or have any knowledge of its features. DP installed itself in my home directory with no heads up and wasted an entire day of my time trying to figure out why none of my QC was doing anything... never used it again and never will.

    I hate shit that makes its own decisions without even giving me a heads up. I realuze FTE does the same thing but, It didn't end up being the one that did. It's like that. Also, spike is available, consistent and approachable. If FTE was the engine that had relocated itself, long before an entire wasted day, spike would have solved my issue... probably in one sentence and within 5 minutes of me asking it, with 100% confidence he was right.

    nobody can compete with that.
    Last edited by MadGypsy; 11-22-2016, 09:13 AM.

    Leave a comment:


  • Julius
    replied
    Originally posted by MadGypsy View Post
    fte for android is total bullshit though. It's almost the entire reason I decided to make my own engine from scratch. It doesn't seem like anybody can make a decent quake engine for droid with some visible on-screen controls.
    Would have been easier to port over the on-screen controls from the DarkPlaces port no? See: https://github.com/thomasgauthier/Qu...roid-Port-QI4A and maybe: http://opengameart.org/content/onscr...trols-8-styles

    And while we are at improvements of FTEQW's Android port: @Spike any chance to see a Vulkan powered Cardboard/Daydream VR version? See for reference the Cardboard VR version of Darkplaces: https://github.com/poVoq/Quake-1-Cardboard-Port-QVR

    Leave a comment:


  • MadGypsy
    replied
    @and an Android port developed by the original author

    love spike, love fte... fte for android is total bullshit though. It's almost the entire reason I decided to make my own engine from scratch. It doesn't seem like anybody can make a decent quake engine for droid with some visible on-screen controls. Not everbody has a gamepad for their droid device and numerous droid devices don't even suppot game controllers.

    Leave a comment:


  • Spike
    replied
    If you want new menus, start eg here: http://triptohell.info/moodles/csaddon/menusys_src.zip
    Its intended for FTE, but has some workarounds for DP so should be mostly usable for both engines, you'd probably want to strip the fte-specifics and provide better alternatives though. its just a starting point, or just treat it as an example of what you can do. no warrenty. :s

    Leave a comment:


  • Spike
    replied
    on windows, you need to somehow hack the exe if you want to change the icon. There are numerous icon changes around the 'net that can do this.
    However there's some other branding things like console prints, but the biggest issue with not changing the exe is gamedirs - like id1, DP will by default use both id1 and a home directory, which means standalone mods have a nasty habit of conflicting with quake/one another.
    With FTE, you can create some default.fmf file that overrides all the branding(except icons)+gamedirs giving proper isolation without changing engine source.
    fteqccgui now also has an option to embed one into the exe itself (and change the icon) too, which also makes fteqw act as an installer for your mod if its run without your gamedata in the working directory, although tbh that needs more polish.

    but yeah, both engines can potentially run without any gamedata at all. quite frankly that's always been the easy bit. the hard bit is getting all the gamecode, models, sounds, maps, etc made... and then polished enough so that they don't look/sound like turds.
    the nice thing about quake engines vs eg ue4 is that you+others will probably have lower expectations, and this in itself makes it muuuuch nicer to work on.
    the down side is that the way you should be doing things isn't really documented, meaning you'll probably opt for the crappy way and never get around to fixing it when you do learn enough about the various 'secret' apis etc that you ought to be using...

    Leave a comment:

Working...
X