For my exam project in coding class I have to recreate a game in Unity where I can also show off my OOP knowledge. Some of the requirements of the project are encapsylation, inheritance and polymorphism.
What are some good ideas for a game that can show all these things? The ideas I had was Candy Crush, Street Fighter, Hearthstone or some tower defense, though I'm not sure if I'll be able to make good use of OOP in these games.
All games you're listing aren't really fit for an exam project. I don't know how much time you have to finish this project, but I'd go with something a lot easier, especially if you're going to do it youself. If the main objective is to use your OOP knowledge, any simple game with maybe different kind of enemies or items will do.
For instance, asteorid, but with other kind of objects and weapons beside the asteroids and the main gun themeselves. Asteorids, bombs, fire balls, you name them. All of them must have some degree of common behavior and that's where OOP can be used. Weapons too. Rayguns, double barrels, radial shots, shockwaves...
This is just an idea. You can do something different like Pac-Man and implement diver kinds of ghosts, for instance. Or different main characters with different abilities.
Although, be aware that Unity (and most other game engines) although built on topo of OO languages prefer a Component-driven approach and true OOP is used in very little quantities in very specific parts of the game. Usually data structures more than game objects.
I had a client ask me to build a Tamagotchi type of game and characters are a place where you can use a lot of inheritance to build some base character types then branch off into specific character types. The classic base "animal" and then "bear"/"wolf" etc or biped/quadruped etc some lay eggs, others are mammals you could come up with some good inheritance trees.
In Unity, the different types would need to implement their different ways of triggering animations via the Animator controllers possibly. Most of the systems in Unity won't need any inheritance though, your plain C# classes would implement these and I don't recommend that you build off of Monobehavior. Instead, you have a ScriptableObject and it will instantiance the necessary C# class possibly based on an enum you have that represents all the different types.
Basically it was a 3D Unity Project (nothing used 2D components) and had a simple plane as the ground, and then the camera was above - pointing down at the "ground". The character had 2D art that was perpendicular to the overhead camera, but they were correctly upright with the normal Z world direction so their "feet" were on the ground plane and normal physics/rigidbody can be turned on. This way you can add a Navmesh to the ground and Nav Agents to your characters making movement really simple. They move around like normal, but their art is facing upwards towards the camera. You can give them colliders and rigidbodies. Setting this up took barely any time and saves you from having to work in pure 2D mode with all the problems it comes with for implementing your own movement and control systems, collision detection, etc. If you go pure 2D you lose a lot of systems and it's not necessary. This way you can just use simple 2D art assets.
Your tower defense is also not a bad idea because towers can have inheritance too. Again, design your own classes and you shouldn't be inheriting from Monobehavior in your base class. You aren't expanding on Monobehavior, you are building your own classes.
Related
Imagine a large free-roam game in Unity,
The yellow size indicates about the largest you can make a typical Terrain in Unity.
Art dept. will completely build, meter by meter, the entire scene.
Please note, this has absolutely no connection to repeating scenery (as in runners) or procedural scenery (as in say some race games).
Really, what is the correct and good way to do this in Unity?
use say 50 or so terrains, each perhaps 100m x 100m ?
can you even have or use that many terrains?
or what?
For anyone googling here.
The correct solution is indeed
Terrain stitching
that's it.
In practice you must use one of the tools available to do this (eg, TerrainFormer) or, your team will write from scratch a terrain stitcher.
Yes, you just use "many terrains".
The best approach to the exact problem posed,
is in fact to just:
"use lots of Terrains".
It seems to be perfectly viable in Unity to have many (dozens) of Terrain units, basically "sitting next to each other".
In practice, you'll need TerrainFormer
https://assetstore.unity.com/packages/tools/terrain/terrain-former-20052
or one of the similar tools.
(Or, I suppose, from scratch write your own tool to stitch terrains, and allow you manipulate them all at once, join the edge-heights perfectly, etc etc.)
It's not realistically possible to just perfectly sit many Terrains together (by hand), matching all the edges, etc etc. So you're going to need a "stitcher" package for putting many Terrain squares together.
So, this huge area ..
has about 12 Terrain.
So that's the answer, you can indeed have "many, many" Terrain in a Unity project, you do indeed essentially just "sit them next to each other". In practice it's not achievable unless you use one of the editor tools such as TerrainFormer.
The proper way to do this would have been with procedural mesh generation with MeshFilter and Mesh API but you mentioned that this not at all random or generative so that one is eliminated.
It's just simply a very long, thin, hand-made environment
The best way in this case would be a Modular Level Design. You need to create Modular Assets. With this you can have a long road in pieces which can be tileable. A good modeling artist should be able to create and texture modular assets with 3D modeling packages like Blender, Maya or 3ds Max.
All the programmer has to do is make each asset a prefab then use the Instantiate function to instantiate them to create any distance of environment. You can also create a static environment in the scene from the Editor. Almost anything can be made into a modular Asset especially buildings and roads.
After assembling them in Unity, you can do static batch on all the instantiated modular parts with Unity's StaticBatchingUtility.Combine to improve performance of the game since they are not being moved.
Below is an example of a modular road asset that can be used to create almost any amount of road:
You already answered your question
in this case would it be better to not bother with Unity's otherwise excellent Terrain, and the modellers would just outright build the long course/scenery? (Obviously you'd have to chunk it so it all occludes fine)
I think it's the way to go. If the performance is an issue, try putting each chunk in different scenes and then have a master scene to load them async and additively. And of course you want to unload each scene as it becomes invisible in the camera.
I personally go with your own solution which is letting the Unity Occlusion Culling system to take care of the hiding and showing chunks. I only go with the separate scenes approach if I'm not getting enough performance this way.
I recently had the same problem. We build a tilebased infinite runner with road crossings. The camera was positioned behind and over the car looking down on the street and the player car. So the setup is quite comparable.
We used Curvy from the Asset store to create paths for moving the player and also for creating the geometry of the streets and the surroundings among the streets.
https://assetstore.unity.com/packages/tools/level-design/curvy-splines-7038
It is also easy to spawn tiles with curvy paths and combine them at runtime. So you can separate long distances into smaller segments and spawn them randomly.
We also used QuickBrush from ProCore to quickly paint environment detail to the geometry like trees, bushes or stones. I think procore tools are now implemented in the new Unity 2018 version.
Worked quite well.
I have been digging around trying to find a way to show a game board of sorts.
It is basically a square board with a round hole in the middle, I am able to render the scnBox and the scnTube, but I would like the area where the scnTube sits in the box for the box to be transparent and see through the game board, but can't seem to find anywhere that has an example. Any help would be much appreciated. I am hoping that I am just missing something very simple, but this is my first time using scene kit.
Thank you.
Before Unreal Engine 4, (UDK and prior) Epic's modelling space was subtraction - a filled block was your game world and its extents. From inside this block you took chunks out to create space for players to run around in, and shoot each other. All's fair in love and war.
I'm telling you this because it's a good example of how contrived 3D modelling is compared to real world scenarios, and should (hopefully) put you at sufficient unease to digest what follows.
This approach of carving out of a finite block is still in Unreal Engine 4 and popular with older users, but it now defaults to an open, infinite world into which things are added. Most new users gravitate towards building into an infinite space of nothingness rather than carving space out of a solid, finite block.
Everything about 3D modelling is virtual, and virtually impossible to relate to the real world. Instead of thinking in terms of how things could be done if objects were real and literal, you need to think in terms of the limitations (and there are many) of geometry definitions as used in most 3D modelling and game engines.
The programming equivalent of this mental gymnastics is going from the concept of classes and objects to their realities within languages and frameworks. On the one hand the ideas and their ideals are wonderful, and on the other the realities are a bleak reminder that programming languages haven't really progressed very far, at all.
3D modelling is exactly like this. It's not much further along than it was decades ago, and is still using archaic ways to solve many of its original problems.
Cutting a nice, clean, efficient round hole in a cube is one such original problem.
A very simple shape is being intersected and cut by a shape with the potential for infinite complexity. What should happen? Should the simple become complex or the complex become simple? How to make the most graceful transition between the two?
That's the problem you're facing: a cube is a simple geometric shape, easily defined by minimal line segments. A cylinder introduces infinite possibilities for line segmentation around its circumference.
So somewhere along the lines of development, the architects of 3D modelling had to come up with a way to make these contrasting line complexities play well together for lightweight presentation on limited hardware. Their solution, in most cases, is a hybrid and a disaster of user operability, but masterful in its geometric efficiency: Polygon modelling, UVW unwrapping and subdivision!
All of which means that if you want to achieve this in the best way possible, with today's tools, for the purposes of Scene Kit, I suggest polygon modelling this board in Maya for 4 reasons.
It's got a 30 day free trial.
It works on a Mac
It's polygon modelling tools are second only to 3ds Max
It's easier to learn (for a complete newcomer) than MODO, and miles easier to learn than Blender.
MODO is interesting if you're already skilled in Polygon modelling, but it's so utterly discombobulating if you don't have that prior experience that I'd recommend using just about anything else first. Except Blender. Blender is free, but don't be tempted. It will cost you more in learning time than buying a copy of every other professional 3D app.
In MODO's favour, and the reason I mention it, it does export nicely for Scene Kit. I know that for a fact, but am not yet sure how well Maya exports for Scene Kit.
Which is the next problem you're going to come up against. All COLLADA files are not born equal.
New Maya does have Unity and Unreal export presets, so I presume it's possible to calibrate its COLLADA exports to match the demands of Scene Kit perfectly, just haven't yet needed to do it. This will (very likely) involve trial and error to get the settings right. It would be nice if Apple would tell us exactly how to configure export from all major 3D apps for Scene Kit, but instead they're giving us the half baked Model I/O, so we can double the effort of importing artwork.
All context aside (which has largely been to demonstrate that 3D is no simpler nor more refined than using an IDE and frameworks like Xcode and Cocoa), here's the meat and potatoes:
A video on one aspect of what's best to make holes, and starts out as you are, with a cube and a cylinder:
https://www.youtube.com/watch?v=zaEv5rio8bk
But it does presume a certain amount of Maya familiarity, some of which you can gain from this rather slow and ponderous examination of two other ways to make holes in cubes:
https://www.youtube.com/watch?v=lvMfoH5Ikrc
Yes, if you're counting, that's 3 ways to make holes. Actually four, because the first video starts with the boolean operation you might have been expecting to be how this could/should be done. In some parallel future we'll have well working boolean geometry operations. We're not there, yet.
Hopefully that same parallel future will offer us a programming language, frameworks and terminology that's not confusing and maintains metaphors long enough to make teaching easy and usage elegant and simple.
I dont know about that long answer but this can be achieved with Boolean Subtraction. You create a cube and a cylinder. You subtract the cylinder from the cube. In 3ds Max this is under compound objects-modifiers-boolean subtraction. I guess Maya has a similair function somwhere in the menus.
I'm using Unity3D for a networked multiplayer online game where I have a very large complex 3D terrain scene like a forest, with trees, cliff, hills, mountains, bounders, etc.
Players can also build structures sort of like minecraft, and put them anywhere in the scene, or even move them around anytime.
Aside from the human controlled players, there are automated AI players and objects like animals roaming around the scene following a path.
The problem is how to make these automated AI players and animals, able to navigate around the static and dynamic player created structures, because the path they follow can easily get blocked by player created structures, or even by other players and other AI objects, cliffs etc. So they have to find away around them or get themselves back on track if they tumble down off a high cliff for example.
So I made a navMesh and used NavAgents, but that just takes care of the static, non moving objects, but how do I make the AI players navigate around each other and also the dynamic structures created by the players which can number in the hundreds?
I thought of adding a NavMeshObstacle to everything, but this would result in it being attached to hundreds of objects since the user created structures are built using little pieces like blocks or little tiles to create a larger object.
Here are my questions:
Would attaching a NavMeshObstacle to hundreds of little objects slow down the game?
Is there another way to navigate of dynamic objects other than using NavMeshObstable without slowing down the networked game?
Thanks
Based on the documentation for NavMeshObstacle, one could reasonably assume that if carving (an obstacle "carving" a piece out of the nav mesh) is disabled, obstacles will only affect agent performance when they are in the agent's way. They won't affect pathfinding. The agent will just go around them when it's close. Note that this will not work for you if there are so many dynamic obstacles that the agents need a very different path. You can also set them to re-carve a piece out of the nav mesh only when they've moved a certain amount. You should test the performance, but that sounds like it might work well for you.
http://docs.unity3d.com/ScriptReference/NavMeshObstacle.html
If you don't want to spend much time on making your own "sensor and navigation" system extending unity's navigation then I think your way is through NavMeshObstacles. If you build your obstacles with blocks like minecraft to avoid add NavMeshObstacle on each block you have a huge range of choices on how to limit/approach on your building system.
There is also good AI systems free as RAIN, for example, that implements some extensible and consistent way to do what you want, take a look on unity market if anything there fits your needs.
I'm working on a 2D game (kind of like a top down space shooter) for the iPhone using an engine very similar to cocos2d (not exactly though) on OpenGL ES. I'm trying to figure out how I'm going to do collision detection.
All the ships for my game are images, and the game will load the image as a texture onto the screen. I've got very very simple detection going already that basically just takes the rectangles of the images and checks to see if those collide and can do that just fine.
But, of course the ship isn't perfectly taking up the entire rectangle so there is whitespace in there. So my question is how am I supposed to account for that whitespace? Do I have to have the matrices of the ships stored? Or is there another way? I've also heard of possibly using the Chipmunk physics engine for collision detection? How would that work?
(1) regarding Chipmunk, the short answer is yes you should immediately download chipmunk, donate something to the bloke, and start learning about it.
Working with that for a day or so will basically answer all the questions you have. If you want to work with physics games you're going to need to get in to it.
(2) you ask about using an approximation ("just" a rectangle) instead of something more accurately shaped like your spaceships. In fact, you'll be perhaps amazed to learn, that is precisely how it is usually done in all your famous big-name games you've played since we were all kids! Indeed sometimes you might use little more than A DOT (!) to detect collisions.
What you'd probably do in production is try a more complicated model, and play with it for a few hours and see, is it actually any better to play with than your simple dot or rectangle model.
If you do want to make a more complicated model -- just make one! Build it up from three or four rectangles using your current system. Try them "all against each other", and have "one big one to check first" to see if it is even anywhere near each other (sort of a simple spatial hashing).
You will find that when you do it with Chipmunk, which as you now know you have to immediately begin after reading this message, you just build it up the same tedious way. It's not a magic bullet. But if you were going to use a "more complicated model" yes it is better to go with something standard, chipmunk, to do the work in - it will get done quicker and better. There is heaps to learn and you should hop to it!
(3) Unity is not just for 3D Finally if you want to do it the smart-ass grown up way, you'd have to use Unity3D which will let you access the very metal, the Nvidia physics on the chipset. Note that unity works perfectly for 2D games also - you just click one button in unity to use a 2D projection (many brand-name ifone 2D games are done exactly like that).
If you use that approach, you can (if you want) have "absolutely exact" physics, with every nook and cranny of your model modelled.
What is the downside to doing this? Ah hah ... well the thing is, you need superb actual 3D models of all the stuff in your game! (Like you see them building in the "how we made the movie" special features that come with your favourite Pixar blu-ray.) To do that you need things like autodesk, maya and the like. you would quite likely buy some models ready-made from a digital prop shop (no need to build "a chair" as it has been done 1000 times already and you can buy one for ten dollars).
(Unity3D is completely free to use for a few months while you see if it can make you money.)
Incidentally on the Chipmunk front --- you can just use Corona which is ridiculously easy to use and has chipmunk-like physics completely built in with zero effort on your part! You could have the whole game done in less time than it took to write this email. You could be selling your game already and thinking up the next one. Or, you could use "Cocos" which indeed has a chipmunk-like physics library built-in .. personally (just me) I do not like and won't touch cocos - but of course many games use it.
(It seems pointless, to me, using cocos which is a "for idiots" product, when you can just go ahead and use Corona, which is a "for idiots" product but stupendously easier to use, 1000x more solid, and probably literally 10x faster to finish your product and start making money.)
Noel Summary:
So in some sense using Unity3D (and hence, the actual nvidia physics on your computer's chips) is the ultimate solution if you want detailed nook-and-cranny collisions. Going down one step, Chipmunk is exactly, precisely what you should be using on the ifone/ipad for 2D physics -- it is precisely what is used in all the famous games we know so well. You have a bit of learning to do so hop to it - it's superfun. Finally go right ahead and just make your current model more complicated if you wish - roll your own by adding more rectangles!
And the fourth point is, be sure to remember that in games, astonishingly, you can often get away with remarkably simple physics (often SIMPLER!! than one rectangle - just a damn point - ie, simply measuring the distance between centers!) Fifthly after going to all the effort of testing more detailed physics, you would play test one against each other, and find out what is the simplest physics you can get away with.
I am new to iPhone dev and would like to write a game that involves 2d collisions. Would somebody give me a conceptual overview on how the various frameworks interact in a typical 2d collision game?
The candidates I see mentioned so far are 2d packages such as quartz and cocos2d and physics engines such as chipmunk and box2d. What I am not extremely clear is the relationships among these in my context.
Thanks in advance for answering!
Quartz is a 2D graphics API by Apple. It's usually not used for performance-intensive games, because you can get better performance by using OpenGL directly or by using some thin framework made for games. (Which is what Cocos2D provides.) The collision stuff is independent on this debate, since the collisions are usually calculated without knowing anything about the graphic representation of the colliding objects.
The relationship between collision (or general physics) engines and the graphic layer is exactly the relationship between a model and a view in the MVC pattern. In each frame you move the physical world a bit forward (physics) and then you draw the objects on their new positions (graphics).
In reality the model and view sometimes blend a bit to make things faster, but in principle they are completely separate things. Which means you can pick any of the possible combinations of OpenGL, Quartz or Cocos2D as the graphics engine and Box2D or Chipmunk as the physics engine and get a decent game. I'm not sure how well do the particular combinations work in practice - if that was your question, then I've just wasted a few minutes of your life :-)
zoul got it right, I would just add this :
Cocos2d for iPhone provides samples including Box2D and Chipmunk if you want to try them and see how easy or hard they are to use. So you can go ahead and download Cocos2d, then play with the samples a bit to see if it fits your needs.