I'm developing a Unreal Engine 4 Survival Game and I have so far allocated to areas for lakes and have entered cubes with water like textures and I want to make it so that you can enter the cube and go into a swimming position. I also need it to have a different color texture when you move into places so that 2 meters away it will be dark and closer light and when you move it changes. I dont mind if we can do one thing at a time. If you guys can help me I would be extremly grateful! Hope you can help!
Set the cube up as a trigger and collide with pawns. When the Cube blueprint has an "OnActorBeginOverlap" cast it to pawn blueprint then call a function on it to tell it to go to swim mode.
https://docs.unrealengine.com/latest/INT/Engine/Blueprints/UserGuide/Events/
You need to first add a collision component in the blueprint viewport of the cube, then place events for triggering material effects, which simulate underwater scene, or you can fairly simply create a post-processing volume like that one on YouTube: w[]ww.youtube.com/watch?v=fLtSfG8f6NM ( Delete the "[]"s )
For super flamboyant but hard effect, check this one out: w[]ww.youtube.com/watch?v=8jbK00s2tKg ( Delete the "[]"s )
The most important part is to implement underwater floating movements. Create another character blueprint that has a floating pawn component in it. After that, add an event to spawn this floating pawn as a runtime object in level blueprint using "SpawnActorByClass" blueprint( tip: using C++ is much more convenient for manipulating runtime objects ) and possess it( https://docs.unrealengine.com/latest/INT/Gameplay/HowTo/PossessPawns/Blueprints/ ). You can modify some floating pawn settings to get better effects.
Plus: Feel free to ask me any questions. In addition, YouTube is a fantastic place for learning UE4. ExpressVPN works if you can't visit YouTube.
Related
I'm slowly introducing myself into some procedural generation techniques. However, instead of generating a map or level in a video game, I want to learn how to create procedural character models.
I guess something that would be akin to this would be the creatures from the video game "Spore". The basic idea is that the program will choose from a set of pieces of a creature, and piece them together to create one model.
Where can I go to learn more about this?
Also, do you know of any game engines that may have some compatibility for this sort of project?
I think as long as the parts of your creature are static assets and predefined by you (together with the information where the joints and fixpoints are), it does not really matter which engine you use. All common engines like Unreal or Unity allow you to create a character in the game from different components, which would be your creature parts.
The only challenge I see is the problem of animating the creature. You will still need some kind of skeleton that tells the engine how to map the animation to your creature. Maybe you can have different creature trunks with skeletons and animation and fixpoints to attach your various parts like arms or legs.
I have a question about organizing code while also displaying fundamental OOP principles. My task is to implement a world (MxN grid) with robots who get instructions to move around in the form of strings. They are also given an initial starting position and orientation. Instructions are performed in completion one robot at a time.
I made two classes, Robot and Map, but when I completed my coding I realized that the Map did not really do anything, and when I want to test functions within the Robot class (making sure coordinates are within bounds, etc.) it seems that the Map class is more of a hassle than anything. However, I feel like it is important for demonstrating the separation of things. In this case is it necessary to have two classes?
I think it does.
Map looks like a collection of Robots. It's like an Eulerian control volume that Robots flux in and out of. It keeps track of the space of acceptable locations in space and time. It maintains rules (e.g. "only one Robot in a square at a time"). Feels analogous to a Board for Chess or Checkers game.
The problem appears to be that you can't figure out what the meaningful state and behavior of a Map is.
I can see how a Robot would interact with a Map: It would propose a motion, which is a vector with direction and magnitude, and interrogate the Map to see if it ran afoul of any of the rules of motion for a Robot. Those are owned by the Map, not the Robot. Different Maps might allow different rules of motion (e.g. no diagonal moves, one square at a time, etc.)
For background I have been working on an RPG based off Ray Wenderlich's tutorials. (Example)http://www.raywenderlich.com/1163/how-to-make-a-tile-based-game-with-cocos2d.
Now I am trying to build a scripted event/Cut scene system so that for instance when a player enters a building, the different characters can have a discussion of the current events, before continuing the adventure. My only problem is I can't really visualize how one would implement this.
I would guess some sort of one time use trigger, maybe kept in a large switch statement on a singleton somewhere ? Which maybe draws all the temp characters ? Then the event then deactivates itself.
I am just looking for a blueprint of how one would do this. Although programming examples are welcome as well.
It depends a lot on how much time you want to commit to the system and how versatile you want the final system to be. A powerful cut-scene system can be flexible enough to be used in almost every interaction in a typical 2d RPG.
If you want to go all out I would suggest a heavily data drive approach. Keep as much data in files and use the filesystem to your advantage. If you say 'all the dialog scenes are in this folder' then when adding a new scene it just needs to be dropped in the folder rather than creating the scene then touching some master switch statement somewhere. Just keep in mind with a large system you want to make adding a new cutscene as simple as possible, not 400 different places to touch.
I would also stay away from switch statements for tracking progress in a cutscene. It adds a lot of code overhead per scene. Idly a cutscene would be a simple as an array of data and a position. Your cutscene manager, the singleton, can parse through the array, decode the data into commands and fire them off.
Sorry if thats a big vague but a lot of these decisions depend on how your engine is structured and what you want out of the system. Keep in mind that the more general the system is, the more uses you may find for it going forward but it will take longer to get up in running to begin with.
you can just check for the tile you are on while you are moving, and when you are on a specific tile you can start a cutscene, also you can add a tag via TiledEditor (this is the recommended editor for using with CCTMXTiledMap) to your map to specify where the cutscene should begin just like he pointed the character start point in that tutorial. the you check for the triger specified (either a specific tile or what the point taged in map) in every gamecycle. and then it's almost very easy you just freeze controls and play a prerecorded camera and object movements till the cutscene finishes. the restore the game to normal mode and turn off checking for the triger.
I'd like to know about the things that make Morphic special.
Morphic is much more than NSView or any other graphics class that simply allow the re-implementation of a limited set of features. Morphic is an extremely malleable UI construction kit. Some design ideas behind Morphic makes this intention clear:
A comprehensive hierarchy of 2D coordinate systems is included. They are not restricted to Cartesian or linear. Useful nonlinear coordinate systems include polar, logarithmic,hyperbolic and geographic (map like) projections.
Separation of the handling of coordinate systems from the morphs themselves. A morph should only need to select its preferred coordinate system, instead of needing to convert every point it draws to World coordinates by itself. Its #drawOn: method and the location of its sub-morphs are expressed in its own coordinate system.
Complete independency of Display properties such as size or resolution. There is no concept of pixel. The GUI is thought at a higher level. All the GUI is independent of pixel resolution. All the rendering is anti aliased.
Separating the coordinate system eases the moving, zooming and rotation of morphs.
All coordinates are Float numbers. This is good for allowing completely arbitrary scales without significant rounding errors.
The Morph hierarchy is not a hierarchy of shapes. Morphs don't have a concept of a border or color. There is no general concept of submorph aligning. A particular morph may implement these in any way that makes sense for itself.
Morphic event handling is flexible and allows you to send events to arbitrary objects. That object need not subclass Morph.
Warning: Smalltalk's live dynamic environment is a red pill. Static, frozen languages will never be the same for you ;-)
In a nutshell: Morphic is a virtual world where you can directly explore live objects (just like the real world). Did you ever look at a UI and...
wonder "wow, that's really cool! How did they do that?"
kvetch "I wish they had done X instead!"
While these thoughts would lead to pain and frustration in any other environment, not so in Morphic.
If you want to blow your mind, become a god in a Morphic world:
Launch a Pharo image, and click on the background (which is actually the "World") to bring up the world menu:
Bring up the "halos" on one of the menu options (shift-alt-click on my Mac):
Drag the "Pick Up" halo (top-middle) and drop it somewhere in the world:
Enjoy your menu item which is now available wherever you want it:
Seriously, click it and watch the Browser open!!
Ever have an option you always use that a vendor has buried three-menu-levels deep? Could this be useful?! This is a glimpse of the power of a live direct GUI environment like Morphic.
If you're intrigued, read John Maloney & Randall Smith's paper Directness and Liveness in the Morphic User Interface Construction Environment
The title do not map your question, so I answer your question and not the title.
I have read about Morphic the last two days and conclude with what I think makes morphic special.
Morphic is perfect for live coding. That is a direct mapping such that when code is changed the output on the screen change. And/or if morphs on screen is changed (draged) the values in the code is changed. That is cool in art performance!
But Morphic aims for higher abstractions than that. The properties of the morphs is abstracted away from the code. Do the SoC to a file or fetch a server-side database.
I suppose WebStorage and JavaScript file is a good option to store the liveness state of the Morph properties changed interactively. You see - programming is done through each Morph. Then the code need only to handle events from click and drag.
The aim for research has even abstracted the code away. Coding can be done through the Morph to define what happen with click or drag. Morphs can be puzzle pieces as in Scratch.
A program has to be backed up into a file somewhere. I don't consider to do coding on a cloud as safe. So a JS-file is the only alternative (if not setting up a server is an option), because datafiles is not allowed locally, not even in same folder as the web app. The Same Origin policy means same server - not same folder.
When the app starts the Javascript file (or Web Storage in first place) will set up the world of morphs. User interacts with that world. The new state can be stored in WebStorage and bacuped by a download.
You can use Lively Kernel as the language in the file or store the morph data in an object or whatever you find simplest to generate as a file to download.
So what is special with this? I am not repeat the accepted answer, but this is my conclusion:
Everything you see on the Morphic screen is a morph.
The tree of morphs is called a world.
The coordinate, dimension and properties of each morph is abstracted away from the code into the tree.
The research aims for abstract away the code too.
I am a C++ programmer trying to learn designing, as a start I am trying to get a hang of designing by giving myself a task to make a OO design for a game of chess.This is not a homework q just trying to develop some skills.
Here is the summary of what i have in my mind till now:
A "Piece" class which will hold the current position of the piece on the board.
specialized classes "Camel" "Horse" "Queen" "Knight" "Pawn" & "Elephant" which will be derived from the "Piece" class. Each of these classes will hold 2 members, "no of places allowed to move" & "rule of moving" and get methods to retrieve the same.
A base "Player" Class which will be extended by classes "BlackPiecePlayer" & "WhitePiecePlayer". Each of these classes will hold another class instance called "PieceManager" The "PieceManager" class will be the one which will determine the logic of moving around the pieces on the Board.
A "ChessBoard" class which will hold the mapping of all the pieces on the board and have access to set of rules with which pieces can be moved. It will provide interfaces to authenticate a move calculated by "PieceManager" and then make the move while updating its own mappings.
Heres a generic flow that i can visualize. A class "WhitePiecePlayer" is asked to make a move, it will ask its own "WhitePieceManager" to make a move. The "WhitePieceManager" will access the positions of pieces on board by using interfaces of "Board" class. Then it will use its internal logic to calculate a move for an piece.Each piece stores its position so it calculates position for that piece. Then authenticates the move is possible by calling a method of the Board class and then makes the move by using Board class interface..and so on..
Sorry for the long story, I am just trying to develop a feel for the design and this is what i have in mind right now, Do you think its good for a start or any suggestions on how to make it better(if it is correct)
A few suggestions
Your hierarchy of piece related classes seems reasonable (though using the proper names for the pieces Knight, Rook, and Bishop would probably be preferable to Horse, Camel, and Elephant).
I would not store the number of squares a piece is allowed to move. You would want to encode that in the "rule of movement" method if only because that can change depending on the situation. A pawn can move two squares on its initial move and then one square in subsequent moves. A king can only move one square unless it is castling.
Your piece classes will need to have some sort of method to get a list of all a piece's valid moves in order to provide those to the engine that is going to choose a move.
You don't need BlackPiecePlayer and WhitePiecePlayer classes. You just need to instantiate two different instances of the Player class and ensure that there is a "color" attribute.
A ChessBoard class is a good idea and will need to represent the positions of the pieces but it should not implement logic evaluating moves. That is something for the move engine to do.
As Javier discusses, building a chess program is likely going to involve quite a bit of effort on the design of an efficient algorithm for choosing a move. Assuming that your intention is to apply OO concepts and not to delve into the discussions about how to build a chess engine (which will often sacrifice OO purity for better performance), and assuming that you want to build something that can play well enough to be interesting, you may want to consider implementing antichess rather than regular chess. From an OO standpoint, it is essentially an identical problem, but the end result is something that plays reasonably well without investing hundreds of hours in mastering chess algorithms. That's a much more enjoyable outcome than a chess program that plays terribly.
A few comments
1) The most important thing in a chess prgoram is the algorithm to choose a move. Usually it is an alpha-beta pruning algorithm. In order for this algorithm to be efficient, the way that pieces in the board are represented is very important. You can read that in this implementation issues section of wikipedia. I'd read that for the basis of board-piece representation. There is a lot of discussion in internet, and open engines like Crazy or Fruit. I doubt that they use OO, though - I do not know if there is any Object Oriented engine in the wild.
2) What are the camel, elephant, etc? What kind of chess are you trying to represent? I am not familiar with that, sorry. Is elephant the rook and camel the bishop?
3) What is the utility of having two different classes, WhitePlayer and BlackPlayer? In which way would they be different from Player? Shouldn't you have two different instances of a Player class, called white and black?
Good luck with your project. I hope you learn a lot from it! :)