I am trying to make a game like Color Hole. I've created a ground and a 3d cylinder. I want this cylinder act like a hole instead of a solid cylinder. Is there any opinion how can I do this without using Blender or etc?
For modeling and mesh prototyping within unity there are very cool assets, such as this, or this.
The most affordable of the solutions of course is to import the model you want as wanted from your modeling program.
It would expected to be possible with pro-builder (modeling tool integrated in unity). However its not.
Window->PackageManager->Probuilder
Then you need to enable the experimental features:
Edit->Preferences->ProBuilder
Then there is a tool that its supposed to make union, instersection and substraction of meshes:
However it does not work and at least for what I tried, I obtain this error always:
StackOverflowException: The requested operation caused a stack overflow.
UnityEngine.ProBuilder.Csg.Plane.SplitPolygon
(Unity version 2018.4.12). Maybe it can be checked if there is an issue with the unity version and if the pro-builder approach migh work in others.
If you attach a script to the "hole" object, you could detect other objects entering in OnColliderEnter(). Then, using the OnColliderStay() method, you could move them downwards "through" the hole, then destroy them (or whatever you want to happen when they pass through the hole).
It's kind of a hacky solution, but it would work if you're unable make a custom asset. It's not going to give you physics engine interaction though, so making the object tumble realistically through the hole will be more effort than it's worth.
I have an XNA zombie survival game, where the player has to hold out in a building and zombies come at them by waves. Zombies initially target barricades to get to the player, and then target the player once they break down the barricade.
Here is an image of the game so far. Walls (indestructible) are in black/grey, barricades are in brown:
UPDATE: I have made a lot of progress so far in my understanding of pathfinding, but still no dice. The above picture shows my current grid/node system.
As you can see, outside the "arena" there are very few waypoints. The zombies need to get to their nearest waypoint on a road, so they can then head towards the barrier (the top road still needs a barrier, I know).
Once they break down the barriers they need to use pathfinding to find and follow the player around walls and obstacles, so there are a lot more waypoints.
I am currently storing each of the grid points in a Microsoft.XNA.Framework.Point array. I have tried so hard to implement this with this article which I have referenced so much, but my system and his are completely different and I can't find a way of making it work. For example, the article's system looks one grid unit in each direction to look for a node neighbour. Seeing as the waypoints outside the arenas don't have node neighbours right next to them, the system fails.
XNA is a dying framework and there is no usable articles/tutorials on pathfinding so I really need some help here.
With an a* style pathfinding algorithm, a grid based game level is ideal, as an array of data provides the a* algorithm with what it needs to determine an optimal path.
When you move away from grid-based games, you need to get a little more clever. Your best option is to create a node based a* pathfinder. This implementation requires you to define "nodes" in your level, that serve as waypoints, in a path. Your algorithm utilizes the pre-defined nodes, in a modified a* implementation, to determine the optimal path.
You can even generate these waypoint nodes programatically based on your level. I wrote an implementation in unity described here .
Beyond this, you can look into Navigation Meshes. This technique involves calculating or pre-defining polygons in your level that allow movement. This is a bit more involved, but produces much better results.
I am making a game where you can travel the entirety of a planet. It will be hosted on a server so procedural generation would probably be a bit too much for the server to generate a world for multiple players. I can build the planet and I would like to be able to load it from game files by each client. The server wouldn't need to load or generate any part of the planet in this case.
A planet would have far too many vertices for unity though, so if i were to build it in blender as a multitude of smaller objects could these be loaded/unloaded as the player moves along the planet?
and I understand this might be a little too far out but, can the models be changed in game and saved? say if I placed a building somewhere on the planet, then send this detail over to current and new players.
Thaaanks!
Yes, you can stream parts of the world. You can do that in unity too. And you could make live updates. However, the way you're asking the question makes it seem to me as if you're new to this, and working alone - in which case, it'd probably be better to build something that works first. All of the things you've lined up are possible, but not necessarily easy to implement.
i wanted to know how to edit 3d models' vertices in XNA at runtime, i wana do something like the 3d max subtract feature where u put 2 models together and delete the intersecting vertices of 1 of them, more like carving one mesh with the other.
see this if i wasn't clear
anyway so any pointers on how to edit vertices at runtime or any help is really really appreciated.
thanks
You can't do that.
AFAIK, OpenGL, DirectX and XNA have no utility functions for boolean operations on triangulated meshes (if they had those, we would be seeing fully destructible environments in every game on the market). If you want to do that, you'll have to implement boolean operations yourself. It will be EXTREMELY difficult (especially dealing with topology), and I mean it (tried to do that, will implement them someday (as exercise) when I have more time).
Or you could try adapting/using source code from blender or libgts. BOth of them have implemented boolean operations, but they are written in C/C++, not in C#, so it will be "fun" no matter how you look at it. Also, be careful about licenses if you decide to use their code. Both use flavors of GPL, and GPL is "viral" license.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Ok, so I ended up writing my own game engine based on top of XNA, and I am just wondering what else I need to make a complete engine.
This is what's in the engine:
Physics (Farseer Physics)
Particle Engine (Mercury Project)
2D Cameras
Input Handling
Screen Management (Menus, Pause Screen, etc.)
Sprite ( Animation, Sprite Sheets)
And XNA stuff like Sound.
Am I missing anything that might be crucial to a game engine?
You're approaching it in an upside-down manner.
What should be in your engine is the following:
All the code that turned out to be common between your first and your second game.
First, write a game. Don't write an engine, because, as you have found out, you don't know what it should contain, or how it should be designed. Write a game instead.
Once you have that game, write another game. Then, when you have done that, examine the second game's code. How much of it was reused from the first game?
Anything that was reused should then be refactored out into a separate project. That project is now your game engine.
This doesn't mean that you shouldn't plan, or shouldn't try to write nice code. But make sure you're working towards something concrete, something where you can tell a good implementation from a bad one. A good implementation of a game, is one that works, is fun, and doesn't crash. Write your code to achieve those things first.
A good implementation of an engine? That's trickier. What's a good implementation of a renderer? Of an AI framework? Of a particle system? Ultimately, the only way to determine whether you have a good engine is by seeing how well it works in an actual game. So if you don't have a game, you have no way to evaluate your engine. And if you have no way to evaluate your engine, you have no way of judging whether any of the code you're writing is actually useful.
A theme or market for your engine. If you're doing anything beyond basic your basic graphics engine, you'll want to concentrate on a market for your engine, like RPG, strategy, puzzle, platformer, action, or FPS (ok, not FPS).
This will help you point yourself in the direction you need to go in order to make further enhancements to the engine without asking us. An engine like say, the Unreal Engine, can do multiple things, but what it tends to do best is what it's made for, FPS games. Likewise, you should tailor your engine so that it suits a particular field of interest, and therefore is picked up for that type of gameplay.
You can make it general to a point, but realize the more generalized your engine is, the harder it is to program, both time wise and skill wise. Other programmers are also less likely to pick up a general engine (unless that's all there is) if a more specific platform is available. Or to just write their own since modifying a generalized engine is about as hard as creating your own.
A few more things:
Path finding - very useful for AI
AI - possibly - depends on how generic you want the engine to be.
High scores
Replays - makes high scores much more interesting, as you can actually watch them.
A couple ideas:
Artificial intelligence (perhaps just simple AI utilities, like pathfinding algorithms)
Saving all or part of the game state (for suspending and restarting at a later time or saving high scores).
I think that you covered the general requirements of a 2D engine. The only thing I would miss in that list would be:
GUI Library
Also to make development processes easier:
Script Engine (LUA, C#Script, ...)
Dynamically Refreshed Assets (see Nick Gravelyn's Blog Entry)
You might also add another layer on top of XNA's existing stuff:
A quite bareboned Network/Lobby implementation
More abstract handling of multiple controllers (DropIn/DropOut during gaming sessions, like see Resident Evil 5 Coop) - maybe event-based
Finally you might add some "ready2use" shaders. Maybe get some inspiration from the discontinued FaceWound (from the "Garry's Mod" developer).
It depends on the game, but another thing often needed is a good networking framework.
Many modern games, including 2D games, seem to have some form of networking in place.
Animation framework so that you can say: take this sprite, move it in this direction, folowing this path using this speed, acceleration and such
Basic GUI system. Don't implement a whole Windows, but basic things like a pointer and a button, and such - keep it basic
Debugging component for displaying FPS, numbers of sprites and such
Also a good thing is to make some games, and then you will quicky see what things you repeat doing for each game, and then look into how to can get that into the engine.
2d lighting system is a good advanced feature. You can use Krypton for that.
Map editor. Or even better support any tile-map format, compatible with "Tiled Map Editor". So you can just use Tiled.
Scheduler/Timer for game actions.
Screen wipe effects such as page turn, fade out, etc. to make nice transitions between screens.
Game layers with build in parallax would be usefull too.
In game console to process commands or scripts without restart.
Easy load for texture atlas as sprites or animation.
Nice Work,
We (me and some of my friends) are working on a game engine too actually,
We've already got all what you mentioned but moreover we've got the following.
audio manager : a simple class to handle background music and sounds
effects in XNA.
video manager : it's not complicated, a simple class to handle video
playing in XNA.
effects manager : is responsible for stuff like bloom, blur,
black/white colors .. etc.
Good Luck :)
3d Acceleration should be in a 2D engine.
Using the 3d hardware that most people have these days is the best way to get amazing performance for your 2D games...
Good collision detection is very helpful. If you implement it efficiently, it really reduces the time required for every frame. Besides that, in my engine (for Pygame) I have a method of separating the main screen into a number of subscreens, which I find useful.
Depending on the target game type, include Navigation Graph(s) with node and edge annotations. (Good for many games, but not so much for the token side scrollers that are made with 2D graphics engines)
A component to generate them (via a flood fill algorithm).
Be sure to include all of the major path finding/planning algorithms (A*/Dijkstra/etc.) to traverse those graphs.
The pitfall of this is that you will have to define what a 'map' is for the engine, which might limit users of the engine.
Related things:
Location based triggers (player enters an invisible circle and something happens - queue cutscene, start ambush, etc.). I would say provide a base class for the trigger and implement some basic ones to show how it's done (ie. weapon pickups etc.)
Some game engines implement networking (though this is kind of part of the 'xna stuff')
The most useful thing to include above all else would be tools to easily use your engine. Maybe use your engine to create the tools. I'm sure you would find a lot of flaws that way.
Simple pixelperfect collision detection. NOT Farseer Physics. Simple drawing routines like drawline, drawcircle etc.
A tile repeat tool. Something that allows the user to add/create a tile, and manipulate the edges for a smooth repeath pattern.
Um. This list is an "internals" list. To make great engine is to make great "external" list.
Look at UE3 for example -- it is here because of great tools. You need tools for world creation, to create optimal packages of resources (it should be in internal list too ;-)), for collision object specification etc.
Plus, to add to Organiccat answer you should decide on tech level. You can go for simple sprites or you can want fancy effects (so shaders are needed, and with this you need infrastructure)