Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

UFPS : Ultimate FPS [ RELEASED ]

Discussion in 'Assets and Asset Store' started by VisionPunk, Mar 9, 2012.

Thread Status:
Not open for further replies.
  1. bubbalovesponge

    bubbalovesponge

    Joined:
    Nov 8, 2012
    Posts:
    69
    I did post full articles on how to use this 100% mobile, but the unity forum removed my account stating posting copy right material.
    I so did not!!
    Mine is 100% mine and only using VisionPunks existing classes but never posted his code, so since I am afriad to post anything.
     
  2. theSoenke

    theSoenke

    Joined:
    Dec 4, 2012
    Posts:
    106
    How can i disable the movement of the player for an menu? When i open my menu in the game and move the mouse the player is also moving
     
  3. lusho_games

    lusho_games

    Joined:
    Jun 4, 2011
    Posts:
    63
    Hi VisionPunk!

    I'm having a lot of fun with this tool, once again I come with a simple question. (sorry if it has been asked before).

    I'm using my own projectile GameObject, how can I decide the position of it when I instantiate it?. Currently my projectile appears at the absolute center of the Player, I would like it to appear from the hand if that's possible.

    I tried with the GameObject script to use the hand's position as a reference but the Vp_FPSshooter seems to override it.

    Thanks.
     
  4. lusho_games

    lusho_games

    Joined:
    Jun 4, 2011
    Posts:
    63
    Nevermind, I fixed, I was doing something wrong.
     
  5. bubbalovesponge

    bubbalovesponge

    Joined:
    Nov 8, 2012
    Posts:
    69
    Create a new .cs
    public GameObject player;
    player = GameObject.FindGameObjectWithTag("Player");

    You can then add getkey input if the ESC key is hit:
    if (Input.GetKeyDown("escape"))
    {
    vp_FPSPlayer pl=(vp_FPSPlayer)player.GetComponent("vp_FPSPlayer");
    pl.enabled=false;
    }
     
  6. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Hi bubba, Just to let you know: I had no idea that your account was closed for posting UFPS stuff :/. Too bad, sorry about that. Not sure of the exact rules that Unity enforce on posting code from assets. As for me, I've told forum users previously that they should not post the full *.cs script with modifications, but posting snippets of the modifications only is perfectly fine. Along the lines of:

    "in function so and so, after the line that says so and so, paste the following:
    Code (csharp):
    1.  
    2. // some code
    3.  
    ... and on the line that says so and so, replace so with yada"

    :)

    That's fine by me ... and works for most cases where code changes aren't massive. Tip: it's a good idea to use the forum code tags like above, and to refer to method names instead of line numbers since the numbers will differ for everyone due to their individual file mods.

    I encourage sharing modifications like this. It's always interesting to see the cool things you come up with.

    Cheers

    Cal
     
    Last edited: Jan 14, 2013
  7. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Sorry if the links are out of date, radiantboy. I'm focusing 100% on getting 1.4 out now, but let's touch base again in a few days if you can't figure it out.

    Cal
     
  8. d10sfan

    d10sfan

    Joined:
    Oct 29, 2012
    Posts:
    25
    Looking forward to seeing the new version!

    Is the animation support going to make it easy to switch between the normal way of the camera, with using the position and rotation changes, and animations with that?

    Also looking forward to seeing the example scripts for health and pickups. I've got a combination of my own stuff and your example of health, but curious to see how it's implemented here. Are the example scripts going to include limited ammo?
     
  9. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Yes very easy. The only difference really is that a few standard animations can be triggered on the meshes. There are editor slots for fire, wield, unwield and idle animations, and these get played on top of everything. So swaying, bob, shaking etc. use the procedural motion. However: there will be no example animation content in this version. The support is just there as a convenience.

    Yes. 1.4 includes an example player with ammo clip logic, along with a base pickup script that can be overridden to create all sorts of pickups. Examples include: ammo, health, speed, weapons and slow motion.
     
    Last edited: Jan 15, 2013
  10. FractalCore

    FractalCore

    Joined:
    May 15, 2009
    Posts:
    151
    First time posting... Love the system, very pleasant to use. I was going to post about a limited ammo solution since that's where I'm stuck at the moment. But thought I should read through all the pages to catch up. Got all this way and then on the last sentence of the last post read what I wanted to hear. "1.4 includes ammo clip logic". Thanks Vision Punk. I know you don't like to commit to dates, but any info on roughly how long, weeks, months? Keep up the good work.
     
  11. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Thanks :). I'm putting all my efforts into getting in out within this month.
     
  12. masterprompt

    masterprompt

    Joined:
    Jan 6, 2009
    Posts:
    115
    I've been working with this system for a little over a month now. I must admit, the demo is very attractive however once one buys the package and finds out about the shortcomings, it quickly becomes less worth the price paid....

    First off, please don't take what I'm saying as my attempt to discredit your hard work, as from the looks of the source, lots of effort went into to make it as 'complete' of a solution as you could. That being said, I believe that is the downfall of the package itself. Your trying to do too much for the user of the package. Sure, one could argue that it's the 'ultimate' package BECAUSE it eliminates as much work as possible however realistically the work eliminated merely cornered the package for only one type of use.

    Our project, an arcade style fps, will be for multiple platforms (mobile included). We like the smooth movement and weapon/arm movements of the system along with the effects (earthquake, boss stomp, etc) however we had to strip MUCH of the guts from your system just to make it usable with more than just a COD style FPS. Below is a list of things we had to modify:

    1. Replace the control with a virtual controller allowing control of the FPS (player, controller and camera) to be dictated to by touch or key/mouse by a 3rd party.
    2. Strip the ammo monitoring components and replace them with a virtual controller that allowed a more robust ammunition control/configuration.
    3. Remove shells as they used instantiation (bad for mobile) and replaced it with a caching/polling system.
    4. Removed bullet completely and replaced with position/vector event so a 3rd party system (cache or polling) could do the leg work of bullet/projectile tracking.

    Issues we're having currently:
    1. trying to disable the whole player hierarchy and/or the fps camera to allow another camera to do some scripted events before player comes into play. When we disable player, and re-enable, some controls don't seem to work properly.

    In my opinion, this system could be much more robust if more of the individual parts were agnostic of each other. A good example would be to create more components that control individual systems such as ammunition (example). Some systems require ammunition caps, others might allow for a default weapon to come up when ammo for another weapon is depleted. Having ammunition scattered and closely tied to the shooter and player means a lot of hunting to modify. Another area where a component could be used is in terms of control. It would be better to have the camera, player, etc look back to a single component for movement rates, mouse locking, etc rather than having the rates and what-not scattered throughout the individual systems (makes it harder to manage control). Use events more (or actions) and let the developer more closely manage their projectiles. Sure, you can have your own projectile as an example (and sure, it can utilize instantiation for simplicity) however as the package stands, we're stuck with your object instantiation for shells, projectiles, and the like.

    Again, I don't mean to offend, because the system is nicely done; just felt it could be a more 'complete' solution in terms of allowing customization/adapting of the system to the developer's end rather than assuming the developer can afford to adapt their existing libraries to the system.
     
  13. ProtonOne

    ProtonOne

    Joined:
    Mar 8, 2008
    Posts:
    406
    Awesome job VisionPunk. I've been using this package for a prototype, it is really fun to work with.

    You have an interesting way of handling reload time isolating bullet logic. I would recommend this package as a great learning tool for anyone curious about good programming practices in Unity. This pack and NGUI stand out to me as great examples of quality code.

    I absolutely love the explosion camera shake effects. Keep up the good work!

    Which reminds me, I should give it a review in the asset store, you haven't had any in 2013 yet! [done]
     
  14. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Hello masterprompt, *phew* that's a long post :)

    You are absolutely correct and this is the big dilemma for me as a developer. My customers fall into two categories, the extremes of which are:
    1. Hobby developers who may be just starting out scripting (or may not know how to script at all) and want a product with a fleshed out feature set to get them ahead quicker. These customers typically want more modern FPS features. This group generates a lot of customer support (approx. 1 hour per day for me now), but they are passionate, fun to work with and exist in the thousands. This creates an incentive for me to make the package more feature rich.
    2. Professional developers who are typically prototyping an FPS for a customer or as part of a more seasoned indie team, and want a lightweight, optimized and low level system with as few game design decisions as possible incorporated into the product from the get go. This group would happily pay $200 or more for it (they often can't grasp why the price is so low) as long as it's clean, professionally designed and does what it says. They get back to me with extremely valuable feedback and insights. However, they are few and far between and so make up a very small portion of the customer base.

    Though I still haven't settled - finally - for one audience, I am well aware that it's dangerous to end up in the limbo inbetween. As you may have seen in previous posts, I'm trying hard to keep things separated in the code - especially to separate gameplay from the core system - although I'm the first to admit: probably not enough. Hopefully version 1.4 will be an improvement in this regard, though it has admittedly not been my main focus.

    Regarding mobile controls and instantiation: This package was not designed for mobile.. However a mobile version will be a high priority once 1.4 is out. Given the scope of the technical re-writes needed, this will likely be a separate product.

    This works a little bit differently in Unity 3 and 4. It should work better in Unity 4. PM or email me if you're still having trouble with this and I'll help out.

    I agree. Though 1.4 won't be a textbook example of decoupling ;) a few things I've done lately is split input from the player class into a separate class, and started to use messaging for a lot of things instead of calling methods directly between classes. Also, 1.4 is full of new example gameplay scripts, but most of it is kept in discardable scripts in the demo folder so as not to complicate the core system. I agree with you in principle and I'll work to decouple things more, although it will be a gradual process.

    Yeah, and obviously the mobile version will have to include a global object pool. Should be no problem.

    No offense taken! On the contrary; your post was very refreshing, gave me a few new ideas and reinforced a couple of existing ones.

    Thanks!

    EDIT: By the way, really cool little zombie shooter you got there! Love the way you blockified the weapons.
     
    Last edited: Jan 16, 2013
  15. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Thanks a lot, Doug :)
     
  16. TVE

    TVE

    Joined:
    Oct 15, 2012
    Posts:
    379
    Awesome job. I really like the design. I would buy however this will not support my mmofps. I will try and create something like it. Very nice, will recommend. Keep it up! :]
     
  17. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Forgot to mention that this looks really cool, AimlessTom. Wasn't this the one with the procedural levels? Can't wait to see more of it ...
     
  18. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,633
    Hey mate Id love to see, if you can post how visionpunk said OR perhaps agree with vision punk to allow it on pastebin or something :)

    Whats new in 1.4 visionpunk? I pray you have mobile supported "natively" lol :) as always loving your asset.
     
  19. masterprompt

    masterprompt

    Joined:
    Jan 6, 2009
    Posts:
    115
    Sry, I can be a bit of a chatty Kathy on little sleep heh :-(

    Glad to hear you say that. I tend to come off as very abrasive in text. I didn't want to sound like I had no appreciation for the package as a whole, because the opposite is true.

    Thanks, it's still in very early prototyping. Many of the slowdowns, sorry to say, are in regards to working with the fps package. More-so of trying to understand what I can change (and not break things) and what I can't. Outside of that, waiting for art (typical of the field).

    Well, if I may offer a possible solution (albeit time consuming one): Start with a basic controller (movement), add in components as you go however code it in such a way where the components aren't required for it to function.

    Assume there will be hundreds of these controllers in a scene, in multiple configurations, with multiple controlling factors. Don't assume everyone will use a weapon camera, don't assume everyone will even have a camera (for look and what not). One of the things I'd like to do with our project is do co-op. What would be ideal would be to have 2 (or more) of the fps controllers running around. One controlled by a local player, others controlled by network updates (or by a behavior for NPC). Perhaps when the player dies, he can take over control of one of the bots (and I just switch out the control scheme of the other FPS controllers).

    pardon this quick rant
    Another thing to do is to let people manually link objects in the editor. I see that with a few things you do component searches for things you require; this tends to be very limited (it can only be setup one way). Sure, you may intend for it to only be setup one way however other configurations, although unintended, may produce bugs which may allow for some interesting (and possibly intentional) results. Let me set the layers (don't take liberties on assuming unused upper end layers aren't ever going to be used). Even hobbyists know that unity, at it's core, is a "drag this, link that" tool. Which brings up the states (text files). They should really be ScriptableObjects and linked via the editor. Having to load a set of rules, and save it out, really defeats a lot of what unity was designed to do.
    /rant

    Then, simply build prefabs for the hobby developers to use and for the professional developers to learn from.

    A lot of the libraries I make for our projects tend to get reused in other projects. I have some core stuff (randomizers, object and transform extensions, etc) that get reused, and more specific stuff (polling/caching systems). I always code it in the assumption that someone else is going to use it, and have 2 basic schemes:

    1. Static - A library that will never change. Sure, functionality can be added to however what it does should never change regardless
    2. Dynamic - A library that I know wont fit every solution. This one will require tweaks or retooling based on the project requirements. I tend to make these abstract and require someone (even if its only me) to inherit it. The basic functionality (purpose for why it was written) is set in stone however the questionable parts are forced as overrides for the inheriting class.

    I understand that however I guess I would update the description on the asset store to include some sort of conveyance of this point. One can surely argue that the package is only $25, and to find out that this will require many many tweaks to work with mobile (a very large market right now) isn't that big a deal. But my issue with not knowing is that my boss looks around for plugins to save us dev time. He tends to buy things based on reviews, descriptions, and demos. He doesn't mind the $25, and neither do I, however he now has an expectation for me to use the solution, and he tends to have pre-determined assumptions on how much time it will save us (not your fault, not his fault, just a general way a project manager thinks). Having something in the description that says it will work for mobile however may require some tweaking in terms of optimizing and control may better allow us (the customer) to have the proper information to gauge our timelines on.

    Don't get me wrong, even with the tweaks/mods required, we probably still would have gone with the solutions as the movement is very smooth and the little details (again, the boss stomp and such) really make the time spent worth the result. With a disclaimer in the product description I could have avoided the stink eye from the boss on why a few extra days of time were needed to get it working ;-)

    Another thing I forgot to mention earlier, that you may want to slate for your mobile retooling, is the use of string comparisons for states. One thing unity started doing (thank the lord) is to hash strings and do comparisons on the hashes (the new animation system and states for example). When we have our project running in profiler, there's quite a few slow downs coming from the fps system from things like zoom, crouch, and run. Most of what I can tell (not having gone too far into it, and just disabling those for now) is that states are using string comparisons. I haven't gone too far into the states either however you may want to make sure that you check existing state to new state to avoid a state change to the same state (again, getting rid of string comparisons may help big time in the processing times).

    Sorry again for the lengthy book. I tend to be chatty. Still love the system though, thanks for putting in all the hard work!
     
    Last edited: Jan 17, 2013
  20. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Hi radiantboy, I made a couple of quick posts on the feature set earlier. It hasn't changed all that much. Mobile controls etc. are not natively supported in 1.4, although I've made many changes in the system to prepare for better mobile performance moving forward. (EDIT: see my next post for a little more details).
     
    Last edited: Jan 18, 2013
  21. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Hehe, that's a lot to digest. I hear you on a lot of things and I'll keep your posts for reference.

    What I can comment on right away is that the upcoming version is already a big overhaul in terms of structure. The core classes are separated from the "extras" both in terms of functionality and file structure in an effort to make the system easier to navigate. As you say, it should be easy to make an architectural walkthrough, an online chat room or what not, and not have to spend days trying to root out the weapon and shooter stuff. 1.4 will make a little progress here, though won't go the whole way quite yet.

    A few other improvements you have mentioned are also already done, for example the state system uses dictionary instead of lists string comparisons. Input is isolated in a class of its own, and the player class has been stripped down to the bare essentials, with a more fleshed out "gameplay-player" inheriting it in an example folder (as a starting point for beginners). A lightweight messaging system replaces many of the hardscripted references between classes. A majority of methods are virtual for easier overriding. I've also begun removing some object instantiation, although this effort is just beginning.

    Again, lots of great feedback there and I'll keep it for later.

    Cheers
     
  22. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,633
    Thanks for the response, I dont want to say im disappointed with no mobile support considering you have given us so much (and I have already paid for and worshipped this asset), but I think the current killer feature is undoubtedly mobile support at this time.

    This is irrelevant to your asset but I made a great little title using it, works lovely on pc, I moved it to mobile and im getting 1 frame per 5 seconds.. I do not have unity pro so what do I do to fix this? Again Im not at all saying its your asset issue, I actually went back and tried your demo and it did work at a sensible pace on my old nexus 1, a big sigh of relief at that point. But im wondering what slows this all down? I have 3D models and some particle effects etc, but oh my the speed was absolutely heart breakingly bad... maybe its time for me to buy unity pro and detect bottlenecks?

    PS. Im hesitant to hack my own changes in there when you may provide us with something even nicer, any tips on that? or is it just examdiff all the way? in your code i mark all my changed with "//GAZ: I DID THIS" so far :)
     
  23. jrkienle

    jrkienle

    Joined:
    Apr 14, 2012
    Posts:
    71
    Another quick update on converting UFPS to multiplayer! I currently have ALL the features working in UFPS! WOOHOO! I only have one noticeable glitch so far: you can ocasionally shoot yourself. I play to have videos showing this conversion soon!
     
  24. Mcg

    Mcg

    Joined:
    Mar 28, 2012
    Posts:
    112
    jSoftApps congratulations on a great project , I was just wondering if in your project melee combat is included? I notice you have a "barbarion" weapon but doesn't seem to swing/attack unlike other weapons so was wondering if it's just a placeholder
     
  25. TryHarder

    TryHarder

    Joined:
    Jan 1, 2013
    Posts:
    121
    Hi,

    Just wanted to let you know after reading the comments in your code re using Axis. i just went out and bought a wireless XBOX controller and hooked it up and altered your code to suit and I have to say its awesome, we can't stop playing the project we are working on everyone wants to borrow my controller.

    Anyways you do need a little tweaking (like 3 hours, LOL) but its worth it, its amazing, works better than I ever thought it would, so big thanks, your hard work has made us all smile and laugh out loud, now we are just waiting for Multiplayer.

    Thanks again !
     
  26. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,633
    Nice work! I tried with ps3 pad, but ended up bluescreening my pc and killing my CMOS.. so I gave up :) still id be happy to try again if you could post the code? :D..
     
  27. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,633
    WOW! any plans to show the code? :D Sounds amazing!!!
     
  28. jrkienle

    jrkienle

    Joined:
    Apr 14, 2012
    Posts:
    71
    Actually, I was planning to add melee weapons to it. I just have to figure out how to make it damage the enemies!
     
  29. Mcg

    Mcg

    Joined:
    Mar 28, 2012
    Posts:
    112
    Very cool thanks
     
  30. Toasttify

    Toasttify

    Joined:
    Mar 27, 2012
    Posts:
    143
    Where is the 60 page pdf file located? For the life of me I can not find it.

    Oh also I too would love moving platform support.


    EDIT: Okay nevermind, the pdf is right inside the unity package haha.
     
    Last edited: Jan 20, 2013
  31. jrkienle

    jrkienle

    Joined:
    Apr 14, 2012
    Posts:
    71
    Hey visionpunk, how would one add moving platforms to UFPS. I speak for myself and a bunch of other people when I ask this.
     
  32. Toasttify

    Toasttify

    Joined:
    Mar 27, 2012
    Posts:
    143
    I am attempting to add moving platforms by copying what the default fps controller uses, but it is very complicated taking into account all the momentum and what not =/
     
  33. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Hi radiantboy, If you don't have access to the Unity Pro profiler, you can always use a little "divide conquer" to find the slowdowns. Disable every system (every type of component, not just the UFPS components) one at a time and see if you can locate the bottleneck for your particular application platform. The last part is an important aspect. What type of mobile hardware are you testing on?

    Hehe, that's actually a good idea! I've hinted at this a little bit before: but the next version has quite massive changes to the codebase, so it is a good idea to isolate your modifications, preferably in derived class scripts.
     
  34. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Congrats, jSoft. I knew you could do it :)


    Yeah, it's only to show how melee weapons would look with the swaying motions, fallimpacts and walk bob. I recommend using "real" animations for bending the arm, hand and fingers (i.e. melee motions). That said, I have actually experimented with using springs to animate the mace as-is lately. It is not a "melee system" worth mentioning, but I may include a prototype script as an extra in the next version for people to play around with..
     
    Last edited: Jan 21, 2013
  35. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Use a vp_FPSShooter that shoots 5-10 projectiles with a wide spread angle (basically a shotgun shooter). And for the projectile: a vp_Bullet prefab with a ~1.5 meter range, an empty gameobject (no decal) and no (or different) FX spawn objects in it, along with different impact sounds. The weapon should have a 'swoosh' for a fire sounds. This doesn't make for the awesomest melee combat experience imaginable :) but it should work decently.
     
  36. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Yeah platform feature is up and coming in a couple of versions. Can't say when really. My best tip is: have a look at the Unity FPS controller examples and see if you can lift principles from there...
     
  37. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Yeah I can imagine. I know this is an eagerly requested feature and I'll look into it as soon as I can. My best guess without having looked into it is: make the controller class aware of the fact that it's standing on an object tagged (or layered) as a "platform", keep a reference to the platform object and every frame snap the controller to the platform (unless jumping or falling). Or something like that...

    EDIT: Maybe some gems can be found here:
    http://answers.unity3d.com/questions/topics/move-with-moving-platform.html
     
    Last edited: Jan 21, 2013
  38. WillOfTom

    WillOfTom

    Joined:
    Aug 6, 2012
    Posts:
    9
    Hey, thanks. I just got a website of my own with a playable build of the game I plan to update every week or so. Check it out: http://aimlessgames.com/?page_id=36
     
  39. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    This is freaking awesome, AimlessTom! I am a big, big fan of procedural generation (and of id, whose legacy I sense in your game :)). Love it how the levels are unique every time the game restarts.
     
  40. SevenBits

    SevenBits

    Joined:
    Dec 26, 2011
    Posts:
    1,953
    This code is not difficult to convert to mobile. The problem likely lies in the physics he is using to animate the weapon. That really kills the CPU of your phone.
     
  41. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,633

    thanks, tried a few times to get it working on mobile but couldnt, seperate issue to the speed thing, i got it to look but not move, will have to give it another go soon. May use the dual joysticks prefab and try tap into that..
     
  42. VisionPunk

    VisionPunk

    Joined:
    Mar 9, 2012
    Posts:
    711
    Yeah, I'll be sure to have a good look at this for the mobile port. Hopefully as much as possible can be optimized and retained. Some things will have to go, I'm sure. Then again, "mobile" is a broad term nowadays. I hope UFPS will run well on a newer iPad, but I'll eat my hat if it runs on an HTC Legend :). Somewhere inbetween would be nice.
     
  43. masterprompt

    masterprompt

    Joined:
    Jan 6, 2009
    Posts:
    115
    It runs decent on ipod 4th gen, so its not terrible. The issues are mistakes most make when they first start out making stuff for mobile platforms. The key to any decent system is to design it for the lowest platform and add more as you go allowing the fun/features for the pc user base. But like i said before:
    1. Object instantiations and destruction are bad
    2. String comparisons are bad (not right away, but added up over time they get to be a nightmare).
    3. Using the unity message system, bad.
    4. Using non-cached transforms, bad (garbage collection is having a field day).

    It's stuff most don't worry about on the pc, but once you make that first app on mobile, and get <10fps, you find that you need to rethink your core design. Not any one of those points will cause you massive slowdown, but adding them up will defiantly not allow you room for any other game logic.

    I look forward to seeing what changes are made in 1.4!
     
  44. SevenBits

    SevenBits

    Joined:
    Dec 26, 2011
    Posts:
    1,953
    Honestly, I was originally considering using this on a canceled mobile shooter project. I'm sure I still have the code somewhere. If you'd like, I can send it to you.

    To be perfectly honest, the physics need to be toned down on mobiles or at least partially faked with animations. The rest is pretty basic though.
     
  45. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,633
    Well your original scenes work well on Nexus One so no worries there mate, your code is efficient enough already to work on old phones already :D just whip up 1.5 with touch joystick control and we will be happy ;) haha im so greedy :)..
     
  46. bubbalovesponge

    bubbalovesponge

    Joined:
    Nov 8, 2012
    Posts:
    69
    That is what I found when I started on my mobile venture. I had to clean up and recode a lot so the mobile would work smoothly.
    Of course all my testing has been on a Samsung Galexy III so I am betting lower smart phone mobiles would have issues and compiled on the 4.0 gingerbread platform. Cannot test on an iPhone since no license to compile to apple products.


    I already did an ammo clip, health meter, and also changed the bullet code to send and take damage from an object.

    In short, a mobile version is so very very possible and works awesome with Ultimate FPS Camera, just a very solid knowledge of VisionsPunk's code is required.
     
    Last edited: Jan 28, 2013
  47. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,633
    Im so interested in this, yet no one has posted code yet, any plans to :) PS I can make you an iOS build for testing :)
     
  48. SevenBits

    SevenBits

    Joined:
    Dec 26, 2011
    Posts:
    1,953
    That's an interesting idea, but you can't just comment out the desktop code and replace with mobile and say, "Done!"

    You have to be mindful of the platform. His spring physics that he's using to animate the gun model are fine on a desktop PC or Mac, but when you get to lower-end devices, like phones, tablets, and netbooks, you need to be mindful. That's what I initially tried and you'll find as you add more content in, the performance will drop, especially since you'll have other enemies, effects, etc. What I did was partially replace the spring physics with generic animations.

    I plan on sharing with VisionPunk my own mobile port as soon as I can get it together. I won't post any code here, as I respect the fact his code is proprietary, but I can assist you all with some advice.
     
  49. Armin-Hidden

    Armin-Hidden

    Joined:
    Jan 24, 2013
    Posts:
    1
    How can a gun Reload, Preset Instead, I use the animation?
    Thanks
     
  50. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,633
    Thanks mate!! You're a life saver! Will give that a go this weekend!!! :-D
     
Thread Status:
Not open for further replies.