I imagine there are plenty of programmers on EMC that either do it professionally or as a hobby. The purpose of this thread is just to be a place to share your thoughts, experiences, questions, advice, or anything else related to programming. I'll go ahead and start it off (I don't have an super formal experience yet so all of this comes from hobby programming. Feel free to correct me if wrong.) I have come to really enjoy languages like scala and rust as well as the functional way of doing things. If you haven't heard of them, I recommend checking them out. Scala is a lot Java but much more powerful and fun to code in. It runs on the jvm so you get all of those benefits (and downsides) while having what I think is a much better language. It adds a few things to the OOP side making it nicer while also fully embracing features normally found in functional languages. When I first came across things like the match statement, Options, and Try, I was amazed. Although Java 8 added some functional features, Scala still has it beat. It is also fully compatible with Java libraries and Java code allowing you to use either whenever it makes the most sense. Rust is more of a successor to C so it is made to be lower level and require little runtime. Although it is relatively young, it has plenty of support. Some of its benefits include having a really cool way of handling memory and thread safety, putting many functional programming concepts first, and just being a nicer language to use compared to something like C++. Having used both and experiencing the frustration caused by the incredibly uninformative "segmentation fault" error in c++, it is really nice knowing that code that could seg fault or do something super weird won't even compile. Like Scala, it features matching as well as immutable by default. Finally, a piece of advice for anyone using Java, Scala, C#, or some other similar language: Learn what passing an object as an argument actually does. Much time was wasted trying to figure out why 2 ArrayLists were magically mirroring the changes to each other. Try to predict what the following code will print: Code: import java.util.ArrayList; public class pointer{ public static void main(String[] args){ //Create two arrayLists ArrayList<Integer> a = new ArrayList<Integer>(); ArrayList<Integer> b = new ArrayList<Integer>(); b.add(3); //a is equal to b so both have 3 as the first element a = b; //Change the first element in b b.set(0, 5); //What do you think happens when you print out the sum of the first element in a and b? System.out.println(a.get(0) + b.get(0)); //Did you guess 8? You would be wrong. The answer is 10 because of pointers and the a=b line. } } As it turns out, these languages automatically put things on the heap for you when you create an object and simply have your variable represent a pointer to it. Passing that variable copies a pointer to your object, not the object itself. When you aren't expecting it, this can lead to some really weird and hard to debug behavior. If you want a longer explanation, look up "Does Java pass by reference or value."
This might sound like an odd one... but it's a question. Anyone know any thoughts of programming a dynamic weather system for a game in c#? I know; Some C# Some java Html and other web based languages Some pho Some binary Switch and router programming Windows and Linux OS programming And many more...
Is it using Unity? If you are more interested in having something and also have $60 to spend, https://www.assetstore.unity3d.com/en/#!/content/2714 looks really good. If you want to hand make it, it seems like you could pull it off using a state machine and some random numbers. For example, sunny state goes for x minutes before checking if a new one should happen. You have a y percent chance of precipitation being the next state. I imagine you would then need to either track the change in your shader code using some kind of uniform or switch out the current shader.
No it's cryengine. I did extensive research before and cryengine was the best as it's open source and no royalties and much more... I also have the newest version of unistorm if you want it.
Interesting thread.... Weighing in software design against software development would be my tip. And with software design I'm specifically referring to the use of one of the many so called modeling languages in order to document the inner workings and structure of your software project. So basically thinking and planning your project instead of just starting off coding away. I know plenty of programmers who feel that the source code itself should be considered both the end product as well as the roadmap which (other) people can use to get a grasp on what the software is doing. Some will even go as far as considering it a bit of a waste of time to try and design something while you could also be spending that time to do the actual coding, especially when dealing with (relatively) small(er) projects. Why not "design" and code at the same time? Or, to go even a little deeper, isn't using a specific design model already enough? Thing is... If you take the time to look at your projects design (and structure) it could easily help you to prepare for situations which may not be an issue right now, but which might become an issue ("problem") at a later time. Things you might not have thought about at first. Also: small projects can sometimes grow. Which is more than often a moment when design flags can surface, sometimes even requiring rewrites to cope with them. A very simplistic example.... Let's say you're working on a project which should check your server status. So roughly checking if all services are running, if there are no weird error messages and it should also check for any signs of potential problems (running out of disk space for example). While it maybe tempting to simply start coding, it could be a better idea to stop to think about the whole thing for a moment. Right now you're working with 1 server, but what to do if you'd be looking at 2 or more instead of one? Even if there's no way that you'd be getting a second server right now it might still be a good idea to keep the possibility in mind anyway and anticipate for this in your code accordingly. So in the event that you do get a server expansion you wouldn't need to rewrite your whole program (or large parts of it) because you already prepared for the possibility of such an expansion. As said, this is a very simplistic example but even so.... It wouldn't be the first time where a software project slowly but steadily grew in size, became more complex than people first anticipated which then resulted in scalability problems. Better put: design problems. Plenty of open source projects which started out somewhat small eventually reached a point where people started rewriting stuff from the ground up in order to overcome (design) flaws which eventually prevented them from building proper expansion. Another advantage is that by documenting ("graphing"?) a software project (or parts of it) you're also making a good start to get material which is useful for documentation purposes. What good is a program when no one understands how to use it? Doesn't matter if you're using on a huge project, or a small one: it can more than often be very refreshing to stop a moment and (try to) focus on the design instead of the development.
Taking a summer camp this week. I learned how to set-up a basic web-site using .html files.. Is that too basic for this thread? xD Really cool though. I've seen some of those codes when I was editing the wiki. Now it makes so much sense. Also, got my first experience with C# and .css files this week.
Yeah. I've been trying to do this, and it really does help. Because it has definitely happened that I was coding something and then, quite far into the project, thought something like "Wait. To implement this, I'll have to do some really diffuse or inefficient stuff. However, if I had written the base/core with this implementation in mind, I could've made it work much more fluently."
Ahahahah. My friend and I in our Minecraft mod like 6 times over. In all seriousness though, expect a bit of a big post about that and how Fishcat and I created a Minecraft mod that changes wolves to have genetics, all sorts of markings, even a different voice type, and some different AI... The possible combinations are virtually endless, as when I did the math, there were over several hundred thousand combinations. Teaser image though:
My "degree" was basically a primer in C++, Java, and VB (the fourth semester focused on SQL/database stuff, but it found no fertile soil in my cranial expanse). I cut my teeth on programming with BASIC, making text-adventures on an old laptop - the kind that weighs 20lbs and booted from 3.5" floppies - so VB was even less challenging than it might've been otherwise. Java, for whatever reason, wasn't any fun to work with. So while I have an understanding of different languages, C++/C# are the only ones I'm really any good with. Unfortunately, it seems like unless I'm actively working with programming, my knowledge quickly deteriorates. Still, I was really proud of myself when I worked out a save/load method using serialization in Unity (C#). ...Mostly I'm just taking this thread as a post-it note reminder that I need to get my butt back in Unity and resume work on my game(s). If for no other reason than to keep my C# claws sharp.
Many will tell you to plan and design your software before you start coding. But you can plan and design only if you have experience, if you know what you're doing. To get the experience you need to learn from others and experiment and practice yourself. Sometimes, you will write and test software just to get the complete and detailed requirements and just to see how to model it in a good way. And then rewrite it from scratch. Don't hesitate to code, but keep in mind - all the code you write before you (are able to) plan and design the software is just testing and experimenting. That code shall not enter the final product. An exception to that are generic functions that you have written in the process. After a review, they can be reused. What are the critical parts and aspects of the software - functional, structural, quantitative, qualitative? Solve the hardest parts first, make proofs of concepts. Use both top-down and bottom-up approach simultaneously. With each task, always analyze it so that you can identify its abstract structure and requirements. Solve the abstract problems, then apply this solutions to your concrete task. This will vastly improve quality of the solution, scalability, maintainability and re-usability. Choose suitable programming paradigms and stick to them. Try to be consistent and try not to repeat yourself. But don't overdo it in any way. Compare software development with architecture and civil engineering. One needs many years of study and practice to be able to produce high quality results.
We sort of split the development of this mod up into doing the jobs we felt we'd enjoy better and do better at: I wrote most of the code for the wolves' existence, their custom AI, and genetics. Slvr is, however, the one who designed the entire mod herself and told me what she wanted to see happen. She also drew all of those lovely textures herself and did most of the code regarding items. It is by no means a professionally made piece of software, and I am not a professional programmer. I've been told I have a knack for it, but honestly, I don't enjoy it much. However, I think the satisfaction of seeing this thing work and getting to play it in our worlds has been well worth the time I put into it. There are a few important things that differ in our mod from other, similar ones. After all, if we wanted to just play a “more wolves” type of mod, plenty already exist. First of all, with the exception of a few types, the wolves in our mod are based on dogs and wolves that can be found in the real world. Secondly, and most importantly, the wolves actually have individual variation within species, and can pass on a variety of traits to offspring using (mostly) Mendelian genetics. Cross-breeding between species (including vanilla Minecraft wolves) is allowed, making for even more variety. Some wild coyotes Cross between a German shepherd and an African wild dog Cross between a golden retriever and an island wolf So, I guess if there's any advice I can give others, it would first be to just go ahead and write what you want to write. You will actually learn a lot more than you thought from it. Basically, the only formal education in programming I got was two semesters of Java class in high school. Before I made this mod, I was making tiny, silly little mods that went nowhere, often due to lack of design because I just wanted to play around and see if I could write whatever. However, I learned more from that than from both of those semesters combined. That's not to say that school is worthless. It certainly did let me get started, but experience is important as well. Also, as a tip in programming in general, I would suggest that you always think about how the different parts of your program are going to work and interact when going to design or implement something, to understand potential glitches and improve it in general. In our mod, for example, our wolves have 2 copies of each trait, one expressed and one hidden. These traits all get assigned on the server, which does all the actual work on them, but your client is completely blind to them. That's an issue, because the client is what will show you what the wolves look like based on the traits! So, you could tell the server to send all those values to the client. Fixed. But when you think about it, that's a lot of useless data to send, if the client's job is just to show you the expressed traits and not to do any real work with them. For this reason, only the expressed traits need to be sent to the client, for use in rendering them on the wolf.
